Головна

Аналіз вимог і визначення специфікацій програмного забезпечення при об'єктному підході

  1.  I. Аналіз виховних можливостей середовища
  2.  I. Значення і завдання аналізу заготівельної діяльності. Аналіз закупівель сільськогосподарської продукції. Аналіз факторів, що впливають на заготівельний оборот.
  3.  I. ЗНАЧЕННЯ І ЗАВДАННЯ АНАЛІЗУ ВИРОБНИЧОЇ ДІЯЛЬНОСТІ. АНАЛІЗ ВИПУСКУ промислової продукції.
  4.  I. Визначення термінів і предмет дослідження
  5.  I. ЗАСТОСУВАННЯ проективної-демонстраційною технікою В глибинний аналіз З
  6.  II. Аналіз якості закупівель.
  7.  II. АНАЛІЗ ВИРОБНИЧОЇ ПОТУЖНОСТІ ПІДПРИЄМСТВА.

Моделі розроблюваного програмного забезпечення при об'єктному підході засновані на предметах і явищах реального світу. В основі цих моделей також лежить опис необхідного поводження розроблюваного програмного забезпечення, т. Е. Його функціональності, але це поведінка пов'язується з станами елементів (об'єктів) конкретної предметної області.

Таким чином, на етапі аналізу ставляться два завдання:

- Уточнити необхідну поведінку програмного забезпечення, що,

- Розробити концептуальну модель його предметної області з точки зору поставлених завдань.

6.1. UML - стандартна мова опису розробки програмних продуктів з використанням об'єктного підходу.

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


Мал. 6. 1. Об'єктна декомпозиція програми побудови таблиць і графіків.

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

Кінець «війні методів» поклало поява в 1995 р першої версії мови UML (Unified Modeling Language - уніфікована мова моделювання), який в даний час фактично визнаний стандартним засобом опису проектів, створюваних з використанням об'єктно-орієнтованого підходу. Його творцями є провідні фахівці в цій області Граді Буч, Івар Якобсон і Джеймс Рамбо, які використовували в своїй мові все краще, що з'явилося в підходах цих авторів під час «війни методів».

Специфікація програмного забезпечення, що при використанні UML об'єднує кілька моделей використання, логічну, реалізації, процесів, розгортання (рис. 6.2.).

Мал. 6. 2. Повна специфікація програмного забезпечення, що при об'єктному підході (UML).

модель використання є опис функціональності програмного забезпечення з точки зору користувача

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

модель реалізації визначає реальну організацію програмних модулів в середовищі розробки

модель процесів відображає організацію обчислень і оперує поняттями «процеси» і «нитки» Вона дозволяє оцінити продуктивність, масштабованість і надійність програмного забезпечення.

І наостанок, модель розгортання показує особливості розміщення програмних компонентів на конкретному обладнанні.

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

Всього UML пропонує дев'ять доповнюють один одного діаграм, що входять в різні моделі:

- Діаграми варіантів використання;

- Діаграми класів;

- Діаграми пакетів;

- Діаграми послідовностей дій;

- Діаграми кооперації;

- Діаграми діяльності;

- Діаграми станів об'єктів;

- Діаграми компонентів;

- Діаграми розміщення.

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

Крім зазначених діаграм, як і при структурному підході, специфікація обов'язково включає словник термінів, а також різного роду опису і текстові специфікації. Конкретний набір документації визначається розробником. UML і запропонована тими ж авторами методика Rational Unified Process підтримуються пакетом Rational Rose фірми Rational Software Corporation. Ряд діаграм UML можна побудувати також засобами програми Microsoft Visual Modeler та інших CASE-засобів. За даними «USA Today» в даний час 49 з 50-ти провідних комп'ютерних компаній USA використовують UML при розробці програмного забезпечення з використанням об'єктного підходу, що і дозволяє говорити про те, що сьогодні UML фактично став стандартом опису подібних розробок.

6.2. Визначення «варіантів використання».

Розробку специфікацій програмного забезпечення починають з аналізу вимог до функціональності, зазначених в технічному завданні. У процесі аналізу виявляють зовнішніх користувачів програмного забезпечення, що і перелік окремих аспектів його поведінки в процесі взаємодії з конкретними користувачами. Аспекти поведінки програмного забезпечення були названі «варіантами використання» або «прецедентами» (use cases).

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

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

Залежно від мети виконання конкретної процедури розрізняють наступні варіанти використання:

- Основні - забезпечують необхідну функціональність програмного забезпечення, що:

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

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

Варіант використання можна описати коротко або докладно. Коротка форма опису містить: назву варіанту використання, його мета, дійових осіб, тип варіанту використання (основна, другорядна або додаткова) і його короткий опис. Короткий опис варіанта використання Виконання завдання системи рішення комбинаторно-оптимізаційних задач можна представити в наступному вигляді:

 Назва варіантаЦельДействующіе ліцаКраткое опис Тип варіанти  Виконання заданіяПолученіе результатів рішення задачіПользовательРешеніе завдання передбачає вибір завдання, вибір алгоритму, завдання даних і отримання результатів решеніяОсновной

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

Діаграми варіантів використання

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

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

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

зв'язок - взаємодія дійових осіб і відповідних варіантів використання.

Варіанти використання також можуть бути пов'язані між собою. При цьому фіксують зв'язку використання і розширення.

Використання має на увазі, що існує деякий фрагмент поведінки розроблюваного програмного забезпечення, який повторюється в кількох варіантах використання. Цей фрагмент оформляють, як окремий варіант використання і вказують зв'язок з ним типу «використання».

розширення застосовують, якщо є два подібних варіанти використання, що розрізняються наявністю в одному з них деяких додаткових дій. В цьому випадку додаткові дії визначають як варіант використання, який пов'язаний з основним варіантом зв'язком типу «розширення».

На рис. 6.3. наведені умовні позначення, які застосовуються при зображенні діаграм варіантів використання.


а Б В

Мал. 6.3. Основні умовні позначення діаграм варіантів використання: а - дійова особа, б - варіант використання; в - зв'язок.

приклад:

Побудувати діаграму варіантів використання для системи обліку успішності студентів.

Дійовими особами системи є Декан, Заступник декана по курсу і Співробітник деканату. Варіанти використання виявляємо, аналізуючи технічне завдання, і зображуємо на діаграмі, пов'язуючи з відповідними дійовими особами (рис. 6. 4).

Мал. 6. 4. Діаграма варіантів використання системи обліку успішності студентів.

Аналіз варіантів використання показує, що варіант отримання зведення успішності по факультету «використовує» варіант отримання зведення за курсом, що і представлено на діаграмі.

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

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

6.3. Побудова концептуальної моделі предметної області.

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

- Концептуальний рівень, на якому діаграми класів, звані в цьому випадку контекстними, демонструють зв'язки між основними поняттями предметної області;

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

- Рівень реалізації, на якому діаграми класів безпосередньо показують поля і операції конкретних класів.

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

Кожну з перелічених моделей використовують на конкретному етапі. Розробки програмного забезпечення:

- Концептуальну модель - на етапі аналізу;

- Діаграми класів рівня специфікації - на етапі проектування;

- Діаграми класів рівня реалізації - на етапі реалізації.

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

Основним поняттям в моделі ставляться у відповідність класи. клас при цьому традиційно розуміють як сукупність загальних ознак заданої групи об'єктів предметної області. Відповідно до цього визначення на діаграмі класів кожному класу відповідає група об'єктів, загальні ознаки яких і фіксує клас. Так клас Студент об'єднує загальні ознаки групи людей, які навчаються у вищих навчальних закладах. Примірник класу або об'єкт (наприклад, Іванов І.І.) обов'язково має всією сукупністю ознак свого класу і може мати власні ознаки, які не фіксовані в класі. Так, наприклад, крім того, що - Іванов І.І. є студентом, він ще може бути спортсменом, музикантом і т. Д. Строго кажучи, таким власним ознакою є і ідентифікує студента ім'я.

На діаграмах клас зображується у вигляді прямокутника, всередині якого вказано ім'я класу (рис. 6.5, а). При необхідності допускається вказувати характеристики класу, наприклад, атрибути, використовуючи спеціальні секції умовного позначення (рис. 6.5, б).

а б

Мал. 6.5. Позначення класу на концептуальній діаграмі класів: а- без уточнення характеристик, б-з уточненням атрибутів.

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

під ставленням класів розуміють статичну, т. е. не залежну від часу, зв'язок між класами. Розрізняють два основних види відносин: асоціація та узагальнення.

ставлення асоціації означає наявність зв'язку між екземплярами класів або об'єктами, наприклад, клас Студент асоційований з класом Інститут. Асоціація може мати ім'я, наприклад, Навчається. Поруч з ім'ям асоціації ставлять стрілку, яка вказує напрямок читання імені («Студент навчається в інституті», а не навпаки).

Зв'язок між екземплярами класів має на увазі деякі ролі, які відповідні об'єкти грають по відношенню один до одного. Роль пов'язана з напрямком асоціації. Так по відношенню до студентів інститут - організація, що здійснює їх навчання, т. Е. Роль інституту можна назвати Місце навчання. Студент для інституту - об'єкт навчальної діяльності інституту, т. Е. Той, якого навчають. Якщо роль власного імені не має, то можна вважати, що її ім'я збігається з ім'ям класу, по відношенню до якого визначається ця роль. Для розглянутого прикладу це відповідно ролі Студент та Інститут (рис. 6.6, а), але роль можна вказати і явно (рис. 6.6, б).


а Б В

Мал. 6.6. Позначення асоціації: а - із зазначенням імені асоціації та її спрямування; б - із зазначенням імен ролей, в - із зазначенням множинності.

Роль також володіє характеристикою множинності, Яка показує, скільки об'єктів може брати участь в одній зв'язку з кожного боку. Допускається вказувати множинність:

 * - Від 0 до нескінченності;

Ціле .. * - від заданого числа до нескінченності;

Ціле - точно певну кількість об'єктів;

Целое1>, целое2> - кілька варіантів точної кількості об'єктів;

Целое1> .. целое2> - діапазон об'єктів.

З теоретичної точки зору атрибут теж клас, екземпляри якого жорстко асоційовані з даним класом. У концептуальної моделі для відображення відповідних відносин можуть використовуватися як асоціації, так і атрибути. Наприклад, ставлення двох понять Студент та Ім'я можна уявити, як у вигляді асоціації відповідних класів, так і у варіанті, коли класу Студент ставиться у відповідність атрибут Ім'я.

Щоб уникнути зайвих нагромаджень рекомендується слідувати простому правилу: якщо деякий об'єкт Х в реальному світі не є числом або текстом, то це швидше за все поняття. В іншому випадку - це атрибут.

узагальненням називають таке відношення між класами, при якому будь-який об'єкт одного класу (підтипу) обов'язково є також і об'єктом іншого класу, званого в даному контексті супертіп. Так, якщо деякий конкретний студент Іванов І.І. є об'єктом підтипу Студент першого курсу супертіпа Студент, то той же самий Іванов І.І. є об'єктом зазначеного супертіпа. Отже, все, що відомо про об'єкти супертіпа (асоціації, атрибути, операції), стосується і об'єктів підтипу. На діаграмі класів узагальнення позначають лінією з трикутною стрілкою на кінці, що підходить до супертіпа (рис. 6.7).


Мал. 6.7. Позначення узагальнення.

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

- Формують безліч понять - кандидатів з іменників, що характеризують предметну область в описі варіантів використання;

- Виключають поняття, неістотні для даного варіанту використання, наприклад, в попередньому прикладі, «інформація», «введення» і т. Д.

6.4. Опис поведінки. Системні події і операції.

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

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

Системні події і операції.

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

Для побудови діаграми послідовностей системи необхідно:

- Представити систему як «чорний ящик» і зобразити для неї лінію життя - вертикальну пунктиром, яка підходить до блоку знизу;

- Ідентифікувати кожна дійова особа і зобразити для нього лінію життя (багато дійових осіб буває в варіантах спільного використання програмного забезпечення);

- З опису варіанта використання визначити безліч системних подій і їх послідовність;

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

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

Безліч всіх системних операцій визначають, ідентифікуючи системні події всіх варіантів використання. Для наочності системні операції зображують у вигляді операцій абстрактного класу (типу) System. Якщо необхідно розділити безліч операцій на підмножини, що ініціюються різними користувачами, то використовують кілька абстрактних класів: Systeml, System2 і т. Д.

Кожну системну операцію необхідно описати. Зазвичай опис системної операції містить:

- Ім'я операції і її параметри;

- Опис обов'язки;

- Вказівка ??типу;

- Назви варіантів використання, в яких вона використовується;

- Примітки для розробників алгоритмів і т. Д .;

- Опис обробки можливих винятків;

- Опис виведення неінтерфейсних повідомлень;

- Припущення про стан системи до виконання операції (передумова);

- Опис зміни стану системи після виконання операції (постусловіем).




 Визначення вимог до ПО і вихідних даних для його проектування |  Аналіз вимог і визначення специфікації ПО при структурному підході |  тестування ПЗ |  Налагодження програмного забезпечення |

© 2016-2022  um.co.ua - учбові матеріали та реферати