Спосіб опису функціональних вимог до системи та її функцій з використанням стандартів і універсальної мови моделювання, CASE-засоби (моделювання), Програмування, статті

Автори: Алфімов Р.В., Краснікова С.А., Золотухіна Е.Б. (Сертифікований фахівець з рішенням IBM Rational, викладач в Навчально-консалтинговий центр компанії “Інтерфейс”).

Значною популярністю при розробці автоматизованих систем в даний час в Росії користується універсальна мова моделювання (Unified Modeling Language – UML). Незважаючи на безумовні плюси, використання UML пов’язане з рядом труднощів методичного характеру, на які ми хотіли б звернути увагу читача. Перш за все, в UML вводиться власний понятійний апарат, в рамках якого традиційні терміни й поняття, пов’язані зі створенням автоматизованих систем і використовуються протягом десятиліть, замінюються на терміни та поняття, що не знайшли поки що повною мірою відображення в міжнародних і вітчизняних стандартах в області інформаційних технологій.

Особливо це стосується базового елемента мови UML “Use Case”, який трактується вітчизняними перекладачами як “варіант використання”, “прецедент”. При цьому контекст, в якому перекладається термін, не враховується. Незважаючи на те, що поняття активно використовується вже досить давно – плутанини виникає все більше і більше. Так, учасники деяких Інтернет-форумів дійшли до того, що порівнюють “Use Case “з технічним завданням. На думку авторів, все це обумовлено стандартним описом UML, не пов’язаним з процесом розробки автоматизованих систем (АС), а також упущеної можливістю при перекладі оригіналу таке зіставлення зробити. До того ж існуючі сучасні методики створення програмних систем від провідних світових виробників, заснованих на використанні UML та інших нотациях, до жаль, більшості вітчизняних розробників в оригіналі просто не доступні.

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

У даній статті представлений спосіб опису функціональних вимог до АС і її функцій з використанням стандартів в області інформаційних технологій, сучасних методологій створення АС, і діаграм “Use Case Diagram “і” Actvity Diagram “універсальної мови моделювання UML 2.0. Автори розраховують, що використання” Use Case “в контексті визначення вимог у відповідності зі стандартами створення АС придбає більшу ясність.

Отже, розглянемо процес визначення вимог згідно з чинними вітчизняним стандартам.

При використанні стандартів створення АС у відповідності з [1, 2] на стадії “Технічне завдання” в документі технічне завдання (ТЗ) фіксуються функціональні та нефункціональні вимоги до АС. Схема функціональної структури АС розробляється на стадії “Ескізне проектування” і “Технічне проектування”, опис автоматизуються функцій АС виробляється на стадії “Технічне проектування”.

При розробці АС відповідно до [1] повинні бути відстежені зв’язку між функціональними вимогами до системи і функціями системи, їх реалізують. Функції системи в свою чергу повинні бути детально описані.

У табл. 1. представлені стадії робіт зі створення АС і документи, формованими на стадіях, пов’язаних з описом вимог і функцій [1-3].

Як видно з табл. 1, створення АС на стадіях 3-5, передбачає підготовку:


Таблиця 1. Стадії створення АС і документи, пов’язані з вимогами до АС і функціями, їх реалізують

























№ стадії по ГОСТ 34.601-90

Найменування
стадії за ГОСТ 34.601-90

Документи, моделі, створювані на стадіях по

ГОСТ 34.602-89,
ГОСТ 34.201-89

ГОСТ, в якому описаний документ

3


Технічне завдання


Технічне завдання (ТЗ)


ГОСТ 34.602

4


Ескізне
проектування


Схема функціональної структури


РД 50-34.698-90 п. 2.3.

5


Технічне
проектування


Схема функціональної структури


Опис автоматизуються
функцій


РД 50-34.698-90 п. 2.5

 

 

 

 

 

 

Відповідно до [4] ТЗ на АС є документ, оформлений в установленому порядку та визначає цілі створення АС, вимоги до АС і основні вихідні дані, необхідні для її розробки, а також план-графік створення АС.

У ТЗ визначаються:


Функціональні вимоги до системи визначають, дії системи, які вона повинна виконувати. Функціональні вимоги реалізуються через функції системи [5]. Під функцією АС мається на увазі сукупність дій АС, спрямована на досягнення певної мети або аспект певної поведінки системи [6], а під завданням – функція або частина функції АС, що представляє собою формалізовану сукупність автоматичних дій, виконання яких призводить до результату заданого виду [4].

Не функціональні вимоги є обмеження, що накладаються на роботу системи, і стандарти, яким повинна відповідати система [5].

У схемі функціональної структури [7] відображаються елементи функціональної структури АС (підсистеми АС), автоматизовані функції та (або) задачі (комплекси задач), сукупності дій (операцій), що виконуються при реалізації автоматизованих функцій тільки технічними засобами (автоматично) або тільки людиною.

В описі автоматизуються функцій [7] наводять:


Тепер розглянемо визначення вимог з використанням поняття “Use Case”. Як уже говорилося раніше, в стандарті UML відсутня прив’язка до стадій створення АС, однак, виробники CASE – засобів для роботи з UML і методологій використання UML, як правило, пропонують схожі підходи до роботи з вимогами.

Розглянемо, наприклад, підхід компанії Sparx System, яка є виробником інструментарію Еnterprise Architect, що підтримує створення моделей предметної області та АС з використанням UML 2.0. Ними запропоновано шаблон моделі вимог, представлений на рис. 1. На рис. 2 представлений приклад моделі вимоги з використанням шаблону.

Як видно з шаблону моделі вимог і його прикладу для моделювання вимог пропонується використати елемент UML “Requirement”. Для моделювання функцій системи пропонується використовувати елемент “Use Case”. При цьому елемент “Use Case” в описі UML, представленому в інструменті Еenterprise Architect, трактується наступним чином: “Use Case elements are used to build Use Case models. These describe the functionality of the system to be built. Use Case Model describes a system”s functionality in terms of  Use Cases”.

Іншими словами, елемент “Use Case” використовується для побудови моделі “Use case Model”. Модель “Use case Model” використовується для опису функціональності системи.

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

У специфікаціях OMG UML (UML Superstructure Specification, v2.0, p. 17) елемент “Use Case” визначається як: “The specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system”.

Іншими словами, елемент “Use Case” визначає послідовність дій системи, які вона може виконувати, включаючи її взаємодія з користувачем системи.

Рис. 1. Спосіб моделювання вимог до системи


 
Рис. 2. Приклад реалізації вимоги
 
 

У доповненні до сказаного вище, хотілося представити визначення моделі “Use Case Model” з популярного в нашій країні і за кордоном процесу розробки систем Rational Unified Process компанії IBM: “The use-case model is a model of the system “s intended functions and its environment …” [5] (рис. 3).

Рис. 3. Визначення моделі “Use Case Model”

 

Модель “Use case Model” є модель передбачуваних функцій системи та її оточення, і служить контрактом між клієнтами і розробниками. Модель використовується як істотні вхідні дані в діяльності з аналізу, проектування і тестування.

У табл. 2 представлено порівняння визначень схеми функціональної структури відповідно до ГОСТ і моделі “Use Case Model”, функції системи і елемента “Use Case” відповідно до описом UML 2.0.

Таблиця 2. Порівняння визначень моделей та їх елементів 















Визначення схеми функціональної структури


Визначення моделі “UseCaseModel”


У схемі функціональної структури відображаються елементи функціональної структури АС (підсистеми АС), автоматизовані функції та (або) задачі (комплекси задач), сукупності дій (операцій), що виконуються при реалізації автоматизованих функцій тільки технічними засобами (автоматично) або тільки людиною


Use Case elements are used to build Use Case models. These describe the functionality of the system to be built.


Use Case Model describes a system”s functionality in terms of Use Cases


Визначення функції


Визначення елемента “UseCase”


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


The specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system.


 

Порівняння визначення схеми функціональної структури з визначенням моделі Use Case Model, визначення функції системи та елементів “Use Case” показує, що ці моделі та елементи порівняти один з одним.

Таким чином, для моделювання вимог до АС ми будемо використовувати елемент вимога “Requirement”, а функцій, що реалізують вимога, елемент “Use Case”.

Відповідно до [2] опис функціонального вимоги повинно включати, пов’язані з вимогою: функції системи, користувачів системи, друковані документи, що імпортуються / експортуються дані, правила та обмеження, нефункціональні вимоги, зв’язку між функціональними вимогами, екранні форми.

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


Шаблон опису вимоги

Загальні відомості про вимогу



























1.               


Вимога


Повинно бути автоматизовано формування звіту про залишки товару


2.               


Мета, яка буде
досягнута при реалізації
вимоги


Оперативне отримання інформації про поточні залишки на складі компанії


3.               


Причина виникнення
вимоги


Вимога керівника компанії


4.               


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


Керівник компанії


5.               


Джерело даних (ручне введення, використання записів БД, даних з суміжної системи)


Звіт повинен формуватися на основі записів у базі даних, що містять інформацію про кількість залишків товару на складі


6.               


Правила, пов’язані з
вимогою


Звіт формується в двох примірниках

Функції, що реалізують вимоги










Назва функції


1.  


Формування звіту “Залишки товару”

Зв’язки між вимогою і функціями

У розділі має бути представлена ​​модель, що відображає зв’язок між вимоги і функціями, що реалізують вимогу, і якщо потрібно, опис зв’язків. Модель “Вимога і функції”:

Опис процесу виконання функції

У розділі повинні бути представлені моделі процесу виконання функції та їх опис. Основні етапи формування звіту:

Пошук товару:

Друк звіту:

 


Опис процесу виконання функції “Формування звіту про залишки”
























































































Користувач


Система


Екранна форма


Умова:
наступний крок


Передумова: Відображено вікно з головним меню системи

1.     


Вибір пункту меню “Звіти-> Залишки”


 


Головне меню


 

2.     


 


Відображення вікна для введення параметрів


Створити звіт


 

3.     


Введення дати, найменування товару, натискання кнопки “ОК”



Створити звіт


 

4.     



Пошук товару


Створити звіт


Товар знайдений: 5


Товар не знайдений: 10

5.     



Закриття вікна “Створити звіт”


Створити звіт


 

6.     



Відображення вікна “Попередній вид звіту”


Попередній вид звіту


 


 

7.     


Натискання кнопки “Друк”



Попередній вид звіту


“Друк”: 8


“Скасувати”: 9

8.     



Висновок звіту на друкувальний пристрій


Вікно “Повідомлення про друк”


9.     



Закриття вікна “Повідомлення про друк” і “Попередній вид звіту”


Вікно “Повідомлення про друк”, Попередній вид звіту


“Друк”: П1


“Скасувати”: П3


Постусловіем 1: Відображено вікно “Створити звіт”. Вміст полів вікна “Створити звіт” зберегло введені користувачем значення. Звіт віддруковано


 

10. 



Повідомлення про те, що товар не знайдений, закриття вікна “Товар не знайдений”


Товар не знайдено



Постусловіем 2: Відображено вікно “Створити звіт”. Вміст полів вікна “Створити звіт” зберегло введені користувачем значення. Звіт не сформований

 



Постусловіем 3: Відображено вікно “Створити звіт”. Вміст полів вікна “Створити звіт” зберегло наведені користувачем значення. Звіт не віддруковано

           

 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


Склад, екранних форм, пов’язаних з функцією





















Назва екранної форми

1.  

Головне меню

2.  

Створити звіт

3.  

Товар не знайдено

4.  

Попередній вид звіту

5.  

Повідомлення про друк


 


 


 


Опис друкованих форм










Назва друкованої форми


1.  


Звіт про залишки

 


 


Опис імпортованих / експортованих даних (імпортованих даних немає)










Імпортовані дані


1.  


      

 










Експортовані дані


1.  


        

 


Нефункціональні вимоги, пов’язані з функціональним вимогою

Тимчасової регламент

Якщо потрібно в розділі вказується час виконання функції. Час формування звіту не повинен перевищувати 5 сек.

Надійність

Якщо потрібно в розділі вказується вимоги до надійності виконання функції.

Точність

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

Достовірність

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

Зв’язки з іншими функціональними вимогами

Якщо потрібно, в розділі вказуються зв’язку між вимогами.

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

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


Список літератури




  1. ГОСТ 34.601-90 “АВТОМАТИЗОВАНІ СИСТЕМИ. СТАДІЇ СТВОРЕННЯ”;


  2. ГОСТ 34.602-89 “ТЕХНІЧНЕ ЗАВДАННЯ НА СТВОРЕННЯ АВТОМАТИЗОВАНОЇ СИСТЕМИ”;


  3. ГОСТ 34. 201-89. ВИДИ, комплектність і позначення документів при створенні автоматизованих систем;


  4. ГОСТ 34.003-90. “АВТОМАТИЗОВАНІ СИСТЕМИ. ТЕРМІНИ І ВИЗНАЧЕННЯ”;


  5. IBM/RATIONAL UNIFIED PROCESS;


  6. ГОСТ Р ІСО / МЕК 15026-2002. ІНФОРМАЦІЙНА ТЕХНОЛОГІЯ. РІВНІ ЦІЛІСНОСТІ СИСТЕМ І ПРОГРАМНИХ ​​ЗАСОБІВ;


  7. РД 50-34.698-90. “АВТОМАТИЗОВАНІ СИСТЕМИ. ВИМОГИ ДО ЗМІСТУ ДОКУМЕНТІВ”;


  8. ГОСТ 28806-90. ГОСТ ЯКІСТЬ ПРОГРАМНИХ ​​ЗАСОБІВ. ТЕРМІНИ І ВИЗНАЧЕННЯ;

 

 

 

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


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

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

Ваш отзыв

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

*

*