Самоучитель UML, 2 издание (Рубрика #Architecture)

Иногда я все-таки очищаю свои книжные полки от старых книг, обычно этот момент наступает, когда у меня не остается места для новых книг. Именно с такой целью я снял книгу Александра Леоненкова 2006 года издания, в которой он рассказывал про UML 1.5. Эта книга была пересказом стандарта на русский язык в вольной форме. С тех пор стандарт убежал до версии 2.5.1, которая вышла в декабре 2017 года, но проблема с языком гораздо глубже ... В этом посте я немного расскажу и про книгу и про свое отношение к языку UML.

Около 20 лет назад я только начинал свою профессиональную карьеру как программист. Я учился на третьем курсе Физтеха и уже начал получать какие-то деньги за написание кода. Я писал код и до этого, он был так себе, а еще я делал это бесплатно. Но когда я понял, что это теперь моя профессия, то я решил подойти к делу серьезно и подучить теорию (это мой стандартный подход к изучению чего-то нового). Забавно, что на свой первый личный компьютер я заработал на стройке Nix, где работал на летних каникулах первого курса. Личный компьютер позволил мне проще погружаться в мир разработки, а опыт работы на стройке помог понять, что лучше работать головой, а не руками. Но вернемся к изучению теории. В университете мы учили C++ и ассемблер (признаюсь, ассемблер прошел мимо меня). На работе надо было писать на html, js, css, php, а еще знать немного linux:) Ну а для себя я решил разобраться с архитектурой и проектированием систем. Так я стал счастливым обладателем нескольких книг по UML, а также книги "Совершенный код" Макконнела, про которую я уже писал. Одной из книжек по UML был именно этот самоучитель Леоненкова, который был хоть и нудноват, но зато неплохо и на русском рассказывал про унифицированный язык моделирования UML. Книга состояла из трех частей:
- Основы UML
- Диаграммы концептуального, логического и физического моделирования
- Анализ и проектирование с использованием UML и IBM Rational Rose 2002

В основах UML автор рассказывал про процедурное программирование, потом объектно-ориентированное программирование, а потом переходил к объектно-ориентированному анализу и проектированию. Причем все это сопровождалось историческим анализом и объяснением как разные методологии разных людей потом оказались сшиты в унифицированный язык моделирования. Про это рекомендую посмотрть подкаст с Гради Бучем, создателем языка, про который я рассказывал раньше. Потом автор погружался в рассказ о моделях реального мира, метамоделях из UML, а после переходил к основным типам диаграмм, про которые я расскажу отдельно в следующем посте. После диаграмм автор рассказывает про использование IBM Rational Rose 2002, которая как раз является делом рук Гради Буча и его компании Rational, которую когда-то выкупил IBM. Гради про это интересно рассказывает в упомянутом выше подкасте.

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

P.S.
В текущий момент эта книга просто раритет. Читать ее никакого смысла уже нет:) Но вот изучить виды моделей из UML может быть полезно, поэтому дальше я расскажу про них

#DistributedSystems #Architecture #Software #Engineering #SystemDesign

Обложка книги "Самоучитель UML, 2 издание". Отмечу, что автор очень тонко уловил будущее языка UML, который при переходе от версии 1* к 2* сместил фокус с людей на машины, так как у мейнтейнеров языка была идея фикс писать описание на UML, а дальше из этого генерировать код. Это привело к падению популярности языка UML, так как люди почти перестали его использовать для общения между собой, а вот использовать его для указания машинам как генерировать код на языках программирования так и не начали:)

Полезные диаграммы из UML (Рубрика #Architecture)

Сегодня утром я вспоминал книгу "Самоучитель UML", а также применимость языка для коммуникации и размышления об архитектурных решениях (1 и 2). Там я пообщел отдельно рассказать о диаграммах, которые я считаю полезными и вот время пришло. Ниже представлен список, который мне кажется полезным и в нынешних условиях, когда UML проиграл другим средствам моделирования, навроде C4 Model, про который хорошо рассказывает Саймон Браун, создатель концепта (смотрите мой разбор его доклада "The C4 Model - Misconceptions, Misuses & Mistakes" из 2024 года)

1) Use case diagram (диаграмма вариантов использования) - это стандартная диаграмма со сценариями, из которой обычно все помнят человечков и эллипсы, но забывают, что это только иллюстрации, а основа в тексте с happy path и exceptional flow. Также тут есть магия про декомпозицию и композицию сценариев. Сам тип диаграммы иногда используется до сих пор, но когда-то стало модно это описывать через user stories, потом customer journey map, потом jobs to be done сценарии и так далее
2) Class diagram (диаграмма классов) - по-факту, это наследие ER диаграммы (entity-relationship), но в объектно-ориентированном исполнении. Почти любая IDE может генерировать такие диаграммы по коду. Они понятные для инженеров и тоже иногда используются
3) Sequence diagram (диаграмма последовательности) - это популярная диаграмма для описания взаимодействия между разными частями системы. Она достаточно интуитивно читается, а также позволяет описать и проанализировать сложное взаимодействие. Хороший пример такого описания и анализа есть в недавные статье от Google "A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google", про которую я рассказывал раньше. Кстати, есть похожая диаграмма, которая тоже про взаимодействия, но отображение чуток другое - это Activity diagram (диаграмма деятельности). Эти диаграммы отображают динамическое поведение системы
4) Component diagram (диаграмма компонентов) - это диаграмма позволяет отобразить компоненты с их интерфейсами, а также как они зависят друг от друга. Эта диаграмма отображает статическое состояние системы.
5) Deployment diagram (диаграмма развертывания) - этот вид диаграмм позволял связать логическое описание системы с его физическим воплощением. То есть мы понимали тут как наши компоненты будут физически воплощены в процессах, внутри серверов, связаны сетью и так далее.
6) State chart diagram (диаграмма конечного автомата) - этот тип диаграмм позволяет описывать конечные автоматы. У него есть состояния и переходы между ними, доступные действия и так далее. В этой диаграмме мы можем описать, например, логику работы чайника. Его состояния могут быть такими: «выключен», «нагревается» и «кипит». Когда мы нажимаем кнопку, он выполняет действие — переходит из состояния «выключен» в состояние «нагревается». А когда вода в чайнике закипает, он автоматически меняется на состояние «кипит». Каждое из этих действий, например, нажатие кнопки или закипание воды, заставляет чайник переходить из одного состояния в другое, по заранее заданным нами правилам.

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

P.S.
Визуальные примеры диаграмм доступны в следующем посте.

#Software #Architect #SystemDesign #SoftwareArchitecture #Processes

Getting to Neutral. How to conquer negativity and thrive in a chaotic world (Главное правило мышления) (Рубрика #Thinking)

Эта интересная книга Тревора Моавада, ментора спортсменов мирового уровня, предлагает интересный подход к управлению своим ментальным состоянием и принятию качественных решений. В английском названии книги основная мысль вынесена в название "Getting to neutral" - автор предлагает концепцию нейтрального мышления, что расположено между позитивным мышлением и негативным. Позитивное мышление - это зобирование себя мыслями, что все так или иначе будет хорошо, а негативное мышление предполагает рассмотрение всего происходящего со стороны негативных факторов и рисков. Автор же предлагает сбалансированно и рационально смотреть на ситууацию и вызовы, которые нам требуется преодолеть. Забавно, что для этого понадобилось отдельное название - я практикую такой взгляд на мир уже больше 30 лет. Странно, что МИФ дал книге альтернативное название при переводе "Главное правило мышления" - это вводит читателей в заблуждение, так как автор ни разу не называет никакого правила мышления в книге, но приводит несколько концепций, которым рекомендует следовать

- Neutral thinking (нейтральное мышление): этот майндсет помогает людям оставаться спокойными и объективными в условиях высокого давления. Вместо того, чтобы быть слишком оптимистичными или пессиместичными такое мышление позволяет оценить обстоятельства и доступные варианты и принять качественне решения
- Power of words (сила слов): Тревор отмечает, что произнесенные слова оказывают на порядок больше влияния, чем мысли. Причем негативные слова оказывают больше влияния, чем нейтральные или позитивные. Например, Тревор называет заболевание, с которым он боролся во время написания книги, "словом на букву р" (и только один раз он говорит о том, что это рак, описывая первый раз, когда ему огласили диагноз)
- Behavior over words (поведение важнее слов): действия значат больше, чем мысли или слова. Тревор отмечает важность фокусировки на желаемом поведении, которое приближает нас к желаемым целям.
- Behavior over emotion (поведение важнее эмоций): успех связан с консистентным поведением больше, чем с флуктуациями эмоций. Нейтральное мышление фокусируется на действиях, что приближают к успеху, а не к следованию за эмоциональными пиками и спадами
- Eliminating negativity (устранение негатива): автор рекомендует читателям идентифицировать и устранять влияние негатива на их жизни, включая чтение новостей и социальных медиа
- Adversity tolerance (устойчивость к невзгодам): нейтральность помогает людям развивать устойчивость, отстраняясь от прошлых неудач или успехов и сосредотачиваясь на том, что можно контролировать в настоящий момент.
- Value-based decision making (принятие решений на основе ценностей): Тревор поощряет выравнивать действия с ключевыми ценностями для поддержания ментального баланса даже в стрессовой ситуации.

Тревор Моавад так и не смог победить рак, но он успел дописать эту книгу, в которой поделился своими секретами психологической подготовки, которые он практиковал с элитными спортсменами, военными и корпоративными лидерами. Он получал награды за его инновационные методы оптимизации производительности в условиях давления, но главное - это признание его вклада в успех его клиентов. Например, послесловие написал квотербек НФЛ Рассел Уилсон, с которым он сначала работал над мотивацией, а потом Рассел помогал Тревору в период его лечения. В общем, Тревор в своей книге предлагает прагматичную альтернативу традиционным парадигмам позитивного мышления. Приняв нейтральное мышление, люди могут лучше ориентироваться в сложностях жизни с ясностью и устойчивостью..

P.S.
Интересно, что эти принципы отлично работают в больших компаниях - например, важно смотреть не на слова, а на действия топ-менеджмента, чтобы понимать какие ценности у компании на самом деле.

#Management #Leadership #Psycho #SelfDevelopment #Brain #Thinking

ArchInsight в Лемана Тех - Панельная дискуссия про архитектуру

Пару недель назад я ездил в Лемана Тех на их первый офлайн-митап архитекторов под названием ArchInsight, где поучаствовал в дискуссию про будущее архитекторов и архитектуры. Буквально сегодня появилась запись дискусии, а также пост ребят о самом мероприятии в их tg канале. Напомню, что мы за час успели обсудить следующие темы
1. Управление архитектурными изменениями в быстро меняющемся мире
2. Сложные кейсы архитектуры: что делать, когда все не так, как должно быть?
3. Архитектурный репозиторий: как сделать его инструментом для всех?
4. Архитектор как посредник между бизнесом и ИТ: как говорить на одном языке?
5. Эффективное управление архитектурными изменениями: от идеи до внедрения

В дискуссии мы вспоминали много разных тем и конкретно книгу "The Software Architect Elevator" Gregor Hohpe, про которую я писал раньше. Суть была в том, что архитектору не стоит отрываться от земли и уходить в фантазии на N-том этаже своей башни, а стоит быть поблжие к земле и спускаться в машинный зал, где работают инженеры. Забавно, что после окончания конфы спикерам раздали подарки в сумке "Do it yourself", где были шуруповерты. В общем, я понял намек на то, что слова не должны расходиться с делами и обязательно воспользуюсь этим инструментом:)

P.S.
Спасибо организаторам за мероприятие - мне понравилось общение с другими участниками панельной дискуссии и всего митапа в целом, а также понравился подарок:)

#Architecture #Software #Management #Leadership