|
Модераторы: Poseidon |
|
||
|
xvr |
|
|||
Эксперт Профиль Группа: Комодератор Сообщений: 7046 Регистрация: 28.8.2007 Где: Дублин, Ирландия Репутация: нет Всего: 223 |
UML - см. http://www.omg.org/technology/documents/mo...pec_catalog.htm, так же можно посмотреть на INTSPEI |
|||
|
||||
archimed7592 |
|
|||
Архимед Профиль Группа: Завсегдатай Сообщений: 2531 Регистрация: 12.6.2004 Где: Moscow Репутация: нет Всего: 93 |
xvr, спасибо, я посмотрю .
-------------------- If you have an apple and I have an apple and we exchange apples then you and I will still each have one apple. But if you have an idea and I have an idea and we exchange these ideas, then each of us will have two ideas. © George Bernard Shaw |
|||
|
||||
Fire-Plug |
|
|||
Шустрый Профиль Группа: Участник Сообщений: 102 Регистрация: 15.3.2005 Репутация: нет Всего: 0 |
В случае "Reverse engineering", т.е. построения UML-диаграмм на основе имеющегося проекта, "текстом" являтся сам исходный код, точнее - объявления классов. В случае же прямого моделирования, Rational Rose сгенерит исходный код для визуально построенных классов. Сам же язык моделирования - графический. |
|||
|
||||
ida |
|
|||
замужем Профиль Группа: Завсегдатай Сообщений: 2275 Регистрация: 14.5.2002 Где: Санкт-Петербург Репутация: нет Всего: 60 |
Да... посмотрела на результаты голосования и опечалилась
Вроде и раздел профильный - С++ объектный язык. Проиллюстрировать мою печаль, пожалуй, лучше всего цитатой из Вигерса:
Это сообщение отредактировал(а) ida - 24.1.2009, 17:17 |
|||
|
||||
serg0s |
|
|||
Новичок Профиль Группа: Участник Сообщений: 1 Регистрация: 13.2.2009 Репутация: нет Всего: нет |
Про UML можно сказать - у меня к нему двойственное отношение.
С одной стороны, он конечно полезен как средство визуального представления, особенно в случае сложных программных элементов – классов, компонентов. Я им пользуюсь в основном для начальной прорисовки структуры программы, иерархии классов, взаимосвязей между блоками и объектами. Можно также получить «скелет» программного кода - классы, методы, и т.д. С другой стороны, как язык он весьма эклектичен, разнороден. Не знаю, хорошо это или плохо – по сути, это единственный язык такого рода, и сравнивать не с чем. Хорош тем, что для разных целей можно брать разные представления, диаграммы. Для разработки требований – прецеденты (Use Case). Для разработки структуры программного средства – диаграммы классов, объектов. Для проработки вопросов в заимодействия элементов (блоков) программы – диаграммы взаимодействия. А плох тем, что из всей этой кучи разнородной информации в один прекрасный момент надо начинать писать программу – и тут голову сломаешь пока все это осмыслишь, поймешь, как и что надо делать. Требуемая информация находится то в одной диаграмме, то в другой, то в третьей. Часто просто откладываешь все это в сторону, и начинаешь писать «по наитию». |
|||
|
||||
Леопольд |
|
|||
Опытный Профиль Группа: Участник Сообщений: 943 Регистрация: 17.6.2009 Репутация: нет Всего: 13 |
Мне почему-то кажется что нельзя начинать писать продукт, пока не поймёшь что и, главное, как! он будет это что-то делать. Легче понимать всё целиком, если части, которые будут между собой взаимодействовать можно было бы понимать как отдельно взятые сущности/абстракции а не только в контексте всей (или значительной части) программы. -------------------- вопросов больше чем ответов |
|||
|
||||
Нитонисе |
|
|||
Опытный Профиль Группа: Участник Сообщений: 917 Регистрация: 5.11.2009 Репутация: нет Всего: 2 |
Начиная программировать на С++ мне постоянно попадались на глаза непонятные диаграммки на языке UML. Долгое время не обращал на них внимания, да и вообще, как осознал позже, мой подход к программированию был структурный, а не объектно-ориентированный и планирования как такового не было. Программы создавались методом проб и ошибок. С ростом сложности программ с возникновением необходимости модифицировать и расширять уже написанные программы - более серьезно озадачился приемами программирования и осознал необходимость четко выделенного этапа проектирования. Вот тут и обратил более пристальное внимание на UML. Наглядность языка и его понятность - дело субъективное, но задачи, которые решают диаграммы на языке UML - однозначно важны. Диаграмма - это модель вашей будущей программы. Без моделирования - тыкаешься как слепой котенок туда сюда, создаешь классы и реализовываешь их, а затем выясняется, что они плохо взаимодействуют с другими и надо все переделать и т.д. Все эти проблемы решаются на стадии проектирования. Так что я за UML!
|
|||
|
||||
baldina |
|
||||||
Эксперт Профиль Группа: Завсегдатай Сообщений: 3433 Регистрация: 5.12.2007 Где: Москва Репутация: 1 Всего: 101 |
ну раз опять тему подняли...
да
да. даже не задумываясь: слелаешь что-то, а оно, гляди, есть паттерн)))
а как же! (неужели кто-то ответит "не, страшно мешают, но все-равно использую". или "нет, т.к. я не знаю что это такое, но не одобряю") продолжить эту старую тему меня побудила такая мысль: объектно-ориентированный подход это стиль мышления. инструмент (UML,C++ etc) вторичен. ООП как метод декомпозиции довольно сильная, эффективная весчь, и че бы его не использовать. вот UML я практически не использую - нэ трэба. паттерны как типовые решения выскакивают сами, а я даже названий многих из них не помню. это все к тому, что овладев методологией, начинаешь её применять. а еще не овладев, только учишься, затрачивая довольно много времени на организацию анализа проекта. это как езда на автомобиле: сначала думаешь, какие педали нажимать, потом - кто кого должен пропустить, а потом - просто ездишь. и вот тут уже можно раскрыть потенциал автомобиля, а вначале что жигули, что мерседес - все едино. так что на инструментах не надо зацикливаться, надо мозг тренировать. применять uml ради uml или придумывать "а не применить ли мне какой-нибудь паттерн" - глупо. вначале - организация процесса, а потом уже - его автоматизация. в требуемых рамках. без организации будет бардак, а его автоматизация - автоматизированный бардак (простите за банальность). |
||||||
|
|||||||
Янчик |
|
|||
Новичок Профиль Группа: Участник Сообщений: 1 Регистрация: 8.2.2012 Репутация: нет Всего: нет |
помогите решить
Тема:Классы. Программирование линейных алгоритмов с использованием функций инициализации set() и вывода результатов print() Пользовательский класс должен содержать необходимые элементы-данные, метод установки их начальных значений: Void set(double X, …); метод печати: Void print(void); метод, решающий поставленную задачу: Void Run(void); Код методов – вне пространства определения класса. Программа должна включать в себя статический и динамический способы создания объектов, и для каждого объекта использовать прямую и косвенную адресацию при вызове методов класса. Присоединённый файл ( Кол-во скачиваний: 7 ) 2012_02_07_132040.jpg 12,46 Kb |
|||
|
||||
Shelby |
|
|||
Новичок Профиль Группа: Участник Сообщений: 1 Регистрация: 21.9.2012 Репутация: нет Всего: нет |
[Delphi & C++] Построение графика функции.
1. Построить график функции, обеспечив следующие требования: a. Возможность изменения шага вычисления значений функции, т.е. количества разбиений диапазона изменения аргумента; b. Изображение на экране координатных осей Х, Y с размеченной шкалой и цифрами, соответствующими диапазонам изменения аргумента и функции (для этого рекомендуется предварительно выполнить анализ изменения значений функции на заданном интервале изменения аргумента); c. Изображение на свободном участке экрана математической формулы функции и фамилии автора программы. Это сообщение отредактировал(а) Shelby - 21.9.2012, 19:28 |
|||
|
||||
Правила форума "Центр помощи" | |
ВНИМАНИЕ! Прежде чем создавать темы, или писать сообщения в данный раздел, ознакомьтесь, пожалуйста, с Правилами форума и конкретно этого раздела.
Более подробно с правилами данного раздела Вы можете ознакомится в этой теме. Если Вам помогли и атмосфера форума Вам понравилась, то заходите к нам чаще! С уважением, Poseidon, Rodman |
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | Центр помощи | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |