Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: taras_aa от 17 Декабря 2011, 11:04:40
-
Требуется изобразить алгоритм, исполняемый совместно экземплярами нескольких разных классов. Один объект (назовём его b) вызывает операции стека и очереди, семантика этих операций заключается в добавлении и извлечении данных. Если данные добавляются, то объект b должен их передать в параметрах соответствующих операций. Если же данные извлекаются, то очередь и стек передают их объекту b в возвращаемых значениях операций. Причём, передаются значения типов sring и float. Как отразить на диаграмме передачу этих данных? Объект b также должен выполнять некоторые вычисления, а в конце должен присвоить значение типа string имеющему этот тип атрибуту ещё одного объекта, после чего происходит переход в конечное состояние. Как это отразить на диаграмме? Если моделируется поведение организации, то распределение работы по отделам и сотрудникам изображается дорожками. А правильно ли применять дорожки для отражения распределения работы по объектам-частям программы, или технического устройства?
-
Тарас, по правилам игры, Вы предлагаете свой вариант диаграммы, участники форума помогают его исправить.
По поводу вопроса: да , безусловно, правильно. На самом деле диаграммы деятельности могут быть трансформированы в диаграммы взаимодействия или конечных автоматов. Но - не старайтесь все изобразить на одной диаграмме - попробуйте использовать их в комплексе. Сюда по тому, что Вы написали -это очень подходит под диаграммы взаимодействия (uml-diagrams.org)
-
А правильно ли применять дорожки для отражения распределения работы по объектам-частям программы, или технического устройства?
Можно, конечно. Почему нельзя? (Тогда дорожки - устройства (классы), а действия - операции.)
Только нужно ли?
В такой ситуации гораздо лучше диаграммы последовательности.
-
А диаграммы взаимодействия - разве не собирательное название, включающее диаграммы деятельностей, последовательностей и коопераций? Мне надо показать не структуру, а именно порядок операций. Задача, решаемая проектируемой системой: есть очередь стек, табло и кнопка, в очереди валяется постфиксное математическое выражение, кнопка должна его посчитать и выдать на табло. При этом саму очередь надо очистить, данные можно сохранять в стек и в закрытые атрибуты кнопки. По поводу своей диаграммы: ну нарисую я. А если на столько не правильно, что будет вообще не понятно, что я имел ввиду? Потому и спрашиваю, как правильно обозначить передачу параметров и возврат значений.
-
Собирательное, и, тем не менее, они разные и используются для разного.
Именно поэтому в данном случае я стал бы рисовать последовательность.
Уважаемый Галоген дал Вам правильный совет: нарисуйте сами так, чтобы Вам самому было понятно. Обсудим.
А рисовать за Вас "поди туда, не знаю куда; принеси то, не знаю что ...", скорее всего, никто не станет.
-
А диаграммы взаимодействия - разве не собирательное название, включающее диаграммы деятельностей, последовательностей и коопераций?
UML2 - действующий стандарт UML (ссылку я вам давал в моем первом ответе). Диаграмма деятельности не входит в диаграммы взаимодействия (и никогда не входила). Диаграмма кооперации получила наименование диаграмма коммуникации. Все эти диаграммы, дополнительно диаграмма автомата, демонстрируют поведение системы или ее частей, хотя содержат и структурные элементы.
То, что вы пытаетесь до нас донести, нами понято сразу. Это типичный протокол взаимодействия. Чаще всего изображается диаграммой последовательности.
Объекты обмениваются сообщениями. Типы этих сообщений не слишком широки (http://umlmanual.ru/?page_id=32). На определенном уровне моделирования на линиях сообщений изображают операции классификатора объекта (при реализации это будут методы). Сигнатура операции стандартизована и описано в руководствах по UML (http://dit.isuct.ru/ivt/books/CASE/case11/ch18.htm#Heading7), При этом они мало отличаются от того, как это делается в типичных программных языках
-
И как это изобразить на диаграмме последовательностей? Я нарисовал свой вариант. Проверьте, пожалуйста.
-
То есть так.
-
Выделение не сбросилось. На самом деле так.
-
Исправил ещё одну стрелку.
-
Богато ты нарисовал. На ДП это изобразить просто. Рисуешь 4 объекта: кнопка, очередь, стек и табло. Для примера.
Судя по алгоритму извне приходит событие Кнопка.OnClick, и далее разворачивается реализация этого клика, т.е. последовательный вызов методов объектов очередь, стек, табло. Смотрим самый первый метод запросить состояние очереди, может выглядеть так: getQueueState.
В программном коде это может выглядеть
proc onclick(sender, aQueue);
begin
if aQueue.State then
begin
блабла
end
else
begin
aStek.getStek
end;
end
и т.д. имхо, только тут ООП не пахнет, налицо антипаттерн MagicButton
-
Там последовательным вызовом не пахнет, а не ООПом. У меня цикл, а не линейный алгоритм. И я немного передумал: char вместо одного стринга.
proc onclick(sender, aQueue);
var t:string;
begin
while aQueue.State do
begin
t:=aQueue.Type;
if t='float' then begin
x:=aQueue.GetFloat;
aSteck.Add(x);
end
else begin
c:=aQueue.GetChar;
x:=aStack.Get;
y:=aStack.Get;
aSteck.Add(x);
case c of
'+':begin r:=y+x;
aStack;
end;
'-':begin r:=y-x;
aStack.Add(r);
end;
'*':begin r:=y*x;
aStack.Add(r);
end;
'/':begin r:=y/x;
aStack.Add(r);
end;
end;
end;
end;
r:=aStack.Get;
tablo.caption:=FloatToStr(r);
end;
Где не ООП? Добавление/извлечение в стеке и очереди. Где последовательный вызов?
-
Точнее так:
proc onclick(sender, aQueue);
var t:string;
begin
while aQueue.State do
begin
t:=aQueue.Type;
if t='float' then begin
x:=aQueue.GetFloat;
aSteck.Add(x);
end
else begin
c:=aQueue.GetChar;
x:=aStack.Get;
y:=aStack.Get;
case c of
'+':begin r:=y+x;
aSteck.Add(r);
end;
'-':begin r:=y-x;
aStack.Add(r);
end;
'*':begin r:=y*x;
aStack.Add(r);
end;
'/':begin r:=y/x;
aStack.Add(r);
end;
end;
end;
end;
r:=aStack.Get;
tablo.caption:=FloatToStr(r);
end;
-
Galogen, не обижаешься, что я не согласился? Я ведь лучше знаю, чего хотел, а если на диаграмме совсем не то, значит она не правильно нарисована. Ну так за тем и тема, чтоб спросить, как правильно. И эта кнопка - только одна функция. Кроме неё там ещё 16 штук, 10 одного класса, 4 второго и две - каждая своего.
-
То есть это о кнопках. Их всего 17. 10 кнопок одного класса, 4 другого и три каждая своего.
-
И они реально разные. Каждый класс решает свою подзадачу. Один класс - набор цифр, второй - набор запятой, третий - ввод символа операции, четвёртый - запись операнда в очередь, пятый - вычисление всего выражения, сколько бы операций в нём не было. Такой вот постфиксный калькулятор, запоминающий много операций.
-
Я не обижаюсь. Ты меня не оскорблял, а то, что не согласен с чем-то, так это даже прекрасно.
Говоря про нарушение стиля ООП я имел в виду один из основных принципов: отделение представления от модели.
Кнопка - интерфейсный элемент, Табло тоже. Цель кнопки - получить команду извне(среагировать на событие) и передать его дальше. Кому? ну некому обработчику, который знает куда ее передать. Он - этот обработчик -подумает и вызовет или очередь или стек и т.п.
Вопрос зачем? Ответ повторность использования, модифицируемость. Опять же реализуется принцип ООП: открытость для расширения, закрытость для модификации....
-
И решает каждый класс свою подзадачу: набор цифры, набор запятой, помещение операнда в очередь, помещение символа операции в очередь и рассчёт. Это калькулятор такой для длинных постфиксных выражений.
-
Кнопка - интерфейсный элемент, Табло тоже. Цель кнопки - получить команду извне(среагировать на событие) и передать его дальше. Кому? ну некому обработчику, который знает куда ее передать.
Согласен, но у меня обработчик зашит в метод. Или это тоже ошибка? Например, в метод "+ void Нажать()" класса "цифровая кнопка" зашит вызов "Табло::+ void Добавить(n:char)", причём, этот вызов - действие внутри метода, а "-char n" - атрибут класса "цифровая кнопка". Это зашито в метод. У запятой в методе уже два действия, второе - вызов операции блокирования самой кнопки, а та операция уже пишет атрибут "- bool Заблокировано", если он true, то в следующий раз операция "Нажать" уже не вызывается. Ну и так далее. Так что скорей уж пору поинтересоваться, не переборщил ли я с ООПом. Не будет ошибкой зашивание обработиков в методы? Мелкософтовый c++ позволяет из оконной процедуры (а именно она контролирует допустимость операций и централизует диспетчеризацию сообщений, предназначенных классу) вызвать что угодно, включая члены классов, лишь бы оно было доступно в глобальной области видимости + можно ключевым словом friend отменить все спецификаторы видимости одного класса в отношении конкретной функции, в том числе, оконной процедуры, а если и этого мало - friend ещё в одном классе и его спецификаторы тоже перестают распространяться на данную функцию. А так как пишу я именно на мелкософтовом c++, то реализовать такую модель могу, но сама оконная процедура формально не может быть членом класса.
-
Вопрос зачем? Ответ повторность использования, модифицируемость. Опять же реализуется принцип ООП: открытость для расширения, закрытость для модификации....
Так ведь именно на классах основано повторное использование. Наследуем от класса и метод-обработчки тоже наследуется. А для не связанных классов он не имеет смысла. Да и доступ из него нужен к атрибутам объекта, а они могут быть закрыты. Одну оконную процедуру френдануть - не велико отступление, а все обработчики френдить=прощай инкапусляция. Да и обработчики по смыслу все общедоступные, их не проблема вызывать и без френда, только завернуть исходники блокируемых обработчиков в альтернативы, проверяющие допустимость операции, но уже на уровне реализации, а не модели.
-
Говоря про нарушение стиля ООП я имел в виду один из основных принципов: отделение представления от модели.
И где же у меня в кнопке хвосты от реализации стека и очереди? Если они ограничены, то могут в качестве внутреннего представления юзить массивы. А можно сделать списки. Очередь будет односвязной, а стек двусязным. А можно на динамических массивах. Можно вообще на файлах сделать. От модели системы в целом это представление как раз и отделено, выбор же самих интерфейсов очереди и стека вытекает из нотации. Не из нотации UML, конечно. А из нотации самих выражений, для которых этот калькулятор предназначен. Инфиксному нужно дерево, постфиксному - одновременно стек и очередь.
-
Для того, чтоб постфиксное выражение посчитать без стека и очереди, придётся его транслировать в другую форму. Для того, чтоб инфиксное выражение посчитать без рекурсии и без даже неявного древовидного представления, его надо транслировать в другую форму.
-
Тарас, объединяй посты. Чего флудишь
Вопрос о диаграмме деятельности выродился в детали реализации. Исходная ошибка - модель идет после реализации, нужно постараться научиться делать наоборот. Иначе диаграмма просто малополезна - код информативнее.
-
Я и делаю наоборот. Нотация математического выражения - это не реализация, а часть постановки. Задача: разработать калькулятор, поддерживающий длинные выражения с бинарными операторами: +, -, *, / (разделить), в постфиксной нотации, в которой операторы не имеют приоритетов, указываются после своих операндов, а порядок их исполнения определяется порядком их следования в выражении, при вычислении значения такого выражения возвращаться по выражению назад нельзя, но одним, или обоими операндами могут быть результаты предшествующих операций, выражение просматривается вперёд, пока не встретится оператор, при этом каждый встреченный операнд помещается в стек, а как только встретился оператор, из стека извлекаются последние элементы в количестве операндов данного оператора, после чего он выполняется над извлечённыи данными и его результат помещается в стек. Это постановка задачи. Разумеется, все её особенности оказались в модели. Реализацией же я пока не занимался вообще. И на чём будут реализованы очередь и стек - пока ни закорючки. Скорее всего это будут динамические массивы, а не списки, но в модели этого пока нет.
-
В любом случае необходимо отделить детали интерфейса от алгоритма.
Для начала можно нарисовать две диаграммы деятельности, не используя плавательные дорожки:
- 'Формирование постфиксного выражения'
(Ввод символа - их, видимо, три типа - цифра, запятая, знак. Вероятно, еще разделитель. Комбинация цифр и запятой составляет операнд. Операнды и знаки добавляются в очередь)
- 'Вычисление постфиксного выражения'
Примерно то, что на Вашей диаграмме, но без дорожек. Или, по крайней мере, без кнопки и табло. А то из диаграммы можно сделать вывод, что пользователь для получения результата выражения должен сорок раз на кнопку 'Расчет' нажать.
Можно еще отдельно - 'Проверка постфиксного выражения' - пригодится.
А действия пользователя с калькулятором изображать на отдельных диаграммах - если это потребуется.
-
Вот, рыбка приплыла, хвостиком махнула. и все сделала ясным и понятным:)
-
Или, по крайней мере, без кнопки и табло.
А то из диаграммы можно сделать вывод, что пользователь для получения результата выражения должен сорок раз на кнопку 'Расчет' нажать.
Зачем 40 раз запускать цикл? Но если нужны значения сорока выражений, то именно так. За один раз ровно одно выражение. Пусть длинное, но одно. А если не понятно, что это цикл, так и без табло будет тоже самое и надо исправлять именно изображение цикла. И без кнопки как она вообще получится, если алгоритм зашивается в кнопку? Причём, пользовательский интерфейс от алгоритма вроде отделён. Я пока не указал, будет ли калькулятор даже десятичным, или шестнадцатеричным. А может вообще вавилонская система будет. Это пока ни где не указано. Знак числа - это унарный -, а у меня предусмотрен только бинарный. Хотя, в принципе можно сделать и унарный на том же классе, что и запятая. А можно так: -4+68+2*4 записывать как
0
4
-
68
2
4
*
+
2*(-3+4) как
2
0
3
-
+
*
или как
2
4
3
-
*
. То есть знака числа нет, он может быть не введён и это не помешает использовать отрицательные числа.
-
Вероятно, еще разделитель.
А вот разделителей быть не может, символы набираются на табло, а в том месте, где водоплавающим видится разделитель, должна быть нажата управляющая кнопка - кнопка помещения уже готового операнда целиком в очередь. Не в строку, а в очередь, следующий помещённый в очередь операнд будет уже другим элементом и отделяется безо всяких разделителей.
-
Я нарисовал новый вариант. Теперь вопросы:
1. Надо ли указать типы данных?
2. Надо ли указать их начальные значения?
3. Я не переврал нотацию обращения через объект к его атрибуту, или операции?
4. Можно ветвление делать сразу с одной ветви на 4, а слияние с 4-х в одну? Как это изображается?
-
Я нарисовал новый вариант. Теперь вопросы:
1. Надо ли указать типы данных?
2. Надо ли указать их начальные значения?
3. Я не переврал нотацию обращение через объект к его атрибуту, или операции?
ДД - по сути блок-схема. Блок-схема - суть визуализация алгоритма. Тебе судить самому правильно ли или не правильно, ты записал свой алгоритм. К синтаксису особых претензий нет
-
Сам я буду искать семантические ошибки, а сюда полез за проверкой нотации, в которой сам пока не могу быть уверен. И ДД - не блок-схема, а её наследник с отличающейся нотацией. Например, на БС слияние было просто стрелкой в линию, а не специальный символ. И Символы начального и конечного состояний другие. Для циклов, наоборот, был специальный символ, а параллельные потоки вообще не были предусмотрены. И ответьте, пожалуйста, на четвертый вопрос, касающийся упрощения диаграммы.
-
Зачем 40 раз запускать цикл? Но если нужны значения сорока выражений, то именно так.
Конечно, но на прежней диаграмме это выглядело так, словно это надо в процессе вычисления одного выражения. В последней версии все гораздо лучше.
без кнопки как она вообще получится, если алгоритм зашивается в кнопку?
Это не алгоритм зашивается в кнопку. Это вызов алгоритма зашивается в кнопку.
Примерно...
class CPostfixExpression
{
public:
//вычисление выражения
float calculate();
//проверка валидности выражения
bool validate();
//добавить символ
void addSymbol(char _c)
//другие методы...
private:
//очередь
string m_Queue[1000];
//стек
float m_Stack[1000];
}
//Очередь и стек, вероятно, будут реализованы как-то по-другому. Но работаем с ними только в методах CPostfixExpression.
CPostfixExpression myExp; //ну скажем, глобальная переменная
На кнопках
void CCalcButton::onClick()
{
myExp.calculate();
}
Как-то так...
-
У меня не вызов. У меня сам обработчик и есть операция класса, а не внешняя функция. Обработчик - это сам метод, а не метод его вызывает. Реально будет всё таки вызов обработчика, но оконной процедурой, а она в модель не входит, на уровне же модели обработчик вызывается пользователем.
class CPostfixExpression
{
public:
//вычисление выражения
float calculate();
//проверка валидности выражения
bool validate();
//добавить символ
void addSymbol(char _c)
//другие методы...
private:
//очередь
string m_Queue[1000];
//стек
float m_Stack[1000];
}
//Очередь и стек, вероятно, будут реализованы как-то по-другому. Но работаем с ними только в методах CPostfixExpression.
CPostfixExpression myExp; //ну скажем, глобальная переменная
На кнопках
void CCalcButton::onClick()
{
myExp.calculate();
}
Не так. Класса CPostfixExpression вообще нет. В принципе, задача системы понята как вычисление единственного выражения, но с остановками для чтения пользователем части промежуточных результатов, а после чтения каждого промежуточного результата продолжается ввод выражения и расчёт его следующей части. Если же надо вдруг начать не связанный расчёт, то резет системы к начальному состоянию, в предыдущем сеансе её функционирование завершается и начинается новый. Соответственно и myExp превращается в само приложение, а его атрибуты - в самостоятельные объекты. И приходим к тому, что кнопка - элемент самого выражения. Я не настаиваю на том, что это всегда так. Это в данном конкретном проекте так по-нерусски. Или так нельзя? И очередь не строк, а смешанная. И с дополнительной возможностью получить тип элемента без извлечения самого элемента.
-
И на диаграмме у меня не классы, а именно объекты. Вопрос: правильно ли писать "объект::атрибут" и "объект::Операция(параметры)"? И сколько всего может быть ветвей с одного ромба?
-
И на диаграмме у меня не классы, а именно объекты. Вопрос: правильно ли писать "объект::атрибут" и "объект::Операция(параметры)"? И сколько всего может быть ветвей с одного ромба?
А в чем проблема изображать так как у тебя или иначе? Диаграмма не код, главное, чтобы понимал читающий. Если диаграмма используется как основания для кодогенерации, тогда требуется некая однозначность воспринимаемая трансформатором.
Что касается второго вопроса
http://www.uml-diagrams.org/activity-diagrams-controls.html#decision-node - ссылка была дадена, что еще ты хочешь услышать?
Сколько хочешь столько и может. Просто следует понимать: не нарушай читабельность, карсоту и гармонию диаграммы.
-
Трансформатор - электрический девайс на подстанции, а это называется транслятор. И дело не в кодогенераторе, он как раз ещё может глянуть на соседнюю диаграмму и увидеть, что "стек" с маленькой буквы - объект. А вот человеку нужна однозначность, чтоб посмотрел и сразу прочитал, не листая на другую диаграмму, иначе теряется наглядность, а вместе с ней и всякий смысл рисовать диаграммы. Итак, какова точно нотация элемента объекта. Не вложенного класса
class A
{
public:
class B
{
...
};
...
}, не атрибута класса, а именно атрибута конкретного объекта.
-
Трансформатор - электрический девайс на подстанции, а это называется транслятор.
И к чему этот ликбез?
Итак, какова точно нотация элемента объекта... не атрибута класса, а именно атрибута конкретного объекта.
Я так понимаю это вопрос?
Я перефразирую ее примерно так:
Итак, какова точно нотация элемента строки...не столбца таблицы, а именно столбца конкретной строки.
1. для меня эта фраза звучит как абракадабра
2. что означает нотация (http://ru.wikipedia.org/wiki/%CD%EE%F2%E0%F6%E8%FF) элемента строки объекта? У каждого элемента свою нотация?
3. что такое нотация атрибута конкретного объекта?
Атрибут класса - это (все) множество значений (обычно конечное) определенного типа. В теориях БД этому сильно соответствует понятия домена. Все объекты одного класса имеют одинаковые атрибуты, но (необязательно) разные значения.
Так что "нотация" атрибута конкретного объекта, можно допустить, = "нотации" атрибута класса, к которому относится объект.
Может я что-то не понял в вопросе? Или это был не вопрос? Повтори, пожалуйста.
-
Для изображения ветвления рисуются две или более стрелки, выходящие из одной точки фокуса управления объекта. При этом соответствующие условия должны быть явно указаны рядом с каждой из стрелок в форме сторожевого условия. Как нетрудно представить, если условие записано в форме булевского выражения, то ветвление будет содержать только две ветви. В любом случае условия должны взаимно исключать одновременную передачу альтернативных сообщений.
taras_aa а не получается ли у Вас , что Вы сначала написали код, а теперь пытаетесь логику изложить?
А вот человеку нужна однозначность, чтоб посмотрел и сразу прочитал, не листая на другую диаграмму, иначе теряется наглядность,
А читающий проверяет Вашу диаграмму на предмет нотации и он знает UML? Или задача понять Ваш код, схематично?
С одной стороны, на начальных этапах проектирования, когда детали реализации деятельностей в проектируемой системе неизвестны, построение диаграммы деятельности начинают с выделения под-деятельностей, которые в совокупности образуют деятельность подсистем. В последующем, по мере разработки диаграмм классов и состояний, эти под-деятельности уточняются в виде отдельных вложенных диаграмм деятельности компонентов подсистем, какими выступают классы и объекты.
С другой стороны, отдельные участки рабочего процесса в существующей системе могут быть хорошо отлаженными, и у разработчиков может возникнуть желание сохранить этот механизм выполнения действий в проектируемой системе. Тогда строится диаграмма деятельности для этих участков, отражающая конкретные особенности выполнения действий с использованием дорожек и объектов. В последующем такая диаграмма вкладывается в более общие диаграммы деятельности для подсистемы и системы в целом, сохраняя свой уровень детализации.
Таким образом, процесс объектно-ориентированного анализа и проектирования сложных систем представляется как последовательность итераций нисходящей и восходящей разработки отдельных диаграмм, включая и диаграмму деятельности. Доминирование того или иного из направлений разработки определяется особенностями конкретного проекта и его новизной.
В заключение следует заметить, что диаграмма деятельности, так же как и другие виды канонических диаграмм, не содержит средств выбора оптимальных решений. При разработке сложных проектов проблема выбора оптимальных решений становится весьма актуальной. Рациональное расходование средств, затраченных на разработку и эксплуатацию системы, повышение ее производительности и надежности зачастую определяют конечный результат всего проекта. В такой ситуации можно рекомендовать использование дополнительных средств и методов, ориентированных на аналитико-имитационное исследование моделей системы на этапе разработки ее проекта.
В частности, при построении диаграмм деятельности сложных систем могут быть успешно использованы различные классы сетей Петри (классические, логико-алгебраические, стохастические, нечеткие и др.) и нейронных сетей. Применение этих формализмов позволяет не только получить оптимальную структуру поведения системы на ее модели, но и специфицировать целый ряд дополнительных характеристик системы, которые не могут быть представлены на диаграмме деятельности и других диаграммах UML.
-
И к чему это ликбез?Я так понимаю это вопрос?
Я перефразирую ее примерно так:
Итак, какова точно нотация элемента строки...не столбца таблицы, а именно столбца конкретной строки.
1. для меня эта фраза звучит как абракадабра
2. что означает нотация (http://ru.wikipedia.org/wiki/%CD%EE%F2%E0%F6%E8%FF) элемента строки объекта? У каждого элемента свою нотация?
3. что такое нотация атрибута конкретного объекта?
Атрибут класса - это (все) множество значений (обычно конечное) определенного типа. В теориях БД этому сильно соответствует понятия домена. Все объекты одного класса имеют одинаковые атрибуты, но (необязательно) разные значения.
Так что "нотация" атрибута конкретного объекта, можно допустить, = "нотации" атрибута класса, к которому относится объект. Может я что-то не понял в вопросе? Или это был не вопрос? Повтори, пожалуйста.
Элемент строки - ячейка, перепутать её с целым столбцом не возможно. При чём здесь схематичность - не понятно. Конечно, задача - понять. И надо исходить из знания языка, но если в UML принято одно, а у меня то же самое изображено совсем не так, то ни какой это не UML, такой нотации он не знает и должен будет листать всю модель в надежде понять сначала нотацию, а это сбивает с толку. Трансляторы всегда смотрели, где декларировано само имя, а уже там высняли, как. Прямоугольник же объекта имеет свой собственный код, отличный от кода прямоугольника класса. То есть для машины эти сущности абсолютно различны, как не перевирай нотацию при последующем использовании. А человеку надо, видя непосредственно данную конкретную диаграмму, опираться на свои знания, чтоб по памяти безо всякого листания определить, что именно изображено определённым символом, а не тратить время на поиск. Знания - информация в памяти, закреплённая многократным использованием, можешь считать их хранилище гигантским кешем. Аспекты же конкретной модели хранятся в обычной долговременной памяти, к тому же глючной. Поэтому и вспоминать, где видел такую же закорючку в данной модели долго, а знания извлечь в оперативу - быстро, и ошибиться в обозначениях на другом листе данной модели можно элементарно, а в знаниях можно быть хоть в какой то мере уверенным. И начинается не нужное листание и поиск. На те листы надо смотреть, когда нужны другие аспекты модели, изображённые там, иначе теряется наглядность, а с ней и смысл изображать что либо именно в виде диаграмм. Про стрелки из одной точки я знаю, но вопрос не в них, а в цикле. Вверх же стрелки не идут? Но и не одно отдельное итеративное сообщение. Жирные горизонтальные тоже известны, но у меня именно выбор ветви, а не разделение на параллельные нити. Нити исполняются одновременно и соответствуют потокам, но только истинно параллельным, а из ветвей исполняется только одна и не в момент времени, а вообще. Здесь два напитка. А если чай, кофе, квас и морс? Можно в один ромб сделать? Объекты надо подчеркнуть? Допустим. А после объекта как сослаться на его атрибут? Через двойное двоеточие? Через простое? Через точку? Через "->"? Как? И код я пока не писал.
-
Подчеркнуть пока не смог. Не подскажите, как это сделать?
-
Состояния могут быть разбиты на несколько параллельных состояний, запускаемых одновременно. На рисунке показан простой будильник, который может включать либо CD, либо радио и показывать либо текущее время, либо время сигнала.
И все-таки давайте по порядку, а то с утра как то не очень "переваривается".
Вам нужно в ветвлении нарисовать много стрелок?
Так нарисуйте
В точку ветвления может входить ровно один переход, а выходить - два или более. Для каждого исходящего перехода задается булевское выражение, которое вычисляется только один раз при входе в точку ветвления. Ни для каких двух исходящих переходов эти сторожевые условия не должны одновременно принимать значение "истина", иначе поток управления окажется неоднозначным. Но эти условия должны покрывать все возможные варианты, иначе поток остановится.
-
много букафф, не осилил...
Я все-таки никак не пойму цель топикстартера.
Есть язык UML, его стандрат доступен для изучения. Он имеет механизмы расширения. Это визуальный язык моделирования. Вопросы исполняемого кода UML изучаются в рамках инициативы MDA, например.
При чём здесь схематичность - не понятно.
А где я про схематичность написал?
-
Вам нужно в ветвлении нарисовать много стрелок?
Пять штук, одна входящая, остальные исходящие, а в другом ромбе наоборот.Так нарисуйте
А можно? Как? Есть язык UML, его стандрат доступен для изучения.
Ссылку можно?
-
Вообще, поисковые машины работаю релевантно :)
http://www.omg.org/spec/UML/
-
Documents Associated With UML Version 2.3 (http://www.omg.org/spec/UML/2.3/)
А можно? Как?
Вы в Visio рисуете ? Там нотация не проверяется. :)
И сами Visio Stencil and Template for UML 2.2 (http://softwarestencils.com/uml/)