UML Design *

В сети вы можете найти множество статей на тему «UML мертв», «Почему системным аналитикам не нужен UML» и множество подобного. Работая на протяжении последних 15 лет в совершенно разных компаниях, с совершенно разным жизненным циклом приложений и систем, с различной структурой и методологиями разработки я вижу одно и тоже — попытки ускорения time‑to‑market за счет отказа от процесса управления требованиями, подаваемые под разными прекрасными аргументами, приводят 100% компаний к необходимости переписывать приложения не потому, что оно не отвечает требованиям, а потому что «никто не знает как или почему оно так работает».

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

Можно перечислить еще огромное количество проблем, к которым приводит разработка без модели требований.

Здравствуйте! Меня зовут Дмитрий Моряков, и я ведущий системный аналитик в компании МаксимаТелеком. Теме миграции с монолита на микросервисную архитектуру (здесь и далее — МСА) за последние годы на страницах Хабра было посвящено немало материалов, поэтому я хотел бы сосредоточиться на узких аспектах этого процесса: выделении критической части при реализации пилотного проекта миграции на МСА и реализацию изоляции полученных микросервисов по данным.

Привет, Хабр!

Меня зовут Костя, и я отвечаю за дизайн в AGIMA. Недавно, рассказывая коллеге, как надо было оформить таблицу, я словил дежавю: делал я это явно не первый раз. Поэтому я решил написать эту совсем базовую статью о том, как делать приличные таблицы, чтобы у меня всегда было куда послать следующего спрашивающего. Статья будет полезна как начинающим дизайнерам, так и просто жаждущим приподнять уровень своих документов чуть выше плинтуса. А в конце ,elen ссылки, которые помогут вам достичь табличного совершенства.

Visual paradigm ― мощный инструмент, идеология использования которого выходит за рамки простого рисования диаграмм. Главное назначение инструментов данного класса (Visual Paradigm, Enterprise Architect и др.) ― описание модели информационной системы и дальнейшая работа с ней. Под работой подразумевается ее визуализация в виде диаграммы, экспорт документации, генерация исходных кодов, анализ, подсчет метрик и т. п. 

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

В статье я расскажу об основах создания плагинов для Visual Paradigm. В качестве примера возьмем формирование SQL-скрипта с комментариями к таблицам и колонкам на основе ER-диаграммы.

Интерактивный видеоконтент позволяет своим зрителям взаимодействовать с контентом и влиять на дальнейшее его повествование. Это уникальное направление видеоконтента, которое активно развивается в последнее время в различных сферах.

В данной статье мы хотим поделиться опытом создания платформы для проектирования интерактивного видеоконтента.

Use-case

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

Прецеденты нашего пользователя:

Привет! Меня зовут Дмитрий Шувалов, я руководитель компании «Интегральный дизайн». В последнее время экономику страны штормит: цены растут, покупательная способность населения снижается, меняются бизнес-цепочки, люди переживают за будущее. Всё это влияет на стратегию развития продуктов и сервисов большинства компаний. Какой бы продукт вы ни развивали, за последний месяц у вас хоть раз, но возникал вопрос: «Что дальше?» Мы с компанией AGIMA разработали фреймворк, который поможет максимально четко на него ответить. В этой статье рассказываю, что мы придумали и как за 2–3 месяца понять, куда двигаться.

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

1. Описание деятельности госинспекции

Сферой деятельности является осуществление федерального пробирного надзора (контроль за обращением драгоценных металлов). В соответствии с возложенными задачами осуществляет следующие функции:

• осуществляет опробование, анализ и клеймение государственным пробирным клеймом всех ювелирных и других бытовых изделий из драгоценных металлов отечественного производства, а также указанных изделий, ввезенных на территорию Российской Федерации для продажи;

• проводит экспертизу оттисков государственных пробирных клейм, контрольные анализы и техническую экспертизу драгоценных металлов и продукции из них, а также лома и отходов драгоценных металлов, экспертизу и диагностику драгоценных камней, экспертизу по постановлениям органов дознания, следователя, прокурора, суда и арбитражного суда;

• проводит экспертизу музейных и архивных предметов, изготовленных из драгоценных металлов и драгоценных камней, а также контроль за обесценением сохранности указанных предметов;

• обеспечивает постоянный государственный контроль за производством, извлечением, переработкой, использованием, хранением и учетом драгоценных металлов и драгоценных камней в организациях

Для кого эта статья? Эта статья, также как и первая, рассчитана на людей, работающих в сфере ИТ.  Для разработчиков, тестировщиков, менеджеров разного уровня, аналитиков и т.д. Для расширения кругозора, она также может быть полезна и всем остальным, просто, чтобы иметь представление о том, чем занимается Системный Архитектор.  Пригодится материал и тем, кто планирует развитие своей профессиональной карьеры, и тем, кто выкладывает такого рода вакансию и ищет специалиста в команду.

Что еще? Думаю что надо как то договорится о подаче материала. Здесь, как и в первой статье, я рассмотрю конкретный пример из своей практики, который, как мне кажется, максимально точно иллюстрирует специфику работу данного специалиста. Как и раньше, в заключении, попробую ответить на следующие вопросы: кто такой Системный Архитектор, какими навыками должен обладать и т.д. Поехали? 

И последнее, думаю, надо представится. Меня зовут Владимир Воловиков. Опыт работы в сфере разработки программного обеспечения более 20 лет. В должности Системного архитектора и Программного архитектора, в общей сложности, более пяти лет. Имею четыре международных сертификата. Текущее место моей работы Системный архитектор, Банк ВТБ. 

Сейчас рынок системного анализа переживает бурный рост и на это есть несколько причин:  

1) низкий порог входа (по сравнению с Java-разработчиками, например)

2) несколько хаотичные требования к системному аналитику на рынке труда (у каждой компании свое видение, кто это такой и чем он должен заниматься)

3) узкая специализация, например, мало кто вообще в детстве мечтал стать аналитиком:)

4) постоянное изменение внешней среды, в результате чего появляются новые возможности для системных аналитиков

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

Привет! Меня зовут Алина, я работаю техническим писателем в компании Quadcode. В этой статье хочу поделиться опытом верхнеуровневого описания архитектуры системы с использованием структуры C4. Небольшая оговорка: предпринятые шаги включают в себя определенные отходы от канонической нотации в угоду удобству и особенностям системы.

Для справки:

HLD (high-level design) – верхнеуровневое описание архитектуры системы, где представлены основные компоненты и их взаимодействия. 

LLD (low-level design) – низкоуровневое детальное описание каждого из компонентов системы.

Для кого эта статья? Конечно, для людей, работающих в сфере ИТ. Для разработчиков, тестировщиков, менеджеров разного уровня, аналитиков и т.д.. Уверен, что и для общего развития всем другим людям, так или иначе, причастным к ИТ было бы все же интересно это прочитать. Просто для расширения своего кругозора, для понимания того как создаются Информационные системы

Что меня сподвигло написать эту статью? Определенный опыт взаимодействия с разного уровня руководителями. Рассмотрим такую ситуацию. У нас есть вакансия, звучит она как Архитектор. И, вроде бы, понимание есть, что должен делать этот человек, но по факту оказывается, ждут “эникейщика”. 

Что еще? Думаю, что надо договорится о подаче материала. Что, если это будет реальная история из моей практики, на мой взгляд, максимально демонстрирует работу Программного архитектора, а также некоторые выводы, которые можно сделать из нее. Постараюсь ответить здесь на следующие вопросы: Кто такой программный архитектор, какими навыками и знаниями должен обладать этот человек? Годиться? 

И последнее, думаю надо представится. Меня зовут Владимир Воловиков. Работаю в ИТ сфере я уже почти 20-ть лет. В должности Системного архитектора и Программного архитектора, в общей сложности, более пяти лет. Имею четыре международных сертификата. Текущее место моей работы Системный архитектор, Банк ВТБ. 

Я дико люблю ковыряться в чужом коде. Это одна из моих любимых специализаций. То есть я просто беру чужой код, анализирую его, читаю. Как я читал его раньше: я переводил код в русский язык. Описывал, что происходит по флоу кода, и пытался понять, что там происходит. Эти записи я в дальнейшем использовал как для написания статей в Confluence, так и для общего понимания происходящего.

С одной стороны, решение работающее. С другой, буквально через неделю-две я уже начинал сомневаться, достаточно точно ли я «перевел» с кода на русский язык? И тогда вспомнил про UML-диаграммы. И вместо того, чтобы записывать текст, стал визуализировать его и исписал неимоверное количество тетрадей. 

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

Давайте вспомним, что такое Unified Modeling Language. Чаще всего в университете UML используется для описания диаграммы классов.

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

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

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

Пришло время посмотреть на тип модели классов UML, который можно встретить во множестве проектов. А ещё, увы, который часто поощряется в книгах по UML.

В первых двух частях (1, 2) мы обсудили общий принципы UML, о семантике и признаках хорошей модели. В этой части добавим ещё кое-что про хорошие модели и перейдём к плохим.

Вторая часть перевода статьи Леона Старра, инженера программных моделей. Первая часть вот здесь. В этой части — о семантике и о том, что отличает хорошую модель.

Мне показался близким подход Леона Старра к объяснению чётких моделей классов и описанию их преимуществ. Настолько, что мы в Retail Rocket решили сделать перевод его большой статьи "How To Build Articulated UML Class Models". Будем выкладывать по частям, под катом — первая из трёх.