Borland Together та його застосування, CASE-засоби (моделювання), Програмування, статті

Зміст



Говорячи про розробку програмного забезпечення, багато користувачів і замовники мають на увазі в першу чергу написання коду програм та їх впровадження. Причиною цього, як правило, служить досвід, набутий багатьма компаніями в 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

Рис. 1. Use Case-діаграма в Borland Together

Рис. 2. Діаграма послідовностей в Borland Together

Рис. 2. Діаграма послідовностей в Borland Together

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

Проектування


На етапі проектування приймаються рішення щодо архітектури та складових частин створюваного рішення, а також відбираються технології, застосовувані при його реалізації. Зазвичай на цьому етапі до моделі, створеної бізнес-аналітиками, додаються діаграми компонентів і класів створюваних додатків і діаграми розгортання створюваного рішення (рис. 3), а також модифікуються деякі з уже створених діаграм.

Рис. 3. Діаграма розгортання

Рис. 3. Діаграма розгортання

Зазначимо, що Together дозволяє застосовувати шаблони проектування, що багато в чому спрощує проектування і створення часто зустрічаються компонентів рішень, а також створення компонентів і навіть цілих проектів з наперед заданими властивостями.

На цьому ж етапі при необхідності може створюватися логічна модель даних, яка містить діаграми “сутність-зв’язок” (рис. 4), на її основі генерується фізична схема даних для конкретної СУБД, вибраної для реалізації проекту.

Рис. 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>

*

*