Версия 10:58, 3 июня 2024

27-28.10.2023 AnalystDays-2023
Доклад на сайте конференции
Видео https://youtu.be/KpdivjKBxrs 
Интересное обсуждение в чате, перенес в этот раздел
Продолжение темы доклада Системное мышление и его место в работе аналитика (AnalystDays-2024a)

Необходимое умение аналитика – выделять объекты и их взаимосвязи и определять типы и workflow документов, в общем – строить модели. Это надо делать при проведении интервью, анализе документов и Excel-файлов. Обычно для этого используют методы объектно-ориентированного подхода. ООП является частным случаем методов системного мышления, базирующегося на рациональном. Они учат структурировать информацию о мире: выполнять разметку текстов и другого нарратива, строить модели, рассматривая мир как на набор взаимодействующих систем. Понимание этих методов мышления дает мощный аппарат для аналитика для решения сложные задачи. Это аналогично с методами интегрирования: есть частные способы для конкретных интегралов и есть общие подходы.

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

Видео

Презентация

Скачать весь pdf

Обсуждение в чате

Anton: Очень интересный доклад. Хотелось бы подискутировать с автором, почему он решил начать с ООП, ведь есть более простое решение mind mapping.

Maxim Tsepkov: Потому что mind map как раз является псевдоструктурированной конструкцией, ты можешь рисовать его произвольно - как и писать текст. У них нет метамодели. Есть правила, которые позволяют рисовать хорошие структурированные mind map, но их массово не придерживаются. Татьяна Гаврилова, которая много лет с этим работает и несколько раз рассказывала на Teamlead о них говорит, что у нее нет проблем найти в интернете плохие схемы, а с хорошими - напряженно. ООП - сразу был ориентирован на структурированное представление мира с метамоделью.

Anton: А как же С4 model? Зачем ООП прикручивать к системному анализу?

Maxim Tsepkov: Объектно ориентированное проектирование (Object Oriented Design and Architecture) построено "поверх" системного подхода, он лежит в основе. Потому что ты там имеешь дело с системами, процессами и так далее. Что касается c4model, то это очень конкретная модель слоя технической архитектуры, с небольшим заходом в архитектуру приложений (как эти слои выделяет, например, Archimate). Пока не было контейниризации было достаточно указать хостинг приложений на нодах, а теперь появился еще один уровень абстракции - контейнеры, его добавила c4 model. А все что выше там упаковано в Context. B она - только про софт, части связанные с людьми там практически отсутствуют.

Anton: Исходя из c4 model (https://infostart.ru/pm/1540208/), Контейнер (Container) (приложения и хранилища данных) - Не Docker! В модели C4 контейнер представляет приложение или хранилище данных. Контейнер - это то, что должно быть запущено для работы всей программной системы. В реальном выражении контейнер - это что-то вроде:

• Серверное веб-приложение: Веб-приложение Java EE, работающее на Apache Tomcat, ASP.NET Приложение MVC, работающее на Microsoft IIS, приложение Ruby on Rails, работающее на WEBrick, Node.js применение и т.д.
• Веб-приложение на стороне клиента: Приложение JavaScript, работающее в веб-браузере с использованием Angular, Backbone.JS, jQuery и т.д.
• Клиентское настольное приложение: Настольное приложение Windows, написанное с использованием WPF, настольное приложение OS X, написанное с использованием Objective-C, кроссплатформенное настольное приложение, написанное с использованием JavaFX, и т.д.
• Мобильное приложение: Приложение Apple iOS, приложение для Android, приложение Microsoft Windows Phone и т.д.
• Консольное приложение на стороне сервера: Автономное (например, "public static void main") приложение, пакетный процесс и т.д.
• Бессерверная функция: Одна бессерверная функция (например, Amazon Lambda, функция Azure и т.д.).

База данных: Схема или база данных в системе управления реляционными базами данных, хранилище документов, графическая база данных и т.д., Такие как MySQL, Microsoft SQL Server, база данных Oracle, MongoDB, Riak, Cassandra, Neo4j и т.д. Хранилище больших двоичных объектов или контента: Хранилище больших двоичных объектов (например, Amazon S3, хранилище больших двоичных объектов Microsoft Azure и т.д.) Или сеть доставки контента (например, Akamai, Amazon CloudFront и т.д.).

• Файловая система: Полная локальная файловая система или часть более крупной сетевой файловой системы (например, SAN, NAS и т. Д.).
• Сценарий оболочки: Один сценарий оболочки, написанный на Bash и т.д.
• и т.д.

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

Maxim Tsepkov: Понятно, что контейнер - не обязательно докер. Но до массовой виртуализации и переходе на микросервисы этот уровень абстракции не выделяли, было два основных шаблона для условно-монолитов, 2 и 3 звенная модель, и это можно было рассматривать как уровни в устройстве приложения, физический (tier), в отличие от логических (layer), хотя это как раз часто смешивали.

Anton: 4-й уровень как раз диаграмма классов. https://www.infoq.com/articles/C4-architecture-model/

Maxim Tsepkov: Да. но это - диаграмма классов устройства конкретного компонента, и эти классы могут быть связаны с объектами предметной области или совершенно с ними не связаны. Если глянуть в историю, напрмиер, шаблоны программирования Фаулера, то использование объектов предметнй области в качестве классов в реализации - лишь один из шаблонов, Business Objects.

Maxim Tsepkov: Вообще если на уровни c4 model посмотреть с точки зрения системного подхода, то получается очень интересная картина, надо будет о ней еще детальнее подумать. И о сопоставлении этой модели с более ранними архитектурными диаграммами.

Anton: А есть более расширенный доклад, по данной тематике, а также пример описания (с нуля) таким методом какой-либо системы?

Maxim Tsepkov: Пока нет, это - мой первый доклад на эту тему. И уже понятно, что надо развивать.

Anton: Просто ваш подход означает, что мы собираем ИТ систему снизу вверх и он имеет место быть, но как бы не получить монолит, либо плохую архитектуру.

Maxim Tsepkov: Про снизу-вверх просьба пояснить. В докладе был пример слоев Archimate: Business - Application - Technical. B на каждом уровне, в общем случае, своя декомпозиция. Сделаем ли мы при этом монолит или проведем декомпозицию, какую архитектуру построим - другой вопрос. Но Achimate - он преимущественно про софт, там Business layer описывает контекст. А реальная система - включает софт вместе с людьми, которые совместно реализуют процессы, что-то в софте, а что-то и- и без него. И насколько монолитной и в какой архитектуре мы ее строим, например, делаем ли мы систему доставки в торговой компании монолитной, или делаем отдельно доставку для интернет-магазина, для доставки из магазинов, для завоза в магазины и для оптовых заказов - это как раз вопрос декомпозиции. И насколько софт должен поддерживать вариации организационной декомпозиции.

Anton: Простите упустил данный момент. Спасибо