Практика реалізації модуля інтеграції для Rational Software Architect. Частина 1, CASE-засоби (моделювання), Програмування, статті

Введення


Постійна практика роботи з інструментом управління змінами IBM Rational ClearQuest виявила як його позитивні, так і негативні сторони. При безперечно сильному і гнучкому механізмі формування та редагування схем управління змінами – від створення екранних форм до програмування станів і переходів для запитів на зміни (ЗИ) – можна відзначити недолік, пов’язаний саме з програмуванням матриці переходів при програмуванні життєвого циклу (ЖЦ) проходження запиту на зміна.


У простому прикладі менеджер з управління конфігураціями (КК) або менеджер з управління змінами (УІ) повинен сформувати склад ЗИ і описати їх життєвий цикл в діаграмах UML (це так званий абстрактний, описовий рівень, Рисунок 1). Після циклу узгоджень і тверджень діаграма передається реалізатору (можливо, адміністратору УІ), який, базуючись на моделі, створює низькорівневий набір команд для реалізації в IBM Rational ClearQuest.


Даний приклад показує ідеальну модель, яка в недостатній мірі застосовується на практиці. Найчастіше модель не набуває електронного вигляду, а відразу переноситься (програмується) в IBM Rational ClearQuest.


Рисунок 1. Подання життєвого циклу проходження запиту на зміну “Defect” у вигляді діаграми UML

 
Читати частина 2

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


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

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

Ваш отзыв

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

*

*