1
Для всех / Re: а получили как всегда
« : 23 Декабря 2011, 13:36:31 »
Да нет, там ракета была, она и получилась, но не полетела из-за того, что американцы забыли украсть дефектную ведомость.
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Не такая уж и большая у Вас диаграмма. Однако, есть множество средств.ИМХО диаграмма может быть быть и не очень большой, но при этом очень запутанной.
Пакеты
Обобщение
Параметризация
В вашем случае наверное можно было бы сделать обобщенный абстрактный класс - Датчик
Вам нужно в ветвлении нарисовать много стрелок?Пять штук, одна входящая, остальные исходящие, а в другом ромбе наоборот.
Так нарисуйтеА можно? Как?
Есть язык UML, его стандрат доступен для изучения.Ссылку можно?
И к чему это ликбез?Я так понимаю это вопрос?Элемент строки - ячейка, перепутать её с целым столбцом не возможно. При чём здесь схематичность - не понятно. Конечно, задача - понять. И надо исходить из знания языка, но если в UML принято одно, а у меня то же самое изображено совсем не так, то ни какой это не UML, такой нотации он не знает и должен будет листать всю модель в надежде понять сначала нотацию, а это сбивает с толку. Трансляторы всегда смотрели, где декларировано само имя, а уже там высняли, как. Прямоугольник же объекта имеет свой собственный код, отличный от кода прямоугольника класса. То есть для машины эти сущности абсолютно различны, как не перевирай нотацию при последующем использовании. А человеку надо, видя непосредственно данную конкретную диаграмму, опираться на свои знания, чтоб по памяти безо всякого листания определить, что именно изображено определённым символом, а не тратить время на поиск. Знания - информация в памяти, закреплённая многократным использованием, можешь считать их хранилище гигантским кешем. Аспекты же конкретной модели хранятся в обычной долговременной памяти, к тому же глючной. Поэтому и вспоминать, где видел такую же закорючку в данной модели долго, а знания извлечь в оперативу - быстро, и ошибиться в обозначениях на другом листе данной модели можно элементарно, а в знаниях можно быть хоть в какой то мере уверенным. И начинается не нужное листание и поиск. На те листы надо смотреть, когда нужны другие аспекты модели, изображённые там, иначе теряется наглядность, а с ней и смысл изображать что либо именно в виде диаграмм. Про стрелки из одной точки я знаю, но вопрос не в них, а в цикле. Вверх же стрелки не идут? Но и не одно отдельное итеративное сообщение. Жирные горизонтальные тоже известны, но у меня именно выбор ветви, а не разделение на параллельные нити. Нити исполняются одновременно и соответствуют потокам, но только истинно параллельным, а из ветвей исполняется только одна и не в момент времени, а вообще. Здесь два напитка. А если чай, кофе, квас и морс? Можно в один ромб сделать? Объекты надо подчеркнуть? Допустим. А после объекта как сослаться на его атрибут? Через двойное двоеточие? Через простое? Через точку? Через "->"? Как? И код я пока не писал.
Я перефразирую ее примерно так:
Итак, какова точно нотация элемента строки...не столбца таблицы, а именно столбца конкретной строки.
1. для меня эта фраза звучит как абракадабра
2. что означает нотация элементастрокиобъекта? У каждого элемента свою нотация?
3. что такое нотация атрибута конкретного объекта?
Атрибут класса - это (все) множество значений (обычно конечное) определенного типа. В теориях БД этому сильно соответствует понятия домена. Все объекты одного класса имеют одинаковые атрибуты, но (необязательно) разные значения.
Так что "нотация" атрибута конкретного объекта, можно допустить, = "нотации" атрибута класса, к которому относится объект. Может я что-то не понял в вопросе? Или это был не вопрос? Повтори, пожалуйста.
class A
{
public:
class B
{
...
};
...
}
, не атрибута класса, а именно атрибута конкретного объекта.
class CPostfixExpressionНе так. Класса CPostfixExpression вообще нет. В принципе, задача системы понята как вычисление единственного выражения, но с остановками для чтения пользователем части промежуточных результатов, а после чтения каждого промежуточного результата продолжается ввод выражения и расчёт его следующей части. Если же надо вдруг начать не связанный расчёт, то резет системы к начальному состоянию, в предыдущем сеансе её функционирование завершается и начинается новый. Соответственно и myExp превращается в само приложение, а его атрибуты - в самостоятельные объекты. И приходим к тому, что кнопка - элемент самого выражения. Я не настаиваю на том, что это всегда так. Это в данном конкретном проекте так по-нерусски. Или так нельзя? И очередь не строк, а смешанная. И с дополнительной возможностью получить тип элемента без извлечения самого элемента.
{
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();
}