Borland Together та його застосування

Зміст



Говорячи про розробку програмного забезпечення, багато користувачів і замовники мають на увазі в першу чергу написання коду додатків та їх впровадження. Причиною цього, як правило, служить досвід, набутий багатьма компаніями в 90-ті роки, коли, отримавши нарешті можливість купувати відносно недорогі комп'ютери в будь-якому необхідному кількості, вони почали намагатися автоматизувати всі підряд, маючи при цьому вельми туманне уявлення про вартість і принципах розробки відповідних рішень. Саме в той період багато завдань автоматизації вирішувалися стихійно і, як правило, силами розробників-універсалів, які, будучи майстрами на всі руки, самі проектували програми, писали код, готували проектну документацію, тестували і впроваджували продукт, нерідко заразом виконуючи і функції системних адміністраторів. Можна, звичайно, обурюватися подібним підходом до автоматизації як неправильним з точки зору довгострокового планування IT-інфраструктури, проте будемо справедливі – в багатьох компаніях це дозволило вирішити ті чи інші нагальні завдання з мінімальними витратами.

Життя не стоїть на місці: завдання та вимоги до якості рішень ускладнюються, і зараз переважна більшість компаній все частіше вважають за краще використовувати спеціалізацію навіть у невеликих проектах. Для успішної реалізації сучасних проектів потрібно дуже широкий спектр знань і умінь, якими, як правило, мають різні фахівці, які виконують в проекті різні функції і задіяні на різних етапах створення продукту. Сьогодні над будь-яким проектом працюють і бізнес-аналітики, які вивчають і моделюють предметну область, і системні аналітики та архітектри, проектують архітектуру рішення, додатки і дані, і автори коду додатків, і фахівці з тестування та оцінки якості, і автори документації, і автори дистрибутивів, і фахівці з впровадження, причому зазвичай ці функції розподіляються між кількома учасниками, хоча суміщення ролей все ще практикується.

У той же час спеціалізація привела до появи бар'єрів між бізнес-аналітиками, які оперують користувача термінологією, і ІТ-фахівцями. А якщо між цими категоріями учасників проектів немає взаєморозуміння, то результати передпроектних обстежень, виконуваних бізнес-аналітиками, часто перетворюються на документи, що мають мало спільного зі створюваними рішеннями, при цьому виникає певний ризик, що ті або інші вимоги замовників не будуть реалізовані взагалі або будуть неправильно інтерпретовані.

Інструменти UML-моделювання, до яких відноситься і Borland Together компанії Borland, придбали за останні кілька років особливої популярності саме завдяки тому, що являють собою вдале засіб подолання подібних бар'єрів. UML-моделі зазвичай досить зрозумілі для замовників і представників кінцевих користувачів і при цьому можуть слугувати непоганою основою майбутніх програм.

Нижче ми розглянемо деякі особливості нещодавно випущеної нової версії Borland Together Community Edition (а також деяких інших редакцій цього продукту) і розповімо про застосування Together, а також про ті переваги, які можуть отримати команди розробників при його використанні.

Застосування Borland 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 є засобом об'єднання команди розробників і підвищення ефективності роботи всієї команди. Цей продукт може спростити взаємодію з замовниками та полегшити роботу над наступними проектами. Крім того, він інтегрується з найпопулярнішими засобами розробки. Тому розробникам і керівникам проектів варто звернути на нього серйозну увагу.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*