Сервисные состояния Services States · UAF
Простыми словами
Ячейка Сервисный × Состояния описывает жизнь одной спецификации сервиса: в каких состояниях она бывает и какие события переводят её из одного в другое. Это самая бедная по составу ячейка сервисной строки — всего четыре элемента: сам сервис, описание состояния (StateDescription), описание состояния сервиса (ServiceStateDescription) и машина состояний из метамодели UML. Форма ровно одна — диаграмма состояний SysML. От Последовательностей отличается тем, что смотрит на одного участника, а не на диалог нескольких; от Процессов — тем, что показывает не работу, а положение, в котором сервис находится. Важно не переносить сюда привычку из стратегической строки: там Состояния — это вовсе не машина состояний, а связь способностей с желаемыми эффектами.
Примеры
Определение вида короткое и полностью описывает содержимое: «specifies the possible states a service specification may have, and the possible transitions between those states.» Предмет интереса добавляет причину переходов — события, вызывающие смену состояния.
UAF DMM 1.3, разд. 8.1.5 — Definition и Concerns вида Services States
Стратегические состояния определены совсем иначе: «captures the relationships between capability(ies) and desired effect(s) that implementation(s) of capability(ies) should achieve.» Там 36 элементов и никакой машины состояний, здесь — четыре элемента и диаграмма состояний.
UAF DMM 1.3, разд. 8.1.3 — Definition вида Strategic States; разд. 8.1.5 — состав рис. 8-39
Четвёртый элемент вида — StateMachine из метамодели UML 2.5, взятый напрямую. UAF не заводит собственного понятия машины состояний, а надстраивает над ним ServiceStateDescription; ровно так же в других ячейках взяты Activity и Interaction.
UAF DMM 1.3, разд. 8.1.5 — перечень Elements под рис. 8-39; разд. 6.4 Core Principles
Определение из первоисточника
дословная выпискаspecifies the possible states a service specification may have, and the possible transitions between those states.
Задаёт возможные состояния спецификации сервиса и возможные переходы между этими состояниями.
Как этим пользуются
Описание представления в источнике: для кого оно нужно, что описывает и в каком виде.
- Кому нужно
- Поставщики решений
- Системные инженеры
- Архитекторы программного обеспечения
- Бизнес-архитекторы
- Что закрывает
поведение спецификации сервиса в терминах состояний и событий, вызывающих переходы между состояниями
- Из чего состоит
- Service
- ServiceStateDescription
- StateDescription
- UML2.5Metamodel::StateMachine
- В каком виде рисуют
- Диаграмма конечного автомата SysML
То же в оригинале
- Кому нужно
- Solution Providers
- Systems Engineers
- Software Architects
- Business Architects
- Что закрывает
the behavior of a service specification in terms of states and events causing transitions between states.
- Из чего состоит
- Service
- ServiceStateDescription
- StateDescription
- UML2.5Metamodel::StateMachine
- В каком виде рисуют
- SysML State Machine Diagram
Основные параметры
Атрибуты этой сущности по справочнику источника.
- Stakeholders: Solution Providers, Systems Engineers, Software Architects, Business Architects.
- Concerns: the behavior of a service specification in terms of states and events causing transitions between states.
- Recommended Implementation: SysML State Machine Diagram.
В других подходах
Сопоставления одного понятия в разных подходах.
Аспект сетки: состояния и режимы.
Семантические различия У NAF в ряду C этот столбец занят эффектами, а не состояниями.
Корпоративные архитектуры
Связанные понятия
Опишите архитектуру своей компании в Storm
Реестр процессов, архитектурное рабочее пространство, связи между системами и процессами — те самые артефакты, только про вашу организацию.
Это же в StormРазработка ТЗРегламенты и политикиРеестр процессов