OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Воскресенье, 17 Ноябрь, 2019 18:22

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 97 ]  На страницу Пред.  1, 2, 3, 4, 5  След.
Автор Сообщение
 Заголовок сообщения: Re: Языки системы и система языков
СообщениеДобавлено: Четверг, 21 Октябрь, 2010 23:39 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
alexus писал(а):
Талантливый инженер не обязан быть хорошим токарем. И не факт, что талантливый токарь станет хорошим инженером. А создание систем - это инженерная прерогатива...

Т.е. Вы подразумеваете, что аналитика выбрасывать из связки с заказчиком и программистом нельзя?
alexus писал(а):
Г. Буча, для примера, я бы и на порог не пустил...

Имеется в виду непригодность UML-методологии или объектность вообще (или по Бучу в частности, если это можно отделить) :) И какие подходы и соответствующие языки Вы видите взамен?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Языки системы и система языков
СообщениеДобавлено: Четверг, 21 Октябрь, 2010 23:56 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Драконограф писал(а):
alexus писал(а):
Талантливый инженер не обязан быть хорошим токарем. И не факт, что талантливый токарь станет хорошим инженером. А создание систем - это инженерная прерогатива...

Т.е. Вы подразумеваете, что аналитика выбрасывать из связки с заказчиком и программистом нельзя?
Как минимум, не надо этого делать...
Драконограф писал(а):
alexus писал(а):
Г. Буча, для примера, я бы и на порог не пустил...

Имеется в виду непригодность UML-методологии или объектность вообще (или по Бучу в частности, если это можно отделить) :) И какие подходы и соответствующие языки Вы видите взамен?
Я вижу непригодность Г. Буча... UML - это вообще что-то несуразное... Давайте вспомним историю... конец 80-х - начало 90-х. Никто Буча (и иже с ним) серьезно не воспринимал, ну, ездили они по конференциям в Америке и Европе, ну, размахивали руками с возгласами: "Давайте создадим единую методологию ООА и ООП!". Единой не получилось, получилась... объединенная... В одну кучу свалили все, что было под рукой, не слишком задумываясь над тем, насколько это совместимо, полезно... или просто нужно. А потом сели писать не менее несуразные книги. Я, когда Г. Буча читал, то удивлялся... то ли плакать, то ли смеяться над его перлами... То, что он пишет про системы... даже дилетантством не назовешь, откуда-то надергал каких-то мыслей и, совершенно не понимая того, о чем они... включил в книгу. Но и в ООП он разбирается примерно также... То у него дерево "состоит_из" (part_of) ствола, кроны, корней, цветов, то оно же у него "плод множественного наследования" (is_a) от тех же элементов, представленных какими-то "специальными" классами. Про методику проектирования... нет это, правда, смех сквозь слезы...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Языки системы и система языков
СообщениеДобавлено: Пятница, 22 Октябрь, 2010 01:23 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8196
Откуда: Троицк, Москва
alexus писал(а):
Info21 писал(а):
Что такое автор. :)
Тот, кто придумал и реализовал...
Вопрос-то был не кто, а что :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Языки системы и система языков
СообщениеДобавлено: Пятница, 22 Октябрь, 2010 01:47 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
alexus писал(а):
Я вижу непригодность Г. Буча... UML - это вообще что-то несуразное... Давайте вспомним историю... конец 80-х - начало 90-х. Никто Буча (и иже с ним) серьезно не воспринимал, ну, ездили они по конференциям в Америке и Европе, ну, размахивали руками с возгласами: "Давайте создадим единую методологию ООА и ООП!". Единой не получилось, получилась... объединенная... В одну кучу свалили все, что было под рукой, не слишком задумываясь над тем, насколько это совместимо, полезно... или просто нужно. А потом сели писать не менее несуразные книги.

Ну понятно... в общем по аналогичной схеме, что и предложения академика Сахарова о "конвергенции капитализма и социализма" (кстати, недавно уточнили, что это он предложил Хрущёву "кузькину мать" рвануть - в смысле 100-мегатонную водородную бомбу в 1961-м - а не сам персек до этого додумался)... на этом фоне невольно вспоминаешь китайцев, которые даже ракет не делали больно много, а выдавали за базы МБР другие объекты :) в общем нужно хорошо думать, прежде чем представления "своей" предметки переносить куда-то ещё...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Как создавать систему?
СообщениеДобавлено: Пятница, 22 Октябрь, 2010 01:50 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
alexus в viewtopic.php?p=52594#p52594 писал(а):
Поэтому, по моему мнению, одной из наиболее важных и интересных задач на современном этапе, является разработка системы языков: строгой концепции расширяемого множества языков для создания больших систем (более трех уровней).

А каковы Ваши соображения о природе языка для каждого уровня и ядре (с которого начинается расширение)?
Вообще Вы предполагаете, что параллельно для каждого уровня должны существовать язык спецификаций и язык программирования, или эти два назначения должны совмещаться в одном языке уровня?
alexus писал(а):
Было бы наивным предполагать, что сегодня можно без особых проблем создать систему, используя для каждого уровня наиболее пригодный/эффективный язык программирования. Не получится... Дело в том, что, не смотря на свои различия, языки должны иметь единую (хотелось бы сказать: семантическую/системную) основу. Однако современные языки разработаны не для создания систем, а для решения некоторого вполне определенного круга задач.

Хочется опять вспомнить Оккама и не умножать уровни и средства их реализации без необходимости. Можно ли понимать иерархию уровней создаваемой информатической системы (имеющей программируемые функции, хотя вообще-то необязательно - и просто оборудование тоже описывается на каком-то языке) следующим образом:
    * класс "нижний уровень" связан со средой исполнения, класс м.б. определён в стольки вариантах, сколько существенных вариаций сред встретилось пользователям данной концепции (разработчику систем);
    * класс "верхний уровень" связан с потребляющей системой (у Вас - "владельцем"), класс м.б. определён в стольки вариантах, сколько "профилей владельцев" практически потребовалось сформировать разработчику;
    * класс "промежуточный уровень" вводится изначально между нижним и верхним, по необходимости число промежуточных уровней, требующих отдельного определения, наращивается добавлением (между промежуточным и нижним, верхним и промежуточным, соседними промежуточными.
Смысл в том, чтобы определять три семейства языков (по одному для каждого класса, а не уровня) и при разработке очередной системы выбирать из уже существующих средств (вариантов реализации) каждого класса. Каково Ваше мнение?
Я тут опираюсь и на концепцию "трёх схем", изначально сформулированную применительно к информационному моделированию (данных; см. IDEF1X-определение в выдержке, вложенной в этом сообщении), но, по-видимому, приложимую и к алгоритмам и к исполнителям. Можно сопоставить верхнему уровню "схему для пользователя", нижнему - "схему для исполнителя (в частности, программно-аппаратной платформы)", промежуточному - "нейтральную схему".
Кстати, и Агафонов в следующем вложении в то же сообщение, по-моему, касался тех же вопросов...

alexus в viewtopic.php?p=52599#p52599 писал(а):
Речь шла не о "свободе от состояний"... а о том, что анализ состояний отдельная, порой, очень не простая задача. При относительно небольшом количестве элементов, можно использовать "конечные автоматы", но при большом (тем более, произвольно большом) числе элементов и их возможных состояний... задача выбора/принятия (оптимального для данных условий) решения... Не легко это. В свое время (лет 15 назад) для подобных задач я пользовался Прологом.

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


alexus в viewtopic.php?p=52621#p52621 писал(а):
Интерфейс с над-уровнем представляет собой некоторое множество операций/функций/деклараций, которые должен реализовать данный уровень. Интерфейс с нижележащим уровнем представляет из себя набор требований к операциям/функциям, которые необходимы данному уровню. Если разбираться более детально, то просматривая интерфейсы сверху-вниз можно увидеть логическую структуру системы (декомпозиция интерфейсов), где каждый уровень реализует вполне определенную часть логики системы. В таком случае, язык, принятый для данного уровня - это эффективное средство реализации/раскрытия этой логики (цели уровня). При этом, языки всех уровней подчиняются единым правилам. Об этом единстве всех языков и говорилось.
Возможно, это не так просто понять, поскольку сегодня языки программирования не имеют системной/объединяющей основы и не имеют привязки к конкретике задач (задаваемой интерфейсами).

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

alexus в viewtopic.php?p=52675#p52675 писал(а):
Проектирование системы начинается не с выбора языка, но с архитектуры системы. Глядя на Оберон, например, я бы не взялся "увидеть" систему, сделанную на его основе (тем более, учитывая, что разных(!) систем... более одной).

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Об интерфейсе "человек-машина"
СообщениеДобавлено: Пятница, 22 Октябрь, 2010 01:51 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
alexus писал(а):
Илья Ермаков писал(а):
Ну, они наверняка несколько раз попробовали, "пощупали" задачи, "нащупали" путь - и только потом совершили "создание интерфейса", уже в отрыве от задачи.
А что они пробовали? Не было ни самого интерфейса, ни задач, которые его используют... Даже "мыши" не было... Это родилось где-то внутри, а потом... были найдены формы.

Очевидно, пробовали новые формы взаимодействия человека с комплексом средств автоматизации... исходя и из эргономики.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 22 Октябрь, 2010 01:54 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Помнится, так это называлось в политэкономии социализма :)
alexus в viewtopic.php?p=52696#p52696 писал(а):
"Производство средств производства" при создании систем - это отдельная интересная тема... Ей, увы, почти не уделяют внимания (в данном случае речь идет не только о том, чем пользуются программисты).

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Конкретика подхода к разработке
СообщениеДобавлено: Пятница, 22 Октябрь, 2010 02:01 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
alexus в viewtopic.php?p=52774#p52774 писал(а):
Драконограф писал(а):
Т.е. Вы подразумеваете, что аналитика выбрасывать из связки с заказчиком и программистом нельзя?
Как минимум, не надо этого делать...

alexus писал(а):
Драконограф писал(а):
alexus писал(а):
Г. Буча, для примера, я бы и на порог не пустил...

Имеется в виду непригодность UML-методологии или объектность вообще (или по Бучу в частности, если это можно отделить) :) И какие подходы и соответствующие языки Вы видите взамен?
Я вижу непригодность Г. Буча... UML - это вообще что-то несуразное...
Я, когда Г. Буча читал, то удивлялся... то ли плакать, то ли смеяться над его перлами... То, что он пишет про системы... даже дилетантством не назовешь, откуда-то надергал каких-то мыслей и, совершенно не понимая того, о чем они... включил в книгу. Но и в ООП он разбирается примерно также... То у него дерево "состоит_из" (part_of) ствола, кроны, корней, цветов, то оно же у него "плод множественного наследования" (is_a) от тех же элементов, представленных какими-то "специальными" классами. Про методику проектирования... нет это, правда, смех сквозь слезы...


alexus в viewtopic.php?p=52703#p52703 писал(а):
С моей точки зрения, позитивным может быть подход, основанный на семантическом моделировании...

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Языки системы и система языков
СообщениеДобавлено: Пятница, 22 Октябрь, 2010 05:35 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Драконограф писал(а):
Ну понятно... в общем по аналогичной схеме, что и предложения академика Сахарова о "конвергенции капитализма и социализма"
Рад, что Вам понятно, правда, что Вам понятно... осталось непонятно (простите за (сознательную) тавтологию). Если для Вас Вас Г. Буч (или кто-то из этой "обоймы") "свет в окошке", то прошу прощения... наступать "на любимую мозоль" я не имел намерения.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Об интерфейсе "человек-машина"
СообщениеДобавлено: Пятница, 22 Октябрь, 2010 06:48 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Драконограф писал(а):
Очевидно, пробовали новые формы взаимодействия человека с комплексом средств автоматизации... исходя и из эргономики.
Да, попробовали... но чтобы попробовать, надо было сначала сделать, а, чтобы сначала сделать, еще раньше надо было "увидеть" эти новые формы в своем сознании.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Как создавать систему?
СообщениеДобавлено: Пятница, 22 Октябрь, 2010 08:24 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Драконограф писал(а):
А каковы Ваши соображения о природе языка для каждого уровня и ядре (с которого начинается расширение)?
Вообще Вы предполагаете, что параллельно для каждого уровня должны существовать язык спецификаций и язык программирования, или эти два назначения должны совмещаться в одном языке уровня?
Совмещать их в одном языке - не слишком разумно (язык - не догма). Каждый уровень имеет свой интерфейс. Интерфейс описывается декларативным языком. Мало того, эти описания на разных уровнях имеют одну и ту же природу, и описания разных уровней образуют формальную декомпозицию (семантики) системы. Представление декомпозиции имеет большое значение для всех: для разработчиков (постановщиков задач, аналитиков, моделистов, проектировщиков, программистов, тестировщиков), для руководства и для заказчика/покупателя.
Драконограф писал(а):
Хочется опять вспомнить Оккама и не умножать уровни и средства их реализации без необходимости.
Хорошо, вспомните...
Драконограф писал(а):
Смысл в том, чтобы определять три семейства языков (по одному для каждого класса, а не уровня) и при разработке очередной системы выбирать из уже существующих средств (вариантов реализации) каждого класса. Каково Ваше мнение?
Я тут опираюсь и на концепцию "трёх схем", изначально сформулированную применительно к информационному моделированию (данных; см. IDEF1X-определение в выдержке, вложенной в этом сообщении), но, по-видимому, приложимую и к алгоритмам и к исполнителям. Можно сопоставить верхнему уровню "схему для пользователя", нижнему - "схему для исполнителя (в частности, программно-аппаратной платформы)", промежуточному - "нейтральную схему".
Кстати, и Агафонов в следующем вложении в то же сообщение, по-моему, касался тех же вопросов...
Языки не определяются произвольно... Задача унификации здесь не совсем уместна. Хорошо, давайте попробуем рассмотреть фрагмент системы. Раз уж здесь заговорили о графическом пользовательском интерфейсе... Очевидно, что любой графический интерфейс рисуется средствами графики (линиями, дугами и пр.). Тогда имеем нижний уровень: уровень графических примитивов. Задаем интерфейс этого уровня: нарисовать, изменить цвет/размер/положение... и т.п. Создаем некоторое множество графических примитивов (точки, полотна, прямые линии, дуги и т.д). Агрегируя эти примитивы, получаем (на том же уровне - интерфейс-то пока неизменен) фигуры: окружности, эллипсы, многоугольники, буквы (шрифты) и пр.). На каком языке лучше реализовать эту простую графику?.. С моей точки зрения, наиболее удобно здесь пользоваться императивными языками (Си, Паскаль, Оберон и т.п.). Можно напрямую использовать среду OpenCL, OpenGL, DirectX и т.п. А можно сделать... декларацию для нижнего уровня и потом портировать эту декларацию (фактически она задает функциональность некоторой библиотеки, которая, в свою очередь, перенаправляет запросы на рисование к конкретной среде). Если сменится среда (появится новая, например), то надо будет портировать эту же библиотеку на новую среду (согласовать заданный интерфейс с объектами, функциями и структурами новой среды). По этому уровню вопросы есть?..
Теперь займемся следующим уровнем: уровнем элементов управления. Интерфейс этого уровня принципиально отличается от предыдущего уровня, хотя элементы рисуются с помощью графики нижнего уровня. Элементы управления отвечают за взаимодействия с пользователем. Здесь не просто появляется понятие "состояние", но оно имеет несколько "проявлений" (доступен/недоступен, выбран/не выбран, в фокусе/не фокусе и т.д.). И основной задачей элементов - является получение и простейшая обработка пользовательского ввода. Описав существо интерфейса с данным уровнем, начнем его населять. Создадим кнопки, поля ввода текста, и т.п, на их основе создадим агрегатные элементы управления: выпадающие списки, комбобоксы, редактируемые таблицы, "деревья" и пр.
Перейдем еще на один уровень выше: на уровень форм и приложений. Задача формы/приложения: позволить пользователю осуществить некое цельное действие/выполнить работу, взаимодействуя с элементами управления на форме и формами в приложении. То есть, форма/приложение, в отличие от элементов управления, ориентированы на предметную область. И отслеживая состояния элементов/форм и действия пользователя, они должны контролировать соответствие логике (небольшой части) предметной области. И т.д.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Об интерфейсе "человек-машина"
СообщениеДобавлено: Пятница, 22 Октябрь, 2010 11:56 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8196
Откуда: Троицк, Москва
alexus писал(а):
еще раньше надо было "увидеть" эти новые формы в своем сознании.
"увидеть в сознании" -- двусмысленная фраза.
Ограничусь этой констатацией.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Как создавать систему?
СообщениеДобавлено: Пятница, 22 Октябрь, 2010 12:30 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
alexus писал(а):
...Тогда имеем нижний уровень...
Теперь займемся следующим уровнем...
Перейдем еще на один уровень выше...
И вот что примечательно: Вы ратуете за разработку сверху вниз, а систему почему-то описываете снизу вверх. Почему? Ведь для выбора средств конструирования нижнего уровня нужно знать какие именно из них больше всего подходят для удовлетворения нужд верхнего уровня. Можно ответить и в отдельной теме.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Об интерфейсе "человек-машина"
СообщениеДобавлено: Пятница, 22 Октябрь, 2010 19:36 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Драконограф писал(а):
Очевидно, пробовали новые формы взаимодействия человека с комплексом средств автоматизации... исходя и из эргономики.
Какие средства? Было время, когда "мыши" не было... Как можно было с ней попробовать работать, если ее еще нет? Очевидно, что она в каком-то виде появилась в чьем-то сознании. Оттуда перекочевало в замысел, из замысла в чертежи, из чертежей в опытное изделие... и только тогда попробовали.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 22 Октябрь, 2010 21:40 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Драконограф писал(а):
Мыслили об этом и "от практики", и задолго до нас... см. хотя бы материал в этом сообщении :)
Мыслили, конечно... от сотворения мира... Что касается ссылки, то это не слишком интересно. IDEF ничуть не лучше, чем UML... это все от тщетного желания понять целое (систему) через частности (бизнес-процессы или структуру). Любое предприятие гораздо легче строго(!) формализовать без применения этих средств и методов. Попробуйте, на досуге, верифицировать какой-нибудь бизнес-процесс... для примера. "Полезность" подобных описательных подходов станет вполне очевидной.
Драконограф писал(а):
А принцип "опережающего развития группы А", сформулированный всё в той же политэкономии, применительно к ИТ-сфере можно реализовать, не слишком превращая проекты в "подопытных кроликов", если найти и использовать оптимальную форму фиксации знаний о решённых задачах, облегчающую как их употребление в дальнейших решениях "как есть", так и вывод новых знаний.
Оптимальная форма только одна, та которая передает смысл/суть. Но именно, об этом я и говорил.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Как создавать систему?
СообщениеДобавлено: Пятница, 22 Октябрь, 2010 21:51 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Valery Solovey писал(а):
alexus писал(а):
...Тогда имеем нижний уровень...
Теперь займемся следующим уровнем...
Перейдем еще на один уровень выше...
И вот что примечательно: Вы ратуете за разработку сверху вниз, а систему почему-то описываете снизу вверх. Почему? Ведь для выбора средств конструирования нижнего уровня нужно знать какие именно из них больше всего подходят для удовлетворения нужд верхнего уровня. Можно ответить и в отдельной теме.
Если Вы не поленитесь посмотреть более ранние мои сообщения, то там сказано, что оба метода проектирования (сверху-вниз и снизу-вверх) не слишком хороши для разработки больших систем.
Те фрагменты, которые Вы цитируете, не определяют последовательность разработки, но представляют собой логику описания. Разработка каждого уровня может происходить параллельно. Элементу управления (его логике) как-то безразлично, какими алгоритмами рисуются линии, безразлично и то, какие линии рисуются. Точно так же, для формы важно, чтобы элемент управления выдавал правильное значение, а будет ли этот элемент представлен "списком" или "деревом"... на логику формы не влияет.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 23 Октябрь, 2010 02:57 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 144
Откуда: Россия, Питер
alexus писал(а):
Любое предприятие гораздо легче строго(!) формализовать без применения этих средств и методов.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 23 Октябрь, 2010 05:38 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
alexus писал(а):
Драконограф писал(а):
Мыслили об этом и "от практики", и задолго до нас... см. хотя бы материал в этом сообщении :)
Мыслили, конечно... от сотворения мира... Что касается ссылки, то это не слишком интересно. IDEF ничуть не лучше, чем UML... это все от тщетного желания понять целое (систему) через частности (бизнес-процессы или структуру). Любое предприятие гораздо легче строго(!) формализовать без применения этих средств и методов. Попробуйте, на досуге, верифицировать какой-нибудь бизнес-процесс... для примера. "Полезность" подобных описательных подходов станет вполне очевидной.
Драконограф писал(а):
А принцип "опережающего развития группы А", сформулированный всё в той же политэкономии, применительно к ИТ-сфере можно реализовать, не слишком превращая проекты в "подопытных кроликов", если найти и использовать оптимальную форму фиксации знаний о решённых задачах, облегчающую как их употребление в дальнейших решениях "как есть", так и вывод новых знаний.
Оптимальная форма только одна, та которая передает смысл/суть. Но именно, об этом я и говорил.

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


Последний раз редактировалось Владислав Жаринов Суббота, 23 Октябрь, 2010 05:57, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Как создавать систему?
СообщениеДобавлено: Суббота, 23 Октябрь, 2010 05:44 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
alexus писал(а):
Драконограф писал(а):
А каковы Ваши соображения о природе языка для каждого уровня и ядре (с которого начинается расширение)?
Вообще Вы предполагаете, что параллельно для каждого уровня должны существовать язык спецификаций и язык программирования, или эти два назначения должны совмещаться в одном языке уровня?
Совмещать их в одном языке - не слишком разумно (язык - не догма). Каждый уровень имеет свой интерфейс. Интерфейс описывается декларативным языком. Мало того, эти описания на разных уровнях имеют одну и ту же природу, и описания разных уровней образуют формальную декомпозицию (семантики) системы. Представление декомпозиции имеет большое значение для всех: для разработчиков (постановщиков задач, аналитиков, моделистов, проектировщиков, программистов, тестировщиков), для руководства и для заказчика/покупателя.
Драконограф писал(а):
Хочется опять вспомнить Оккама и не умножать уровни и средства их реализации без необходимости.
Хорошо, вспомните...
Драконограф писал(а):
Смысл в том, чтобы определять три семейства языков (по одному для каждого класса, а не уровня) и при разработке очередной системы выбирать из уже существующих средств (вариантов реализации) каждого класса. Каково Ваше мнение?
Я тут опираюсь и на концепцию "трёх схем", изначально сформулированную применительно к информационному моделированию (данных; см. IDEF1X-определение в выдержке, вложенной в этом сообщении), но, по-видимому, приложимую и к алгоритмам и к исполнителям. Можно сопоставить верхнему уровню "схему для пользователя", нижнему - "схему для исполнителя (в частности, программно-аппаратной платформы)", промежуточному - "нейтральную схему".
Кстати, и Агафонов в следующем вложении в то же сообщение, по-моему, касался тех же вопросов...
Языки не определяются произвольно... Задача унификации здесь не совсем уместна. Хорошо, давайте попробуем рассмотреть фрагмент системы. Раз уж здесь заговорили о графическом пользовательском интерфейсе... Очевидно, что любой графический интерфейс рисуется средствами графики (линиями, дугами и пр.). Тогда имеем нижний уровень: уровень графических примитивов. Задаем интерфейс этого уровня: нарисовать, изменить цвет/размер/положение... и т.п. Создаем некоторое множество графических примитивов (точки, полотна, прямые линии, дуги и т.д). Агрегируя эти примитивы, получаем (на том же уровне - интерфейс-то пока неизменен) фигуры: окружности, эллипсы, многоугольники, буквы (шрифты) и пр.). На каком языке лучше реализовать эту простую графику?.. С моей точки зрения, наиболее удобно здесь пользоваться императивными языками (Си, Паскаль, Оберон и т.п.). Можно напрямую использовать среду OpenCL, OpenGL, DirectX и т.п. А можно сделать... декларацию для нижнего уровня и потом портировать эту декларацию (фактически она задает функциональность некоторой библиотеки, которая, в свою очередь, перенаправляет запросы на рисование к конкретной среде). Если сменится среда (появится новая, например), то надо будет портировать эту же библиотеку на новую среду (согласовать заданный интерфейс с объектами, функциями и структурами новой среды). По этому уровню вопросы есть?..
Теперь займемся следующим уровнем: уровнем элементов управления. Интерфейс этого уровня принципиально отличается от предыдущего уровня, хотя элементы рисуются с помощью графики нижнего уровня. Элементы управления отвечают за взаимодействия с пользователем. Здесь не просто появляется понятие "состояние", но оно имеет несколько "проявлений" (доступен/недоступен, выбран/не выбран, в фокусе/не фокусе и т.д.). И основной задачей элементов - является получение и простейшая обработка пользовательского ввода. Описав существо интерфейса с данным уровнем, начнем его населять. Создадим кнопки, поля ввода текста, и т.п, на их основе создадим агрегатные элементы управления: выпадающие списки, комбобоксы, редактируемые таблицы, "деревья" и пр.
Перейдем еще на один уровень выше: на уровень форм и приложений. Задача формы/приложения: позволить пользователю осуществить некое цельное действие/выполнить работу, взаимодействуя с элементами управления на форме и формами в приложении. То есть, форма/приложение, в отличие от элементов управления, ориентированы на предметную область. И отслеживая состояния элементов/форм и действия пользователя, они должны контролировать соответствие логике (небольшой части) предметной области. И т.д.

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


Я ведь к чему всё это говорю... Вот смотрите. Материальный объект пространственно описывается, допустим, геометрическими фигурами из некоторого базового набора - точка, прямая линия, кривые (второго/третьего порядков, скажем), тела вращения. В математике все они имеют выражение; для информатической формализации можно задать алгоритмы их отрисовки, в т.ч. параметризованные. И комбинируя эти фигуры как примитивы (включая операции включения/исключения, пересечения и пр.), создать из них любое приближение к заданной форме.
Точно также понятия о системе выражаются на языке описания архитектуры - и при восхождении от уровня к уровню меняется как состав понятий (вводятся новые, опираясь в т.ч. на ранее введённые), так и какие-то возможности комбинировать. И если есть один прогязык, выражающий базовые понятия, которыми можно описать любой уровень - какова цель использования многих языков? А если его теоретически нет - то как у нас работают информашины (исполняя результаты разработки ПО по любой концепции на одном языке - своей системы команд)?
видимо, я рассуждаю о "лексиконе программирования"... только с другой стороны :)

Далее. Систему необходимо проверять расчётом. Для этого у нас сегодня появляются возможности, и даже автоматизированные - ввёл в среду проверки описание функционирования, задал требования к функционированию и анализируешь полученные результаты. И вот какая штука - язык-то для описания системы в среде почему-то один... Стало быть, все описания на всех уровневых языках надо на него перевести... и вот вопрос - а нужна ли такая кросс-работа?

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 23 Октябрь, 2010 08:48 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 746
Ильченко Эдуард писал(а):
alexus писал(а):
Любое предприятие гораздо легче строго(!) формализовать без применения этих средств и методов.

Не могли бы Вы уточнить, как именно можно легко и строго формализовать работу предприятия? Или дать ссылки.
Если это интересно, то можно сделать формализацию в другой теме. Не проблема.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 97 ]  На страницу Пред.  1, 2, 3, 4, 5  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB