ATPO_T-4_Zasobi_spetsifikatsiyi_ta_modelyuvannya_vimog


Чтобы посмотреть этот PDF файл с форматированием и разметкой, скачайте его и откройте на своем компьютере.

Дисциплина:
«Анализ требований к ПО» /

проф
. Н.В. Ткачук / каф.
ПИИТУ,
НТУ "ХПИ"

// 2016
-
17



1

Тема 4:
ЗАСОБИ СПЕЦИФІКАЦІЇ
ТА МОДЕЛЮВАННЯ
ВИМОГ

В ПРОЦЕСІ ПРОЕКТУВАННЯ ПЗ



I
.
СП
ЕЦИФІКАЦІЯ
В
ИМОГ

В МЕТОДОЛОГІЇ
RUP

I
.1
.

Текстовий формат специфікація
вимог


В контексті
методології
RUP

вимог
и

(В)

щодо ПЗ

-

це весь н
абір
певних
прецедентів

використання
програмн
ої системи

(
П
С
)
, що проектується
.

П
рецедент

(
Use

Case
)



це набір вз
а
ємопов

язаних
сценаріїв
, який описує
використання
ПС

певним
актором

для вирішення однієї із задач
.

Актор

(
Actor
)

-

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

Сценарій (
S
cenario
)



послідовність дій

або взаємодій між актором та
ПС
.

Первинною формою опису прецедентів є текст, який

має бути
сформованим

у
процесі
виявлення
В

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

опису

прецедентів існує декілька форм:



Свободна форма опису



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



Стислий опис



анотація у вигляді одного абзацу. Вона описує
тільки головний
успішний сценарій.



Розгорнутий опис



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

Найбільш
інформативн
им

та корисн
им

для подальшого використання

В

в проектуванні
ПС
є
р
озгорнутий опис

прецедентів.
Він


має наступний формат
, який
ми
розглянемо
на
приклад
і

розробки
ПС

для
оформлення продаж
ів товару в деякому супермаркеті
:


ПРИКЛАД опису розгорнутого сценарія

прецеден
ту


1
)

Зацікавлені особи

прецеденту

та їх вимоги
:

в цій секції

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



К
асир
:

повинен


точно і швидко обробити дані щодо покупки

кожного покуп
ця
.



Покупець
:

х
оче швидко оформити
свою
покупку з мінімальними
витратами часу.



Керівництво супер
маркету
:

х
оче
мати повну

інформацію щодо всіх
тран
з
акц
ій
касира та
покупців.






Дисциплина:
«Анализ требований к ПО» /

проф
. Н.В. Ткачук / каф.
ПИИТУ,
НТУ "ХПИ"

// 2016
-
17



2


2
)

Користувач ПС тобто о
сновний

актор цього прецеденту
:

це
касир с
упермаркету
,
який працює із
покупцями за допомогою ПС, що має бути розроблена
.

3
)

Передумови
прецед
енту
(
preconditions
)
:

ц
е п
ерелік

по
дій які
завжди повинні

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

виконанням
деякого
іншого прецеден
ту. Наприклад
, це можуть

бути наступні умови



ПС має бути
активною



Касир
повинен

успішно пройти процедуру ау
тентифікації
в ПС



…..

4
)

Основний успішний сценарій
:

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

1.
Касир
починає

оформлення нового
продаж
у

при наявності запиту
певного
покупця
;

2.
Касир вводить ідентифікатор

поточного
товару

із переліку покупця

3. ...



5
)

Розширення
основного сценарію
або альтернативні потоки
:

у цій секції

вказуються
всі інші

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

прецеденту П
С повинна

забезпечити

повер
нення

користувача
в ос
новний сце
нарій
, якщо
в
ПС
не передбачен
о

альтернативний хід подій
.


Наприклад, р
озширення основного сценарію:




Неправильний ідентифікатор

товару

1.

ПС

повідомляє
касира
про помилку і відміня
є

ввід

дан
их щодо поточного

товару
.

2.

У разі необхідності касир
може запросити у ПС і отримати (як підказку)

весь
список

можливих назв товарів та їх і
дентифікаторів.

3.

Касир
повторно
вводить кор
ектний
ідентифікатор товару
.

4.

ПС підраховує та
відображає оновлену проміжну вартість

поточного продажу

(
це є
точка повернення в основній сценарій
)
.


...

6)

Постумови (
postconditions
):

це перелік

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


Дисциплина:
«Анализ требований к ПО» /

проф
. Н.В. Ткачук / каф.
ПИИТУ,
НТУ "ХПИ"

// 2016
-
17



3



дані щодо
продажу

оброблені та збережені

в ПС
,



роздруковано

потрібн
ий

чек
,



транзакція
успішно зафіксована в базі дани
х ПС,



…………………….


7)

Спеціальні вимоги
:

ця секція

опису

містить перелік
нефункціональних
вимог,
атрибут
ів

якості або
певни
х
обмеження

в функціонування ПС
, що
є
пов

язан
ими і
з д
аним
прецедентом.

Наприклад
, це може бути:



Необхідно забезпечити 100%

надійність обробки всіх транзакцій
,



Потрібно забезпечити
м
ожливість локалізації інтерфейсу користувача
ПС
(
тоб
то
підтримка багатомовності

діалогу з ПС
);





8)

Список
необхідних
технологій
та додаткових
пристоїв
:

типовим прикладом можуть

бути технічні вимоги, які висувають зацікавлені особи для технологій вводу/виводу даних
тощо.



ПС має бути розроблена як
Web
-
орієнтована система,



і
дентифікатор товару
з
чит
у
ється
із

штрих
-
коду лазерним сканером;



Для користувача
має бути використан
о

с
енс
орний екран монітору




….


I
.
2. ЗАСТОСУВАННЯ
UML
-
ДІАГРАМ ДЛЯ ОПИСУ ПРЕЦЕДЕНТІВ


Диаграмма вариантов использования
UML

(
Use

Case

Diagram
)


это графическое

представлен
ие основных
В
, которое может быть создано на основе анализа

их текстового
описания.

Её базовые «строительные элементы»


акторы и варианты использов
ания.
Диаграмма задумана так, чтобы дать наиболее общее представление о функциональности
системы (её компоненты),
не вдаваясь в детали взаимосвязей функций

(Прим.
Сравнить этот подход с п.
II.2).

Поэтому основной вид отношения, используемый в
диаграмме


ассоциация между актором и вариантом использования.


Другие виды отношений


отношение включения (
include
), расширения (
extend
) и
обобщения/генерализации.


Дисциплина:
«Анализ требований к ПО» /

проф
. Н.В. Ткачук / каф.
ПИИТУ,
НТУ "ХПИ"

// 2016
-
17



4

Включение служит для обозначения подчинённых вариантов использования (к
огда
один или более вариантов использования содержат вызовы одной и той же
функциональности).


Расширение соответствует точке
разветвления основного сценария

ва
рианта
использования



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


II
.
АЛЬТЕРНАТИВНІ НОТАЦІЇ ДЛЯ СПЕЦИФІКАЦІЇ
В
ИМОГ

II.1.
Таблична форма опису

Також прецедент може бути описаний у фо
рмі двох колонок таблиці.


Предметна область:


«
Програмна система

для автоматизації продаж
»




Основний успішний сценарій:


Дії
основного
актора

1)
К
асир
почина
є

новий продаж






Реакція
ПС


2
)

ПС
відкриває

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

Дисциплина:
«Анализ требований к ПО» /

проф
. Н.В. Ткачук / каф.
ПИИТУ,
НТУ "ХПИ"

// 2016
-
17



5


3
)

Касир вводить ідентифікатор
поточного
товару







5
)

……



К)
Касир
закінчує обробку списку товарів
по
точного
п
окупця




К+2)
Касир інформую покупця та після
сплати
ним
грошей за покупку завершує
обробку

даних

щодо цього продажу
.




К+
4
) Касир передає чек покупцю та
починає оформлення наступного

продажу

тра
нзакцію

в базі даних





4
)

ПС


аналізує ідентифікатор

товару


і
видає його опис, ціну. Ціна обчислюється
на основі набору правил

(наприклад, із
урахуванням можливих
пільг для певних
категорій покупців

тощо
)

…….



...........




К+1)
ПС

обробляє
введені дані та
обчислює

загальну суму
поточного
продажу



К+3)
ПС

завершує транзакцію в базі
даних,
реєструє
поточну
продаж і
друкує ч
ек
.

К+4)

ПС
.




К+5) ПС

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






Дисциплина:
«Анализ требований к ПО» /

проф
. Н.В. Ткачук / каф.
ПИИТУ,
НТУ "ХПИ"

// 2016
-
17



6

II
.2
SADT
-

методо
логи
я структурного анализа и проектирования

ПО




(обновлено
07
.04.1
7

-

НВТ)




SADT (Structured Analysis and Design Technique)
-

одна из самых известных
методологий
структурного
анализа
и проектирования ПО
,
вв
еденная в

программную
инженерию в

1973 г. Россом (Ross).

И
сторически
она
предшествовала объектно
-
ориентированному подходу к анализу и синтезу ПО, однако и в настоящее время
достаточно успешно может применяться для проектирования
некоторых видов
программных

систем, которые
разрабатываются с применением функционально
-
ориентрованного подхода
,
напр.,
это т.н. встроенн
ое ПО

(
embedded

software
)

в
различных
систем
ах

управления

технологическими процессами и подвижными объектами
,

системы
реального времени

(
real
-
tim
e

system
)

и т.п.
[3
-
4]


Основным
логическим

элементом при моделировании
требований в
э
том подходе

является
SADT
-

диаграмма
, которая
графически представляется в нотации
ID
E
F
0
.

В свою
очередь,
она является одной из семейства
нотаци
й
стандарта
IDEF
, который был
разработан в 1981 г.
:

э
то
сокращенное название от термина
Icam

DEFinition
, который
возник
в ходе реализации
в тот период в США
обширной программы по автоматизации
большой группы промышленных предприяти
й (
ICAM



Integrated

Comput
er

Aided

Manufacturing
)

[
3
]
.

Модель

п
роектирования

SADT

/
IDEF
0


основывается на

таких
понятиях как

декомпозиция (
decomposition
),
функциональный блок (
activity

block
),
интерфейсная дуга (
interface

arrow
) и глоссарий проекта (
project

glossary
)
.



Декомпозиция является основным принципом подхода
SADT

/
IDEF
0

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

(ФБ)
.


Кажд
ый ФБ представляет собой некоторую (
достаточно сложную
)

функцию,
которая должна быть реализована в рамках проекти
руемой ПС.
Графически ФБ
.

изобража
е
тся
прямоугольникам
,
который
внутри

имеет название
, сформули
рованное на


естественном языке, описывающим

его

действи
я
.
К
аждая сторона
та
кого
блока имеет
вполне определенное
назначение

и графически с помощью стрелок (интерфейсных дуг)
показывает с
л
едующ
ее
:

левая сторона

-

Вход

(
Input
)
,

правая
-

Выход

(
Output
)
,

верхняя

-

Управ
лени
е

(
Control
)
,

нижняя

-

Механизм

(
Mechanism
)
.
Кроме того, каждый ФБ
на
IDEF
0



диаграмме
может быть пронумерован, например, ФБ с номером А0


(
а
ctivity

number

0

и
т.д
.
).

Общий вид таког
о

ФБ
[
4
]
показан на рис.1
.















Рис. 1
-

Обший вид
ФБ в нотации
IDEF
0



Семантически
эти
графические
обозначения
интерпретируются следующим образом:


Дисциплина:
«Анализ требований к ПО» /

проф
. Н.В. Ткачук / каф.
ПИИТУ,
НТУ "ХПИ"

// 2016
-
17



7

1.

Интерфейс
Вход



это

могут быть

любые
входные данные

(либо сырье, товары
и т.п.


в случае моделирования некоторого производственного

процесса
либо
б
из
нес
-
процесса)
,

которые должны быть обработаны
этим

ФБ
. Э
та
интерфейсная дуга не является обязательной, поскольку в прое
к
тируемой
системе могуть быть

такие

ФБ,

которые не обрабатывают никак
их

входн
ых

данных
, но при этом
генерируют некоторы
й результат (выход).

2.

Интерфейс

Выход


это
результат
выполнения обработк
и входных данных

(
либо
сырья)

в этом ФБ
. Э
то могут быть
:

новые данные

(напр.,

численные
параметры,
полученные в результате расчета)
,
либо новая
информация

(т.е.
приращение знаний о не
котором процессе, явлении и т.д.

-

представленные в
виде текстов системных рекомендаций, графиков и т.д.
),

3.

Интерфейс

Управление



определяет условия

(правила)

и / или ограничен
ия,
алгоритмы,
модели

и т.п.
,
которые определяют, когда и как выполняется соотв.
ФБ
. К
омпоненты этого интерфейса остаются неизменными
во время работы
данного ФБ
, и если некоторая часть компонентов этого интерфейса
(напр.,
некоторая инструкция, правило выпо
лнения и т.п.
) изменяются в ходе работы
этого ФБ,
то при разработки такой
IDEF
0
-
диаграммы
их нужно перенести
в
интерфейс
Вход
.

4.

Интерфейс

Механизм


это
внешние компоненты
системы

(
эксперты /
пользователи
,
ПО, аппаратные
ресурсы и т.п.)
, которые
, возможно (но не
обязательно


см. ниже)

дополнительно

необходимы для

работы этого

ФБ
.


Следует
отметить, что любой
ФБ

по требованиям стандарта

IDEF
0

должен иметь, по
крайней мере, одну управляющую интерфейсную дугу и одну


выходную (
исходящую
),
но при этом он

может не иметь ни одной входящей дуги
. Это и
меет вполне определенный
«инженерный» смысл:
каждый
технологический процесс или подсистема в составе
проектируемой ПС
должен
ваыполняться
по
определенным

правилам (
что показывает
интерфейсная
дуг
а
Управление
) и

должен выдавать некоторый результат (выходящая дуга

Выход
), иначе его
моделирование
не имеет смысла.


Модель
проектируемой ПС в нотации
SADT

/

IDEF0 всегда начинается с
представления системы как единого целого
:
одного
центрального
ФБ

с интерфейсными
ду
гами,
которые поступают на его вход и выходят из него
, отражая связи проектируемой
ПС
, которые выходят
за

предел
ы

рассматриваемой
предметной
области. Такая диаграмма
с одним
центральным ФБ
называется
контекстной диаграммой

(
context

diagram
)

проектируемой с
истеми
.

Пример
такой контекстной диаграммы
при
разработки некоторой
ПС
в

предметной области
:

«Автоматизация банковской деятельности»
показан на рис.
2,
при этом интерфейс
ные дуги: «Платежные документы»

и

«Деньги» отражают ее связь с
двумя
другими предмет
ными областями
: «
Бух
галтерский
учет
на
предприяти
и
»

и

«
Кредито
вание предприятий
-
клиентов
»

соотве
т
ственно
.


При выполнении дальнейшей декомпозиции контекстной диаграммы новые ФБ
размещаются по
«ступенчатой» схеме

в соответствии с их
логической иерарх
ией и
функциональными взаимосвязями, отображаемы
ми

с помощью интерфейсных дуг.




Дисциплина:
«Анализ требований к ПО» /

проф
. Н.В. Ткачук / каф.
ПИИТУ,
НТУ "ХПИ"

// 2016
-
17



8














Р
ис.
2

-

Пример контекстной
IDEF
0
-
диаграмы

[3]

И
ерархи
я

нескольких ФБ, в
ыходы некоторых из которых поступают на вход других

ФБ
,

либо выступают
для них
в качестве управляющих воздействий
,
показа
на на рис.

3
.




























Рис
.
3



Иерархия

нескольки
х

ФБ в сложной
SADT
/
IDEF
0
-
модел
и

[
3
]


Дисциплина:
«Анализ требований к ПО» /

проф
. Н.В. Ткачук / каф.
ПИИТУ,
НТУ "ХПИ"

// 2016
-
17



9


Рассмотрим

более подробно
при
м
ер построения

модели

SADT
/
IDEF
0

для
предметной

области

(
ПрО
)
:

«
Определение кредитоспособности клиента банка
»
.

Вначале
строится ис
ходн
ая

кон
текстн
ая

диаграмм
а

с одним ФБ
-
1
:

«Определение
кр
едитоспособности», которая показана на рис.
4
. На ней определены следующие
интерфейсные дуги

и их компоненты
:

1)

в качестве

интерфейса

входа

для
этого
ФБ
-
1

выделены компоненты
:

«Обучающая выборка»
и
«
Данные о новом клиенте
»
;

2)

управляющими воздействиями

являютс
я компоненты:

«Набор характеристик»,
«М
одель

логистической регрессии»
,
«
Модель дерева решений
»

и «Граничные
значения
»
;

3)

компо
нентами интерфейса
механизм реализации

выступают: «Программное
обеспечение», которое должно быть разработано для решения этой зада
чи, а
также 2 типа его пользователей, а именно
,

«Кредитный эксперт»
-

это лицо,
которое будет
принимать решение о возможности выдачи кредита,
и
«Кредитный

инспектор
»

-

лицо, которое будет непосредственно обслуживать
клиента банка, который обратился по пов
оду выдачи ему кредита
;

4)

интерфейс
выхода
содержит единственный компонент: «Рекомендации по
выдаче кредита»
, т.е. это та информация, которая получается в результате
работы данного ФБ, и на основании которой может быть принято окончательное
решение (
как поло
жительное
,

так и отрицательное
)

относительно возможности
кредитования банком данного клиента.























Рис. 4


Исходная контекстная диаграмм для

заданной ПрО



Дисциплина:
«Анализ требований к ПО» /

проф
. Н.В. Ткачук / каф.
ПИИТУ,
НТУ "ХПИ"

// 2016
-
17



10


Н
а рис. 5 показан

р
е
зультат

декомпозиции контекстной диаграммы в виде 2
-
х ФБ, а
именно: ФБ
-
1.1 «Построение модели»


и ФБ
-
1.2 «Оценка кредиспособности», каждый из
которых

уже

имеет св
ои
интерфейсные дуги
.

В

частности,
отсюда

видно, что
компонент
интерфеса
выход
а

(

т.е. результат работы)

ФБ
-
1.1
-

«Модель оценивания»
,
-


является
одним из
компонентов
интерфейса управления

для следующего ФБ
-
1.2 «Оценка
кредиспособности»

(см. рис.5).














Р
ис.

5

-


Результат д
екомпозици

контекстной диаграммы
из рис. 4


Более детальные сведения о методике построения более сл
ожных
SADT
/
IDEF
0



диаграмм см. в
[4].


II
.3

Диаграмма потоков данных

Диа
грамма потоков данных (
Data

Flow

Diagram

-

DFD
)


один из основных
инструментов структурного анализа и проектирования
ПО
,
которые использовались до
появления
UML
. Несмотря
на переход

от структурного к объектно
-
ориентированному
подходу
, структурные нотации

по
-
прежнему широко и эффективно использую
тся как в
бизнес
-
анализе, так и при разработке ПО
на этапе сбора и анализа
требований

(
см., напр.,
в
[4])
.


На

рис.

6


показан пример
DFD
-
диаграммы

При этом используются следующие обознач
ения (т.е. элементы нотации
DFD
)



потоки данных



это направленные стрелки с текстовым комментарием
(«Запрос на поставку», «Остатки» и т.д.);


Дисциплина:
«Анализ требований к ПО» /

проф
. Н.В. Ткачук / каф.
ПИИТУ,
НТУ "ХПИ"

// 2016
-
17



11



внешн
яя

сущност
ь
-

это

внешние элементы

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

именами
(напр., «Клиент»

и т.п.
);


.



Рис. 3


Пример
DFD
-
диаграммы

для ПрО

«Поставки
товаров
клиент
ам
»



процессы



это существующие в
нутри
пр
оектируемой
системы
алгоритмы
преобразования информации, порождающие новые потоки данных



они
обозначены
диаграмме
как овалы

с соответствующими названиями

(напр.,
«Зарегистрировать запрос» и т.п.);




накопители данных



это любые структуры
и
для хранения

данных

(отдельные
файлы, локальные БД, удаленные
БД и т.п.
)
, которые
могут поступать на вход к
некоторым
процессам, помещаться
и
извлекаться
другими

процессами, а затем и

передаваться

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



DFD
-
диаграммы, как и ранее рассмотренные
SADT

/
IDEF
0
-
модели, могут
объединяться в иерархические структуры, которые описывают сложные объекты и
процессы

в
соответствующей

ПрО

(см.

дополн.

[
3
-
4]
)
.



Дисциплина:
«Анализ требований к ПО» /

проф
. Н.В. Ткачук / каф.
ПИИТУ,
НТУ "ХПИ"

// 2016
-
17



12


КОНТРОЛЬН
Ы
Е ВОПРОСЫ



Текстовый формат описания требований

1.

Объясните
основные

термины описания прецедента
в методологии
RUP
.

2.

На конкретном примере покажите процесс построения текстового описания
прецед
ента по
RUP
-
шаблону.


Use

Case

диаграммы
UML

3.

Для какого этапа проектрования ПО используется этот вид диаграмм?

4.

Какие элементы вхо
ят в состав
Use

Case

диаграммы
? Покажите и объясните их
назначение на конеретном примере такой диаграммы.

5.

Какой основной тип от
ношений между элементами используется в этих
диаграммах?

6.

Что такое отношение включения («
include
»)

и для чего оно используется?

7.

Чем отличается отношение расширения («
extend
»)

от отношения включения

include
»)?


Модели SADT

8.

Является ли методология анализа

и проектирования SADT объектно
-
ориентированной? Что означает это название?

9.

Из каких основных компонентов состоит SADT


модель представления СТ в
некоторой ПрО?

10.

Как выглядит базовый функциональный блок SADT , какие интерфейсы он имеет?

11.

В какие структуры

могут объединяться отдельные SADT


диаграммы? Приведите
пример такого представление конкретной SADT
-
модели
.


DFD



диаграммы

12.

Для чего примен
я
е
тся этот вид диаграмм?

Чем они отличаются от
UML
-
диаграмм?

13.

Какие основные структурные элементы входят в состав
D
FD



диаграмм?
Объясните их назначение на примере конкретной
DFD



диаграммы

14.

Что представляет собой
накопители данных

в
DFD



диаграммах?

15.

Как обозначаются
потоки данных

на
DFD



диаграммах? Какие структурные
элементы
DFD



диаграмм могут их порождать?



Лектор


проф. Н.В. Ткачук



Дисциплина:
«Анализ требований к ПО» /

проф
. Н.В. Ткачук / каф.
ПИИТУ,
НТУ "ХПИ"

// 2016
-
17



13

Доп.
источники инф
-
и


1.

Мацяшек Лешек, А. Анализ требований и проектирование систем. Разработка
информационных систем с использованием UML.: Пер. с англ.
-

М.: Издательский
дом "Вильямс", 2002.
-

432 с..

2.

Крэг Ларман

Применени
е
UML

2.0
и
шаблонов

проектирования.
Практическое
руковолство, 3
-
е издание.Пер. с англ.
-

М.
ООО «
И.Д.
Вильямс», 200
9


736 с.

3.

Кулябов Д.С., Королькова А.В. Введение в формальные методы описания бизнес
-
процессов: Учеб. пособие.


2008.


173 с.






Приложенные файлы

  • pdf 17448152
    Размер файла: 496 kB Загрузок: 0

Добавить комментарий