екранних форм або меню.
Акторам слід присвоїти імена, що відображають їх ролі в роботі з системою.
Визначення варіантів використання. Визначення ВІ виконується на основі аналізу екранів працюючої системи. Спочатку визначаються пакети ВІ. Для цього слід знайти всі первинні екрани і для кожного з них у моделі на головний діаграмі ВІ завести окремий пакет. Таким чином, на цій діаграмі буде пакет акторів і кілька пакетів ВІ.
Далі виконується деталізація побудованих пакетів ВІ на основі аналізу екранних форм. Рекомендовані правила:
В· якщо екран містить меню, то це пакет ВІ. При цьому кожен рядок меню - це або підпакету, або окремий ВІ;
В· якщо основний екран - форма, то це окремий ВІ.
Визначення взаємодій акторів і ВІ. Оскільки дуже важливо показати, як актори співвідносяться з ВІ, після знаходження ВІ визначається, які актори взаємодіють з системою в цьому варіанті. У модель включаються асоціації. Вони мають напрямки, відповідні напрямках передачі інформації між акторами і ВІ.
Розподіл по пакетах. Якщо число акторів або ВІ занадто велике, то для спрощення підтримки моделі ВІ доцільно розділити їх по пакетах. Це також спрощує розуміння моделі і розподіл відповідальності шляхом призначення розробників, відповідальних за пакети ВІ. Можна використовувати такі критерії упаковки ВІ в один пакет:
В· якщо вони взаємодіють з одним актором;
В· мають один з одним відносини включення або розширення (див. статтю В«Варіанти використання системи. Use case діаграми В»). p> Можуть бути й інші способи забезпечення наочності моделі, важливо лише мати чітку стратегію розбиття на пакети.
Побудова навігації екранів. Одночасно з виділенням ВІ будується навігація екранів наследуемой системи у вигляді діаграми класів UML. Кожен екран показується в моделі як окремий клас, в якому полям відповідають атрибути, функціональним кнопкам - операції, а кнопках меню - однойменні відносини.
Деталізація функціональності. Деталізація функціональності являє собою побудову сценаріїв реалізації ВІ, представлених в моделі ВІ. Вона виконується за допомогою діаграм послідовностей і діаграм діяльностей UML. Вибір виду діаграм в кожному конкретному випадку залежить від того, що переважає в даному ВІ - логіка виконання або передачі даних. У першому випадку переважно застосовувати діаграми діяльностей, де легко показувати розгалуження і паралельну обробку, у другому - діаграми послідовностей.
Деталізація потрібно особливо для тих варіантів використання, в яких важлива послідовність дій, враховується стан системи, мається розгалужена логіка виконання. Доцільно деталізувати виконання ВІ, визначальних основну функціональність системи. Якщо замовник висловлює побажання щодо того, що з наследуемой системи має бути збережено в нової ПС, то саме ці ВІ повинні бути деталізовані.
Деталізація здійснюється на основі аналізу вихідних кодів. За текстами програм виявляються розгалуження, вирази, цикли. Це дозволяє відновити алгоритми, представивши їх у вигляді діаграм діяльностей або діаграм станів. Інший шлях - це проведення експериментів з працюючою наследуемой системою. Варіювання вхідних даних і аналіз реакції системи на ці дані робить можливим виявлення розгалужень та обмежень. Можна також висувати і перевіряти гіпотези про алгоритми обчислень.
Моделі, побудовані в результаті реінжинірингу, є основою для визначення вимог до проектованої ПС, а також для побудови логічного і функціональної моделей нової системи.
Цілі і завдання реінжинірингу
В
Цілі реінжинірингу
Цілі проведення реінжинірингу полягають у наступному:
В· отримання подання про склад існуючої системи;
В· моделювання існуючої системи;
В· визначення фрагментів програмного коду, які можуть бути використані в розробляється новій системі;
В· визначення успадкованих даних.
Завдання реінжинірингу
Завдання, які вирішуються при реінжинірингу, включають:
В· визначення системних архітектур;
В· визначення акторів існуючої системи;
В· визначення функціональності існуючої системи;
В· визначення логічної структури системи;
В· відновлення реляційної моделі даних.
Порядок вирішення цих завдань принципово відрізняється від порядку дій, виконуваних при розробці нових проектів. Логічна архітектура системи визначена її реалізацією, зокрема, структурою каталогів, розміщенням файлів по каталогах, розподілом завдань між сервером і клієнтськими місцями. Крім того, частина моделей системи може бути отримана автоматично за допомогою інструментальних засобів. Таким чином, не функціональний опис системи служить основою для виявлення класів і відносин між ними, а навпаки, попередньо отримані діаграми класів можуть істотно полегшити опис поведінки системи.
В
Проблеми ...
