Форум Сообщества Аналитиков
Общий раздел => Теория моделирования и нотации => Тема начата: Keen_G от 27 Мая 2007, 22:33:41
-
У меня предложение обсудить в этой теме основные аспекты моделирования, поговорить о значении моделирования при разработе (проектировании если хотите) систем различного рода, решить для чего мы собственно строим модели и разобрать самые фундаментальные понятия.
Начну с основного определения:
Моделирование - формализация описания системы, т.е. построение модели.
Модель - это отображение реальной системы (оригинала), имеющее определенное объективное соответствие ей и позволяющее прогнозировать и исследовать ее функциональные характеристики, т.е. х-ки, определяющие взаимодействие системы с внешней средой
Модель - это искусственно создаваемый образ конкретного объекта, процесса или явления, в конечном счете любой системы.
(А.В. Антонов "Системный анализ")
Теперь предлагаю обсудить принципы моделирования, с которыми не очень согласен, из книги "Язык UML. Руководство пользователя" (Г.Буч, Д.Рамбо, И.Якобсон)
1. Выбор модели оказывает определяющее влияние на подход к решению проблемы и на то, как будет выглядеть это решение.
2. Каждая модель может быть представлена с различной степенью точности.
3. Лучшие модели - те, что ближе к реальности.
4. Нельзя ограничиваться созданием только одной модели. Наилучший способ при разработке любой нетривиальной системы - использовать совокупность нескольких моделей, почти независимых друг от друга
-
Сильно. И в чём состоит тезис? "это всё неправильно"? Так мы слона не продадим.
Может стоит тему поуже сформулировать, а не замахиваться сразу на "Уильяма нашего, на Шекспира"? )
-
Теперь предлагаю обсудить принципы моделирования, с которыми не очень согласен, из книги "Язык UML. Руководство пользователя" (Г.Буч, Д.Рамбо, И.Якобсон)
1. Выбор модели оказывает определяющее влияние на подход к решению проблемы и на то, как будет выглядеть это решение.
2. Каждая модель может быть представлена с различной степенью точности.
3. Лучшие модели - те, что ближе к реальности.
4. Нельзя ограничиваться созданием только одной модели. Наилучший способ при разработке любой нетривиальной системы - использовать совокупность нескольких моделей, почти независимых друг от друга
Предлагаю в данном случае исходить из практических задач, из-за которых Вам потребовалось подняться до анализа собственно теории моделирования и Вы обнаружили, что цитированные тезисы не подтверждаются Вашей практикой. Если же в процессе обсуждения Вы сможете показать, что методы решения задач (проблем) моделирования, с которыми Вы столкнулись, могут быть распространены на достаточно широкий класс задач, то решения этих проблем могут претендовать на масштаб теории моделирования. Причем с оговорками о рамках применимости этой теории.
Присоединяюсь к предложению уточнить, с чем именно Вы не согласны в приведенной цитате?
-
"Любое правило, любой принцип, любое условие можно и должно подвергать сомнению, поскольку они имеют ограниченную область действия...", я не помню кто это сказал :D
Ну меня, в общем, смущает немного 3й пункт...
3. Лучшие модели - те, что ближе к реальности.
Модель должна упрощать реальность. Это относится и к диаграммам, где гуру советуют не перегружать модели второстепенными элементами, из-за того что она станет визуально непонятной и сложной. И к тому же в качестве примера можно привести различные математические модели, которые бывает невозможно (по ряду причин: из-за недостаточной мощности компьютеров, развитие науки и тд), и зачастую даже ненужно уточнять, т.е. необходимо использовать определенную степень приближения. Конечно согласен, что чем подробней мы опишем систему, тем проще нам с ней будет работать в дальнейшем, но опять же точность модели зависит от поставленной задачи...
-
Модель должна упрощать реальность. Это относится и к диаграммам, где гуру советуют не перегружать модели второстепенными элементами, из-за того что она станет визуально непонятной и сложной. И к тому же в качестве примера можно привести различные математические модели, которые бывает невозможно (по ряду причин: из-за недостаточной мощности компьютеров, развитие науки и тд), и зачастую даже ненужно уточнять, т.е. необходимо использовать определенную степень приближения. Конечно согласен, что чем подробней мы опишем систему, тем проще нам с ней будет работать в дальнейшем, но опять же точность модели зависит от поставленной задачи...
А, ну так бы и говорили, что хотите обсудить правило максимальной адекватности модели моделируемому объекту.
Норберту Винеру приписывают слова, что "лучшей моделью кота является кот, а ещё лучше - тот самый кот".
Мне кажется, что всё-таки важно различать контекст моделирования как научного метода, и как промышленного метода.
В науке, как мы видим, систематически происходило уточнение моделей (Птолемей -> Коперник, Ньютон -> Эйнтшейна), которое сопровождалось новыми возможностями по использованию этих уточнённых моделей.
В науке правит бал беспредельное и чистое познание, не знающее преград. Цель учёного - создать как можно более точную модель, чтобы выявить новые, ранее не известные свойства объекта моделирования. Учёный ищет максимально точные, лучшие решения.
В индустрии центральное лицо - Инженер (для моделирования - инженер-исслдеователь). Его задача - поиск оптимальных моделей - т.е. максимально полезных в рамках имеющихся целей и ресурсов. Его примат - адекватность модели не только и не столько объекту моделирования, но и целям моделирования, т.е. прагматизм.
В механистических, редукционистских индустриальных подходах, таких как UML/ARIS/whatever... до последнего времени считалось, что если мы моделируем дискретную и/или реактивную систему, как это бывает в большей части современного типового бизнеса и соотв. ИС, то мы можем брать отдельные представления модели, такие как модель оргструктуры, модель бизнес-процессов, модель состояний и т.д. и они будут в достаточной мере адекватности отражать моделируемую систему.
Холистические, системные подходы же говорят, что важны не только отдельные проекции, но и эмерджентные свойства системы, такие как "социальный капитал", "душа компании" и т.д.
-
В механистических, редукционистских индустриальных подходах, таких как UML/ARIS/whatever... до последнего времени считалось, что если мы моделируем дискретную и/или реактивную систему, как это бывает в большей части современного типового бизнеса и соотв. ИС, то мы можем брать отдельные представления модели, такие как модель оргструктуры, модель бизнес-процессов, модель состояний и т.д. и они будут в достаточной мере адекватности отражать моделируемую систему.
Холистические, системные подходы же говорят, что важны не только отдельные проекции, но и эмерджентные свойства системы, такие как "социальный капитал", "душа компании" и т.д.
Отлично сказано, но... Мне, кажется , Денис ты тут переборщил.
Во-первых, не очень понимаю почему UML ARIS названы механистическими подходами. Для начала это языки описания, достаточно формализованные.
Во-вторых, холистический подход - очень красивое слово, когда системный уже не цепляет.
Моделирование столь же разнообразно, сколь и сложно.
Моделирование бывает разное. Моделирование суть инструмент. Использовать инстуремнт можно по-разному. Типичным являются два подхода: механистический от частного к целому, и системный от общего к частному. Тут естественны такие понятия как дедукция, индукция, абдукция.
Системность сама по себе предполагает эмерджетность, это одна из важных закономерностей системы.
Поэтому часто и подчеркивается, что система описывается совокупностью моделей
-
UML и ARIS походя названы мной "подходами" потому, что они, как и любой язык, опираются на парадигму мировосприятия, говорящую о том, что есть, что может быть, что важно, а что - нет. ARIS так явно позиционируется как методология (способ мышления о принцпах и методах моделирования), а не только язык и инструмент.
Почему именно "механицизм", цитирую:
...В более широком смысле механицизм есть метод «сведения» сложных явлений к их более простым составляющим, метод разложения целого на части, неспецифичные для данного целого (на биологические отношения, когда речь идёт о социальных явлениях, на физико-химические, когда речь идёт о биологии, и т. д.)...
...Для М. в целом как мировоззренческой установки характерно сведение сложного к простому, целого к сумме частей, отрицание качественно своеобразных законов у объектов с различным типом системной организации....
Именно это, имхо, и делают методологи моделирования Буч и Шеер - предлагают описывать целое как набор частей, не более.
То, что набор разноаспектных моделей далеко не всегда достоверно описывают систему, достаточно хорошо демонстрирует притча про 6-терых мудрецов и слона.
Да, слово "системный" порядком затаскано, без должного понимания употребляющими, которые зачастую под "системным" всё равно имеют в виду подход "аналитический, редукционистский".
Эд, скажи честно - где эмерджентность в классическом подходе 4+1?
-
Эд, скажи честно - где эмерджентность в классическом подходе 4+1?
Стоп, Ден, давай сначал определимся что такое классический подход 4 + 1. Подход типа RUP? Возможно я изнаю этот подход, но, вероятно, не под именем 4+1.
Далее возьмем это крассивое слово эмерджентность
emergence (http://ru.wikipedia.org/wiki/Эмерджентность) [I'mE:dZ(q)ns] n
1. 1) выход, появление; возникновение
emergence of seedlings - прорастание /появление/ всходов
the emergence of many new nations - возникновение многих новых государств
2) выход на поверхность
3) мор. всплытие, появление на поверхности
2. выявление, проявление
3. бот. эмергенцы
4. геол. прирост (суши); отрицательное движение уровня моря
Т.е. появление какого-либо свойства отсутствующего у частей.
Любое моделирование - есть суть анализ и синтез. Эмерджентность и является неким внезапным появление, что оно проявляется внезапно, т.е. это нечто нельзя вывести из простой суммы частей, составляющих систему, нельзя предсказать его. Можно предположить наличие такого свойства, можно оценить степень риска от его появления. Но нельзя точно знать, что оно есть, можно догадаться, но нельзя вывести математически.
Вот ты формируешь некую систему ИС. Отлично, конечно, ты сделаешь гигантскую ошибку, если будешь уделять внимания аппаратно-программным аспектам, и совсем мало другим: социальным, организационным и т.п. Вот тут я считаю и будет потерян твой холистический подход, системность решения.
Однако!!! Мы все-таки говорим о моделировании, а моделирование это процесс - процесс построения модели или ее совокупностей, и процесс изучения модели с определенной целью: целью управления, целью познания, целью описания, целью соглашения, целью унификации ....
Все средства моделирования типа UML IDEF ARIS - это описательные системы моделирования, знаковые, языковые, символьные - это не все виды моделирования - а довольно узкая его часть.
-
"Любое правило, любой принцип, любое условие можно и должно подвергать сомнению, поскольку они имеют ограниченную область действия...", я не помню кто это сказал :D
Ну меня, в общем, смущает немного 3й пункт...Модель должна упрощать реальность. Это относится и к диаграммам, где гуру советуют не перегружать модели второстепенными элементами, из-за того что она станет визуально непонятной и сложной. И к тому же в качестве примера можно привести различные математические модели, которые бывает невозможно (по ряду причин: из-за недостаточной мощности компьютеров, развитие науки и тд), и зачастую даже ненужно уточнять, т.е. необходимо использовать определенную степень приближения. Конечно согласен, что чем подробней мы опишем систему, тем проще нам с ней будет работать в дальнейшем, но опять же точность модели зависит от поставленной задачи...
Определить, является ли элемент важным или второстепенным невозможно вне контекста создания и использования модели. Как отметил выше Galogen - моделирование инструмент деятельности, но важно уточнить: инструментом оно является в контексте (деятельности) использования модели. В контексте создания модели сама модель является целевым объектом процесса создания модели. Мы можем либо верифицировать модель на соответствие правилам в процессе её создания, либо опытным путем - на соответствие целям Зазказчика модели в процессе её использования. Априорно определить второстепенные детали исходя из внутренней логики самой модели невозможно. Вне контекста можно обсуждать только наличие или отсутствие внутренних противоречий в самой модели с точки зрения внутренних правил самой модели.
Даже если рассматривать контексты научного моделирования и моделирования практический человеческой деятельности (бизнеса) сразу можно отметить отличия, связанные с разной природой сложности моделирования в этих контестах.
Контекст практической деятельности человека (бизнеса):
1. При моделировании человеческой деятельности мы пытаемся постигнуть логику бизнеса, которая была придумана человеком. Человеческая деятельность может носить системный характер и логика модели может быть распределенной по раличным професиональным специалиазациям. Но принципиально важно, что для устоявшихся относительно медленно изменяющихся процессов пытаться понять их логику гораздо менее рискованное занятие чем пытаться построить модель для решения научной проблемы. Применительно к практике моделирования (анализа) человеческой деятельности мы ограничены рамками интеллекта создателей (и пользователей) бизнеса. А как сказал герой одного фильма: «Что один человек собрал, другой завсегда разобрать сможет…». И это выгодно отличает с точки зрения возможностей моделирования человескую деятельность от природных процессов и явлений.
2. Субъективность целевых оснований человеческой деятельности (эмерджентность - её проявление) – наоборот, затрудняет моделирование человеческой деятельности, по сравнению с моделированием природы. Полет мысли некоторых Заказчиков существенно опережает возможности моделирования её результатов.
Контекст научного моделирования:
В практике же научного моделирования ученый пытается постигнуть логику (замысел) природы (Лейбниц: «Cum Deus calculat, fit mundus - Как Бог вычисляет, так мир и устроен»), разрешить парадоксы и проблемы, возникшие на границе (или за гранью :) разумной практики человека.
Ученый лишен возможность общаться с природой на природном человеческом языке (Галилей: «Природа разговаривает с нами на языке математики…»), еще меньше возможностей у ученого моделировать природу исходя из целей природного замысла.
Поэтому, и средства моделирования и критерии адекватности модели реальности (лучше – действительности) нужно выбирать с учетом специфики контекста. И при моделировании человеческой деятельности важно исходить из целей моделирования.
Если мы моделируем целенаправленную деятельность человека, то, как правило, он уже пользуется моделью, может быть даже несовершенной. То, что эта модель умопостижима означает, что существуют и достаточно понятные способы представления этой модели. Аппеляция к сложности природных явлений в данном случае неуместна. Если человек (Заказчик модели) осуществляющий моделируемую практику, не имеет о ней умопостижимого представления, то моделирование (из позиции аналитика) невозможно (возможно толко уже из позиции предпринимателя), а Заказчик под видом бизнеса занимается только имитацией разумной деятельности. А вот как из него (Заказчика, заинтересованного лица) эти представления вытащить – это другой разговор, для этого надо выбирать соответствующие средства. И правила рисования диаграмм (синтаксис языка моделирования и даже семантика моделируемой предметной области) – это только часть средств моделирования.
-
Стоп, Ден, давай сначал определимся что такое классический подход 4 + 1. Подход типа RUP? Возможно я изнаю этот подход, но, вероятно, не под именем 4+1.
Я имел в виду The 4+1 View Model of Architecture (http://www.google.com/search?q=4%2B1+view+model), хотя наверное не совсем прав, т.к. этот подход говорит об описании только архитектуры, а не всей системы, а Эмерджентность присуща системам, а не их архитектуре.
Все средства моделирования типа UML IDEF ARIS - это описательные системы моделирования, знаковые, языковые, символьные - это не все виды моделирования - а довольно узкая его часть.
Хорошо, узкая. А какая ещё часть есть?
-
Хорошо, узкая. А какая ещё часть есть?
Семиотика моделирования:
1. Синтаксис - правила конструирования систем знаков (сложных знаков - схем, дигаграмм) из простых.
2. Семантика - смысл и значение знаковых систем
3. Прагматика - практика, приемы и способы использования знаковых систем субъектами и сообществами.
Средства моделирования, как инструменты, включают 1 и 2. Объять прагматику моделирования в форме некоторого OTC продукта вряд ли вообще возможно. Тем не менее без прагматики построение модели невозможно.
-
Средства моделирования, как инструменты, включают 1 и 2. Объять прагматику моделирования в форме некоторого OTC продукта вряд ли вообще возможно. Тем не менее без прагматики построение модели невозможно.
Да, теперь понял. Правда, объём прагматики определяется сложностью и гибкостью языка, объёмом пространства моделирования. Если язык моделирования очень узок (например, Тетрис), то объём прагматики стремится к нулю.
Если говорить про UML, то его прагматика описывается в RUP и различной литературе, например у тех же Рамбо-Блаха и в материалах по образцам моделирования. Если говорить про ARIS как методологию, то его прагматика также излагается в соотв. литературе Шеера и прочих Логик Бизнеса.
Если возвращаться к теме дискуссии, то можно поставить вопрос так - позволяют ли Синтаксис, Семантика и Прагматика популярных методик моделирования в достаточной степени описывать существующие и создаваемые системы? Вредит ли избыточная детализация моделей? Если да, то как её избежать?
-
Если возвращаться к теме дискуссии, то можно поставить вопрос так - позволяют ли Синтаксис, Семантика и Прагматика популярных методик моделирования в достаточной степени описывать существующие и создаваемые системы? Вредит ли избыточная детализация моделей? Если да, то как её избежать?
Судя по тому, что OMG продолжает разрабатывать новые средства описания предметной области:
1. Business Motivation Model (BMM) Specification
2. Semantics of Business Vocabulary and Business Rules (SBVR)
то OMG не считает вопрос создания средств моделирования закрытым. Один замах, судя по названиям, чего стоит!
Если обсуждать достаточность существующих средств, то нужно бы уточнить:
1. "достаточная степень описания" - достаточная для чего?.
2. Какие качества существующих моделей (избыточноть?), которые мы связываем с используемыми средствами моделирования, нас решительно не удовлетворяют?
3. Что имеется в виду под избыточной детализацией моделей? Можно ли попытаться категориально проклассифицировать ситуации такой избыточности (чем вызвана, в частности, вызвана ли они именно средствами модлеирования, в чем проявляется)? Возможно, попробовать проиллюстрировать ситуацию такой избыточной детализации на примерах из тем данного форума ?
-
Хорошо, узкая. А какая ещё часть есть?
Ден! Когда я рассказываю студентам о моделировании, то я примерно так начинаю. Понятие модели и моделирования имеет очень широкую интерпретацию в зависимости от контекста. И это не противоречие. Модель и моделирование понятия многозначны. Причем последнее - скорее довольно однозначно - процесс создания модели и процесс изучения модели.
Действительно - модель платья - это в нашем ООП понимании скорее некий тип платья чем модель, но тоже называется моделью. 3D-модель - просто рисунок, а может и не просто. Ну и со фа...
Моделирование тоже бывает разных типов или видов:
Полное Неполное Приближенное
Детерминированное Стохастическое
Статическое Динамическое
Дискретное Дискретно-непрерывное Непрерывное
Мысленное: Наглядное, Символическое, Математическое
Реальное: Натурное, Физическое
Очевидно, что моделирование в нашем UML2 контексте :) будет
Детерминированное, Статическое или Динамическое, Дискретное (дискретно-непрерывное), Мысленное(Символическое и Математическое)
Но это если в полном объеме, т.е. включая структурные, информационные, имитационные, прототипирование=макетирование, языковое, знаковое.
Возможны даже натурные эксперименты при вводе системы в эксплуатацию, для определения расчетных нагрузкона сетевые соединения и т.п. Но только если рассматривать систему не только как программную ее часть, но и аппаратную, человеческую и другие.
Очевидно разные стороны системы по требуют разных моделей и разных типов(видов) моделирования.
-
Модель - это такая вещь, которая даёт обобщённое, упрощённое, иногда - идеализированное представление о чём-либо. Её ценность - только в том, что она упрощает понимание цели и структуры целого, а также поиск его частей. Сама по себе, в отрыве от реальности и исполнителей, она ценности не имеет. Если программистам удобнее без неё, чем с ней - значит, это плохая модель.
Не уверен, что имею опыт, позволяющий оспаривать классиков, но:
"4. Нельзя ограничиваться созданием только одной модели. Наилучший способ при разработке любой нетривиальной системы - использовать совокупность нескольких моделей, почти независимых друг от друга" - не согласен. Модели одной вещи всегда будут зависимы друг от друга. Понимание этой связи - IMHO основа системного подхода.
Бизнес-мотивация, "социальный капитал" и "душа компании"... Здорово, но я бы бюджета на построение таких моделей не дал. По-моему, самостоятельной ценности они не имеют. Записать всё нельзя. Не все вещи могут быть формализованы без искажения. А перечисленные вещи должны быть в голове у каждого менеджера, записывать это - всё равно, что записывать, с кем и почему дружишь.
-
Очевидно, что моделирование в нашем UML2 контексте :) будет
Детерминированное, Статическое или Динамическое, Дискретное (дискретно-непрерывное), Мысленное(Символическое и Математическое)
1. Не совсем понятно как связаны UML и математическое моделирование? (приведите пожалуйста пример).
2. А существует ли альтернатива UML? Для моделирования, например игрового сервера, бизнес процессов и включающая в себя математическое моделирование. Потому что, возвращаясь к теме конференции - что-то UML мне не "ICE" :) особенно не нравится большая привязанность UML к ООП. И вообще стоит ли искать альтернативу или продолжать изучение UML? потому как лучшего на сегодняшний день не существует.
-
И вообще стоит ли искать альтернативу или продолжать изучение UML?
Смотря для чего?
-
1. Не совсем понятно как связаны UML и математическое моделирование? (приведите пожалуйста пример).
Давно уже это писалось. И почему написалось именно так, не помню.
Тем не менее не вижу проблемы.
Математическое моделирование — процесс построения и изучения математических моделей
Математическая модель — это упрощенное описание реальности с помощью математических понятий.
UML как средство описание математической модели например.
UML как средство описание того, как математическая модель может быть реализована на компьютере, например.
-
Смотря для чего?
Например для моделирования игрового сервера и последующей его реализации. В котором присутствует большая БД игроков, типа "бойцовского клуба". Ну и так как я работаю инженером-программистом электронных изделий, применение полученных навыков моделирования в работе.
-
Например для моделирования игрового сервера и последующей его реализации. В котором присутствует большая БД игроков, типа "бойцовского клуба". Ну и так как я работаю инженером-программистом электронных изделий, применение полученных навыков моделирования в работе.
Если игровой сервер - это программная система или комплекс программных систем, то UML вполне подходит, поскольку он впитал в себя многие нотации и методы описания взаимодействия, структуры и поведения программных компонентов
-
1. Не совсем понятно как связаны UML и математическое моделирование? (приведите пожалуйста пример).
2. А существует ли альтернатива UML? Для моделирования, например игрового сервера, бизнес процессов и включающая в себя математическое моделирование. Потому что, возвращаясь к теме конференции - что-то UML мне не "ICE" :) особенно не нравится большая привязанность UML к ООП. И вообще стоит ли искать альтернативу или продолжать изучение UML? потому как лучшего на сегодняшний день не существует.
Сначала ставится задача, потом выполняется проектирование.
Чем проектировать - сугубо личное дело. Можно карандашом на бумажке нарисовать. Относитесь к этому проще, UML это лишь один из множества способов представления ваших концепций и возможных решений. Вас никто не ограничивает в использовании любых других инструментов или придумывании своих - которые будут удобны лично вам (если не стоит задача промышленной разработки).
Поэтому вопросы "а существует ли альтернатива.. для.." бессмысленны - любой инструмент хорош только на своем месте и тогда, когда умеешь им пользоваться.
-
1. Выбор модели оказывает определяющее влияние на подход к решению проблемы и на то, как будет выглядеть это решение.
Ну а как? Ты же не по самой предметной области будешь систему делать. Раз ты пользуешься моделью, то она тебе и заменяет саму задачу, а если нет, то ты её не используешь, так как модель по своему определению есть заменяющий объект, значит выбор модели определяет представление задачи, ну а представление задачи определяет подход к её решению. Это всё равно как выбор языка оказывает определяющее влияние на набор используемых при общении слов. А как иначе? Нельзя говорить по-русски английскими словами. Нельзя решать задачу математическими методами, выбрав в качестве модели макет, если только перед непосредственно решением не построить математическую модель уже макета (модель модели, видимо метамодель). Нельзя, выбрав модель в приращениях, принимать решения об управляющих воздействиях на печь в полных уровнях и наоборот.
-
2. Каждая модель может быть представлена с различной степенью точности.
И как же интересно можно зафиксировать уровень детализации? Модель есть объект, заменяющий другой объект, систему, процесс, или явления и адекватно воспроизводящий все важные с точки зрения цели моделирования свойства заменяемого объекта, системы, процесса, или явления.
Больше свойств воспроизведёшь - модель точнее, меньшее - наоборот. Те же свойства адекватнее воспроизведёшь - модель точнее, загрубишь - наоборот. Но модель то в любом случае можно менять, при этом меняются, добавляются, или убираются свойства.
3. Лучшие модели - те, что ближе к реальности.
А как ещё? Вот представь: делаешь ты текстовый редактор с поддержкой иврита, а твоя модель не учитывает, что евреи пишут с права налево. Не годна твоя модель и редактор будет без поддержки иврита, а если это единственные его язык, то вообще не получится и всё только из-за того, что модель далека от реальности. Или по-твоему лучше ничего не сделать и свалить вину на моделиста? 4. Нельзя ограничиваться созданием только одной модели. Наилучший способ при разработке любой нетривиальной системы - использовать совокупность нескольких моделей, почти независимых друг от друга
Вторая модель - это другие аспекты предметной области, которые ты мог пропустить при создании первой модели, но только в том случае, когда они не зависимы, иначе это просто две формы одной модели, возможно два уровня её детализации, но замыленный шараповский глаз (см "Место встречи изменить нельзя") так и не прочищен.
-
Модель должна упрощать реальность.
Упрощать, но не перевирать и в меру. Вот представь математическую модель релятивистского ускорителя (БАК, например). Если заложить ньютоновские формулы для ускоряемых частиц, то модель проще, но дальше от реальности и ускоритель вообще не сможет работать. Но кварки в бетоне стен туннеля того же ускорителя можно не моделировать.
-
Так и до чего договорились?
Уточняем принципы моделирования или ????
"Любое правило, любой принцип, любое условие можно и должно подвергать сомнению, поскольку они имеют ограниченную область действия..."
Как раз этот принцип входит в морфологический подход
В 1942 г. швейцарский астрофизик Ф.Цвикки обнародовал ряд методов, которыми рекомендовалось пользоваться при решении научных и технических задач. Сначала этих методов было семь, впоследствии Цвикки остановился на трех основных, сочтя остальные либо недостаточно эффективными, либо недостаточно самостоятельными. В их числе:
1) метод отрицания и конструирования (МОК);
2) метод систематического покрытия поля (МСПП);
3) метод морфологического ящика (ММЯ).
Совокупность методов Цвикки получила название "морфологический подход".
Есть также статья Принципы моделирования систем различной природы (http://www.uni-altai.ru/Journal/pedagog/pedagog_8/at24.html)
-
скажите пожалуйста, как лучше (правильно) описывать поведение кнопок в интерфейсе в варианте использования или в интерфейсе или дублировать?
-
скажите пожалуйста, как лучше (правильно) описывать поведение кнопок в интерфейсе в варианте использования или в интерфейсе или дублировать?
Описывать поведение кнопок в варианте использования категорические не рекомендуется. Поскольку ВИ - это требования, а требования диктуют то, ЧТО следует сделать, но не КАК.
Кнопки и их поведение вероятно следует описывать на стадии проектирования графического интерфейса, принимая во внимания стиль программной реализации, архитектурные принципы и другие требования, обычно нефункциональные.
-
Порция некротрединга.
скажите пожалуйста, как лучше (правильно) описывать поведение кнопок в интерфейсе в варианте использования или в интерфейсе или дублировать?
Если вариант использования имеет область действия "система как белый ящик" или "подсистема", то можно описывать поведение кнопок в нём. Если вариант использования имеет область действия "система как чёрный ящик" (как правило, те ВИ, которыми описывают требования, имеют эту область действия), то поведение кнопок (как и других составных частей системы) в нём описывать не следует.
Те варианты использования, который писал Айвар Якобсон, когда их изобретал, были "с кнопками", к слову сказать.
-
Он не Айвар, а Ивар
https://forvo.com/word/ivar_jacobson/
-
Я не раз предупреждало, что мой ксенолингвист барахлит (как и у многих переводчиков литературы на русский). Не удивляйтесь.
Радо возможному проявлению широкого взгляда на ВИ, допускающему для него более чем одну разновидность, т. е. не только "цель пользователя".
-
Те варианты использования, который писал Айвар Якобсон, когда их изобретал, были "с кнопками", к слову сказать.
Кстати, да. Позже я тоже об этом узнал где-то. Кстати, нет ли у вас в ксеноархивах, образчиков авторского стиля?
Про недопущение технических деталей в спецификации ВИ по-моему впервые и явно я прочитал у Коберна (которого тоже почему-то многие называют Кокберном).
-
В книге Коберна (впервые я о нём услышало через ксенолингвист как о Кобурне) есть и о недопустимости, есть и о полезности расширения описаний сведениями о GUI (см. 17.4). Заметим себе, что Коберн пишет о ВИ, как о способе описания функциональных требований. Отсюда, мне кажется, не следует делать вывод, что применение ВИ исчерпывается этим. Коберн увязывает наличие/отсутствие описания "кнопок" с уровнем цели ВИ. При разборе ошибок (см. 19), сведения о GUI вытираются из описаний ВИ с областью действия "система как ЧЯ" и целью "уровня моря". Можно конечно, ограничиться рассмотрением и написанием только таких ВИ, если стоит такая цель.
Про Джекобсона написало в личку.
-
В книге Коберна (впервые я о нём услышало через ксенолингвист как о Кобурне) есть и о недопустимости, есть и о полезности расширения описаний сведениями о GUI (см. 17.4). Заметим себе, что Коберн пишет о ВИ, как о способе описания функциональных требований. Отсюда, мне кажется, не следует делать вывод, что применение ВИ исчерпывается этим. Коберн увязывает наличие/отсутствие описания "кнопок" с уровнем цели ВИ. При разборе ошибок (см. 19), сведения о GUI вытираются из описаний ВИ с областью действия "система как ЧЯ" и целью "уровня моря". Можно конечно, ограничиться рассмотрением и написанием только таких ВИ, если стоит такая цель.
На самом деле интересный вопрос.
Я почему-то развивался в парадигме недопущения технических деталей при описания ВИ (да в стиле черного ящика),
и мне это всегда казалось вполне разумным.
-
Всё верно, если пишется ВИ ЧЯ+УМ. Т. к. такие ВИ пишутся часто, то есть повод не рассматривать другие ВИ.
-
Всё верно, если пишется ВИ ЧЯ+УМ. Т. к. такие ВИ пишутся часто, то есть повод не рассматривать другие ВИ.
Насчет описания белого ящика - это уже в терминах конкретной реализации, когда используется шаблон BCE - boundary control entity.
Или для описание бизнес-процессов.
Конечно, можно использовать нотацию UC для описания взаимодействия и низкоуровневых элементов. Но обычно используют другие средства UML.
Или я заблуждаюсь?
-
Вроде того (с поправкой, что речь идёт о текстовых описаниях, которые могут предшествовать UML-диаграммам и/или дополнять их).
Есть статья (https://www.scenarioplus.org.uk/papers/use_cases/use_cases.htm) 2002 года, не мейнстрим, но есть.