ЯЗЫКИ ОПИСАНИЯ АРХИТЕКТУР Различными организациями было разработано несколько

Зарегистрируйтесь, чтобы просмотреть полный документ!

ЯЗЫКИ ОПИСАНИЯ АРХИТЕКТУР Различными организациями было разработано несколько различных ADL: AADL (стандарт SAE), Wright (разработан в университете Carnegie Mellon), Acme (разработан в университете Carnegie Mellon), x. ADL (разработан в UCI), Darwin (разработан в Imperial College в Лондоне), DAOP-ADL (разработан в Университете Малаги) By. ADL (Университет L'Aquila, Италия). Общими элементами для всех этих языков являются понятия компонента, коннектора и конфигурации. 1

ЯЗЫКИ ОПИСАНИЯ АРХИТЕКТУР Общими элементами для всех этих языков являются понятия компонента, коннектора и конфигурации. AADL был впервые разработан в области авионики(совокупность всех электронных систем, разработанных для использования в авиации) , и был известен ранее как язык описания архитектуры авионики. В связи с его акцентом на встроенные области, AADL содержит конструкции для моделирования программного обеспечения и аппаратных компонентов. Эта архитектура модели может быть использована либо в качестве проектной документации для анализа, или для генерации кода (в программную часть), как UML. 2

Wright (ADL) Общими элементами для всех этих языков являются понятия компонента, коннектора и конфигурации. Wright формализует архитектуру программного обеспечения с точки зрения таких понятий, как компоненты, коннекторы, роли и порты. Øкомпонент (component) – сложный, потенциально состоящий из множества элементов, вычислительный блок или хранилище данных в программной системе (ПС). Компонент обладает интерфейсами – портами, для связи с его окружением; 3

Wright (ADL) Øпорт (port) – интерфейс взаимодействия компонента для связи с его окружением (другими компонентами ПС, внешней средой). Порт может предоставлять как простой интерфейс, например вызов одного метода, так и сложный, например, последовательные вызовы коллекции методов. Øпростой порт (Single Port) – интерфейс взаимодействия компонента для связи с его окружением. Øпереключаемый порт (Case Port) – имеет возможность работы с разными коннекторами, например, метод класса может иметь дополнительный параметр булевого типа, значения которого указывают методу для какой среды его будут использовать. 4

Wright (ADL) Коннектор (connector) – архитектурный блок, связывающий порты между разными компонентами. Роль (role) – определение участников взаимодействия моделируемого коннектором. Взаимодействие (interaction) – свойство коннектора, которое определятся с помощью ролей. 5

ACME Acme является простым языком общего описания архитектуры программного обеспечения (ADL), Acme язык и инструментарий обеспечивают три основные возможности: архитектурный обмен. Предоставляя общий формат обмена для архитектурных конструкций, Acme позволяет разработчикам легко интегрировать их инструментарий с другими дополнительными инструментами. Кроме того, в распоряжении архитекторов использующих Acme-совместимость имеется более широкий спектр инструментов для анализа и проектирования , чем у архитекторов использующих инструментарий одного ADL. 6

ACME расширение основы для новой архитектуры и инструментов анализа. Большинство инструментов архитектурного проектирования и анализа требуют представления для описания, хранения и манипулирования архитектурными проектами. К сожалению, развивающиеся хорошие архитектурные представления сложные, отнимают много времени, и дорогостоящие. Acme может смягчить стоимость и трудность создания архитектурных инструментов путем предоставления языка и набора инструментальных средств для использования в качестве основы создания инструментов. Acme обеспечивает надежную, расширяемую основу и инфраструктуру, что позволяет инструмент настроить, чтобы избежать нужды восстановления инфраструктуры стандартных инструментов. 7

ACME описание архитектуры. Acme стала полезным языком описания архитектуры в своем собственном праве. Он обеспечивает простой набор языковых конструкций для описания архитектурного сооружения, архитектурные виды и стили, и свойства архитектурных элементов. Хотя это и не подходит для всех приложений, описание Acme архитектуры языка обеспечивает хорошее введение в архитектурное моделирование, и простой способ для описания относительно простой архитектуры программного обеспечения. 8

Дарвин (ADL) Дарвин язык описания архитектуры (ADL). Он может быть использован в разработке программного обеспечения контекста для описания организации части программного обеспечения в компонентах, их интерфейсы и привязки между компонентами. В сравнении с другими ADLS, таких, как Wright , язык не дает понятие разъемов в качестве первого класса концепции. Язык может быть использован для описания поведения моделирования, а также может быть использованы для анализа. Позволяет проверить временные свойства архитектуры. 9

DAOP-ADL является языком описания архитектуры, используемый для описания компонентов и аспектов. При помощи этого языка, приложения CAM модели может быть преобразовано в набор документов XML, который может быть легко истолкован Runtime Environment - т. е. на платформе DAOP. Архитектура описания использованием DAOP-ADL состоит из двух частей: одна определяет автономные компоненты и аспекты, а вторая - состав спецификации. 10

DAOP-ADL является языком описания архитектуры, используемый для описания компонентов и аспектов. 11

Use-case model (модель вариантов использования) Модель – это абстракция, описывающая моделируеемую систему с определенной точки зрения и на определенном уровне абстрагирования. Модели – это абстракции системы, которые создаются архитекторами и проектировщиками. Вариант использования — это часть функциональности системы, необходимая для получения пользователем значимого для него, ощутимого и измеримого результата. Варианты использования обеспечивают функциональные требования. Сумма всех вариантов использования составляет модель вариантов использования. 12

ВЛИЯНИЕ НА АРХИТЕКТУРУ 13

Модель вариантов использования Ведение журнала преподавателя Сформировать журнал преподавателя Изменить список студентов в журнале Преподаватель Отметить посещение студентами занятий Ввести качественную оценку активности проявления знаний Печать журнала преподавателя 14

Что такое вариант использования? Вариант использования Øописывает поведение системы в ответ на воздействия из внешней среды Øспособ описания функциональности системы в виде сценариев Øсценарий – основа для дальнейшего проектирования системы и получения детальных требований 15

Что такое действующее лицо? Действующее лицо • «Представитель» внешней среды, который взаимодействует с системой • Роль, исполняемая сущностью из внешней среды Виды действующих лиц • Пользователь • Внешняя система • Внешнее устройство • Время 16

Для чего нужны варианты использования? … Пользовательский интерфейс Вариант использования Ограничения Классы Форматы данных Нефункциональные требования 17 … Функциональные требования

Подход на основе вариантов использования Кассир выбирает функцию бронирования и печати билета. Система запрашивает параметры брони. Пользователь выбирает название представления из списка, дату и время представления, выбирает место и подтверждает бронь. Система регистрирует бронь и распечатывает билет с указанием цены. 18 Функциональные требования: 1. Система должна позволять бронировать билеты на представление. 2. Система должна позволять распечатывать забронированные билеты 3. Система должна регистрировать забронированное место, присваивая брони уникальный идентификатор Класс-сущность: Бронь • Представление – Тестовое поле (100 символов) • Дата и время – Дата в формате ЧЧ: ММ ДД. ММ. ГГГГ • Место – Числовое значение (01 -100) • Цена – Числовое значение (xxxx. xx) Пользовательский интерфейс: Представление: Дата и время: Место: Отмена Печать

Спецификация требования и варианты использования Основные разделы документа: 1. Описание основных возможностей системы 2. Модель вариантов использования 3. Описание вариантов использования 4. Дополнительные требования a) Правила и ограничения b) Требования к производительности c) Требования к надежности d) Требования к удобству использования и пользовательскому интерфейсу e) Требования к форматам данных 5. Матрицы трассировки требований 6. Модель предметной области (классы) 7. Прототипы пользовательского интерфейса 19

Быть или не быть? Вот в чем вопрос… Быть. Если в системе: • преобладают функциональные требования • много типов пользователей с разными целями • много интерфейсов • автоматизируются бизнеспроцессы 20 Не быть. Если в системе: • Преобладают нефункциональные требования • Мало пользователей и интерфейсов • интеграционные проекты

Шаблон описания варианта использования <UID> Название варианта использования Краткое описание и действующие лица Предусловие Постусловие Потоки событий {basic} Основной поток событий {alt} Альтернативные потоки событий {err} Ошибки и исключения {sub} Подпотоки Точки расширения Примечания и допущения Правила и дополнительные требования 21

Название и идентификатор Название варианта использования • Глагол + существительное • Отражает цель действующего лица • Уникальное в рамках системы (подсистемы) Уникальный идентификатор • • В документе перед названием варианта использования Уникальный в рамках всей системы (документации) Упрощает поиск требований в документации Используется при трассировке требований Примеры: • • 22 UC 134 Создать документ с требованиями UC. 07. 09. 14 Оплатить банковский счет ВИ-23 Оформить покупку товара ВИ 15_12 Зарегистрировать пользователя

Краткое описание варианта использования • несколько предложений • отражает назначение данного варианта использования • отражает цель пользователя • краткое описании основного потока событий. Пример: Данный вариант использования позволяет кладовщику создавать и сохранять в системе новый документ с описанием товара. Каждому документу в системе присваивается уникальный идентификатор, и для документа устанавливается связь с товаром на складе 23

Предусловие и постусловие Предусловие: Состояние или событие, которое должно быть истинно для того, чтобы вариант использования начался. Постусловие: Состояния или данные, которые появляются в результате выполнения варианта использования. Примеры: • Пользователь должен быть авторизирован в системе • Документ должен иметь статус черновика • Документ разнесен на лицевой счет • Создана новая учетная запись пользователя 24

Потоки событий Действие СИСТЕМА Отклик Поток событий последовательность действий пользователя и откликов системы Рекомендации: • Пишите КТО совершает действие – пользователь или система • Отделяйте шаги друг от друга • Давайте названия потокам событий Действующее лицо Шаблон: Шаг 1. [Действующее лицо] совершает [Действие] Шаг 2. [Система] отвечает [Откликом] 25

Потоки событий. Примеры оформления Пример 1: 1. Пользователь задает параметры документа и подтверждает сохранение данных 2. Система сохраняет новый документ, присваивая ему уникальный идентификатор. 3. Пользователь… Пример 2: Пользователь задает параметры документа и подтверждает их сохранение. Система сохраняет новый документ с новым номером. Пользователь … Пример 3: О 1 Основной поток событий – Создание нового документа: О 1. 1 Пользователь задает параметры документа и подтверждает сохранение данных О 1. 2 Система сохраняет новый документ, присваивая ему уникальный идентификатор. О 1. 3 Пользователь… 26

Основной поток событий • Наикратчайший путь для достижения цели пользователя • Всегда удачное завершение • Всегда имеет точку старта и точку выхода • Содержит 7 -9 шагов • В варианте использования может быть несколько основных потоков (например, CRUD) 27

Основной поток событий. Примеры Одна точка старта Вариант использования начинается, когда пользователь решает создать новый документ. 1. Пользователь инициирует создание нового документа 2. Система запрашивает пользователя параметры нового документа: • Название • Номер счет-фактуры • Код товара • … 3. Пользователь задает необходимые параметры и подтверждает сохранение документа 4. … Две точки старта • • 28 Вариант использования начинается, когда пользователь инициирует просмотр справочной информации. В случае вызова контекстной справки из другого варианта использования, система отображает необходимую страницу справочной документации (в зависимости от точки расширения).

Основной поток событий. Примеры Точка выхода 1. … 2. Пользователь вводит название учетной записи (логин) и пароль и подтверждает вход в систему 3. Система проверяет наличие учетной записи, ее статус (заблокирована или нет) , корректность и срок действия пароля. 4. Система настраивает пользовательский интерфейс в соответствии с настройками пользователя и его правами. 5. Пользователь входит в систему и получает доступ к необходимой функциональности клиента НИ. Вариант использования завершается удачно. 1. … 2. Система сообщает пользователю о том, что учетная запись заблокирована и необходимо обратится к администратору системы. Вариант использования завершается неудачно. 29

Альтернативные потоки событий и ошибки Отклонения от основного потока событий, которые приводят к • достижению цели действующего лица • частичному достижению цели • не достижению цели Рекомендации: • Идентифицируйте и описывайте обработки ВСЕХ ошибок • Ищите альтернативные пути достижения цели действующего лица • Всегда указывайте точку старта и точку выхода • Присваивайте наименования альтернативным потокам событий. 30

Альтернативный поток событий. Примеры Пример 1: [Шаг 3 Основного потока] Отмена создания документа 1. Пользователь отменяет создание документа. 2. Система запрашивает подтверждение на отмену и сообщает о том, что новый документ не будет создан. 3. Пользователь подтверждает отмену Вариант использования завершается неудачно Пример 2: [Шаг 2 Основного потока] Прикрепить файл к письму 1. Пользователь выбирает присоединение файла к письму. 2. Система запрашивает путь к файлу. 3. Пользователь выбирает файл и подтверждает его загрузку 4. Система сохраняет файл, присоединив его к письму Переход к шагу 4 основного потока событий 31

Подпотоки Ø Детализация действий системы О. 1 П. 2 П. 3 О. 2 Ø Сокращение описания потоков событий Ø Вынесенное отдельно описание повторяющихся шагов потоков событий Пример: О. 1. Система выполняет проверки учетной записи пользователя П. 1 Система проверяет наличие учетной записи пользователя П. 2 Система проверяет корректность и срок действия пароля пользователя П. 3 Система проверяет наличие и срок действия сертификата безопасности О. 2. В случае удачного выполнения проверок система открывает рабочее пространство пользователя. 32

Точки расширения Точка расширения место для введения нового поведения в потоки событий варианта использования Точки расширения могут быть: • Внутренними (ссылки на шаги) • Внешними (зависимость «extend» ) Точка расширения имеет: • Название • Условие • Идентификатор положения в потоке событий 33

Точки расширения. Примеры. Пример 1: Внутренняя точка расширения [Шаг 3 Основного потока] Отмена создания документа 1. Пользователь отменяет создание документа. 2. Система запрашивает подтверждение на отмену и сообщает о том, что новый документ не будет создан. 3. Пользователь подтверждает отмену Вариант использования завершается неудачно Пример 2: Внешняя точка расширения [На любом шаге основного потока] Получить справочную информацию 1. Вызов «UC 231 Просмотреть справочную информацию» Возврат обратно к шагу вызова 34

Дополнительные требования • Ограничения и бизнес-правила • Атрибуты качества • Требования к форматам данных • Требования к пользовательскому интерфейсу • Другие Пример: ID Требование RQ 21 Атрибуты учетной записи имя пользователя, пароль, контактный телефон должны быть обязательны для заполнения, остальные – опциональны и могут заполняться по желанию пользователя BRUL 23 Срок действия пароля в соответствии с политикой безопасности компании (пункт 3. 2. 4 ) устанавливается равным трем месяцам с момента его создания/смены. 35

Сценарий варианта использования Сценарий А 1. 1 О 1 А 1. 2 О 2 А 1. 3 О 3 Экземпляр варианта использования. Один из способов прохождения потоков событий А 2. 1 О 4 А 2. 2 А 3. 1 О 5 А 2. 3 А 3. 2 О 6 Пример - Сценарии О 1 -О 2 -О 3 -О 4 -О 5 -О 6 О 1 -А 1. 2 -А 1. 3 О 1 -А 1. 2 -О 3 -О 4 -О 5 -О 6 О 1 -О 2 -А 2. 1 -А 2. 2 -А 2. 3 О 1 -О 2 -А 2. 1 -А 3. 2 36

Модель вариантов использования • Вариант использования • Действующее лицо • Ассоциации • Обобщения • Зависимости «include» и «extend» • Пакеты и граница системы 37

Вариант использования и действующее лицо Действующие лица • • • Основные – инициируют вариант использования Вспомогательные участвуют в варианте использования Всегда ВНЕ границ системы Вариант использования • • 38 связан с действующим лицом ассоциацией всегда ВНУТРИ границ системы

Обобщение вариантов использования и действующих лиц • Абстрактный вариант использования описывает общее поведение системы • Абстрактное действующее лицо описывает общую роль в системе • Абстрактный вариант использования и абстрактное действующее лицо не могут иметь экземпляров 39

Обобщение действующих лиц. Пример «Получить доступ к мониторингу» ДЛ: Участник мониторинга платежей (далее Пользователь) Основной поток событий : 1. Пользователь запускает приложение. 2. Система запрашивает данные для аутентификации 3. Пользователь вводит логин и пароль 4. Система проверяет данные…… 5. ……. . 40

Абстрактный вариант использования. Схема Вариант использования - потомок Замещение Абстрактный поток событий Замещение Абстрактный вариант использования - родитель Вариант использования - потомок 41

Абстрактный вариант использования. Пример Создать форму Краткое описание: Данный вариант использования описывает общую логику создания формы, как составной части ФНО. К формам относятся: основная форма, приложения и дополнительные формы. Данный вариант использования является абстрактным, т. к. используется для описания общего поведения при создании (добавлении) форм. …. Основной поток событий (абстрактный): 1. Пользователь инициирует создание формы выбирая соответствующий тип. 2. Система запрашивает пользователя параметры формы (в зависимости от типа формы отображаются необходимые параметры - см наследники) 3. Пользователь задает параметры формы 4. Пользователь подтверждает создание формы. 5. Система отображает графическое представление формы и дерево иерархии (структуру). 6. Пользователь инициирует сохранение формы. 7. Система сохраняет документ. 42

Абстрактный вариант использования. Пример UC. 07. 01 Создать описание ФНО Краткое описание: Создание Описания ФНО как совокупности форм и добавление Основной формы ФНО. Основной поток событий: … 2. Система запрашивает пользователя параметры описания ФНО • код ФНО, • наименование ФНО, • тип ФНО • номер приказа, • дату утверждения • дата начала применения • дата окончания применения • информация , описывающая ФНО 3. Пользователь задает параметры описания ФНО … 43

Зависимость «include» • Общее поведение выносится во включаемый вариант использования • Экземпляр базового варианта использования не может существовать без шагов включаемого варианта использования • Включаемый вариант использования, который не инициируется самостоятельно не может иметь экземпляров 44

Зависимость «include» . Схема Базовый вариант использования Точка старта 2 Точка старта 1 Точка выхода 2 Точка выхода 1 Подпоток Включаемый вариант использования 45

Зависимость «extend» • • Точки расширения = точки входа • 46 Вводит новое поведение в базовый вариант использования Базовый вариант использования «не знает» про расширяющий вариант использования

Зависимость «extend» . Схема Базовый вариант использования Точка расширения Точка старта 2 Точка выхода 2 Точка старта 1 Точка выхода 1 Поток расширения Расширяющий вариант использования 47

Пакеты: • структурируют модель • Очерчивают границы системы • «черновики» для компонентов Рекомендации: • Группируйте варианты использования по пакетам • Группируйте действующих лиц по пакетам • 1 пакет – 3 -9 вариантов использования 48

Скачать презентацию ЯЗЫКИ ОПИСАНИЯ АРХИТЕКТУР Различными организациями было разработано несколько

APPZ_3.pptx

Количество слайдов: 48