© Наталия Елманова
Статья была опубликована на сайте КомпьютерПресс 10'2004
Говоря о разработке программного обеспечения, многие пользователи и заказчики подразумевают в первую очередь написание кода приложений и их внедрение. Причиной этого, как правило, служит опыт, приобретенный многими компаниями в 90-е годы, когда, получив наконец-то возможность покупать относительно недорогие компьютеры в любом необходимом количестве, они начали пытаться автоматизировать всё подряд, имея при этом весьма туманное представление о стоимости и принципах разработки соответствующих решений. Именно в тот период многие задачи автоматизации решались стихийно и, как правило, силами разработчиков-универсалов, которые, будучи мастерами на все руки, сами проектировали приложения, писали код, готовили проектную документацию, тестировали и внедряли продукт, нередко заодно выполняя и функции системных администраторов. Можно, конечно, возмущаться подобным подходом к автоматизации как неправильным с точки зрения долговременного планирования IT-инфраструктуры, однако будем справедливы — во многих компаниях это позволило решить те или иные насущные задачи с минимальными затратами.
Жизнь не стоит на месте: задачи и требования к качеству решений усложняются, и сейчас подавляющее большинство компаний все чаще предпочитают использовать специализацию даже в небольших проектах. Для успешной реализации современных проектов требуется весьма широкий спектр знаний и умений, которыми, как правило, обладают разные специалисты, выполняющие в проекте различные функции и задействованные на разных этапах создания продукта. Сегодня над любым проектом работают и бизнес-аналитики, изучающие и моделирующие предметную область, и системные аналитики и архитектры, проектирующие архитектуру решения, приложения и данные, и авторы кода приложений, и специалисты по тестированию и оценке качества, и авторы документации, и авторы дистрибутивов, и специалисты по внедрению, причем обычно эти функции распределяются между несколькими участниками, хотя совмещение ролей все еще практикуется.
В то же время специализация привела к появлению барьеров между бизнес-аналитиками, оперирующими пользовательской терминологией, и ИТ-специалистами. А если между этими категориями участников проектов нет взаимопонимания, то результаты предпроектных обследований, выполняемых бизнес-аналитиками, часто превращаются в документы, имеющие мало общего с создаваемыми решениями; при этом возникает определенный риск, что те или иные требования заказчиков не будут реализованы вообще или будут неправильно интерпретированы.
Инструменты UML-моделирования, к которым относится и Borland Together компании Borland, приобрели за последние несколько лет особую популярность именно благодаря тому, что представляют собой удачное средство преодоления подобных барьеров. UML-модели обычно достаточно понятны для заказчиков и представителей конечных пользователей и при этом могут служить неплохой основой будущих приложений.
Ниже мы рассмотрим некоторые особенности недавно выпущенной новой версии Borland Together Community Edition (а также некоторых других редакций этого продукта) и расскажем о применении Together, а также о тех преимуществах, которые могут получить команды разработчиков при его использовании.
Применяя средства UML-моделирования, бизнес-аналитики, помимо текста требований, который становится потом техническим заданием на разработку продукта, нередко создают набор моделей, позволяющих лучше понять эти требования. Такие модели могут быть весьма разнообразны: среди них как минимум могут быть описания как имеющегося состояния бизнес-процессов, которые предполагается автоматизировать (данные модели называются AS IS — "как есть"), так и состояния бизнес-процессов, в котором они должны эволюционировать после внедрения продукта (модель TO BE — "как должно стать"). Кроме того, модели могут отличаться способами описания бизнес-процессов, составных частей проекта и взаимодействия с ними пользователей.
Из диаграмм, наиболее часто включаемых бизнес-аналитиками в модели, создаваемые на этапе предпроектного обследования, следует отметить в первую очередь Use Case-диаграммы (диаграммы сценариев взаимодействия пользователя с продуктом с точки зрения пользователя; рис. 1); диаграммы последовательностей, описывающие порядок передачи сообщений от одних объектов к другим (рис. 2); диаграммы кооперации, описывающие взаимодействие объектов друг с другом, а также диаграммы деятельности, описывающие потоки работ и изменение состояний объектов.
Рис. 1. Use Case-диаграмма в Borland Together
Рис. 2. Диаграмма последовательностей в Borland Together
Модели, созданные на этапе определения требований, нередко упрощают понимание требований и заказчиками и разработчиками за счет более наглядного представления процессов, чем их текстовое описание, и служат для дальнейшего проектирования приложений. Однако стоит заметить, что многие современные инструменты моделирования, в том числе и Borland Together, отнюдь не являются просто средствами создания иллюстраций — работу над моделями, созданными бизнес-аналитиками, продолжают другие участники проекта, используя модели для генерации кода, для генерации проектной документации, для создания планов тестирования и даже для контроля качества созданного приложения.
На этапе проектирования принимаются решения относительно архитектуры и составных частей создаваемого решения, а также отбираются технологии, применяемые при его реализации. Обычно на этом этапе к модели, созданной бизнес-аналитиками, добавляются диаграммы компонентов и классов создаваемых приложений и диаграммы развертывания создаваемого решения (рис. 3), а также модифицируются некоторые из уже созданных диаграмм.
Рис. 3. Диаграмма развертывания
Отметим, что Together позволяет применять шаблоны проектирования, что во многом упрощает проектирование и создание часто встречающихся компонентов решений, а также создание компонентов и даже целых проектов с заранее заданными свойствами.
На этом же этапе при необходимости может создаваться логическая модель данных, содержащая диаграммы "сущность—связь" (рис. 4), на ее основе генерируется физическая схема данных для конкретной СУБД, выбранной для реализации проекта.
Рис. 4. Диаграмма "сущность—связь"
На этапе создания клиентского и серверного кода моделирование может применяться весьма активно — практически все современные средства UML-моделирования могут осуществлять генерацию кода на различных языках программирования (этот процесс называется forward engineering), а некоторые из них могут осуществлять и обратное проектирование (reverse engineering), создавая диаграмму классов на основе готового приложения. Технология Borland LiveSource и сами продукты семейства Borland Together (в которых эта технология впервые появилась) позволяют не думать о вопросах синхронизации кода и моделей, обеспечивая непосредственную работу с кодом, представленным в виде соответствующих UML-диаграмм. Кроме того, прямая работа с кодом позволяет естественным образом интегрировать в среду разработки не только средства UML-проектирования, но и инструменты рефакторинга (то есть средства автоматического преобразования кода с целью оптимизации, упрощения "читаемости" при переименовании классов или методов), как это сделано, например, в новой версии Borland Together Edition for Visual Studio .NET 2.0
Возможность синхронного изменения кода и модели значительно упрощает многие процессы, сопровождающие собственно разработку. Во-первых, в этом случае не требуется ручного восстановления модели на основе уже созданного кода для создания проектной документации, отражающей реальное положение вещей. Во-вторых, модель уже созданного решения может быть повторно использована в других проектах (возможно, с определенными модификациями) и в этом случае собственно код можно сгенерировать для другого языка программирования, другого средства разработки и даже для другой платформы.
Поскольку при тестировании проверяется соответствие продукта требованиям, план тестирования создается именно на их основе, а следовательно, при его создании можно применять модель, созданную на этапе определения требований. Сценарии взаимодействия пользователей с системой выполняются при тестировании пользовательских интерфейсов и при функциональном тестировании.
Помимо тестирования в последнее время немалое внимание стало уделяться оценке качества кода. А поскольку Together обладает средствами разбора кода приложений, то они используются в качестве основы для встроенных в этот продукт средств аудита кода.
Кроме диаграмм, современные средства моделирования позволяют создавать разнообразные отчеты по моделям и включать их в проектную документацию, и чем аккуратнее велась работа над моделью, тем проще эту документацию создавать. В то же время модель может содержать практически все, что требуется отразить в документации, причем не только в руководстве системного администратора или администратора баз данных, но и в руководстве пользователя. Borland Together позволяет создавать документацию в соответствии с шаблонами и регламентами, настроенными с учетом стандартов страны или отрасли, специфики данной организации, используемой методологии или проекта.
На этапе внедрения продукта специалистами по внедрению обычно применяются диаграммы развертывания, созданные системными аналитиками на этапе проектирования приложения. На этапе же сопровождения продукта соответствующим специалистам может понадобиться практически все, что было произведено при работе над проектом, в том числе код и все созданные модели, особенно если на этом этапе выявляется необходимость какой-либо доработки продукта.
Поскольку модели могут применяться практически всеми участниками проекта и подвергаться постоянным изменениям, довольно серьезной может оказаться проблема управления версиями одной и той же модели. Именно поэтому современные средства моделирования обладают, как правило, механизмами интеграции со средствами управления изменениями и средствами контроля версий, что, в свою очередь, позволяет осуществить корректное применение одной модели коллективом участников проекта. Что касается Borland Together, то этот продукт интегрируется со средством управления изменениями Borland StarTeam, а также со средством управления требованиями Borland Caliber RM.
Borland Together можно применять на различных платформах — Windows (поддерживаются версии Windows 2000, Windows XP Professional, Windows NT 4.0 SP6a), Linux (поддерживаются версии Red Hat Linux 7.2, 7.3 и 8.0, SuSE Linux 8.0 и 8.1, Solaris (версии 8 и 9), Mac OS X (версия 10.2.2).
Итак, Borland Together можно использовать на всех этапах жизненного цикла разработки приложений — от определения требований до внедрения и сопровождения продукта. Однако разным участникам проекта требуется различный набор функций, и именно это определяет состав соответствующего семейства продуктов.
Семейство продуктов Borland Together состоит из следующих редакций:
Потребность в тесной интеграции средств управления требованиями, инструментов проектирования, сред разработки и систем конфигурационного управления и отслеживания изменений (Software Configuration & Change Management, SCCM) по сути привела к тому, что на рынке появился новый класс программных продуктов категории Enterprise Studio, объединяющий и интегрирующий такого рода средства в рамках единой среды. Из таких продуктов, содержащих в своем составе Together, стоит в первую очередь назвать Borland Enterprise Studio for Java.
Как было упомянуто выше, в ближайшее время следует ожидать выпуска нескольких новых версий Together, позволяющих создавать модели в стандарте UML 2.0 и обладающих разнообразным набором функций. Впрочем, о них мы расскажем после их выхода.
Обычно в нашем издании не принято уделять много внимания ценам программного обеспечения, однако в данном случае есть смысл сделать исключение. Дело в том, что стоимость инструментов UML-моделирования обычно довольно высока, в основном потому, что компании, реализующие крупные проекты, в состоянии заплатить за такой инструментарий достаточно большие деньги. Borland Together стал здесь приятным исключением — цены многих редакций этого продукта таковы, что их приобретение могут позволить себе и небольшие компании. Напомним, что в семействе продуктов Together предусмотрена и свободно распространяемая версия, позволяющая, тем не менее, создавать все основные типы диаграмм UML 2.0.
***
Итак, мы видим, что Borland Together является средством объединения команды разработчиков и повышения эффективности работы всей команды. Этот продукт может упростить взаимодействие с заказчиками и облегчить работу над последующими проектами. Кроме того, он интегрируется с самыми популярными средствами разработки. Поэтому разработчикам и руководителям проектов стоит обратить на него серьезное внимание.
За дополнительной информацией обращайтесь в компанию Interface Ltd.
| INTERFACE Ltd. |
| ||||
