16

UML SysML и пр. / Re: Что за символ UML 2 - объединине?

« : 21 Декабря 2011, 05:54:18 »

Именно мерг. Спасибо.

17

Примеры / Re: Пример описания поведения UI. Прошу мнений

« : 21 Декабря 2011, 05:50:01 »

Мерг по начертанию идентичен ветвлению?

18

Примеры / Re: Вопросы о диаграмме деятельностей

« : 21 Декабря 2011, 05:46:49 »

Вероятно, еще разделитель.

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

19

Примеры / Re: Вопросы о диаграмме деятельностей

« : 21 Декабря 2011, 05:41:10 »

Или, по крайней мере, без кнопки и табло.
А то из диаграммы можно сделать вывод, что пользователь для получения результата выражения должен сорок раз на кнопку 'Расчет' нажать.

Зачем 40 раз запускать цикл? Но если нужны значения сорока выражений, то именно так. За один раз ровно одно выражение. Пусть длинное, но одно. А если не понятно, что это цикл, так и без табло будет тоже самое и надо исправлять именно изображение цикла. И без кнопки как она вообще получится, если алгоритм зашивается в кнопку? Причём, пользовательский интерфейс от алгоритма вроде отделён. Я пока не указал, будет ли калькулятор даже десятичным, или шестнадцатеричным. А может вообще вавилонская система будет. Это пока ни где не указано. Знак числа - это унарный -, а у меня предусмотрен только бинарный. Хотя, в принципе можно сделать и унарный на том же классе, что и запятая. А можно так: -4+68+2*4 записывать как
0
4
-
68
2
4
*
+
2*(-3+4) как
2
0
3
-
+
*
или как
2
4
3
-
*
. То есть знака числа нет, он может быть не введён и это не помешает использовать отрицательные числа.

20

Примеры / Re: Вопросы о диаграмме деятельностей

« : 20 Декабря 2011, 16:09:25 »

Я и делаю наоборот. Нотация математического выражения - это не реализация, а часть постановки. Задача: разработать калькулятор, поддерживающий длинные выражения с бинарными операторами: +, -, *, / (разделить), в постфиксной нотации, в которой операторы не имеют приоритетов, указываются после своих операндов, а порядок их исполнения определяется порядком их следования в выражении, при вычислении значения такого выражения возвращаться по выражению назад нельзя, но одним, или обоими операндами могут быть результаты предшествующих операций, выражение просматривается вперёд, пока не встретится оператор, при этом каждый встреченный операнд помещается в стек, а как только встретился оператор, из стека извлекаются последние элементы в количестве операндов данного оператора, после чего он выполняется над извлечённыи данными и его результат помещается в стек. Это постановка задачи. Разумеется, все её особенности оказались в модели. Реализацией же я пока не занимался вообще. И на чём будут реализованы очередь и стек - пока ни закорючки. Скорее всего это будут динамические массивы, а не списки, но в модели этого пока нет.

21

Примеры / Re: Вопросы о диаграмме деятельностей

« : 20 Декабря 2011, 14:28:28 »

Для того, чтоб постфиксное выражение посчитать без стека и очереди, придётся его транслировать в другую форму. Для того, чтоб инфиксное выражение посчитать без рекурсии и без даже неявного древовидного представления, его надо транслировать в другую форму.

22

Примеры / Re: Вопросы о диаграмме деятельностей

« : 20 Декабря 2011, 14:24:39 »

Говоря про нарушение стиля ООП я имел в виду один из основных принципов: отделение представления от модели.

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

23

Примеры / Re: Вопросы о диаграмме деятельностей

« : 20 Декабря 2011, 10:41:51 »

Вопрос зачем? Ответ повторность использования, модифицируемость. Опять же реализуется принцип ООП: открытость для расширения, закрытость для модификации....

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

24

Примеры / Re: Вопросы о диаграмме деятельностей

« : 20 Декабря 2011, 10:32:07 »

Кнопка - интерфейсный элемент, Табло тоже. Цель кнопки - получить команду извне(среагировать на событие) и передать его дальше. Кому? ну некому обработчику, который знает куда ее передать.

Согласен, но у меня обработчик зашит в метод. Или это тоже ошибка? Например, в метод "+ void Нажать()" класса "цифровая кнопка" зашит вызов "Табло::+ void Добавить(n:char)", причём, этот вызов - действие внутри метода, а "-char n" - атрибут класса "цифровая кнопка". Это зашито в метод. У запятой в методе уже два действия, второе - вызов операции блокирования самой кнопки, а та операция уже пишет атрибут "- bool Заблокировано", если он true, то в следующий раз операция "Нажать" уже не вызывается. Ну и так далее. Так что скорей уж пору поинтересоваться, не переборщил ли я с ООПом. Не будет ошибкой зашивание обработиков в методы? Мелкософтовый c++ позволяет из оконной процедуры (а именно она контролирует допустимость операций и централизует диспетчеризацию сообщений, предназначенных классу) вызвать что угодно, включая члены классов, лишь бы оно было доступно в глобальной области видимости + можно ключевым словом friend отменить все спецификаторы видимости одного класса в отношении конкретной функции, в том числе, оконной процедуры, а если и этого мало - friend ещё в одном классе и его спецификаторы тоже перестают распространяться на данную функцию. А так как пишу я именно на мелкософтовом c++, то реализовать такую модель могу, но сама оконная процедура формально не может быть членом класса.

25

Теория моделирования и нотации / Re: Теория и принципы моделирования

« : 20 Декабря 2011, 08:43:33 »

Модель должна упрощать реальность.

Упрощать, но не перевирать и в меру. Вот представь математическую модель релятивистского ускорителя (БАК, например). Если заложить ньютоновские формулы для ускоряемых частиц, то модель проще, но дальше от реальности и ускоритель вообще не сможет работать. Но кварки в бетоне стен туннеля того же ускорителя можно не моделировать.

26

Теория моделирования и нотации / Re: Теория и принципы моделирования

« : 20 Декабря 2011, 08:36:29 »

2. Каждая модель может быть представлена с различной степенью точности.

И как же интересно можно зафиксировать уровень детализации?

Модель есть объект, заменяющий другой объект, систему, процесс, или явления и адекватно воспроизводящий все важные с точки зрения цели моделирования свойства заменяемого объекта, системы, процесса, или явления.

Больше свойств воспроизведёшь - модель точнее, меньшее - наоборот. Те же свойства адекватнее воспроизведёшь - модель точнее, загрубишь - наоборот. Но модель то в любом случае можно менять, при этом меняются, добавляются, или убираются свойства.

3. Лучшие модели - те, что ближе к реальности.

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

4. Нельзя ограничиваться созданием только одной модели. Наилучший способ при разработке любой нетривиальной системы - использовать совокупность нескольких моделей, почти независимых друг от друга

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

27

Теория моделирования и нотации / Re: Теория и принципы моделирования

« : 20 Декабря 2011, 08:19:50 »

1. Выбор модели оказывает определяющее влияние на подход к решению проблемы и на то, как будет выглядеть это решение.

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

28

UML SysML и пр. / Re: Что за символ UML 2 - объединине?

« : 20 Декабря 2011, 08:00:07 »

Дайте, пожалуйста, один сюда. И как нибудь выделите сам символ.

29

Примеры / Re: Вопросы о диаграмме деятельностей

« : 20 Декабря 2011, 07:49:59 »

И решает каждый класс свою подзадачу: набор цифры, набор запятой, помещение операнда в очередь, помещение символа операции в очередь и рассчёт. Это калькулятор такой для длинных постфиксных выражений.

30

Примеры / Re: Вопросы о диаграмме деятельностей

« : 19 Декабря 2011, 15:01:34 »

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