Здравствуйте! Меня зовут Дмитрий Моряков, и я ведущий системный аналитик в компании МаксимаТелеком. Теме миграции с монолита на микросервисную архитектуру (здесь и далее — МСА) за последние годы на страницах Хабра было посвящено немало материалов, поэтому я хотел бы сосредоточиться на узких аспектах этого процесса: выделении критической части при реализации пилотного проекта миграции на МСА и реализацию изоляции полученных микросервисов по данным.
Привет, Хабр!
Меня зовут Костя, и я отвечаю за дизайн в 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.
Вторая часть перевода статьи Леона Старра, инженера программных моделей. Первая часть вот здесь. В этой части — о семантике и о том, что отличает хорошую модель.
Мне показался близким подход Леона Старра к объяснению чётких моделей классов и описанию их преимуществ. Настолько, что мы в Retail Rocket решили сделать перевод его большой статьи "How To Build Articulated UML Class Models". Будем выкладывать по частям, под катом — первая из трёх.
