Методологія застосування uml для проектування іс (rup rational Unified Process) Зміст



Скачати 92.76 Kb.
Дата конвертації21.11.2017
Розмір92.76 Kb.



Методологія застосування UML для проектування ІС (RUP - Rational Unified Process)

Зміст


Зміст 2

Вступ 3


Основна частина 3

RUP як методологія 4

Методика проектування інформаційних систем на основі UML 6

Визначення вимог 7

Аналіз 7

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

Реалізація 8

Тестування 9

Висновок 10

Література 11




Вступ


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

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

Одна з найбільш досконалих технологій, яка претендує на роль світового корпоративного стандарту - Rational Unified Process (RUP). RUP являє собою програмний продукт, розроблений компанією Rational Software (www.rational.com), яка нині входить до складу IBM.

Основна частина


Rational Unified Process (RUP) – одна з кращих методологій розробки програмного забезпечення, створена в компанії Rational Software, допомагає створювати складні програмні системи, ґрунтуючись на індустріальних методах розробки. Одним з основних засад, на які спирається RUP, є процес створення моделей за допомогою уніфікованої мови моделювання (UML).

RUP значною мірою відповідає стандартам та нормативним документам, пов'язаним з процесами ЖЦ ПЗ і оцінкою технологічної зрілості організацій-розробників (ISO 12207, ISO 9000, CMM та ін). Основним принципом RUP є ітераційний і інкрементний (нарощуваний) підхід до створення ПЗ. У відповідності з ним розробка системи виконується у вигляді декількох короткострокових міні-проектів фіксованої тривалості (від 2 до 6 тижнів), так званих ітерації. Кожна ітерація включає свої власні етапи аналізу вимог, проектування, реалізації, тестування, інтеграції і завершується створенням дієвої системи.

Ітераційний цикл ґрунтується на постійному розширенні і доповненні системи в процесі декількох ітерацій з періодичним зворотним зв'язком і адаптацією додаються модулі до існуючого ядра системи. Система постійно розростається крок за кроком, тому такий підхід називають ітераційним і інкрементним.

Згідно RUP, ЖЦ ПО розбивається на окремі цикли, в кожному з яких створюється нове покоління продукту. Кожен цикл, у свою чергу, розбивається на чотири послідовні стадії:

• початкова стадія (inception);

• стадія розробки (elaboration);

• стадія конструювання (construction);

• стадія введення в дію (transition).

В основі методології RUP, як і багатьох інших програмних методологій, які об'єднують інженерні методи створення, лежить "покроковий підхід". Він визначає етапи життєвого циклу, контрольні точки, правила робіт для кожного етапу і, тим самим, впорядковує проектування та розробку ПО. Для кожного етапу життєвого циклу методологія задає:

- склад і послідовність робіт, а також правила їх виконання;

- розподіл повноважень серед учасників проекту (ролі);

- склад і шаблони формуються проміжних і підсумкових документів;

- порядок контролю та перевірки якості.

RUP як методологія


Методологія RUP дозволяє об'єднати проектну команду, надаючи в її розпорядження перевірені світовою практикою кращі підходи до розробки ІС. До них відносяться такі процеси життєвого циклу ПЗ, як управління проектами, бізнес-моделювання, управління вимогами, аналіз і проектування, тестування і контроль змін. Впровадження RUP в організації сприяє виробленню якісних внутрішньокорпоративних стандартів та підвищенню загальної культури розробки.

RUP спирається на інтегрований комплекс інструментальних засобів Rational Suite. Він існує в наступних варіантах:

• Rational Suite AnalystStudio - призначений для визначення та управління повним набором вимог до розроблюваної системи;

• Rational Suite DevelopmentStudio - призначений для проектування та реалізації;

• Rational Suite TestStudio - являє собою набір продуктів, призначених для автоматичного тестування додатків;

• Rational Suite Enterprise - забезпечує підтримку повного життєвого циклу ПЗ та призначений як для менеджерів проекту, так і окремих розробників, які виконують кілька функціональних ролей в команді розробників.

До складу Rational Suite, крім самої технології RUP як продукту, входять наступні компоненти:

• Rational Rose - засіб візуального моделювання (аналізу і проектування), який використовує мову UML;

• Rational XDE - засіб аналізу і проектування, інтегрований з платформами MS Visual Studio .NET і IBM WebSphere Studio Application Developer;

• Rational Requisite Pro - засіб керування вимогами, призначений для організації спільної роботи групи розробників. Воно дозволяє команді розробників створювати, структурувати, встановлювати пріоритети, відслідковувати, контролювати зміни вимог, що виникають на будь-якому етапі розробки компонентів програми;

• Rational Rapid Developer - засіб швидкої розробки додатків на платформі Java 2 Enterprise Edition;

• Rational ClearCase - засіб управління конфігурацією ПЗ;

• Rational SoDA - засіб автоматичної генерації проектної документації;

• Rational ClearQuest - засіб для управління змінами та відстеження дефектів в проекті на основі засобів e-mail і Web;

• Rational Quantify - засіб кількісного визначення вузьких місць, що впливають на загальну ефективність роботи програми;

• Rational Purify - засіб для локалізації важко виявлених помилок часу виконання програми;

• Rational PureCoverage - засіб ідентифікації ділянок коду, пропущених при тестуванні;

• Rational TestManager - засіб планування функціонального і навантажувального тестування;

• Rational Robot - засіб запису і відтворення тестових сценаріїв;

• Rational TestFactory - засіб тестування надійності;

• Rational Quality Architect - засіб генерації коду для тестування.

Методика проектування інформаційних систем на основі UML


Уніфікований процес можна представити як суму різних видів діяльності компанії-розробника, необхідних для переведення вимог замовника в програмну систему. Систему, яка давала б «значимий результат» користувачам і виконувала б саме те, що вони очікують від системи. Тому процес управляється варіантами використання (Use Case) системи, або інакше – прецедентами.

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

Вся розробка ПЗ розглядається в RUP як процес створення артефактів.

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



Визначення вимог


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

Для деталізації конкретного прецеденту використовується діаграма активності (Activity Diagram).

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

Також діаграма прецедентів може використовуватися для створення сценаріїв тестування, оскільки всі взаємодії користувача і системи вже визначені.



Аналіз


Після визначення вимог і контексту, в якому буде працювати система, настає черга аналізу отриманих даних. У процесі аналізу складається аналітична модель, яка підводить розробників до архітектури майбутньої системи. Аналітична модель – це погляд на систему зсередини, на відміну від моделі прецедентів, яка показує, як система буде виглядати зовні.

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

На відміну від створюваної надалі моделі проектування, модель аналізу є більшою мірою концептуальною моделлю і тільки наближає розробників до класів реалізації. Ця модель не повинна мати можливих суперечностей, які можуть зустрітися в моделі прецедентів.

Для відображення моделі аналізу за допомогою UML використовується діаграма класів зі стереотипами (зразками поведінки) «граничний клас», «сутність», «управління», а для деталізації використовуються діаграми співробітництва (Collaboration). Стереотип «граничний клас» відображає клас, який взаємодіє із зовнішніми актантами, «сутність» – відображає класи, які є сховищами даних, а керування – класи, керуючі запитами до сутностей.



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


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

Для створення моделі проектування використовуються цілий набір UML діаграм: діаграми класів, діаграми кооперації, діаграми взаємодії, діаграми активності.

Додатково у цьому робочому процесі може створюватися модель розгортання, яка реалізується на основі діаграми розгортання (Deployment Diagram). Це найпростіший тип діаграм призначений для моделювання розподілу пристроїв у мережі. Для відображення використовується всього два варіанти значків процесор і пристрій разом зі зв'язками між ними.

Реалізація


Основне завдання процесу реалізації – створення системи у вигляді компонентів – вихідних текстів програм, сценаріїв, двійкових файлів, виконуваних модулів і т. д. На цьому етапі створюється модель реалізації, яка описує те, як реалізуються елементи моделі проектування, які класи будуть включені в конкретні компоненти. Дана модель описує спосіб організації цих компонентів у відповідності з механізмами структурування і розбиття на модулі, прийнятими у вибраній середовищі програмування і представляється діаграми компонентів.

Тестування


В процесі тестування перевіряються результати реалізації. Для даного процесу створюється модель тестування, яка складається з тестових прикладів, процедур тестування, тестових компонентів, однак не має відображення на UML діаграми, тому не будемо на ньому зупинятися.

Висновок


Отже, були розглянуті лише основні процеси методології Rational. RUP досить великий, і містить рекомендації по веденню різних програмних проектів, від створення програм групою розробників в кілька людей, до розподілених програмних проектів, що об'єднують тисячі людей на різних континентах. Однак, незважаючи їх колосальну різницю, методи застосування моделей, створюваних за допомогою UML будуть одні і ті ж. Діаграми UML, що створюються на різних етапах розробки, невіддільні від інших артефактів програмного проекту і часто є сполучною ланкою між окремими процесами RUP.

Рішення про застосування конкретних діаграм залежить від поставленого в компанії процесу розробки, який, хоча і називається уніфікованим, однак не є щось застигле. Компанія Rational не тільки пропонує його поліпшувати і допрацьовувати, але і надає спеціальні засоби внесення змін в базу даних RUP.



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

Література


  1. Буров Є.В. Система формальних специфікацій для проектування розподілених інформаційних систем [Текст] / Буров Є.В. // Вісник держуніверситету «Львівська політехніка» - Інформаційні системи та мережі. - 2000.- № 406

  2. Буров Є. Застосування виконувальних моделей для проектування сервісно-орієнтованих інтелектуальних інформаційних систем // Режим доступу: http://ena.lp.edu.ua:8080/bitstream/ntb/1218/1/30.pdf

  3. Методика проектирования информационных систем на основе UML // Режим доступу: http://bigor.bmstu.ru/?cnt/?doc=190_CAD/7011.mod/?cou=190_CAD/base.cou

  4. Управление проектом разработки информационной системы // Режим доступу: http://sergeeva-i.narod.ru/inform/page12.htm#_Toc159137879

Каталог: 689517
689517 -> Лексико-семантичне поле посесивності в сучасній англійській мові
689517 -> «Оцінка інвестиційної привабливості підприємства дп
689517 -> Теорія інфляції та аналіз індексів цін
689517 -> "Рослинні угрупування України"
689517 -> Навчально-методичний посібник для студентів спеціальності 010104 «Професійна освіта. Комп’ютерні технології»
689517 -> Створення інформаційно-новинної платформи у мережі інтернет для газети \"Сирець\"
689517 -> "Рослинні угрупування України"
689517 -> Патріотичне виховання дітей старшого дошкільного віку в ігровій діяльності

Скачати 92.76 Kb.

Поділіться з Вашими друзьями:




База даних захищена авторським правом ©uchika.in.ua 2020
звернутися до адміністрації

    Головна сторінка