Welcome to php club

В.: Что это?
О.: UML – это язык моделирования, но т.к. моделирование ведется на объектно-ориентированном языке, то UML – это ещё и документирование объектно-ориентированной системы. UML стандартный способ визуального отображения структуруы проекта. Он не зависит от языка на котором пишется проект и это делает его еще более привлекательным. Можно написать проект на С++, а потом, используя UML, переписать это все на джаву или С#, например. Кроме того, это очень удобный способ организовать работу в команде. Если все члены команды умеют читать диаграммы, то тогда нет проблем – выдай каждому по копии и вперед.


UML это средство для визуализации процесса разработки. Только и всего. Можно вполне обходится и без него. и это совсем не значит что ты не сможешь сделать хороший проект. Запросто сможешь.


В.: Зачем?
О.: Использование UML особенно полезно при работе в команде. Например, если новый человек приходит в команду, то ему можно просто показать диаграмки, что, где и как работает, а с нюансами разбираться по ходу дела (если они не прилагаются к диаграмме, как developers-notes). Однако работа в команде не обязательное условие использования UML. Язык удобно использовать при разработке приложений, к примеру, с использованием ООП, когда классов «более двух» или для разработки структуры баз данных. Но этим сфера применения UML не ограничивается.


В.: Удорожает ли проект применение UML?
О.: Дело не в UML, а в квалификации. У кого она выше — берут больше. Есть так же зависимость между квалификацией и пониманием необходимости в использовании проектирования.


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


Точно так же, не правильно говорить об удорожании стоимости проекта за счет применения UML. UML позволяет более глубоко продумать структуру проекта. Поэтому брать за его использование дополнительные деньги это все равно, что брать деньги с клиента за то что ты не просто делаешь то, что ему нужно, а делаешь это хорошо и думаешь о том, что ты делаешь.


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


В.: UML применяется только для разработки ООП приложений?
О.: Объектно-ориентированное это будет приложение или нет – это никак не связано непосредственно с UML.


В.: Есть мнение, что UML не навязывает вообще никакого стиля проектирования. А как же всевозможные диаграммы состостяний, диаграммы, кооперации и т.д.?
О.: Ни одна из диаграмм не является обязательной. Каждую из них можно составить с разной степенью детализации.


В.: Существуют ли какие-то сложности в применении UML?
О.: Да, конечно. Ниже приведён опыт использования UML участниками форума:


1. Не нужно пытаться использовать диаграммы для непосредственной генерации кода.
2. Самой важной частью являются usecase'ы, причем не диаграммы, а их текстовая часть.


Следование этим правилам снимает большинство проблем.


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


Многие скептически относятся к использованию UML для небольших проектов. Это в самом деле так?
Crazy:
Это не проблема UML, а отголоски известной болезни под названием «маниакальное проектирование». Им должен переболеть каждый, кто знакомиться с формальными методиками проектирования. У большинства быстро вырабатывается иммунитет, но у некоторых переходит в хроническую фазу.

Признаками хронической стадии «маниакального проектирования» являются попытки составить ВСЕ возможные типы диаграмм для КАЖДОГО этапа проекта. В этом случае для гостевой книги в две страницы кода порождается 30–40 страниц диаграмм и работа занимает в 5–6 раз больше времени.

Признаком выработанного иммунитета является понимание того, что нужно составлять и поддерживать только необходимый минимум диаграмм. Для той же гостевой книги это usecase и, возможно, диаграмму классов для отображения структуры БД.

«Я напишу лучше без проектирования» срабатывает только на типовых задачах, которые настолько разжеваны, что в них вообще не осталось неясных мест.

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


 
Комментариев нет. [Показать комментарии/форму]