Эффективные совещания
Вспоминаем UML. Диаграмма классов UML
Cхема сущностей / Диаграмма классов UML
Обзор нотации Archimate
А теперь детали и нюансы
CookBook как использовать Archimate на данном курсе
Микросервисная архитектура
Первый набросок системы (First System Sketch)
Управление ресурсами гражданского аэропорта
Участники рынка
Ключевые понятия и концепции предметной области - вылет
Ключевые понятия и концепции предметной области - прилет
Ключевые регуляторные ограничения
Дерево качества
Контекстная диаграмма
Контекстная диаграмма Archimate
Функциональная декомпозиция
Функциональная декомпозиция
Функциональная декомпозиция
Диаграмма развертывания
Проверка через диаграмма развертывания
Уточненные Функциональные блоки
Схема сущностей
Схема сущностей
Переходы статусов
Проверка функциональной декомпозиции через ключевые сценарии
Исправление функциональных блоков
Исправление функциональных блоков
Исправление функциональных блоков
Исправление функциональных блоков
Сборка расписания на сезон
Сценарии запуска расчетов
Уточнение границ проекта и варианты развития
Требования к технологическим решениям
Предложение по разделению команд
План внедрения
Вопросы на экзамене по этой лекции
21.06M

Лекция 5. Archimate First System Sketch

1. Эффективные совещания

Архитектура в ИТ
Курс лекций для магистров
Заборов Михаил
Лекция 5 Эффективные
Образец
совещания
заголовка

2. Вспоминаем UML. Диаграмма классов UML

ВУЗ
Название
Адрес
Телефон
Зачислить студента ()
Отчислить студента ()
Класс
Вспомогательный
текст,
(Сущность)
Название класса
описывающий процесс
взаимодействия классов
Атрибуты
Студент
сущности
1..2 ← обучается в 100..* Номер зачетки
Фамилия
Обучает →
Имя
Номер паспорта
Поменять фамилию ()
Методы
Поменять паспорт ()
Связь
операции
класса
название
•[m..n] - интервал от m до n включительно (m <= n). Такая запись будет означать, что в коллекции
может храниться от m до n значений включительно.
•[n] – интервал, который можно рассматривать, как сокращённую запись [0..n].
Может случиться так, что мы захотим показать, что в массиве может храниться неограниченное
количество элементов. В таком случае верхняя граница n заменяется символом *.
Примеры интервалов:
•[1] - ровно один объект. То же самое, что и интервал [1..1]
•[0..1] - ноль или один объект.
•[0..*] - ноль или неограниченное количество объектов. Часто такой интервал обозначают просто
как [*].
•[1..*] - один или неограниченное количество объектов.
Образец
заголовка

3. Cхема сущностей / Диаграмма классов UML

Cхема сущностей / Диаграмма классов
ВУЗ
UML
Работает в
1..*
Название
Специализация
Аккредитация
0..*
1
«Факультет» является частью
«Университета» и факультет без
университета существовать не
может, следовательно здесь подходит
композиция.
<<Enumeration>>
Категория
имеет
1
состоит из
1..*
Университет,
Академия
Институт
0..1
Факультет
декан
Название
1
очная
вечерняя
заочная
<<Enumeration>>
Форма обучения
бакалавр
магистр
Ассоциация
Ассоциация
Фамилия
Имя
Паспорт
Относится к
1
1..*
имеет
<<Enumeration>>
Форма обучения
Человек
Группа
0..* Номер
Курс
1
0..* Форма обучения
Ступень (бакалар/ магистр)
имеет
1
0..1
Староста
числится в
«Студент» не является неотъемлемой частью «Группы», но в то же время,
группа состоит из студентов, поэтому следует использовать агрегацию.
1
Образец
заголовка
Студент
Номер зачетки
1
Преподаватель
Должность
Звание
5..*
Наследование
Преподаватель это всегда человек
Студент это всегда человек
*

4.

вспоминаем UML
Образец
заголовка

5.

вспоминаем UML
Образец
заголовка

6.

вспоминаем UML
Образец
заголовка

7.

вспоминаем UML
Образец
заголовка

8.

Образец
заголовка

9. Обзор нотации Archimate

С комментариями по ее применимости к моделям,
используемым в СМ

10.

Archimate прямой наследник UML
Образец
заголовка

11.

Большое количество элементов и связей
напрямую заимствовано из UML
Образец
заголовка

12.

Как работать с нотацией Archimate
+ меньше схоластических споров
+ быстрее рисовать
+ не нужно перерисовывать ( в том
числе старое
+ можно оставить более человекопонятную и привычную схему
- Сложнее делать анализ проверки
и общие правила
- Хуже подходит как база для
других процессов
Свободный
холст
Рисуй какие элементы связи и
элементы тебе кажется больше
подходят по смыслу и не
заморачивайся. Для
вдохновения можно погуглить
разные схемы , но там много
мусора
+ Стандартизуем только то что
понятно и если это нужно для
чего-то еще
+ можно оставить более человекопонятную и привычную схему
+ Можно делать машинный анализ ,
проверки и интеграцию с CMDB+
- Придется перерисовать старое
при уточнения стандартов
Мягкая унификация
Есть небольшой набор правил
которым нужно следовать и
рекомендации с примерами, как
рисовать правильно . Все что не
зафиксировано правилами и
примерами – рисуй как
понимаешь
Стандартизировано
ограниченное количество типов
диаграмм
По сути это наш собственный
Cookbook
+ Можно делать машинный анализ
и проверки на корректность
диаграмм
+ Можно делать интеграции с
CMDB+
- Сложно зафиксировать общее
понимание (высокий порог
вхождения). Т.к. формулировки
размытые (+языковой барьер)
- Много избыточных деталей и
связей только потому ,что так
требует нотация
- Нужно заводить свой
методологический центр
- Придется перерисовать старое
при уточнения стандартов
- Узкое горло «экспертов по
нотации»
Жесткая
нотация
У элементов и связей четко
фиксированный смысл и правила
использования. Нужно рисовать
"правильно". Только в соответствии
шаблонами и примерами. Не
понимаешь как нарисовать –
обратись к источнику. Знания. Все
диаграммы должны строго
соответствовать
нотации

13.

Обзор нотации Archimate
1.
2.
3.
4.
5.
Элементы в виде прямоугольников
Пиктограммы - типизирующие элементы
Связи между элементами
Вложенность элементов
Группировка
Связи и элементы называются концептом
Соединитель связей это мулька для связей - расскажу там

14. А теперь детали и нюансы

2 у элементов есть пиктограммы, которые можно использовать
вместо прямоугольников
Примеры
Эквивалентно

15.

Слои в Archimate
Моя интерпретация
Оригинал
Бизнес
Приложения
Технологии
Физический
Мотивация
Слои Архитектуры
предприятия
Слои ArchiMate
Стратегия
Внедрение и миграция
Отдельный слой
В нотации принадлежность слою определяется цветом элемента.
Поэтому нельзя красить элементы так как тебе вздумается

16.

Слои Архитектуры предприятия в разных вариациях
Togaf 8
Teaf
Мин Обороны
США
Беспальчук

17.

Применимость слоев для модели СМ Lab
Мотивация
Мотивация людей, цели /предположения/ принципы . Слой БА и архитекторов
[Enterprise, Solution, Domain]
Стратегия
Стратегические решения и развилки . Слой БА.
Бизнес
Как устроено предприятие, в котором работают ИТ системы
Слой для архитекторов [Enterprise, Solution, Domain] и аналитиков
Приложения
Как реализовано в ИТ системах в логике проектирования. Слой Архитекторов
[Enterprise, Solution, Domain, System], аналитиков и разработчиков
Технологии
Как ИТ системы работают в технологическом ИТ окружении (Сервера, Системное ПО)
Слой Разработчиков, Эксплуатации и Сисадминов
Физический
Объекты физического мира для визуализации производственных и технических процессов
Слой для Архитекторов [Enterprise, Solution, Domain, System] аналитиков
Внедрение и миграция
Дорожные карты и планы изменений.
Слой для РП, PL , Архитекторов [Enterprise, Solution, Domain, System],
Концепцию со слоями считаю исключительно полезной.
Только ради нее стоит использовать Archimate

18.

Аспекты Archimate
В нотации принадлежность к аспекту определяется формой элемента **.
Технологии
Физический
Мотивация*
Приложения
Структура
Бизнес
Поведение
Стратегия
Внедрение и миграция
Аспекты ArchiMate
* Одновременно и отдельный слой и отдельный аспект. Поэтому выделяется и
цветом и формой
** Аспекты к сожалению влияют не только на форму элементов , но и на связи, но об
этом позже

19.

Логика аспектов Archimate
Структурный аспект
Кто делает ?
Активная
структура
Пассивная
структура
Мама
Поведенческий аспект
Что делает ?
Мыла
На что
направлено
действие?
Раму

20.

Применимость аспектов для СМ
Archimate
Спортмастер
Структурный аспект
Статические виды
Активная структура
внутренняя
внешняя
Функциональный
вид
Пассивная
структура
Поведенческий аспект
Структурный
вид
Информационный
вид
Динамические виды (runtime)
Процессы, сценарии, …, UX, CX, …
Функции
Аспекты Archimate нам совсем не подходят, что создает нам некоторые проблемы и ограничения (в основном на уровне
связей)
…, UI, …

21.

Мотивация

22.

Мотивация

23.

Стратегия

24.

Элемент
Базовые элементы (по
Archimate)
Аспект
Описание
Активная
структура
представляет собой точку доступа, в которой внешней среде предоставляются один или
несколько сервисов.
Активная
структура
совокупность двух или более элементов внутренней активной структуры, работающих вместе для
выполнения некоторого коллективного действия. возможного только когда все
участники задействованы
Внутреннее
поведение
Представляет собой последовательность бизнес-действий которая
позволяет достичь определенного результата
Внутреннее
поведение
набор действий, основанных на определенных критериях(ресурсы, компетенции ,
местоположение) и управляемых, выполняемых или реализуемых как единое целое.
Внутреннее
поведение
единица коллективного поведения, которая должна выполняться двумя или более элементами
внутренней активной структуры, назначенными напрямую, или объединенными в рамках
совместной работы.
Внешнее
поведение
Представляет собой явно определенное открытое поведение доступное внешней среде
Поведение
Изменение состояния
Пассивная
струкрура
Пассивный структурный элемент представляет собой элемент, над которым выполняется
действие.
Business
Application
Technology

25.

Элемент
Базовые элементы (по
Archimate)
Аспект
Описание
Активная
структура
представляет собой точку доступа, в которой внешней среде предоставляются один или
несколько сервисов.
Активная
структура
совокупность двух или более элементов внутренней активной структуры, работающих вместе для
выполнения некоторого коллективного действия. возможного только когда все
участники задействованы
Внутреннее
поведение
Представляет собой последовательность бизнес-действий которая
позволяет достичь определенного результата
Внутреннее
поведение
набор действий, основанных на определенных критериях(ресурсы, компетенции ,
местоположение) и управляемых, выполняемых или реализуемых как единое целое.
Внутреннее
поведение
единица коллективного поведения, которая должна выполняться двумя или более элементами
внутренней активной структуры, назначенными напрямую, или объединенными в рамках
совместной работы.
Внешнее
поведение
Представляет собой явно определенное открытое поведение доступное внешней среде
Поведение
Изменение состояния
Пассивная
струкрура
Пассивный структурный элемент представляет собой элемент, над которым выполняется
действие.
Business
Application
Technology

26.

Спец элементы слоев - Бизнес

27.

Спец элементы слоев – Application и Technology

28.

Спец элементы слоев физический слой

29.

Слой для планирования работ по внедрению
развертыванию

30.

Метамодель Archimate

31.

Метамодель Archimate
Видимо есть ограничения по использованию
связей, в зависимости от аспектов соединяемых
элементов

32.

Связи (отношения)
4 типа связей
Структурные
Зависимости
Динамические
Прочие
связи
Визуальные отличия стрелок минимальные.
Запутаться очень легко
Конекторы
связей

33.

Структурные связи

34.

Связи для зависимостей

35.

Динамические связи
Передач
а

36.

Прочие связи

37.

Как работать с нотацией Archimate
+ меньше схоластических споров
+ быстрее рисовать
+ не нужно перерисовывать ( в том
числе старое
+ можно оставить более человекопонятную и привычную схему
- Сложнее делать анализ проверки
и общие правила
- Хуже подходит как база для
других процессов
Свободный
холст
Рисуй какие элементы связи и
элементы тебе кажется больше
подходят по смыслу и не
заморачивайся. Для
вдохновения можно погуглить
разные схемы , но там много
мусора
+ Стандартизуем только то что
понятно и если это нужно для
чего-то еще
+ можно оставить более человекопонятную и привычную схему
+ Можно делать машинный анализ ,
проверки и интеграцию с CMDB+
- Придется перерисовать старое
при уточнения стандартов
Мягкая унификация
Есть небольшой набор правил
которым нужно следовать и
рекомендации с примерами, как
рисовать правильно . Все что не
зафиксировано правилами и
примерами – рисуй как
понимаешь
Стандартизировано
ограниченное количество типов
диаграмм
По сути это наш собственный
Cookbook
+ Можно делать машинный анализ
и проверки на корректность
диаграмм
+ Можно делать интеграции с
CMDB+
- Сложно зафиксировать общее
понимание (высокий порог
вхождения). Т.к. формулировки
размытые (+языковой барьер)
- Много избыточных деталей и
связей только потому ,что так
требует нотация
- Нужно заводить свой
методологический центр
- Придется перерисовать старое
при уточнения стандартов
- Узкое горло «экспертов по
нотации»
Жесткая
нотация
У элементов и связей четко
фиксированный смысл и правила
использования. Нужно рисовать
"правильно". Только в соответствии
шаблонами и примерами. Не
понимаешь как нарисовать –
обратись к источнику. Знания. Все
диаграммы должны строго
соответствовать
нотации

38.

Свободный холст - пример

39. CookBook как использовать Archimate на данном курсе

40.

1. Обязательно: Соблюдаем цвета слоев
Допустимо :
• Разные оттенки
• Разные цвета у группировок
• Рамка другого цветка
• Другой цвет текста
Как выбрать цвет если сомневаешься
Слой
Technology
Application
Business
Для чего используем
Примеры
Для Серверов , виртуальных машин, ИТ систем в области ответственности эксплуатации, Midlware Админов и ЦК
эксплуатации
Платформенные решения на , которых идет прикладная разработка
Сервер, Компьютер, Смартфон, Сеть, Виртуальная машина
Linux, Oracle, IIS, WAF, Rabbit MQ, Elastic Search, Kafka, k8s,
Weblogic, Hadoop,Zabbix, Prometheus, Graphana, Magic Info
1 Форма, 1C УТ,
Для всего что реализовано внутри ИТ систем, которые находятся под управлением FAST.
Включая коробочные решений от вендоров, которые мы дорабатываем сами и Заказную разработки от внешнего
вендора. А также внешние прикладные системы с которыми интегрируются ИТ системы под управлением FAST
ComPro, Сайт 3.0 , КИС РМ, RMS, 1C ERP (?), Flex PLM, dEngage,
Naumen,
Эквайринг Сбера, Alix, Раппорто, 7tech, Диадок
Все объекты предприятия которых нет в ИТ системы, или которые мы рисуем без контекста ИТ
Люди , Подразделения , бизнеса - понятия, функциональные
схемы области, Customer Journey, СX.

41.

Как рисуем: роли / акторы
Элемент
Для чего используем
Примеры
Объекты которые есть в оргструктуре компании (в том числе функциональной). Назначены приказом :
Люди
Должности
Подразделения
УИС, ДУТК, Заборов, Архитектор Fast, PL, Product Owner,
Продавец (должность)
DPD, Сбербанк, ЦРТП
Другие организации
Роль которые могут исполнять разные сотрудники / подразделения
Злоумышленник, Представитель клиентского сервиса,
Продавец (роль), Архитектор CTE,, Stakeholder

42.

Бизнес интерфейсы, функции, понятия
Элемент
Для чего используем
Примеры
Точка контакта с компанией глазами Клиента
Сайт, Приложение, Контакт центр, Магазин, Сотрудник
доставки
Звонок, Чат (СМС, Мессенджеры) , Соцсети, AppStore и т.д
Канал коммуникаций
функции (в определении презентаций по архитектуре с SM Lab - Преобразование с четко
фиксированным и входом и выходом и детерминированным и повторяемым
поведением ) реализуемые вне контекста ИТ систем или без учета такого контекста.
Понятие предметной области
Логистика, Розница
Транспортная экспедиция, Формирование сделки, Исполнение
сделки , Приемка Отгрузка
Грузовая партия, Мерчендайзинговая цветомодель, Customer
Experience , Точка входа , Инцидент, Платеж, Заказ, Клиент,
Партия

43.

Бизнес интерфейсы, функции, понятия
Бизнес - функции

44.

Бизнес интерфейсы, функции, понятия

45.

Бизнес интерфейсы, функции, понятия
Бизнес - интерфейсы

46.

ИТ Компоненты ИТ функции, Продукты
Элемент
Для чего используем
Примеры
ComPro , КИС РМ, OrderGate, Payment Gate, СMS, ContentGate
Информационная система или ее компонент выделяемы на уровне кода. Хорошо если совпадает с функциональным
блоком.
План счетов КИС РМ. Ядро КИС РМ, Backend Сайта
По возможности называется также как в CMDB/P&P
ИТ функции (в определении презентаций по архитектуре с SM Lab - Преобразование с четко
Карточка товара, Корзина, Накладные
фиксированным и входом и выходом и детерминированным и повторяемым
поведением ) реализуемые внутри ИТ системы или ее компонента.
Рисуется только внутри элемента Компонент (Исключение –абстрактная функция для
обобщения взаимодействия похожих систем - пример: Frontoffice)
Продукт - это кусок предметной области над автоматизацией которой работают 1 или несколько команд. Внутри
продукта находится 1 или несколько информационных систем над которыми(в том числе) работают команды. У
продукта ровно один PL и один общий продуктовый backlog , котором ведутся все задачи команд участвующих в
продукте.
Называется строго также как в P&P.
Продукт также можно использовать и для подходящих бизнес-объекты если они
появятся. Например для подписки на тренировки, которые мы будем продавать в
мобильном приложении
Шлюз Заказов и платежей, ИМ Спортмастер 3.0

47.

ИТ Компоненты ИТ функции, Продукты
ИТ система
Компонентная
Декомпозиция системы
Функциональная
Декомпозиция системы
Монопродукт
так тоже можно
Монопродукт
Мультисистемный
продукт
Прикладной код
сделанный на платформе
Более сложный вариант
Использование библиотеки
Продукты внутри ИТ системы

48.

ИТ Компоненты ИТ функции, Продукты
Модульное приложение и обобщенные функции фронтофиса

49.

ИТ Компоненты ИТ функции, Продукты
Модульное приложение и обобщенные функции фронтофиса

50.

ИТ Интерфейсы и сервисы
Элемент
Для чего используем
Примеры
Технология/ тип интерфейсы по которому система или ее компоненты интегрируются с другими
системами/компонентами или взаимодействуют с людьми
Rest Api, SOAP WS, Web GUI, Desktop GUI, DB View, DbLink
Конкретные вызовы и EndPoint-ы API в случае Rest Api, SOAP WS и т.д.
Конкретные Пакеты и методы в случае интеграции по Dblink
Get_alt_channels, submit, pk_ware, pk_subj
Таблицы БД и витрины. В том числе по которым происходит интеграция
v_lk_order_info
v_lk_bonuses_history

51.

ИТ Интерфейсы и сервисы
Разные интерфейсы ИТ системы МАРС
Логическая схема БД
(упрощенная)

52.

Системное ПО, Ноды, Устройства
Элемент
Для чего используем
Примеры
Виртуальная машина, Контейнеры , Pod
NAUMEN-WS1.gksm.local:3389 [10.80.130.36]
exp-sentry01.gksm.local
Физическое ИТ устройство
Сервер, Компьютер, Смартфон, Планшет, СХД, Датчик
Программное обеспечение за которое отвечает Админы. Поставляется вендором как готовых закрытый продукт с
настройками + Платформенные решения на , которых идет прикладная разработка
Linux,Windows, Oracle, IIS, WAF, Rabbit MQ, Elastic Search, Kafka,
k8s, Weblogic, Hadoop,Zabbix, Prometheus, Graphana, Magic
Info
1 Форма, 1C УТ,
Схема Базы данных, Файл
shop_admin, 1.Txt

53.

Системное ПО, Ноды,
Устройства
Разворачивание КИС РМ в инфраструктуре

54. Микросервисная архитектура

Декомпозиция по функциям
Структурно-функциональная композиция
Декомпозиция на контейнеры
Микросервисы (понятная картинка)
Микросервисы (отрисованное по Феншую)
Образец
заголовка

55.

Лаборатория (контуры и стенды)

56.

Использование связей
Flow: Данные из МАРС попадают в GeoGate
Access: Компонент может редактировать и читать данные из
другого компонента
Triggering: GeoGate запрашивает данные у МАРС
Чуть более сложно
Serving и Realization: Логика пишется на ядре, которая поставляется в виде
библиотеки

57.

Использование связей
Агрегация, композиция и наследование ровно также как в UML.
Как впрочем и ассоциации
Influence: мультикорзина отрицательно влияет на конверсию.
Используем только для Motivation и Strategy
-

58.

Использование связей
Связь «Реализация» показывает, как более конкретный элемент реализует или материализует что-то, определенное более абстрактным элементом. Стрелка в сторону Более абстрактноно
элемента как в наследовании

59.

Роудмап

60. Первый набросок системы (First System Sketch)

Цели Задачи системы
Порядок проработки не важен.
Много проходов по кругу
Ключевая функциональность
Важные концепции предметной области
Границы MVP
Варианты развития
Основные сценарии
Дерево качества
Структура системы
Контекстная диаграмма
2-3 уровня Building Block View
Диаграмма развертывания
Схема сущностей и ключевых объектов
Диаграммы статусов ключевых объектов
Учет(?)
UI (?)
Внедрение и развертывание системы
Как система будет развертываться
Где и когда
В какой инфраструктуре
Технологии разработки
Организация команд
План внедрения
Образец
заголовка

61. Управление ресурсами гражданского аэропорта

Хочу систему которая получая запросы от
авиакомпаний формирует расписание
рейсов, на основании которого, управляет
базовыми объектами инфраструктуры
аэропорта, которые сильно зависят от
расписания такими как:
• Стойки регистрации
• Багажные ленты
• Выходы на посадку
• Службы бортового питание
• Обслуживание самолета
• Трапы
• Автобусы
• И т.д.
Образец
заголовка

62. Участники рынка

Образец
заголовка

63. Ключевые понятия и концепции предметной области - вылет


Регистрация
Посадка
Предполетный досмотр
Паспортный контроль
Фитосанитарный контрол
Ветеринарный контроль
Таможня
Чистая зона
Дьюти-фри
Залы ожидания
Выходы на посадку
• Рукава
• Автобусы
• Взлетное поле
• Питание
• Багаж
Образец
заголовка

64. Ключевые понятия и концепции предметной области - прилет

Образец
заголовка

65. Ключевые регуляторные ограничения

Регулирование
Что нам важно
Правила ICAO и IATA
Коды Авиакомпаний аэропортов , рейсов багажных бирок регулируются IATA и
ICAO
Правила обслуживания пассажиров
В случае задержек рейса нужно предоставлять питание и ночлег
Ограничения на максимальный вес и размеры груза, который
может быть перевезен на воздушном судна
Нужно считать нагрузку на судно и предусмотреть сценарии в случае
нарушения нагрузок
Требования к обязательному проведению регулярных
проверок и технического обслуживания воздушных судов
На список процедур влияет много участников. Он будет постоянно меняться
Требования к обеспечению безопасности пассажиров,
включая проверку на предмет запрещенных предметов и
проведение процедур безопасности на борту
Длительность и количество этапов проверки безопасности будет постоянно
меняться
Ограничения на количество и тип воздушных судов, которые
могут одновременно находиться на взлетно-посадочной
полосе или в районе аэропорта, для предотвращения
столкновений и обеспечения безопасности полетов.
Ошибки диспетчеризации взлетно-посадочных полос очень дорого стоят. Они
жестко регламентированы и их нужно жестко контролировать. В том числе
предусмотреть экстренные системы реагирования. Лучше вынести в отдельную
систему
Способы и правила тарификации
Нужно закладывать в структуру данных все необходимые разрезы для фактов,
чтобы потом можно было выставить счет авиакомпании
Правила покупки и бронирования билетов и
взаимодействия с авиакомпаниями
Мастер запись о покупке билета в авиакомпании
Багаж в полете хранится в системе авиакомпании
Образец
заголовка

66. Дерево качества

Качество системы
планирования
Ресурсов аэропорта
Высокая доступность
Рассчитанное расписание необходимо
для управление аэропортом. Должно
быть доступно в любой момент времени
Безопасность
Расписание работы внутренних служб секретно
Гибкость и расширяемость
Изменения состава услуг аэропорта и способов
тарификации
Образец
заголовка
Подключение новых потребителей расписания

67. Контекстная диаграмма

Публичное
Расписание
Внешние
агрегаторы
Пассажиры
Расписание
Публичное
Расписание
Заявки на
рейсы
Авиакомпании
Расписание для а/к
Система управление ресурсами
гражданского аэропорта
Багаж на рейсе, произведенные работы
Списки пассажиров на рейс
Доп запросы на обслуживание и ремонт судов
Образец
заголовка
Планы и расписания
Сотрудники
аэропорта
Поставщики
услуг

68. Контекстная диаграмма Archimate

Образец
заголовка

69. Функциональная декомпозиция

Компонент или
функция?
Образец
заголовка

70. Функциональная декомпозиция

Образец
заголовка

71. Функциональная декомпозиция

Образец
заголовка

72. Диаграмма развертывания

Возвращаемся и обновляем
Предыдущие диаграммы
Образец
заголовка

73. Проверка через диаграмма развертывания

Образец
заголовка
Offtop про MicroService Architecture (MSA)

74. Уточненные Функциональные блоки

Образец
заголовка

75. Схема сущностей

<<Перечисление>>
Тип рейса
Куда
Аэропорт
*
1
Строка
расписания
*
Для нашего
аэропорта это
1
Вылет
Откуда
Код IATA
Номер рейса
1
Название
*
GPS координаты
Время вылета
Время прилета
Выполняет
1
Багажное место
везет с собой
PNR
*
1
Багажная метка
ФИО
1
*
Выполняется
<<Перечисление>>
Отметки пассажира
получает в процессе
Запрос на питание
<<Перечисление>>
Заявка
День недели
Утверждено
Этап процесса
Статус (успех/ отказ)
дожен быть
обеспечен
*
Вторник
*
*
1
/статус
Понедельник
Отклонено
Код IATA
Номер документа
Место в самолете
Статус согласования
Время прилета
Авиакомпания
Название
Пассажир
Прилет
Купил билет на
Среда
Штабквартира
Чартерный
Адрес шлюза интеграци
в дни
Регулярный
0..*
Даты [*]
1
Id Ресурса
0..*
1
Пятница
Суббота
дожен быть
обеспечен
Дата
1
Время плановое
*
Ресурсы для рейса
Этап подготовки
*
Начала использования
Конец использования
Время фактическое
Воздушное судно
Планируемы поэкземплярно
*
Регистрационный номер
Тип планирования (экземп/кол-во)
Производитель
*
Модель самолета
предоставляется авиакомпанией для
Дата последнего обслуживания
1
Тип последнего обслуживания
Вместимость пассажиров
Вместимость багажа
Ресурс аэропорта
Четверг
Рейс
принадлежит
1
Планируемы
поэкземплярно
Образец
заголовка
Планируемы
количеству
Экземпляр
Количество
Общие ресурсы
Количество

76. Схема сущностей

Ресурс аэропорта
Id Ресурса
Планируемы поэкземплярно
Общие ресурсы
Тип планирования (экземп/кол-во)
Количество
Зоны досмотра
Транспорт
Стойка регистрации
Выход на посадку
Бригады
Багажная лента
Паспортный контроль
Таможня
Трапы
Автобусы
Клининг
Ветеринаный и фито
санитарный контроль
Питание
Образец
заголовка
Залы ожидания
Заправщики
Погрузка/выгрузка
багажа
Буксиры
Техобслуживание
Машины сопровождения
Водители

77. Переходы статусов

Рейс вылет
Открыта
регистрация
Регистрация
Закрыта
Отложен
Начата
посадка
Посадка
закончена
Пассажир на рейсе вылета
Оказался лететь
Зарегистрировался
Забрал багаж
Сдал багаж
Вышел из зоны
безопасности
Прошел зону
безопасности
Прошел границу
обратно
Прошел пограничный
контроль
Снят с рейса
Прошел на посадку
Багажное место вылет
Зарегистрировано
Строка расписания
Новая заявка
Загружено в
самолет
Утверждена
Потеряно
Вылетел
Рейс
отменен
Самолет
улетел
Рейс прилет
Рейс
отменен
Багажное место прилет
Пассажир на рейсе прилета
Ожидается к прилету
Ожидается
Вышел из самолета
Пассажиры
высажены
Прошел границу
Получил багаж
Багаж выдан
Ожидается
Не прилетел
Образец
заголовка
Потеряно
Выгружено
из самолета
невостребовано
Подано на
багажную
ленту
Отклонена

78. Проверка функциональной декомпозиции через ключевые сценарии

Сценарий
Результат проверки
Вылет - прямой сценарии (без задержек и
изменений)
Не предусмотрена процедура назначения воздушного судна на рейс
Проработать регулярность запуска процедур обмена с авиакомпаниями, включая
блокировки по статусам
Прилет – прямой сценарий (без задержек и
изменений)
Предусмотреть загрузку списка прибывающих пассажиров
Проработать регулярность и timeline запуска процедур обмена
Вылет / Прилет – задержка рейса
Необходимо в интерфейсах взаимодействия модуля расчета расписания и системами
управления и планирования внутренней инфраструктуры и предусмотреть не только
передачу нового но и изменения расписания
Необходимо продумать механизм обновления расписаний
Нужен функциональный модуль который получает(откуда) изменения и запускает
перерасчет
Прилет потеря багажа
На данный момент есть только фиксация
Сбор и акцепт заявок на расписание от A/K
Не проявлен блок который принимает решения по заявкам ( видимо где-то внутри
расчета расписания)
Проработать регулярность и timeline запуска процедур обмена с авиакомпаниями,
включая блокировки по статусам
Образец
заголовка

79. Исправление функциональных блоков

Образец
заголовка

80. Исправление функциональных блоков

Образец
заголовка

81. Исправление функциональных блоков

Образец
заголовка

82. Исправление функциональных блоков

Образец
заголовка

83. Сборка расписания на сезон

Расписание разрабатывается на два сезона, которые называются ЛЕТО и ЗИМА. Сроки
действия летнего и зимнего сезонных расписаний соответствуют срокам, установленным
ИАТА, для аналогичных сезонов международного расписания:
— "ЛЕТО": начало — последнее воскресенье марта; конец — последняя суббота октября;
— "ЗИМА": начало — последнее воскресенье октября; конец — последняя суббота марта.
Образец
заголовка

84. Сценарии запуска расчетов

Образец
заголовка

85. Уточнение границ проекта и варианты развития

• Управление воздушным пространством, включая взлетно- посадочные полосы - за рамками
системы
• Разборки с потерянным багажом в другой системе
------------------------• Емкости служб считаем условно постоянными в течении длительного периода времени
• Размер судна не влияет существенно на расписание служб
--------------------------• Взаиморасчеты с авиакомпаниями, включая тарификацию услуг за рамками системы
• Информацию об изменениях в расписании получаем внесистемно
• За границами MVP:
• Объекты, которые зависят от общего потока, а не от расписания
• Зоны досмотра и безопасности
• Таможня и паспортный контроль на границе
• Залы ожидания
• Аэропорты с большим количеством терминалов на дальних расстояниях
• Трансфертные пассажиры
• Учет в алгоритмах расстояний между объектами
• Специальные грузы пассажиров(Оружие, Животные и т.д)
Образец
заголовка
Скорее всего
это совсем
другая система
Сделать можно
но придется
переделывать
Простое
развитие
системы

86. Требования к технологическим решениям

Требуемое решение
Описание
Горячее резервирование сервера
Intraday
Нужно катастрофоустойчивое решение которое при проблемах с сервером и сетью позволяет без простоя
подключить резервные мощности
Горизонтальное масштабирование
сервера Intraday
Нужно уметь обрабатывать пики нагрузки за счет временного подключения доп мощностей. Включая
кластеризацию и шардинг
Вертикальное масштабирование
сервера Intraday
Функциональные модули блока «Системы управления и планирования внутренней инфраструктуры»
должны деплоиться независимо, что позволяет их разносить на разные физические сервера
Защита периметра на сетевом
уровне
Злоумышленники попав в сеть авиакомпании / поставщика не должны иметь возможности нарушить
работу сервера Intraday или получить доступ к сетям других авиакомпаний и поставщиков. Все
взаимодействие через небольшое заранее оговоренное количество Endpoint-ов, которые должны
регулярно проверяться через PEN тесты. Желательна возможность управление доступом по расписанию.
Технологии разработки
Большая часть разработки:
- для модуля расчета расписания - серверная логика (может быть в субд, может быть на сервере
приложений)
- для блока «Системы управления и планирования внутренней инфраструктуры» - серверная логика и
Web/Android интерфейсы. Скорее всего лучше всего использовать Java/ Kotlin
СУБД
Так как объемы данных не очень большие, а целостность данных важна ( особенно для справочников и
расписаний) рекомендуется использовать реляционную базу данных (Oracle, Postgre). Исключение –
публичная витрина для сайтов ( тут можно использовать СУБД для Web – Mongo, Redis и т.д)
Единое API для контрагентов
API для авиакомпаний состоит из 2ух частей, которые делаются в разных функц блоках и потенциально
разными командами. Хорошо бы сделать так, чтобы для контрагента оно выглядело единым ( например
API Gateway)
Образец
заголовка

87. Предложение по разделению команд

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

88. План внедрения

Образец
заголовка

89. Вопросы на экзамене по этой лекции

Вопрос
Слои и Аспекты ArchiMate. Как связаны с типами Архитектуры и Архитектурными Viewpoints
Базовые элементы и связи ArchiMate
Слой мотивации и стратегии ArchiMate
Элементы слоя Business ArchiMate
Элементы слоя Application ArchiMate
Элементы слоя Technology ArchiMate
Элементы физического слоя ArchiMate
Элементы слоя Implementation ArchiMate
First System Sketch
Образец
заголовка
English     Русский Правила