Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Центр помощи > Объектно-ориентированный анализ и проектирование

Автор: Medved 22.3.2007, 04:11

Знакомы ли в с объектно-ориентированным проектированием и UML?  Используете ли вы паттерны в своих проектах? Помогают ли они вам в ваших программах? Спасибо.

Автор: Earnest 22.3.2007, 10:37

Цитата(Medved @  22.3.2007,  05:11 ) Знакомы ли в с объектно-ориентированным проектированием и UML?  Знакома, но UML не использую (не кажется наглядным и полезным в том, чем я занимаюсь) Проектирую стоя, пешком (в голове), рисуя в тетрадке не относящиеся к делу картинки, потом пишу интерфейсы сразу в коде. Цитата(Medved @  22.3.2007,  05:11 ) Используете ли вы паттерны в своих проектах? Помогают ли они вам в ваших программах? Да, постоянно. Конечно, помогают, иначе не использовала бы. Не очень связанные вопросы, ИМХО. Поэтому не знаю, как голосовать.

Автор: a_n_d_y 22.3.2007, 12:44

знаком использую помогают =)))

Автор: Medved 22.3.2007, 13:28

Цитата(Earnest @  22.3.2007,  13:37 ) Не очень связанные вопросы, ИМХО. Поэтому не знаю, как голосовать.  А где ты не видишь взаимосвязи? p.s. Спасибо за ответы!

Автор: Earnest 23.3.2007, 09:24

Цитата(Medved @  22.3.2007,  14:28 ) А где ты не видишь взаимосвязи? Использование объектно-ориентированного проектирования и UML и использование паттернов. Одно другого не подразумеваеи и не исключает.

Автор: MAKCim 23.3.2007, 09:35

ОО анализ использую (здорово упрощает жизнь) Но ООП нет (приложения системного характера)

Автор: Medved 23.3.2007, 14:41

Цитата(Earnest @  23.3.2007,  12:24 ) Использование объектно-ориентированного проектирования и UML и использование паттернов. Одно другого не подразумеваеи и не исключает. А я не согласен. Использование паттернов - хороший стиль проектирования. Но с тобой согласен. Теоретически конечно да, можно и без паттернов обойтись. Но так же можно вообще без проектирования обойтись, при написании программы  Мы просто немного в разных плоскостях смотрим на этот вопрос.

Автор: Earnest 23.3.2007, 16:14

Цитата(Medved @  23.3.2007,  15:41 ) А я не согласен... Но с тобой согласен.      Без проектирования вообще - никак, без объектно-ориентированного проектирования и UML - запросто, смотря что делаешь.  Ну вообще я имела в виду то, что про ООП в книгах пишут: проектирование как стадия отдельная разработки со всякими схемами-диаграммами, описаниями и прочая. Но я, упаси боже, не собираюсь отрицать ценность ООП вообще: все зависит от задачи. Мои - не требуют.

Автор: Любитель 24.3.2007, 01:31

Моё личное мнение, но всё же. UML - формальное выражение проектирование, это не лучший вариант обычно (я говорю, конечно, про то, с чем сам работал). Особенно для плюсов. Получается лишь лишняя бесполезная прослойка. А проектирование нужно. Обязательно нужно. А вот как его выражать - а как придёться.  Конечно, при работе в команде, вероятно придёться соблюдать какие-то формальности, но и то (как я считаю) лучше неформально разобраться с моделью и пр. Цитата(Earnest @  23.3.2007,  16:14 ) проектирование как стадия отдельная разработки Вот, опять таки считаю, что отдельной стадией это делать не надо. Надо быть готовым допроектировать и даже перепроектировать. По мере работы над проектом и пониманием его специфики и недостатков начальной модели. Без кода зачастую тяжело оценить удачность этой модели. Легче дважды написать какой-то код, чем какими-то неведомыми силами угадать, какое решение выбрать. Достаточно привлекают меня многие концепции http://ru.wikipedia.org/wiki/Экстремальное_программирование. Очень идеи нравяться. PS А почему тему именно в плюсы? Целевая аудитория должна быть ограниченной?

Автор: Medved 24.3.2007, 01:37

Цитата(Любитель @  24.3.2007,  04:31 ) PS А почему тему именно в плюсы? Целевая аудитория должна быть ограниченной?  Да.

Автор: FelikZ 25.3.2007, 18:28

Не использую, а зря  в ближайших проектах буду т.к. щитаю это удобно + зарание знаешь что и как будешь реализовывать...

Автор: NoNo 29.3.2007, 09:34

Что - то интересно стало...... где про UML надыбать можно.....стоб поближе с ним познакомиться...

Автор: Earnest 29.3.2007, 15:11

Целый раздел про UML на форуме.

Автор: Medved 5.4.2007, 03:06

Цитата(NoNo @  29.3.2007,  12:34 ) Что - то интересно стало...... где про UML надыбать можно.....стоб поближе с ним познакомиться... В первую очередь рекомендую ознакомиться с  http://www.helloworld.ru/texts/comp/other/oop/index.htm Гради Буч Это классика жанра. Гради Буч один из отцов-основателей объектно-ориентированного программирования, и языка UML.  а затем  Леоненков. http://khpi-iip.mipk.kharkiv.edu/library/case/leon/index.html

Автор: bsa 7.4.2007, 20:51

Цитата(Medved @ 5.4.2007,  03:06) а затем  Леоненков. http://khpi-iip.mipk.kharkiv.edu/library/case/leon/index.html Читал, читал. Но не осилил. Очень напоминает лекции профессоров (читай - неумелых преподавателей). Куча совершенно абстрактной теории, непонятно куда применимой, чтение которой вызывает сон или уход мыслей в сторону. До сих пор не могу понять, это то, что мне нужно, или совершенно бесполезная для меня вещь.

Автор: Medved 8.4.2007, 02:24

Цитата(bsa @  7.4.2007,  23:51 ) Куча совершенно абстрактной теории, непонятно куда применимой, чтение которой вызывает сон или уход мыслей в сторону. Это основополагающие принципы, основы. Он рассказывает как и из каких абстрактных научных теорий родился "практический" язык моделирования приложений. Мне этот учебник тем и понравился, что в нем преподаются глубокие знания, а не поверхностное описания, как это бывает в других книгах.  Если этот "не нравиться" лучше сам посоветуй какой-нибудь учебник по UML.

Автор: bsa 8.4.2007, 20:12

Как я посоветую учебник по предмету, который совершенно не понимаю (но немного хочу понять)?!? Для меня, например, идеальным был бы проект, расписываемый по шагам в этом UML. Пусть даже не сложный. Но чтобы видеть с чего конкретно все начинается и как, что делается сначала, а что потом. И главное, зачем это нужно.

Автор: Medved 8.4.2007, 21:40

Ну вот для начала и рекомендуется Гради Буч, там описано с самого начала, и на реальных проектах.  В книге правда применяется не сама нотация UML а ее предшественница, после этой книги Леоненков думаю будет более понятен.

Автор: archimed7592 16.9.2007, 18:48

А можно, не вникая в подробности и умные книги получить ответ на вопрос, который очень давно меня волнует: UML - это язык(как XML, к примеру) или просто схемки?

Автор: Daevaorn 16.9.2007, 19:49

Цитата(archimed7592 @  16.9.2007,  19:48 ) UML - это язык(как XML, к примеру) или просто схемки?  Unified Modeling Language - язык. но не многие на нем говорят:(

Автор: archimed7592 16.9.2007, 20:02

Цитата(Daevaorn @  16.9.2007,  19:49 ) Unified Modeling Language - язык.  Я знаю как расшифровывается и именно поэтому меня гложил этот вопрос - ни разу, во время беглого чтения учебников по UML не видел там ни строчки "кода" на этом "языке". Только схемки/диаграмки. А можно увидеть какой-нибудь пример на этом UML? Пусть будет абстрактный класс A с ф-цией foo и реализующий эту ф-цию класс C со своей ф-цией bar. Просто интересно на что похож этот язык .

Автор: Daevaorn 16.9.2007, 20:17

archimed7592, пжалста

Автор: archimed7592 17.9.2007, 08:47

Daevaorn, то ли у меня лыжи не едут, то ли... Ок, переформулирую вопрос: UML имеет какой-нибудь стандартизированный текстовый язык, по исходникам которого какая-нибудь незамысловатая программка будет строить подобные схемки? Если да, то хотелось увидеть исходник приведённой тобой диаграммы.

Автор: Daevaorn 17.9.2007, 08:52

Цитата(archimed7592 @  17.9.2007,  09:47 ) то ли у меня лыжи не едут, то ли... наверно Цитата(archimed7592 @  17.9.2007,  09:47 ) UML имеет какой-нибудь стандартизированный текстовый язык, по исходникам которого какая-нибудь незамысловатая программка будет строить подобные схемки? Если да, то хотелось увидеть исходник приведённой тобой диаграммы.  схемы это язык. текстового нет.

Автор: archimed7592 17.9.2007, 09:00

Цитата(Daevaorn @  17.9.2007,  08:52 ) текстового нет.  Понятно. Это плохо. Ладно, спасибо .

Автор: Daevaorn 17.9.2007, 09:04

Цитата(archimed7592 @  17.9.2007,  10:00 ) Это плохо. это классно. поэтому uml и называется универсальным.

Автор: archimed7592 17.9.2007, 09:57

А чем схемы универсальней текста? А если я решил отказаться от visio и начать пользоваться другой UML-средой? Был бы текст - читалось бы везде одинакого, а так прийдётся делать заново в новой среде.

Автор: Daevaorn 17.9.2007, 10:18

Цитата(archimed7592 @  17.9.2007,  10:57 ) А чем схемы универсальней текста? Они не навязывают так явно стиль описания, как текстовые конструкции. Тот же pseudo-code уж слишком похож на существующие языки программирования;) А UML тем более может быть использован не только для процесса написания програм. Цитата(archimed7592 @  17.9.2007,  10:57 ) А если я решил отказаться от visio и начать пользоваться другой UML-средой? Был бы текст - читалось бы везде одинакого, а так прийдётся делать заново в новой среде.  А если я решил бы перейти с С++ на Python, что бы мне пришлось делать с текстом программы? А так я имею одну схему на все реализации и через xml вполне можно добиться совместимости. Да и потом всегда можно сделать простую картинку

Автор: archimed7592 17.9.2007, 12:52

Цитата(Daevaorn @  17.9.2007,  10:18 ) А если я решил бы перейти с С++ на Python, что бы мне пришлось делать с текстом программы? Если ты решил перейти с msvs на bds, то особых проблем перекомпиляции(при условии следования стандарту) быть не должно. Цитата(Daevaorn @  17.9.2007,  10:18 ) А так я имею одну схему на все реализации и через xml вполне можно добиться совместимости. Так всё таки есть какой-то промышленный стандарт сериализации UML схем? Цитата(Daevaorn @  17.9.2007,  10:18 ) Да и потом всегда можно сделать простую картинкуsmile  А если нужно что-то  к ней добавить/удалить/изменить?

Автор: bsa 18.9.2007, 20:34

archimed7592, если честно, я не очень понимаю, что ты имеешь в виду под словом "сериализация" в данном контексте, но предположу, что ты хочешь услышать такое: - многие программы для работы с UML умеют импортировать классы (т.е. парсят готовый код на каком-то языке, например на С++, и делают из него часть диаграмм на UML) и создавать классы по диаграммам. Например, это умеет делать Umbrello (входит в kdesdk).

Автор: archimed7592 18.9.2007, 20:38

Цитата(bsa @  18.9.2007,  20:34 ) archimed7592, если честно, я не очень понимаю, что ты имеешь в виду под словом "сериализация" в данном контексте Я имею ввиду независимое от программы/платформы/и т.п. вещей представление данных. Ну вот исходник - это исходник, а бинарник - это уже бинарник . В моём понимании UML-схемка - это бинарник, а исходник... А исходник - это незнамо что, что я и хочу выяснить . Видимо понятия исходник для UML не применимо.

Автор: Medved 18.9.2007, 20:43

У MS Visio есть модуль интеграции с MS Visual Studio. В Visio вторая нотация UML используется.

Автор: archimed7592 18.9.2007, 20:52

Medved, если честно, ничего в UML и его нотациях не смыслю. Это какое-то XML представление UML-диаграм?

Автор: bsa 18.9.2007, 23:31

Цитата(archimed7592 @ 18.9.2007,  20:52) Medved, если честно, ничего в UML и его нотациях не смыслю. Это какое-то XML представление UML-диаграм? да.

Автор: Daevaorn 18.9.2007, 23:38

Цитата(archimed7592 @  18.9.2007,  21:38 ) Видимо понятия исходник для UML не применимо.  Исходник где угодно: у тебя в голове, в голове у менеджера, на листе бумаги, на доске в зале совещайний и т.п. UML это способ описания моделей, графический.

Автор: Medved 19.9.2007, 01:05

Когда вы слышите что-то, вы это забудете. Когда вы видете что-то, вы это запомните. Но до тех пор, пока  вы не сделаете что-нибудь, вы этого не поймете. (Старая китайская пословица)

Автор: JackYF 19.9.2007, 15:21

Цитата(Medved @  19.9.2007,  01:05 ) Когда вы слышите что-то, вы это забудете. Когда вы видете что-то, вы это запомните.   неверно для общего случая. Я часто запоминаю лучше со слов, чем со зрительного образа.

Автор: Dims 13.11.2007, 08:07

А можно ли наоборот, из диаграммы UML составить код на Си++ (или Джава)? Если нет, то получается, что это как бы односторонний язык, то есть, язык, на котором можно "читать", но на котором нельзя "писать". Или, быть может, можно сделать так, чтобы заранее составленная картинка на UML следила бы, что твой код ей соответствует?

Автор: bsa 13.11.2007, 12:57

Цитата(Dims @ 13.11.2007,  08:07) А можно ли наоборот, из диаграммы UML составить код на Си++ (или Джава)? Можно. Обычно, это делают сами среды редактирования UML.

Автор: Dims 13.11.2007, 19:52

Цитата(bsa @  13.11.2007,  12:57 ) Можно. Обычно, это делают сами среды редактирования UML. Ну вот в Visual Studio я этого не нашёл. Как я понял, он может только нарисовать то, что есть, но не обратно. С другой стороны, такая возможность, если она есть, означает, что ей НАДО пользоваться. Ведь мы же всегда мечтали составлять программы из кубиков. Разве это не оно? Либо у этой возможности есть какие-то ограничения. Фактически, ведь во всех средах есть какие-нибудь класс-менеджеры или проджект-вьюверы, которые в древовидной форме показывают структуру программы. Очевидно, если возможности UML полны, то вместо этого там должна быть картинка UML.

Автор: nickless 14.11.2007, 00:42

Цитата(Dims @  13.11.2007,  17:52 ) Ну вот в Visual Studio я этого не нашёл. ИМХО (студией давно не пользовался) это возможно только начиная с какой-то из навороченых версий, что-то вроде enterprise architect или что-то в этом роде.

Автор: baldina 18.12.2007, 00:42

Dims, Студия: рисовать диаграммки можно в Visio, который генерит код, еоторый вставляешь в студию. Medved, Цитата Использование паттернов - хороший стиль проектирования Не факт. Патерн - уже сделанное кем-то общее решение типовой задачи. Из таких задач состоит проект (но не только из таких). Так что паттерны могут использоваться в проектировании. Нет правила "проект плох, если он не использует ни одного паттерна", потому что не проектирование для паттернов, а паттерны для проектирования.  Увлечение паттернами (как и сладким) может быть вредным, см. http://ru.wikipedia.org/wiki/%D0%90%D0%BD%D1%82%D0%B8-%D0%BF%D0%B0%D1%82%D1%82%D0%B5%D1%80%D0%BD. bsa, читал я когда-то леоненкова, довольно бестолково изложено (не знал бы раньше - не понял). в первоисточнике (Буч, Якобсон и еще кто-то) намного логичнее и доступнее. А, http://zipsites.ru/books/buch_yazyk_uml_ruk_polz/ например. Добавлено через 6 минут и 57 секунд по поводу проектирования я когда-то прочитал нечто вроде: Цитата построить без проекта собачью конуру скорее всего получится, и собака, возможно, останется довольна. построить без проекта дом, где будут жить люди, невозможно

Автор: chipset 19.12.2007, 07:44

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

Автор: HistoryEarth 20.12.2007, 18:28

Если приложение имеет сложную структуру без этого трудно.

Автор: Lotrex 25.12.2007, 11:59

Сейчас при написании проги на С++ я использую (как мне кажется) объектно-ориентированное программирование (НЕ проектирование). Причем до меня дошло, что и как, только после того, как немножко изучил Java и написал на ней одну не очень большую программку (то-то около 1200 строк в общей сложности). Имхо, проектирование в программировании - весчь "ограниченно полезная", в т.ч. и объектно-ориентированное. К такому мнению я пришел после прочтения книги К.Бека "Экстремальное программирование. Разработка через тестирование".      Не раз я натыкался на проблему - работаешь над классом, тщательно продумываешь интерфейс, и т.д. А потом...  в  использовании этот класс оказывается жутко неудобным, половина методов не используется, а нужных методов нет.     А из упомянутой книги (да и по своему опыту) я понял следующее: как бы вы не пытались придумать класс, спроектировать его - жизнь все равно богаче. Поэтому сначала пишем код, использующий данный класс, его не существующие (пока что) методы. Тут все и открывается - какие методы нужны, что они должны делать. А потом и сами методы потихоньку реализуем. Тот же подход можно использовать и при написании библиотек функций. Пишем сначала код, использующий  данную библиотеку (и тут сразу видно, какие функции хорошо бы иметь в наличии). А уж потом - реализацию. И еще один (немаловажный!) плюс данного подхода -  мы сразу имеем тест, проверяющий наш класс (или библиотеку).

Автор: xvr 25.12.2007, 12:54

Цитата(archimed7592 @ 18.9.2007,  20:38) Цитата(bsa @  18.9.2007,  20:34 ) archimed7592, если честно, я не очень понимаю, что ты имеешь в виду под словом "сериализация" в данном контексте Я имею ввиду независимое от программы/платформы/и т.п. вещей представление данных. Ну вот исходник - это исходник, а бинарник - это уже бинарник . В моём понимании UML-схемка - это бинарник, а исходник... А исходник - это незнамо что, что я и хочу выяснить . Видимо понятия исходник для UML не применимо. UML - см. http://www.omg.org/technology/documents/modeling_spec_catalog.htm, так же можно посмотреть на http://www.intspei.com

Автор: archimed7592 25.12.2007, 21:15

xvr, спасибо, я посмотрю .

Автор: Fire-Plug 23.1.2009, 21:01

Цитата(archimed7592 @ 17.9.2007,  09:00) Цитата(Daevaorn @  17.9.2007,  08:52 ) текстового нет.  Понятно. Это плохо. Ладно, спасибо . В случае "Reverse engineering", т.е. построения UML-диаграмм на основе имеющегося проекта, "текстом" являтся сам исходный код, точнее - объявления классов. В случае же прямого моделирования, Rational Rose сгенерит исходный код для визуально построенных классов. Сам же язык моделирования - графический.

Автор: ida 24.1.2009, 17:14

Да... посмотрела на результаты голосования и опечалилась  Вроде и раздел профильный - С++ объектный язык. Проиллюстрировать мою печаль, пожалуй, лучше всего цитатой из Вигерса: Цитата Большинство людей при строительстве дома даже не интересуются подрядчиком, пока в полном объеме не обсудят свои потребности и желания и не уточнят все детали. Покупатели понимают, что внесение изменений влечет за собой изменение цены; им это не нравится, но они это понимают. Однако люди весело ищут оправдания, когда дело касается разработки ПО. Ошибки, допущенные на стадии сбора требований, составляют от 40 до 60% всех дефектов проекта. Основное следствие проблем с требованиями - переделка того, что, как вы думаете, уже готово. На это расходуется от 30 до 50% общего бюджета разработки, а ошибки в требованиях стоят от 70 до 85% стоимости переделки.

Автор: serg0s 13.2.2009, 08:40

Про UML можно сказать - у меня к нему двойственное отношение. С одной стороны, он конечно полезен как средство визуального представления, особенно в случае сложных программных элементов – классов, компонентов. Я им пользуюсь в основном для начальной прорисовки структуры программы, иерархии классов, взаимосвязей между блоками и объектами. Можно также получить «скелет» программного кода -  классы, методы, и т.д. С другой стороны, как язык он весьма эклектичен, разнороден. Не знаю, хорошо это или плохо – по сути, это единственный язык такого рода, и сравнивать не с чем. Хорош тем, что для разных целей можно брать разные представления, диаграммы. Для разработки требований – прецеденты (Use Case). Для разработки структуры программного средства – диаграммы классов, объектов. Для проработки вопросов в заимодействия элементов (блоков) программы – диаграммы взаимодействия. А плох тем, что из всей этой кучи разнородной информации в один прекрасный момент надо начинать писать программу – и тут голову сломаешь пока все это осмыслишь, поймешь, как и что надо делать. Требуемая информация находится то в одной диаграмме, то в другой, то в третьей. Часто просто откладываешь все это в сторону, и начинаешь писать «по наитию».

Автор: Леопольд 24.6.2009, 18:09

Цитата(serg0s @ 13.2.2009,  08:40) А плох тем, что из всей этой кучи разнородной информации в один прекрасный момент надо начинать писать программу – и тут голову сломаешь пока все это осмыслишь, поймешь, как и что надо делать. Требуемая информация находится то в одной диаграмме, то в другой, то в третьей. Часто просто откладываешь все это в сторону, и начинаешь писать «по наитию». Мне почему-то кажется что нельзя начинать писать продукт, пока не поймёшь что и, главное, как! он будет это что-то делать. Легче понимать всё целиком, если части, которые будут между собой взаимодействовать можно было бы понимать как отдельно взятые сущности/абстракции а не только в контексте всей (или значительной части) программы.

Автор: Нитонисе 31.10.2010, 08:58

Начиная программировать на С++ мне постоянно попадались на глаза непонятные диаграммки на языке UML. Долгое время не обращал на них внимания, да и вообще, как осознал позже, мой подход к программированию был структурный, а не объектно-ориентированный и планирования как такового не было. Программы создавались методом проб и ошибок. С ростом сложности программ с возникновением необходимости модифицировать и расширять уже написанные программы - более серьезно озадачился приемами программирования и осознал необходимость четко выделенного этапа проектирования. Вот тут и обратил более пристальное внимание на UML. Наглядность языка и его понятность - дело субъективное, но задачи, которые решают диаграммы на языке UML - однозначно важны. Диаграмма - это модель вашей будущей программы. Без моделирования - тыкаешься как слепой котенок туда сюда, создаешь классы и реализовываешь их, а затем выясняется, что они плохо взаимодействуют с другими и надо все переделать и т.д. Все эти проблемы решаются на стадии проектирования. Так что я за UML!

Автор: baldina 1.11.2010, 16:29

ну раз опять тему подняли... Цитата Знакомы ли в с объектно-ориентированным проектированием и UML?  да Цитата Используете ли вы паттерны в своих проектах? да. даже не задумываясь: слелаешь что-то, а оно, гляди, есть паттерн))) Цитата Помогают ли они вам в ваших программах? а как же! (неужели кто-то ответит "не, страшно мешают, но все-равно использую". или "нет, т.к. я не знаю что это такое, но не одобряю") продолжить эту старую тему меня побудила такая мысль: объектно-ориентированный подход это стиль мышления. инструмент (UML,C++ etc) вторичен. ООП как метод декомпозиции довольно сильная, эффективная весчь, и че бы его не использовать. вот UML я практически не использую - нэ трэба. паттерны как типовые решения выскакивают сами, а я даже названий многих из них не помню. это все к тому, что овладев методологией, начинаешь её применять. а еще не овладев, только учишься, затрачивая довольно много времени на организацию анализа проекта. это как езда на автомобиле: сначала думаешь, какие педали нажимать, потом - кто кого должен пропустить, а потом - просто ездишь. и вот тут уже можно раскрыть потенциал автомобиля, а вначале что жигули, что мерседес - все едино. так что на инструментах не надо зацикливаться, надо мозг тренировать. применять uml ради uml или придумывать "а не применить ли мне какой-нибудь паттерн" - глупо. вначале - организация процесса, а потом уже - его автоматизация. в требуемых рамках. без организации будет бардак, а его автоматизация - автоматизированный бардак (простите за банальность).

Автор: Янчик 8.2.2012, 14:20

помогите решить Тема:Классы. Программирование линейных алгоритмов с использованием функций инициализации set() и вывода результатов print() Пользовательский класс должен содержать необходимые элементы-данные, метод установки их начальных значений: Void set(double X, …); метод печати: Void print(void); метод, решающий поставленную задачу: Void Run(void); Код методов – вне пространства определения класса. Программа должна включать в себя статический и динамический способы создания объектов, и для каждого объекта использовать прямую и косвенную адресацию при вызове методов класса.

Автор: Shelby 21.9.2012, 19:24

[Delphi & C++] Построение графика функции. 1.    Построить график функции, обеспечив следующие требования: a.    Возможность изменения шага вычисления значений функции, т.е. количества разбиений диапазона изменения аргумента; b.    Изображение на экране координатных осей Х, Y с размеченной шкалой и цифрами, соответствующими диапазонам изменения аргумента и функции (для этого рекомендуется предварительно выполнить анализ изменения значений функции на заданном интервале изменения аргумента); c.    Изображение на свободном участке экрана математической формулы функции и фамилии автора программы.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)