Привет, меня зовут Сергей, я ведущий разработчик в DDoS-Guard и человек из мемов xkcd, который любит всё экстраполировать, истовый фанат визуализации данных. Диаграммы и графики решают кучу моих проблем с онбордингом джунов и объяснением задачи исполнителям.
В этой статье я расскажу о нескольких не самых стандартных, но очень полезных диаграммах, и покажу на трех примерах, как визуализация данных помогала мне в моей работе.
Такие схемы на проектах готовят наши архитекторы. Достаточно ли их чтобы оценить состав и сложность каждого модуля, объем и трудоемкость работ в целом. Поможет ли такая схема при планировании работ?
В статье рассуждение о том что могло бы помочь.
Системный аналитик всегда и везде сталкивается с бесконечным количеством диаграмм разного вида, с нотациями (правилами), чтобы нарисовать данные диаграммы и с бесконечным количеством инструментов для их описания. Но мало кто говорит о таком инструменте, как PlantUML.
Лично мне завесу тайны приоткрыл Альфа-Банк, здесь документация ведется рядом с кодом, и схемы логичнее описывать тоже кодом. Но это не так страшно и не так сложно (почти) как кажется. Давайте я приоткрою ящик Пандоры и сниму кармическое проклятье с этого инструмента.
Привет, Хабр!
Меня зовут Костя, и я отвечаю за дизайн в AGIMA. Недавно, рассказывая коллеге, как надо было оформить таблицу, я словил дежавю: делал я это явно не первый раз. Поэтому я решил написать эту совсем базовую статью о том, как делать приличные таблицы, чтобы у меня всегда было куда послать следующего спрашивающего. Статья будет полезна как начинающим дизайнерам, так и просто жаждущим приподнять уровень своих документов чуть выше плинтуса. А в конце ,elen ссылки, которые помогут вам достичь табличного совершенства.
Привет! Меня зовут Дмитрий Шувалов, я руководитель компании «Интегральный дизайн». В последнее время экономику страны штормит: цены растут, покупательная способность населения снижается, меняются бизнес-цепочки, люди переживают за будущее. Всё это влияет на стратегию развития продуктов и сервисов большинства компаний. Какой бы продукт вы ни развивали, за последний месяц у вас хоть раз, но возникал вопрос: «Что дальше?» Мы с компанией AGIMA разработали фреймворк, который поможет максимально четко на него ответить. В этой статье рассказываю, что мы придумали и как за 2–3 месяца понять, куда двигаться.
Для кого эта статья? Эта статья, также как и первая, рассчитана на людей, работающих в сфере ИТ. Для разработчиков, тестировщиков, менеджеров разного уровня, аналитиков и т.д. Для расширения кругозора, она также может быть полезна и всем остальным, просто, чтобы иметь представление о том, чем занимается Системный Архитектор. Пригодится материал и тем, кто планирует развитие своей профессиональной карьеры, и тем, кто выкладывает такого рода вакансию и ищет специалиста в команду.
Что еще? Думаю что надо как то договорится о подаче материала. Здесь, как и в первой статье, я рассмотрю конкретный пример из своей практики, который, как мне кажется, максимально точно иллюстрирует специфику работу данного специалиста. Как и раньше, в заключении, попробую ответить на следующие вопросы: кто такой Системный Архитектор, какими навыками должен обладать и т.д. Поехали?
И последнее, думаю, надо представится. Меня зовут Владимир Воловиков. Опыт работы в сфере разработки программного обеспечения более 20 лет. В должности Системного архитектора и Программного архитектора, в общей сложности, более пяти лет. Имею четыре международных сертификата. Текущее место моей работы Системный архитектор, Банк ВТБ.
Я дико люблю ковыряться в чужом коде. Это одна из моих любимых специализаций. То есть я просто беру чужой код, анализирую его, читаю. Как я читал его раньше: я переводил код в русский язык. Описывал, что происходит по флоу кода, и пытался понять, что там происходит. Эти записи я в дальнейшем использовал как для написания статей в Confluence, так и для общего понимания происходящего.
С одной стороны, решение работающее. С другой, буквально через неделю-две я уже начинал сомневаться, достаточно точно ли я «перевел» с кода на русский язык? И тогда вспомнил про UML-диаграммы. И вместо того, чтобы записывать текст, стал визуализировать его и исписал неимоверное количество тетрадей.
Но в какой-то момент подумал, что хорошо бы перевести все это в электронный вид, чтобы какой-то инкремент оставался. Не фоткать же, например, для документации, свою тетрадь с каракулями. Так я нашел инструмент PlantUML — opensource-решение, которое использует графическую библиотеку graphviz, превращающее код в наглядные схемы.
Давайте вспомним, что такое Unified Modeling Language. Чаще всего в университете UML используется для описания диаграммы классов.
Вторая часть перевода статьи Леона Старра, инженера программных моделей. Первая часть вот здесь. В этой части — о семантике и о том, что отличает хорошую модель.
Мне показался близким подход Леона Старра к объяснению чётких моделей классов и описанию их преимуществ. Настолько, что мы в Retail Rocket решили сделать перевод его большой статьи "How To Build Articulated UML Class Models". Будем выкладывать по частям, под катом — первая из трёх.
Советский плакат «Автоматическую систему управления производством — народному хозяйству!», художник Р. Сурьянинов, 1972
К одной из моих статей по моделированию «сказочной» предметной области (часть 1, часть 2) был оставлен комментарий, цитирую:
«Было бы здорово увидеть рассказ о моделировании именно сложных систем».
И я пообещала подобрать что-то из реальной жизни.
В 1-ой части статьи "От моделирования процессов к проектированию автоматизированной системы" мы моделировали процессы «сказочной» предметной области — строчки про белку из "Сказки о царе Салтане, о сыне его славном и могучем богатыре князе Гвидоне Салтановиче и о прекрасной царевне Лебеди" А.С.Пушкина. И начали мы с диаграммы Activity, договорившись о структурировании поля диаграммы с помощью «плавательных» дорожек – Swim lanes. Имя дорожки соответствует типу элементов диаграммы, которые присутствуют на этой дорожке: «Входные и выходные артефакты», «Шаги процесса», «Участники» и «Бизнес-правила». Этот подход отличается от стандартного, когда дорожки обозначаются именами участников процесса, таким образом закрепляя за ними определенные зоны ответственности в процессе.
В данном примере я использую среду Enterprise Architect от австралийской компании Sparx Systems [1].
Подробнее о применяемых подходах к моделированию см. [2].
Полную спецификацию UML см. здесь [3].
В 1-ой части мы использовали «сказочную» предметную область, вдохновленные примерами изучения диаграмм UML с опорой на сюжеты сказок (см., например, здесь [1]). До начала моделирования мы договорились относительно использования некоторых элементов диаграммы Activity и начали формировать соглашение по моделированию. С учетом этих договоренностей мы на 1-ом этапе описали процесс в виде диаграмм Activity, а на 2-ом этапе выделили шаги процесса, для которых требуется (и возможна) автоматизация.
Напомню, что автоматизировать мы собираемся деятельность по учёту материальных ценностей, которая возникает вот в этих процессах.
Сразу поясню, при чем тут «белка». Наткнувшись в Сети на забавные проекты для изучения UML с опорой на предметную область, заимствованную из сюжетов сказок (например, здесь [1]), я для своих студентов тоже решила подготовить подобный пример, чтобы можно было изучить для начала всего три вида диаграмм: Activity Diagram, Use-case Diagram и Class Diagram. Умышленно не перевожу на русский язык названия диаграмм, чтобы избежать споров о «трудностях перевода». Что для чего – поясню немного позже. В данном примере я использую среду Enterprise Architect от австралийской компании Sparx Systems [2] – хороший инструмент за разумные деньги. А в рамках учебных занятий применяю Modelio [3], неплохое бесплатное средство объектно-ориентированного проектирования, поддерживающее стандарты UML2.0 и BPMN, без излишних наворотов в части изобразительных возможностей, но вполне достаточное для изучения основ языка.
