ИЯ_ТАП

Инженерный язык. Расширение для требований, анализа и
проектирования
Содержание
1. Область применения .................................................................................................2
1.1.
Назначение ..........................................................................................................2
1.2.
Ссылки .................................................................................................................2
1.3.
Определения ...................................................... Error! Bookmark not defined.
2. Требования .................................................................................................................3
2.1.
Модель требований ............................................................................................3
2.1.1. Используемые примитивы ............................................................................3
2.1.2. Описание применения ...................................................................................3
2.2.
Модель требований к интерфейсу (Use-case storyboard) ................................4
2.2.1. Используемые примитивы ............................................................................4
2.2.2. Описание применения ...................................................................................5
2.3.
Типовые правила структурирования моделей требований ............................6
3. Анализ и проектирование .........................................................................................8
3.1.
Модель анализа ...................................................................................................8
3.1.1. Используемые примитивы ............................................................................8
3.1.2. Описание применения ...................................................................................9
3.2.
Типовые правила структурирования модели анализа...................................11
3.3.
Модель проектирования ..................................................................................11
3.3.1. Используемые примитивы ..........................................................................12
3.3.2. Описание использования ............................................................................12
3.4.
Типовые правила структурирования модели проектирования ....................13
3.5.
Модель развёртывания .....................................................................................16
3.5.1. Используемые примитивы ..........................................................................16
3.5.2. Описание использования ............................................................................16
3.5.3. Структура модели развертывания..............................................................17
1. Область применения
1.1. Назначение
Настоящий документ определяет инженерный язык, используемый в процессах
формирования требований, анализа и проектирования.
1.2. Ссылки
[1]. Инженерный язык. Общее руководство.
2. Требования
2.1. Модель требований
Модель требований является специализацией модели вариантов использования
UML. Для детализации вариантов использования используются диаграммы действий
UML.
2.1.1.
Используемые примитивы
См. [1] подраздел 4.1.1. Основные элементы.
См. [1] подраздел 4.3.1. Основные элементы.
2.1.2.
Описание применения
Модель требований к системе – это модель предполагаемых функций системы и её
окружения, которая является контрактом между потребителем и разработчиками.
2.1.2.1. Пример использования
Посылка уведомлений
Размещение заказа
Продавец
Покупатель
Выставление счета
Оплата счета
Рис. 1 – Фрагмент модели требований
Выполнение банковской
операции
: Клиент МЦР
МЦР
Создание
сообщения
Сообщен
ие
[создано]
Отправка
сообщения
Сообщение
[отправлено]
Рис. 2 - Детализация варианта использования "Рассылка справочной информации"
2.2. Модель требований к интерфейсу (Use-case storyboard)
Примечание – Используется только при наличии сложного пользовательского интерфейса.
Статическая модель определяется с помощью моделей статической структуры UML.
Динамическая структура определяется с помощью моделей взаимодействий UML.
2.2.1.
Используемые примитивы
2.2.1.1. Стандартные элементы
См. [1] подраздел 4.2.1. Основные элементы.
2.2.1.2. Расширения UML
Новые элементы модели требований к интерфейсу, их нотация и назначение
приведены Табл. 1.
Табл. 1
Базовый элемент
модели (UML)
Класс
Model
Element
(UML)
Class
Стереотип
Нотация
Назначение
Boundary. Моделирует
взаимодействие между
внешним агентом и
системой.
<<boundary>>
Boundary1
Класс
Class
Внешний
агент.
Соответствует
внешнему агенту на
модели
внешнего
окружения.
<<actor>>
Предъявляющий счета
(from Actors)
2.2.2.
Описание применения
Модель требований к интерфейсу является логическим и концептуальным
описанием того, как вариант использования реализуется с помощью пользовательского
интерфейса, с помощью взаимодействия между пользователем и системой. Модели
статической структуры описывают boundary классы, участвующие в реализации варианта
использования и их отношения. Модели взаимодействий (модели последовательностей и
сотрудничества) описывают взаимодействия между внешними агентами и boundary для
выполнения варианта использования.
2.2.2.1. Примеры использования
1..n
1
Почтовый ящик
1
n
Пользователь почты
1
Почтовое сообщение
n
Файловое дополнение
Рис. 3 – Фрагмент модели требований к интерфейсу
1: начать с показа почтовых ссобщений
2: расположить согласно критерию(отправитель, тема)
7: закончть работу с пришедшими сообщениями
: Почтовый ящик
: Пользователь
почты
3: прочитать почтовое сообщение
4: сохранить почтовое сообщение
5: сохранить файловые дополнения
6: сохранить файловое дополнение
: Почтовое сообщение
Рис. 4 - Фрагмент модели требований к интерфейсу
: Файловое дополнение
2.3. Типовые правила структурирования моделей требований
Для структурирования модели требований может использоваться следующая
структура. В Табл. 2 указана структура модели требований.
Табл. 2
Элемент модели

(package) Use-Case Model
o
o
(package) Actors

(use-case diagram) Внешние агенты

(<<actor>>) Внешний агент 1
(package) Use Cases

(use-case diagram) Варианты использования

(package) Вариант использования 1
o
(use-case diagram) Вариант использования 1
Описание
Стандартный
пакет.
Внешние агенты
моделируемой
системы.
На одной или
нескольких
диаграммах
изображаются
внешние агенты
и
отношения
наследования
между ними.
Для
каждого
внешнего агента
должно
быть
указано:

описание
роли
по
отношению
к
моделируем
ой системе
(ее
предприятия
м);

примеры
(экземпляры
) внешнего
агента.
Стандартный
пакет
На одной или
нескольких
диаграммах
изображаются
варианты
использования
системы (в виде
use-case) и их
связи
с
внешними
агентами
и,
возможно,
с
другими
вариантами
использования.
Модель варианта
использования
Вариант
использования1.
На одной или
нескольких
диаграммах
показываются
связи варианта
использования
Вариант
использования1
с
другими
вариантами
использования и
o
(<<use-case>>) Вариант использования 1


(activity diagram) Вариант использования 1
(package) Boundary
o
(class diagram) Boundary
o
(<<boundary) Boundary
внешними
агентами.
Вариант
использования.
Одна
или
несколько
диаграмм
действий,
раскрывающих
ход
выполняемого
варианта
использования.
Классы boundary
системы
На одной или
нескольких
диаграммах
изображаются
boundary-классы,
и
отношения
между
ними
(наследование,
ассоциации,
агрегации,
композиции).
Также
на
диаграммах
могут
присутствовать
классы –внешние
агенты из пакета
Внешние агенты.
Для
каждого
класса
должно
быть указано:
- назначение (в
реализации
какого варианта
использования
участвует);
- характеристика
содержания
артефакта
(краткая,
если
указаны
атрибуты
и
полная,
если
артефакт
не
детализируется
атрибутами);
3. Анализ и проектирование
3.1. Модель анализа
Концептуальная (логическая) модель системы, в которой не рассматриваются
особенности среды реализации. Используются модели статической структуры и модели
взаимодействий.
3.1.1.
Используемые примитивы
3.1.1.1. Стандартные элементы
См. [1] подраздел 4.2.1. Основные элементы и раздел 4.4. Модели взаимодействия.
3.1.1.2. Расширения UML
Новые элементы модели анализа, их нотация и назначение приведены в Табл. 3.
Табл. 3
Базовый
элемент
модели
(UML)
Класс
Model
Element
(UML)
Class
Стереотип
Нотация
Назначение
<<entity>>
Order
Класс
Class
<<control>>
Reporter
(from Controls)
Класс
Class
Информационный класс. Используется
для моделирования информации,
которая
должна
храниться,
и
связанного
с
ней
поведения.
Информационные
объекты
используются,
чтобы
хранить
информацию о некотором феномене,
событии,
или
другом
объекте
реального времени. Эти объекты
обычно являются долгоживущими.
Управляющий класс. Используется
для моделирования управляющего
поведения, специфичного для одного
или
нескольких
вариантов
использования. Управляющие классы
инкапсулируют
поведение,
специфичное
для
вариантов
использования.
Интерфейсный класс. Используется
для моделирования взаимодействий
между окружением системы и её
внутренними работами.
<<boundary>>
Boundary1
Для классов анализа существуют ограничения на допустимые ассоциации. А
именно, допускаются ассоциации, перечисленные в Табл. 4.
Табл. 4
От\К
(направление
ассоциации)
Интерфейсный класс
Информационный класс
Управляющий класс
Интерфейсный
класс
Да
Да
Да
Информационный
класс
Не рекомендуется
Да
Не рекомендуется
Управляющий
класс
Да
Да
Да
Примечание – Направление ассоциации от Класса 1 к Классу 2, означает, что Класс1 инициирует
взаимодействие с Классом 2.
3.1.2.
Описание применения
Статические модели анализа используются для описания логической структуры
системы. Статические модели содержат описание имеющихся в системе контроллеров,
сущностей и граничных классов. Статическая модель анализа специализирует модель
статической структуры UML (см. [1] подраздел 4.2. Модели статической структуры). На
основе классов вводятся новые элементы модели –управляющие классы, информационные
классы и интерфейсные классы.
Динамические модели описывают взаимодействия классов анализа в рамках
выполнения вариантов использования. Динамическая модель анализа специализирует
модели взаимодействия в UML (см. [1] подраздел 4.4. Модели взаимодействия).
3.1.2.1. Примеры использования
Рис. 5 – Фрагмент модели анализа
Рис. 6 – Фрагмент модели анализа
: Предъявляющий счета
: BillTransport
P
P
P
: Bill
: Бухгалтер
Рис. 7 - Фрагмент модели анализа
: AccountantUI
: Accepter
: AccountantUI
: Бухгалтер
getBillParameters
: Reporter
: Bill
makeBill(BillParamete...
<<create>>
: Issuer
: BillTransport
Каждый control создается перед первым к нему
вызовом
issueBill(Bill)
deliver(Deliverable)
Рис. 8 – Фрагмент модели анализа
3.2. Типовые правила структурирования модели анализа
Для структурирования модели анализа может использоваться следующая структура.
В Табл. 5 указана структура модели анализа.
Табл. 5
Элемент модели
Logical View

(package) Analysis Model
o (package) Entities

(class diagram) Информационные классы.
o

(<<entity>>) Информационный класс 1
(package) Controls

(class diagram) Управляющие классы.
o

(<<control>>) Управляющий класс 1
(package) Boundaries

(class diagram) Интерфейсные классы.
o

(<<boundary>>) Интерфейсный класс 1
(package) Use-case realizations

(package) Вариант использования 1

(sequence diagram) Поток событий1
Описание
Стандартный пакет.
Информационные классы системы.
На одной или нескольких диаграммах
изображаются
информационные
классы и их отношения.
Информационный класс.
Стандартный пакет.
На одной или нескольких диаграммах
изображаются управляющие классы и
их отношения.
Управляющий класс.
Стандартный пакет.
На одной или нескольких диаграммах
изображаются интерфейсные классы и
их отношения.
Интерфейсный класс.
Стандартный пакет.
Модель
варианта
использования
Вариант использования1.
На одной или нескольких диаграммах
изображаются возможные потоки
событий в рассматриваемом варианте
использования.
3.3. Модель проектирования
Модель системы с учетом особенностей среды реализации. Модель проектирования
использует диаграммы классов, описывающие структуру системы, и диаграммы
взаимодействия, описывающие реализацию вариантов использования системы.
3.3.1.
Используемые примитивы
3.3.1.1. Стандартные элементы
См. [1] подраздел
взаимодействия.
4.2.1.
Основные
элементы
и
подраздел
4.4.
Модели
3.3.1.2. Расширения UML
Новые элементы модели проектирования, их нотация и назначение приведены в
Табл. 6.
Табл. 6
Базовый
элемент
модели (UML)
Пакет
Model
Element
(UML)
Package
Стереотип
Нотация
<<subsystem>>
<<subsystem>>
DataStorage
3.3.2.
Назначение
Подсистема
проектирования.
Одновременно имеет
семантику пакета (т.к.
содержит
другие
элементы модели) и
класса
(т.к.
имеет
поведение).
Может
содержать классы и
другие
подсистемы.
Реализует один или
более интерфейсов.
Описание использования
Модель проектирования представляет собой абстракцию реализации системы.
Статические модели проектирования используются для описания структуры
системы с учетом среды реализации. Статические модели содержат описание классов
проектирования. Классы проектирования выделяются на основе классов анализа, при этом
каждый класс проектирования может соответствовать, например, одному или нескольким
классам анализа или части класса анализа и т.п.
Динамические модели описывают взаимодействия классов проектирования в рамках
выполнения вариантов использования. Динамическая модель анализа специализирует
модели взаимодействия в UML (см. [1] подраздел 4.4. Модели взаимодействия).
3.3.2.1. Примеры использования
Рис. 9 - Фрагмент модели проектирования
Issue Bill
- alarming
: Alarmer
:
DataStorage
:
ProxyPushConsumer
:
ProxyPushSupplier
:
AccountantUI
makeSelection(BillQuery)
push(in any)
<<signal>>
push(in any)
Рис. 10 - Фрагмент модели проектирования
3.4. Типовые
правила
проектирования
структурирования
модели
Для структурирования модели проектирования может использоваться следующая
структура. В Табл. 9 указана структура модели проектирования.
Табл. 7
Элемент модели
Logical View

(package) Design Model
o (package) Design subsystem

(class diagram) Классы подсистемы.
Описание
Стандартный пакет.
Подсистема проектирования
На одной или нескольких диаграммах
o

(class) Класс 1
(package) Use-case realizations

(package) Вариант использования 1

(sequence diagram) Вариант использования
изображаются классы подсистемы и
их отношения.
Класс проектирования.
Стандартный пакет.
Модель
варианта
использования
Вариант использования1 (из Use case
View).
На одной или нескольких диаграммах
изображаются возможные потоки
событий в рассматриваемом варианте
использования.
3.5. Модель данных
Модель данных создается при проектировании системы и используется для
моделирования схемы базы данных с учетом особенностей используемой БД. Модель
данных специализирует модели статической структуры. Описывает используемые
таблицы, представления, хранимые процедуры.
3.5.1.
Используемые примитивы
3.5.1.1. Стандартные элементы
См. [1] подраздел 4.2.1. Основные элементы.
3.5.1.2. Расширения UML
Новые элементы модели данных, их нотация и назначение приведены в Табл. 6.
Табл. 8
Базовый
элемент
модели
(UML)
Пакет
Model
Стереотип
Eleme
nt
(UML)
Package <<scheme>>
Нотация
<<Schema>>
S_0
(from Schemas)
Класс
Class
<<table>>
Класс
Class
<<SP Container>>
Назначени
е
Схема БД. Содержит
диаграммы данных,
таблицы и хранимые
процедуры.
Для
генерации
должна
быть привязана к
некоторой БД.
Таблица. Таблица БД,
для
которой
указываются
столбцы,
ограничения,
отношения и т.п.
Хранимая процедура.
Класс Используется
как контейнер для
хранимых процедур.
Класс
может
содержать
набор
хранимых процедур.
3.5.2.
Описание использования
Модель данных представляет собой модель схемы БД, по которой может быть
создана схема для выбранной БД. Таблицы выделяются на основе классов анализа
(entities). Хранимые процедуры определяются на основе классов анализа (controls).
Для создания и работы с моделью данных используется инструмент Rational Rose
Data modeler.
1.
В пакете Logical View создается схема БД (Data modeler->New->Scheme).
2.
В появившейся схеме создаётся диаграмма данных (Data diagram).
3.
На созданную диаграмму данных помещаются таблицы и хранимые процедуры,
указываются отношения между ними.
4.
Для последующей генерации схемы БД необходимо создать БД в Component
View (Data modeler ->New->Database), выбрать тип этой БД (Oracle 8.x) и
назначить эту БД созданной схеме.
Для описания схемы для СУБД Oracle (без хранимых процедур) может
использоваться специальный инструмент Rational Rose (Пункт меню Tools ->Oracle8>Data Type Creation Wizard). Этот инструмент позволяет использовать Object Type, Nested
Table, Object Table. Для генерации необходимо выполнить для созданной схемы (Пункт
меню Tools ->Oracle8->Scheme Generation).
3.5.3.
Примеры использования
3.5.4.
Типовые правила структурирования модели данных
Для структурирования модели проектирования может использоваться следующая
структура. В Табл. 9 указана структура модели проектирования.
Табл. 9
Элемент модели
Logical View

(package) Schemas
o (package) Schemas1

(data model diagram) Диаграмма данных


Component View

(package) БД
(сlass <<table>>) Таблица1
(class) Хранимая процедура 1
Описание
Стандартный пакет.
Подсистема проектирования
На одной или нескольких диаграммах
изображаются таблицы и отношения
между ними.
Таблица БД.
«Контейнер», содержащий одну или
несколько хранимых процедур.
o
База данных, для которой указывается
тип (Oracle 8.x).
(component) DB1
3.6. Модель развёртывания
Модель развертывания предназначена для моделирования топологии аппаратных
средств, на которых выполняется система. Модель развертывания является
специализацией модели развертывания UML. Помещается в Deployment View.
3.6.1.
Используемые примитивы
3.6.1.1. Стандартные элементы
См. [1] подраздел 4.6.1. Основные элементы.
3.6.1.2. Расширения UML
Новые элементы модели развертывания, их нотация и назначение приведены в
Табл. 10.
Табл. 10
Базовый
элемент
модели
(UML)
Узел
Model
Element
(UML)
Стереотип
Нотация
Node
Узел
Узел
Node
Устройство
3.6.2.
Назначение
Узел.
Представляет
собой
элемент
обработки данных в
системе. Имеет хотя бы
один
процессор
и
память.
Устройство. Физическое
устройство,
не
рассматриваемое как
элемент
обработки
данных
на
моделируемом уровне
абстракции.
Описание использования
Модель развертывания показывает конфигурацию элементов обработки данных в
системе и связи между ними. Она состоит из узлов, на которых происходит собственно
обработка данных; физических устройств, не рассматриваемых как элементы обработки
данных на моделируемом уровне абстракции и поддерживающих работу узлов;
связующих звеньев (ассоциаций) между узлами и между узлами и устройствами. Для
каждого узла в его спецификации указываются процессы, выполняемые на этом узле.
Также для узла могут указываться сборки (builds), устанавливаемые на данном узле.
3.6.2.1. Пример использования
СУБД
Сервер доступа
к данным
executive
DataStoring
субд
Network
Inteface
Printer
BillingServer
Billing
Session*
Receipting
BillCreating
Рис. 11 - Фрагмент модели развертывания
3.6.3.
Структура модели развертывания
Модель развертывания изображается на диаграмме развертывания (Deployment
View).
Табл. 11 – Структура модели развёртывания
Элемент модели
Deployment View

(package) Schemas
o (package) Schemas1

(data model diagram) Диаграмма данных


(сlass <<table>>) Таблица1
(class) Хранимая процедура 1
Component View

(package) БД
o (component) DB1
Описание
Стандартный пакет.
Подсистема проектирования
На одной или нескольких диаграммах
изображаются таблицы и отношения
между ними.
Таблица БД.
«Контейнер», содержащий одну или
несколько хранимых процедур.
База данных, для которой указывается
тип (Oracle 8.x).