Автор Тема: web семенары  (Прочитано 251282 раз)

alexus

  • Гость
Re: web семенары
« Ответ #90 : Август 10, 2012, 07:09:14 pm »
1. Вы пишете, что внутри системы слабые связи.
Какие же они слабые? Исходя из определения системы, разрыв любой связи прекращает существование данной системы (но, возможно, создаёт другую).
Термин "слабые связи" - это из теории систем, туда он видимо попал из физики. "Слабые связи" - это связи, которые устанавливает система между своими элементами, по мере необходимости, система может перестраивать слабые связи. "Сильные связи" - это связи, благодаря которым образуются элементы системы, то есть связи внутри элемента. Если же из системы спустится в один из элементов, то внутри элемента, "сильные связи" будут снова называться "слабыми связями", а связи, которые образуют субэлементы будут называться "сильными", и т.д. Это только принятая терминология.

2. Получилось, что на каждый этап по две таблицы в БД?
В простом случае - да. Но таких простых случаев в природе нет. Возьмите те же ресурсы, они имеют какие-то характеристики, характеристики измеряются в каких-то единицах (иногда разных, как ГСМ, к примеру, в килограммах/тоннах и литрах). Но пока все эти детали неважны. Позже можно вернуться к каждой сущности и рассмотреть её подробнее, пока же мы говорим на концептуальном уровне, делая проекцию на реляционную БД.
Сами же сущности, да, представляются двумя таблицами на каждом этапе. Желательно, просто заполнить эти таблицы простыми данными и подумать над тем, что же получилось.

3. Три этапа пронумерованы.
Но они являются чёткими блоками. Может, у них есть свои имена?
Я не давал им имён, назовите сами, так как считаете нужным.

Связаны ли этапы с уровнями системы. Чтобы их можно было как-то соотносить.
По-моему связаны, но не упорядочены.
Нет, никак не связаны. Эту модель можно использовать на каждом уровне. Например, с её помощью можно описать производство, где с операции (элемента) на операцию передаются ресурсы (полуфабрикаты), но можно и описать макроэкономический уровень, где ресурсы (продукция) передаются от предприятия к предприятию. Все логические построения останутся справедливыми для любого уровня.
« Последнее редактирование: Август 10, 2012, 07:11:23 pm от alexus »

Влад Жаринов

  • Full Member
  • ***
  • Сообщений: 189
    • Просмотр профиля
Re: Системы: средства и цели
« Ответ #91 : Август 11, 2012, 01:02:19 pm »
...
Здесь приводилось описание "6 кружков" - это и есть язык. Смотрите. Система имеет элементы и связи (в модели: "подсистемы" и "ресурсы"). Отметьте, что элементы и связи есть в любой системе, то есть это структура системы. Эта структура должна быть выражена в языке (понятия (декларации) элементов и связей должны быть частью языка). Далее, добавление, удаление элементов - операторы языка моделирования системы; установление связи, переключение связи, удаление связи - это тоже операторы языка. И т.д. Можно взять для примера языки описания БД (близкие понятия - сущность (entity) и связь (relationship)).
Но мне бы в очередной раз хотелось вернуться к мысли, которую я уже неоднократно Вам высказывал: для описания систем вполне пригоден обычный разговорный язык, поскольку, если система построена на адекватной модели, то она всегда проста.
А, то, что мы с Вами обсуждали в личке по исчислению схем... и где-то близко к этому Кауфман, когда рассматривает задачу построения сетей - скажем, здесь на Обероне и ТП5.5: http://forum.oberoncore.ru/viewtopic.php?p=72006#p72006 ?..

Влад Жаринов

  • Full Member
  • ***
  • Сообщений: 189
    • Просмотр профиля
Re: Системы: средства и цели
« Ответ #92 : Август 11, 2012, 01:07:11 pm »
Я бы даже уточнил первый вопрос - я вот так понимаю Александра Сергеевича, что проектируем предприятие (орг[тех]систему), а программная система - результат "технологической реализации" выбранных частей (функций?) как киберсистемы, где между человеком и предметами/средствами/продуктами труда ставится (частично/иногда) "языковая машина", прогсистемой "настроенная на" определение/произведения языка предметной области?.. верно?..
Понятно, что обычное определение формального языка как "множества возможных цепочек символов в заданном алфавите" покрывает аспекты и определения языка, и свода произведений на нём... это я для уточнения своей мысли так подразделил...
После уточнения... я совсем перестал понимать вопрос... :) Можно, как-нибудь попроще изложить вопрос?
...
Т.е. программа - результат просто разделения функций между машиной (для которой реализуется язык представления делегированной ей части функций "для объекта" и "для человека") и человеком (для которого вместо прежнего языка реализуется новый - для оставшихся функций и для управления машиной)?..

Влад Жаринов

  • Full Member
  • ***
  • Сообщений: 189
    • Просмотр профиля
Re: Системы: средства и цели
« Ответ #93 : Август 11, 2012, 01:10:37 pm »
...
2) Вообще та или иная концепция товарно-денежных отношений, по-Вашему, влияет на семантическую модель предприятия?
О какой "концепции товарно-денежных отношений" Вы говорите? Всё, что я говорю: "предприятие является агентом товарно-денежных отношений", то есть, оно включено в товарно-денежный обмен наряду с другими предприятиями, частными потребителями, гос. органами и пр. Концепции товарно-денежных отношений не озвучивались, в частности потому, что мы не разбирали ещё, что такое "товар", и что такое "деньги" (на уровне смыслов этих понятий).
...
Как примеры концептуальных положений - считаем мы деньги эквивалентом труда или чем-то иным?.. допускаем кредит только под простой процент или и под сложный?.. ещё что-нибудь?.. может ли влиять на модель семантики или она всегда одинакова?

Влад Жаринов

  • Full Member
  • ***
  • Сообщений: 189
    • Просмотр профиля
Re: Системы: средства и цели
« Ответ #94 : Август 11, 2012, 01:28:29 pm »
...
Я не увидел в работе Кубанычбека описания/определения какой-то общей ситуации. ... Принципиальное различие "тогда" и "сейчас" состоит в том, что "тогда" было глубокое понимание (или стремление к пониманию) сути, а "сейчас" - желание быстро получить результат (неважно как). При чтении "Вступления" к книге Кубанычбека мне видится "сейчас", а хотелось бы "тогда".
...
Да, у меня тоже возникли сомнения... которые Вы и сформулировали... :) Возможно, сказанное здесь:
Цитата: Валерий Аджиев в http://www.osp.ru/os/1998/06/179592/
..., когда критерии качества не имеют столь высокого приоритета, как удобство пользования, простота освоения и дешевизна - и все это в сочетании с избыточной функциональностью, пожирающей компьютерные ресурсы, и отсутствием у производителя стимула выбрасывать на рынок действительно отлаженный продукт. Весьма взрывчатая смесь. В обозримом будущем мы можем оказаться свидетелями катастрофических ситуаций, в которые попадут пользователи массовых продуктов, и, похоже, что только это способно сдвинуть ситуацию с ее нынешнего печального положения.
- приближается и из-за т.о. направленных усилий?..
Кстати, что Вы думаете о его оценках разницы программно-управляемых реализаций и аппаратных:
Цитировать
Можно выделить и такой фактор, как переоценка уровня безопасности, в принципе гарантируемого программным обеспечением. Это послужило стимулом заменить используемые в предыдущих версиях системы защитные механизмы, которые контролировали радиационные потоки и блокировали их в случае выхода из нормального режима, с "аппаратных" блокираторов (на базе электронно-механических устройств) на чисто программные. ...

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

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

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

Влад Жаринов

  • Full Member
  • ***
  • Сообщений: 189
    • Просмотр профиля
Re: Системы: средства и цели
« Ответ #95 : Август 11, 2012, 01:32:31 pm »
...
3) В смысле сказанного здесь: http://forum.oberoncore.ru/viewtopic.php?p=52789#p52789 - можно считать, что [мета]язык "внешней схемы" - система предметных [подъ]языков? Которым и д.б. изоморфны языки того же класса "нейтральные"?
Не понял...
В смысле - что ЯВУ просто передают то же содержание, что и предметные языки (DSL) того же уровня - только не "разговорно", а для алгоритмически строгого исполнителя?.. Т.е. надо иметь две системы (иерархии) языков моделирования?..

alexus

  • Гость
Re: Системы: средства и цели
« Ответ #96 : Август 11, 2012, 06:49:20 pm »
Т.е. программа - результат просто разделения функций между машиной (для которой реализуется язык представления делегированной ей части функций "для объекта" и "для человека") и человеком (для которого вместо прежнего языка реализуется новый - для оставшихся функций и для управления машиной)?..
Да. Программа - это изложенный формально метод/способ решения задачи или нескольких взаимосвязных/однотипных задач. При этом не всегда/необязательно параметры решения задаются человеком. То есть, программа, как человеко-машинный интерфейс, - частный случай программы.

Цитата: Влад Жаринов
В смысле - что ЯВУ просто передают то же содержание, что и предметные языки (DSL) того же уровня - только не "разговорно", а для алгоритмически строгого исполнителя?.. Т.е. надо иметь две системы (иерархии) языков моделирования?..
Почему две иерархии? Причём здесь иерархии? Есть языки моделирования (часто неформальные), есть языки проектирования (более или менее формальные), есть языки программирования (формальные). Но эти языки не образуют иерархии, они просто отражают этапы жизненного цикла.

alexus

  • Гость
Re: Системы: средства и цели
« Ответ #97 : Август 11, 2012, 06:52:18 pm »
Как примеры концептуальных положений - считаем мы деньги эквивалентом труда или чем-то иным?.. допускаем кредит только под простой процент или и под сложный?.. ещё что-нибудь?.. может ли влиять на модель семантики или она всегда одинакова?
Деньги не являются эквивалентом труда, суть денег в другом. В экономике рассматриваются функции денег, но это всё второстепенное, не главное. Может быть мы дойдём до рассмотрения сути товаров и денег.

alexus

  • Гость
Re: Системы: средства и цели
« Ответ #98 : Август 11, 2012, 07:17:19 pm »
Возможно, сказанное здесь:
Цитата: Валерий Аджиев в http://www.osp.ru/os/1998/06/179592/
..., когда критерии качества не имеют столь высокого приоритета, как удобство пользования, простота освоения и дешевизна - и все это в сочетании с избыточной функциональностью, пожирающей компьютерные ресурсы, и отсутствием у производителя стимула выбрасывать на рынок действительно отлаженный продукт. Весьма взрывчатая смесь. В обозримом будущем мы можем оказаться свидетелями катастрофических ситуаций, в которые попадут пользователи массовых продуктов, и, похоже, что только это способно сдвинуть ситуацию с ее нынешнего печального положения.
- приближается и из-за т.о. направленных усилий?..
Есть такая категория людей, которые любят пугать разного рода "пророчествами". Серьёзно к ним относится нельзя. Ошибки допускаемые при написании программ не хуже и не лучше ошибок допускаемых при создании, например, инженерных сооружений. Ошибка - спутница любого творчества. Возможно, когда-то удастся полностью формализовать процесс кодирования, этого я не исключаю, но пока до этого далеко. Но избежать ошибок в проектировании, а тем более при моделировании... не удастся. Для того, чтобы не допускать таких ошибок или исправлять их нужен интеллект превосходящий человеческий (интеллект, в данном случае, это не только способности к логическим построениям).

Кстати, что Вы думаете о его оценках разницы программно-управляемых реализаций и аппаратных:
Цитировать
Бытует мнение, что стоимость программно-аппаратных систем обычно меньше, чем аналоговых или электромеханических, выполняющих ту же задачу. Однако, это миф, если, конечно, не говорить о "голом" hardware и однажды оплаченном ПО, сработанном "на коленке". Стоимость написания и сертификации действительно надежного ПО очень высока; к тому же необходимо принимать во внимание затраты на сопровождение - опять же такое, которое не подрывает надежности и безопасности. ...
Борьба с мифами путём порождения новых мифов. Сертифицируют и hardware, и software. Сказать, что из них дороже сертифицировать, не могу, поскольку далёк от этой области, но думаю, что затраты на сертификацию сопоставимы. А стоимость единицы продукта (как hard, так и soft) определяется по разному. Чтобы сделать ещё одну копию hardware нужно покупать "железо", электронные компоненты и пр. Чтобы сделать ещё одну копию software нужно просто скопировать файлы. В этом разница. Чем выше тираж, тем больше отрыв в дешевизне у софта.

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

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

Илья Ермаков

  • Sr. Member
  • ****
  • Сообщений: 493
    • Просмотр профиля
Re: Системы: средства и цели
« Ответ #99 : Август 12, 2012, 05:15:45 pm »
Борьба с мифами путём порождения новых мифов. Сертифицируют и hardware, и software. Сказать, что из них дороже сертифицировать, не могу, поскольку далёк от этой области, но думаю, что затраты на сертификацию сопоставимы.

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

albobin

  • Full Member
  • ***
  • Сообщений: 198
    • Просмотр профиля
Re: web семенары
« Ответ #100 : Август 12, 2012, 06:31:23 pm »
И критика от Лопатникова :)
http://sl-lopatnikov.livejournal.com/516958.html
У Лопатникова очень много допущений, натяжек и ошибок.
Ну, ёксель-моксель, что бы раньше предупредить. Ну, теперь, буду осторожнее.
Да, кстати, а у 'alexus'а  как с этим?

alexus

  • Гость
Re: Системы: средства и цели
« Ответ #101 : Август 12, 2012, 08:03:41 pm »
Борьба с мифами путём порождения новых мифов. Сертифицируют и hardware, и software. Сказать, что из них дороже сертифицировать, не могу, поскольку далёк от этой области, но думаю, что затраты на сертификацию сопоставимы.

Тем не менее, если говорить о нецифровом hardware (аналоговая электроника, а тем более механика), то не будете же Вы отрицать, что проанализировать и показать корректность непрерывной конструкции проще (не будем обсуждать сейчас, на сколько, но проще), чем дискретной? Если Вы знаете, что балка в диапазоне нагрузок от p1 до p2 ведёт себя по непрерывному закону (и уверены, что там нет "особых точек"), то вы испытываете её (математически или реально) при p1 и p2 - и получаете надёжность во всём диапазоне. С электроникой иногда сложнее - ибо "особых точек" в аналоговой системе там может оказаться неожиданно больше (типа самовозбуждения и т.п.), но всё-таки нет комбинаторного взрыва дискретных вариантов.
Отличие между случаем, когда тестирование может дать гарантии в определённом рабочем диапазоне параметров, или тем, когда тестирование вообще не даёт никаких гарантий - качественное отличие.
Можно, конечно, спорить с очевидным. Можно, но надо ли? Если бы с помощью механики делали то же самое, что делается с помощью электроники, и если бы с помощью электроники делали тоже самое, что делают с помощью программирования... то, вряд ли жизнь стала бы проще. Как бы интересно выглядел механический смартфон? Можно было бы его возить с собой на грузовой машине или только в железнодорожном составе? Был бы он конструктивно проще и надёжнее своего программно-электронного аналога, который легко помещается в кармане?

Valery Solovey

  • Hero Member
  • *****
  • Сообщений: 509
    • Просмотр профиля
Re: web семенары
« Ответ #102 : Август 15, 2012, 09:43:39 am »
В общем, я предлагаю, чтобы следующая тема была про производство.

adva

  • Sr. Member
  • ****
  • Сообщений: 385
    • Просмотр профиля
Re: web семенары
« Ответ #103 : Август 15, 2012, 02:43:15 pm »
И желательно заранее озвучить (дня за 2-3), не хотелось бы пропустить

Valery Solovey

  • Hero Member
  • *****
  • Сообщений: 509
    • Просмотр профиля
Re: web семенары
« Ответ #104 : Август 15, 2012, 03:06:44 pm »
Ну так прошлый раз тоже заранее было.

Тут проблема в другом: как бы снова именно ресурс не подкачал.

Зайти бы на этот гугл и минутку его потестировать в действии. Одному-то с этим проблематично...