Рассмотрим применение диаграмм UML в рабочем процессе разработки программных систем по методологии Rational Software.
Методология RUP
Унифицированный процесс
Rational Unified Process
Рабочие процессы RUP и диаграммы UML
http://www.caseclub.ru/articles/rup_uml.html
Rational Unified Process (RUP) – одна из лучших методологий разработки программного обеспечения, созданная в компании Rational Software. Основываясь на опыте многих успешных программных проектов, Унифицированный процесс позволяет создавать сложные программные системы, основываясь на индустриальных методах разработки. Одним из основных столпов, на которые опирается RUP, является процесс создания моделей при помощи унифицированного языка моделирования (UML).
Рассмотрим применение диаграмм UML в рабочем процессе разработки программных систем по методологии Rational Software.
Известно, что создание программного обеспечения – это сложный процесс, который, с одной стороны, имеет много общего с творчеством, а с другой, – хотя и высокодоходный, но и высокозатратный бизнес. Жестокая конкуренция на рынке вынуждает разработчиков к поиску более эффективных методов работы. Путей создания программных систем в еще более короткие сроки, с меньшими затратами и лучшим качеством. Сложность программ постоянно увеличивается. Еще недавно программные продукты могли быть созданы в обозримые сроки одиночками или, например, в IT-отделе автоматизируемого предприятия.
Сейчас же одиночкам, создающим программы самостоятельно («на коленке») остается область небольших утилит и различных модулей расширения «тяжелых» программных продуктов. Будущее за индустриальным подходом к созданию ПО. В 1913 году Генри Форд запустил первый автомобильный конвейер, а в 90-х аналогичный конвейер стал применяться в сфере IT-технологий. Командная разработка требует совсем другого подхода и другой методологии, которая рано или поздно должна была быть создана.
|
|
|
Корпорация Rational Software (http://www.rational.com) выпустила на рынок структурированную базу знаний под названием Rational Unified Process (RUP), которая представляет собой набор исчерпывающих рекомендаций для создания практически любых программных продуктов. Вобрав в себя опыт лучших разработок, RUP подробно рассказывает когда, кто и что должен делать в проекте, чтобы в результате получить программную систему с установленные сроки, с определенной функциональностью и в рамках отведенного бюджета.
Унифицированный процесс можно представить как сумму различных видов деятельности компании-разработчика, необходимых для перевода требований заказчика в программную систему. Систему, которая давала бы «значимый результат» пользователям и выполняла бы именно то, что они от системы ожидают. Поэтому процесс управляется вариантами использования (Use Case) системы, или иначе – прецедентами.
|
|
|
Для реализации требований заказчика в установленные сроки, Унифицированный процесс разделяется на фазы, которые состоят из итераций, поэтому процесс еще называют итеративным и инкрементным. Каждая итерация проходит цикл основных работ и подводит разработчиков к конечной цели: созданию программной системы. В ходе итераций создаются промежуточные артефакты, которые требуются для успешного завершения проекта и вариант программной системы, который реализует некоторый набор функций, увеличивающийся от итерации к итерации. Фазы и основные потоки работ процесса показаны на рис. 1, там же даны примерные трудозатраты работ по фазам. Артефакты - это такие изменения в системе, которые либо усиливают имеющиеся свойства, либо добавляют новые.
Рис. 1 Фазы и потоки работ RUP
Нужно отметить, что на рис. 1 показаны только основные работы Унифицированного процесса. Например, работы по управлению деятельностью здесь не показаны, чтобы не загромождать диаграмму.
Вся разработка ПО рассматривается в RUP как процесс создания артефактов. Любой результат работы проекта, будь то исходные тексты, объектные модули, документы, передаваемые пользователю, модели – это подклассы всех артефактов проекта. Каждый член проектной группы создает свои артефакты и несет за них ответственность. Программист создает программу, руководитель — проектный план, а аналитик — модели системы. RUP позволяет определить когда, кому и какой артефакт необходимо создать, доработать или использовать.
|
|
|
Одним из интереснейших классов артефактов проекта являются модели, которые позволяют разработчикам определять, визуализировать, конструировать и документировать артефакты программных систем. Каждая модель является самодостаточным взглядом на разрабатываемую систему и предназначена как для очерчивания проблем, так и для предложения решения. Самодостаточность моделей означает, что аналитик или разработчик может из конкретной модели почерпнуть всю необходимую ему информацию, не обращаясь к другим источникам.
Модели позволяют рассмотреть будущую систему, ее объекты и их взаимодействие еще до вкладывания значительных средств в разработку, позволяют увидеть ее глазами будущих пользователей снаружи и разработчиков изнутри еще до создания первой строки исходного кода. Большинство моделей представляются UML диаграммами, подробнее об UML можно прочитать, например в [3].
|
|
|
Унифицированный язык моделирования (Unified Modeling Language) появился в конце 80-х в начале 90-х годов в основном благодаря усилиям «трех друзей» Гради Буча, Джима Рамбо и Ивара Якобсона. В настоящее время консорциум OMG принял этот язык как стандартный язык моделирования, который предоставляет разработчикам четкую нотацию, позволяющую отображать модели общепринятыми и понятными каждому члену проекта графическими элементами.
Однако не следует забывать, что язык моделирования дает только нотацию – инструмент описания и моделирования системы, а унифицированный процесс определяет методику использования этого инструмента, как впрочем, и других инструментов поддержки методологии от компании Rational. UML можно использовать и без конкретной методологии, поскольку он не зависит от процесса и какой бы вариант процесса не был бы применен, вы можете использовать диаграммы для документирования принятых в ходе разработки решений и отображения создаваемых моделей.
Программная система создается для решения определенных проблем пользователя, а не для опробования новых технологий программистами и получения опыта руководителем проекта. По большому счету, пользователю не важно используете ли вы в процессе разработки объектно-ориентированный подход, UML, RUP или создаете систему по методу XP (экстремального программирования) [4]. Применение тех или иных методик, технологий, создание оптимальной внутренней структуры проекта остается на совести разработчиков, которые принимают решения исходя из предыдущего опыта и собственных предпочтений. Однако пользователь не простит вам игнорирование его требований. Будь программная система хоть десять раз разработана при помощи суперсовременных методов и технологий, если пользователь не получит от нее то, что называется «значимым результатом», ваш программный проект с треском провалится.
Из этого следует, что бездумное применение UML, просто потому что это модно, не только не приведет разработку к успеху, но и может вызвать недовольство сотрудников, которым необходимо изучать большое количество дополнительной литературы и руководителей проекта, когда окажется, что трудозатраты на проекте возрастают, а отдача не повышается. Нужно четко представлять себе, что вы хотите получить от внедрения этой технологии и следовать этой цели. Применение UML экономит ресурсы разработки, поскольку позволяет получить представление о системе быстрее, чем при создании макетов и прототипов, затратив на это несравнимо меньше ресурсов.
Диаграммы позволяет легче общаться членам проекта между собой, и, что особенно ценно, вовлекают в процесс конечных пользователей системы. Моделирование позволяет уменьшить риски проекта, поскольку программистам всегда легче делать то, что ясно и понятно, чем идти к неопределенному результату. Создание диаграмм аналогично созданию проекта в строительстве – можно обойтись и без него, например, при строительстве сарая на дачном участке, однако, чем больше здание (в нашем случае программный продукт), тем труднее это делать и неопределеннее конечный результат.
Один известный специалист проводил семинар по RUP в компании-разработчике программного обеспечения, которая уже десять лет довольно успешно работает на рынке, но не использует в своем рабочем процессе моделирования вовсе, а основывается на прототипах. В зале собралось около двадцати молодых и умудренных опытом программистов, которые внимательно прослушали все, что я им рассказал о RUP и UML. И вот один из них, посмотрев на доску, испещренную примерами диаграмм, заметил: «Это все интересно и, наверное, хорошо подходит для других проектов», – сказал он, «но мы работаем довольно давно без всего этого, раз мы до сих пор обходились без UML, он, наверное, нам это просто не нужен».
Этот вопрос приводит к размышлению о том, что изменение бизнес-процессов, которое неизбежно должно произойти в компании-разработчике программного обеспечения при внедрении RUP и UML может проходить также тяжело, как внедрение информационной системы на промышленном предприятии. Любое внедрение – это ломка стереотипов. Поскольку квалификация сотрудников в компании-разработчике ПО довольно высока, то и отказаться от своих взглядов таким людям труднее, чем «простым смертным», а возникающие трудности и неприятие можно сравнить с переходом от процедурного к объектно-ориентированному мышлению.
Дата добавления: 2016-01-05; просмотров: 18; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!