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

Спасибо.

знаком. но кодю сам - для себя/начальника использую более простую самодельную нотацию. 

да. немного, правда, этих проектов было...

конечно. как и знание синтаксиса - если знаешь, какой инструмент есть в твоем распоряжении и умеешь его применять - это только поможет делу и ускорит процесс 

Знаком, но чисто поверхностно.

К сожалению, не использую... Времени нет на изучение.

Хочется подробно изучить UML, но вот никак не удаётся выделить свободные минуты для этого.

Я о нём слышал, но не разбирался.

Спасибо за ответы!

А что это такое???

Объектно-ориентированный анализ и проектирование Гради Буч

Это классика жанра. Гради Буч один из отцов-основателей объектно-ориентированного программирования, и языка UML. 
В книге используются примеры на C++. Если для кого-то представляет сложным чтение синтаксиса С++ то можно прочитать только первые главы, где говориться об общих принципах.

Книга читается легко, и плавно.

Спасибо за книгу. Буду углубляться )

Вот еще хорошая книга
Леоненков. Самоучитель UML.

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

З.Ы.Нам на на диплом говорили, что если у вас объектный подход,  то забудте о блок-схемах.

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

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

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

Модель приложения - это практически готовая программа но на бумаге (или в голове), которую осталось только непосредственно набить в редакторе кода (т.е. реализовать). 

Требования -> Модель (UML) -> Реализация (Delphi) -> Готовая программа (.exe)

Кто-нибудь может знает книги по UML2.0 применительно к BDS и Delphi2007?

Ищи информацию по ModelMaker.

Добавлено через 44 секунды
http://www.modelmakertools.com/
http://www.thoughtsmithy.com/mmjump/MMGett...rted_Intro.html

cemick,
Да, UML может заменить привычные нам блок-схемы. Даже более, насколько я смог въехать, в UML используются диаграммы взаимодействия.

В чем суть UML?

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

Отсюда:
1. Если излишне расписывать систему, то спец "увязнет" в детаталях! Пример: "Написать ПО читающее файл раз в сутки" считается хорошей задачей, а вот "Написать ПО которое вызывает ReadFile c обработкой ошибок с помощью ф-ции GetLastErrror" это уже плохо!
Вывод: нужно отобразить только смысл - нафига вообще надо?
2. Предметная область должна иметь четко выраженные рамки! Ну скажите на фига в проекте Записная книжка Химика, хранить запись об алгоритме сортировки Хоара?
Вывод: должна быть четко сформулированная цель!
3. Между элементами должна быть показана ясная и четко выраженная схема взаимодействия, чтобы не было ситуации что остался лишний болтик ;)

Так вот, UML дает вам краткость, ясность, смысл всего проекта. При довольно больших проектах, разработчик теряется и думает "Так, я кажется забыл чтение файла икс", потом задумается и выразит: "да, наверно это все таки не надо". Скажите нафига ему думать об этом?
Он уже заранее должен знать, надо или нет, т.к. недолжно быть потери человеко\часов! 

ООП:
1. многие из нас, подходят утром к компу у себя  на работе\дома и жмут на ПУСК!!! Какие мысли у нас в этот момент? Да никаких, он просто включается и все!!!! Т.е. нам глубоко фиалетово, что и как там внутри, мы еще даже не проснулись окончательно, но он от этого хуже включаться ведь не стал?!
Вывод: Разработка четко отлаженного и скольугодно сложного механизма, с предоставлением простого интерфейса ведет к простоте и ясности действий! Вот это и есть ИНКАПСУЛЯЦИЯ

2. У нас всегда есть, громадное кол-во однотипных задач,но которые решаются с нюансами. К примеру мы читаем из файлов, баз данных, сети. Но все же везде по разному, но корень всего этого читать отсюда и делаем концепцию архива, в нем говорим что мы умеем читать. А реализации, к примеру файле потомке от архива, читаем уже посредством ReadFile, Или из базы данных читаем посредством Query.Execute - но везде читать. Но только разные формы реалзиаци.
Вывод: много образие форм можно вывести в концепцию, дать эту концепцию вновь прибывшему сотруднику. Он ее всего лишь один изучит и будет знать как читать из файла, из сети, из базы данных. Это и есть ПОЛИМОРФИЗМ!

3. Вы наверно уже когда то писали открытие файла и понимаете, что не зависмо какой это файл JPEG или AVI, это все таки файл, а значит все файлы открываются одинаково. Нафига каждый раз когда делаем новую реализацию чтения с файлом делать ее заново?
Вывод: если есть механизм получения кода, который мы или наш друг раньше уже разрабатывали, то полная халява! Каждому программеру в отделе отдать позадаче, а потом собрать воедино! Получения кода потомком от родителя - есть НАСЛЕДОВАНИЕ!

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

Решил показать, то что я сделал я. Возможно кому-то это понадобиться!
Я Инженер-Программист в группе АСУТП на ТЭЦ.
Задачи, разработка ПО:
- для просмотра архивов значений по технологич. режиму, 
- Для репликации данных с одной БД в другую
- Для сбора данных с OPC-серверов в БД
- Для передачи клиентам данных через ЛВС

БД органзована или на файлах или под управлением какой либо СУБД(у нас Oracle, Interbase)

Обобщим действия моего ПО:
- Открыть архив
- Закрыть архив
- Перейти на первую запись
- На последнюю
- предыдущую
- следующую
- Добавить новую
- Прочитать запись
- Записать запись
- Прочиать i-е значение i-го технологич. параметра записи
- Записать значение в i-й элемент ассициированного с технологич. параметром

Обобщение нас подводит к:



К чему это все приведет?

К тому что я зная как работать с потомком от TCustomFileArchive, смогу без лишних трудностей и изврата работать с любым потомком TCustomDataBaseArchive. Пример? Вот держите:



Если я надумал работать с базой, То в чем сложность? Я меняю кусок кода:

на:

var


И все!!! Остальной код, сколь угодно сложным он небыл, остается таким же!!! А ведь за место кода:


может код на множество строк!!! К примеру чтение в грид, вывод в отчет, вывод в другой архив, вывод сеть или еще что это может быть довольно объемный и очень сложный код! Но он остается таким же как и был!