Введение

Я — системный аналитик, и моя работа заключается в том, чтобы проектировать автоматизированные информационные системы. Впрочем, нет, она заключается в том, чтобы писать и писать документы. Третий раз слово «писать» повторять не буду — все-таки, не «Илиада». Но занудность формы чем-то определенно роднит проектную документацию с древнегреческой поэмой, особенно если речь идет о работе с государственным заказчиком.

Диаграммы — глоток творчества в этом море текста. О диаграммах и пойдет речь в данной статье. Если точнее — о PlantUML — с моей точки зрения, наиболее адекватном инструменте их создания на текущий момент.

Уточняем описание функций системы с помощью диаграммы Sequence (продолжение "Белки")

В данной статье рассмотрим, как можно детализировать (уточнить) описание автоматизируемой функции с помощью UML Sequence Diagram — диаграммы последовательности.

В данном примере я использую среду Enterprise Architect от австралийской компании Sparx Systems [1].
Полную спецификацию UML см. здесь [2].

Для начала поясню, что мы будем детализировать.
В 1-ой части статьи "От моделирования процессов к проектированию автоматизированной системы" мы моделировали процессы «сказочной» предметной области — строчки про белку из "Сказки о царе Салтане" А.С.Пушкина. И начали мы с диаграммы Activity. Потом во 2-ой части мы разработали функциональную модель с помощью диаграммы Use-case, на Рисунке 1 представлен фрагмент.

Рисунок 1. Связь требования и функции

Теперь мы хотим уточнить информацию о выполнении данной автоматизируемой функции:

• с какими компонентами интерфейса будет взаимодействовать наш пользователь;
• какие управляющие компоненты нам понадобятся;
• что мы будем хранить;
• какими сообщениями будут обмениваться пользователь и компоненты системы для выполнения функции.

Советский плакат «Автоматическую систему управления производством — народному хозяйству!», художник Р. Сурьянинов, 1972

«Рассказ о моделировании именно сложных систем»

Предыстория

К одной из моих статей по моделированию «сказочной» предметной области (часть 1, часть 2) был оставлен комментарий, цитирую:

«Было бы здорово увидеть рассказ о моделировании именно сложных систем».

И я пообещала подобрать что-то из реальной жизни.

• UML зародился в 90-х годах как результат работы по создания языка объектно-ориентированного моделирования.
• Спецификация 1.0 вышла в 1997 году.
• Спецификация 2.0 вышла в 2005 году.
• На сегодняшний день версия UML 2.5, развитие получили несколько профилей, такие как SysML и SoaML.

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

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

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

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

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

Сравнение двух подходов структурирования диаграммы Activity (по мотивам "Белки")

В 1-ой части статьи "От моделирования процессов к проектированию автоматизированной системы" мы моделировали процессы «сказочной» предметной области — строчки про белку из "Сказки о царе Салтане, о сыне его славном и могучем богатыре князе Гвидоне Салтановиче и о прекрасной царевне Лебеди" А.С.Пушкина. И начали мы с диаграммы Activity, договорившись о структурировании поля диаграммы с помощью «плавательных» дорожек – Swim lanes. Имя дорожки соответствует типу элементов диаграммы, которые присутствуют на этой дорожке: «Входные и выходные артефакты», «Шаги процесса», «Участники» и «Бизнес-правила». Этот подход отличается от стандартного, когда дорожки обозначаются именами участников процесса, таким образом закрепляя за ними определенные зоны ответственности в процессе.

В данном примере я использую среду Enterprise Architect от австралийской компании Sparx Systems [1].

Подробнее о применяемых подходах к моделированию см. [2].

Полную спецификацию UML см. здесь [3].

«Один день из жизни белки» или от моделирования процессов к проектированию автоматизированной системы учёта материальных ценностей «Белка-1.0» (Часть 2)

Использована иллюстрация к "Сказке о царе Салтане" А.С.Пушкина, изд."Детская литература", Москва, 1949 год, Ленинград, рисунки К.Кузнецова

Краткое содержание предыдущей серии

В 1-ой части мы использовали «сказочную» предметную область, вдохновленные примерами изучения диаграмм UML с опорой на сюжеты сказок (см., например, здесь [1]). До начала моделирования мы договорились относительно использования некоторых элементов диаграммы Activity и начали формировать соглашение по моделированию. С учетом этих договоренностей мы на 1-ом этапе описали процесс в виде диаграмм Activity, а на 2-ом этапе выделили шаги процесса, для которых требуется (и возможна) автоматизация.

Напомню, что автоматизировать мы собираемся деятельность по учёту материальных ценностей, которая возникает вот в этих процессах.

«Один день из жизни белки» или от моделирования процессов к проектированию автоматизированной системы учёта материальных ценностей «Белка-1.0» (Часть 1)

Использована иллюстрация к "Сказке о царе Салтане" А.С.Пушкина, изд."Детская литература", Москва, 1949 год, Ленинград, рисунки К.Кузнецова

При чем тут «белка»?

Сразу поясню, при чем тут «белка». Наткнувшись в Сети на забавные проекты для изучения UML с опорой на предметную область, заимствованную из сюжетов сказок (например, здесь [1]), я для своих студентов тоже решила подготовить подобный пример, чтобы можно было изучить для начала всего три вида диаграмм: Activity Diagram, Use-case Diagram и Class Diagram. Умышленно не перевожу на русский язык названия диаграмм, чтобы избежать споров о «трудностях перевода». Что для чего – поясню немного позже. В данном примере я использую среду Enterprise Architect от австралийской компании Sparx Systems [2] – хороший инструмент за разумные деньги. А в рамках учебных занятий применяю Modelio [3], неплохое бесплатное средство объектно-ориентированного проектирования, поддерживающее стандарты UML2.0 и BPMN, без излишних наворотов в части изобразительных возможностей, но вполне достаточное для изучения основ языка.

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

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

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

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

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

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

Есть ли какое-то официальное определение системного аналитика и его области ответственности?

Пользовательские истории (User stories, юзер стори), вероятно, являются самой популярной техникой аджайл (гибкой методологии) для описания функциональности продукта: с пользовательскими историями очень легко работать. Но «рассказывать» эффективные истории бывает достаточно сложно. Следующие десять советов помогут вам в создании хороших пользовательских историй.

Аудиоверсия статьи здесь.

Скачать аудиоверсию можно здесь.

Всем привет. Меня зовут Капранов Кирилл, я — руководитель направления системного анализа в компании Sportmaster Lab. 10 марта 2021 года мы с коллегами сделали первый митап по системному анализу, и я хочу поделиться с вами тем, как это было.

Что первым приходит в голову, когда слышишь фразу: "работаю в Спортмастере"? Уверен, у 90% людей промелькнет в голове: "Хм, наверное, продаёт кроссовки". Почему именно эти стереотипы?

Всё просто: в прошлом компания "Спортмастер" делала упор на развитие розничной сети, создание собственного производства, налаживание сети поставок, и, хотя ИТ в этом играло большую роль, знали об этом только внутри компании.

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

Привет! Меня зовут Саша, и я хочу стать хорошим системным аналитиком.

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