Анализ и проектирование систем *

Введение

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

Как бы то ни было, неплохо бы разобраться в том, что же собой представляют ИТС и для чего они предназначены. Опустим транспортную и политическую составляющие и сосредоточимся на «Айтишной». Разберем на самом высоком уровне архитектуру ИТС и коротко пробежимся по основным ее блокам. Заодно системным архитекторам будет любопытно узнать, как вообще строится архитектура систем масштаба страны.

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

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

Картинок, естественно, не будет, они тут совершенно не нужны, у всех технически грамотных людей должно быть абстрактное мышление.

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

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

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

Задача одновременного перемещения масс людей — есть задача вычислительная, задача оптимизации, которой должен заниматься не человек, а компьютер.

Мне давно хотелось в простой и доступной форме рассказать о построении интеллектуальных транспортных систем. Потому что мне кажется, что эта тема недостаточно хорошо раскрыта на русском языке, а российских специалистов в этой области можно пересчитать по пальцам. Себя я к числу этих специалистов пока отнести не могу, так как только начал разбираться в проблеме. Но именно поэтому мне интересно об этом писать. Я хочу рассказать о том, как живет отрасль сейчас, какие вообще существуют технологии и средства решения транспортных проблем, какие нюансы и интересные особенности есть в этой сфере. Я хочу написать то, что мне самому так хотелось прочитать хотя бы год назад, когда вокруг не было совсем ничего. Если вам что-то покажется наивным или совершенно очевидным, не судите строго. Для меня эта наивность — хлеб и соль. Только эта наивность, помноженная на богатую фантазию помогает строить в воображении детальную модель будущего. Которая при некоторых познаниях в UML и BPML превращается в проектную документацию.

Раз уж нам с вами предстоит пройти некоторый путь вместе, позвольте представиться. Меня зовут Алексей. По специальности я инженер-системотехник, профессиональный сисадмин. Окончил профильный ВУЗ в 1999 году, 6 лет работал системным инженером, потом 3 года специализировался в менеджменте в области ИТ, а потом нашел себя в роли бизнес-аналитика.

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

Надо сказать, коллеги, что эта работа — просто рай для любителей игры Sim City и Transport Tycoon. Где еще вам представиться возможность построить транспортную систему целого города? И не на экране компьютера, а живьем.

Конечно, не все в этой отрасли радужно и прекрасно. Особенно в нашей стране. Далее о проблемах.

Мы, Сергей Нужненко и Денис Бесков, объявляем набор в летнюю школу системного анализа.

Что это такое
Это базовый курс прикладного системного анализа в информационнных технологиях, который мы будем вести в Москве очно и бесплатно всё лето, 12 недель, каждое воскресенье, с 12 до 15 часов дня.

В состав курса входят лекции, практические занятия, домашние задания и ежемесячный рубежный контроль. Общий объём курса — от 36 до 100 очных часов (программа уточняется), возможны интенсивы (недельный тренинг в рабочее время, если позволит расписание всех участников). Средняя нагрузка на учащегося в неделю (занятия и самостоятельная работа) — от 5 до 10 часов.

Что приобретут участники

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

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

На хабрахабре регулярно публикуются статьи о юзабилити. Некоторые вещи, которые в них говорятся обычно достаточно очевидны, некоторые требуют серьезной подготовки. Однако во всех них чего-то не хватает.

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

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

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

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

V. Анализ бизнес-проблем

Проблемы, их владельцы и причины

Описание проблем удобно описывать с помощью таблицы, чтобы структурировать информацию по следующим пунктам.

1. Проблема.
2. На кого воздействует.
3. Результатом чего является.
4. Выигрыш от новой системы.
5. Приоритет.

После описания всех проблем необходимо сортировать в порядке убывания по приоритету, чтобы выделить наиболее значимые.

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

IV. Описание предметной области

Законодательные ограничения

— Зрителю должно быть больше 14 лет (для сделкоспособности).
— Необходимо дополнительное пользовательское соглашение, в котором пользователю будет необходимо дать согласие на использование его персональных данных.
— В соглашении также должно быть указано, что услуга бронирования предоставляется безвозмездно.

Словарь терминов

Диаграмма сущностей

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

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

III. Описание процесса в графической форме

В виде диаграмм бизнес-процесс можно описывать с помощью различных нотаций: ARIS — VAD и EPC, IDEF0, BPMN и др. Нотаций много, у каждой есть свои достоинства и недостатки, в рамках этой статьи эта тема не затрагивается.

Основной плюс использования диаграмм — наглядность. Основные минусы — сложно изображать все возможные варианты ветвлений и долго вносить изменения.

Посещение кинотеатра без предварительного бронирования билетов (в нотации VAD)

I. Бизнес-контекст

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

Издательский дом «Афиша» был основан в апреле 1999 года и сегодня является владельцем нескольких ведущих журналов и сайтов о развлечениях. Компания издает журнал «Афиша», выходящий в трех версиях, — для Москвы, Петербурга и 20 других городов России. Аудитория одного номера журнала составляет около 1 миллиона человек. Сайт «Афиши» ежемесячно посещают порядка 3,2 млн человек.

С целью расширения функционала сайта, развития портала и подготовки к продаже билетов на киносеансы было принято решение рассмотреть возможность запуска сервиса бронирования билетов, который бы работал следующим образом: «Афиша» вступает в партнерские отношения с сетью кинотеатров N и предоставляет зарегистрированным пользователям сайта возможность осуществлять он-лайн бронирование билетов на киносеансы данной сети. В свою очередь, компания N размещает на территории своих кинотеатров рекламные объявления, содержащие ссылку на сайт afisha.ru. Объявления могут размещаться в любом виде: на плакатах, на билетах, в виде логотипа на любых информационных материалах.

Всем привет!

Мы, Денис Бесков (beskov) и Илья Поляк (ilyap1) начинаем публикацию цикла статей, посвящённых процессу проектирования веб-сервисов. Цикл построен вокруг 3-хуровневого процесса, в котором явным образом выделяются уровни анализа и проектирования:

1. Бизнеса
2. Продукта
3. Технологий

Здесь, на хабре, достаточно хорошо освещается тема проектирования на уровне технологий. Мы хотим показать взаимосвязь этого уровня, видов работ и проектных решений с вышестоящими уровнями на примере сквозного демо-кейса — проектирования веб-сервиса бронирования билетов в кино, в разработке которого участвовал пару лет назад один из авторов.

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

1. Какими способами можно описывать требования к ПО?
2. Какие из требований к системе обязательно необходимо включать в ТЗ, а без каких можно обойтись?
3. Какие могут быть варианты при выборе форматов описания требований?
4. Как зависит выбор вида описания требований от параметров (продолжительности, рисков и др.) проекта?
5. Какого рода решения помогают принять соответствующие виды требований?

В цикле не рассматриваются аспекты заказной разработки ПО. Статья рассчитана на пользователей, которые работают в некорпортивной среде, т.е. не привязаны к каким-либо регламентам.

В предыдущей статье на примере создания объектной модели простого сайта производились одиночные загрузки сущностей из базы данных по их идентификаторам конструкцией Object::Create($id), при этом мы знали, у какой сущности (чаще всего класса), какой идентификатор, так как сами создавали эти сущности и в крайнем случаи могли просто заглянуть в базу данных. На практике загружать сущности по идентификатору проблематично, если нас интересуют сущности, о существовании которых можно только догадываться, то есть, не имея информации об их идентификаторах. Более того существует необходимость загружать несколько сущностей разом, отвечающих некоторым условиям.

В магазине, например, мы не выбираем товар по его серийному номеру или штрих-коду, не зная при этом, что он означает – мы смотрим на свойства товара интересующие нас. На главной странице сайта, опять же для примера, необходимо выводить последние новости, что сводится к выборке из базы данных (объектной модели данных) 10 объектов класса «Новость» с сортировкой по дате их создания. Для осуществления подобных запросов необходим гибкий способ описания условий выборки сущностей – условий поиска с учетом особенностей объектной модели. На основе условия необходимо создавать SQL код для непосредственной выборки из БД идентификаторов сущностей удовлетворяющих условию, имеем идентификаторы – имеем сущности.

Продолжаем тему объектной модели данных. В этой части речь пойдет о модуле Data, являющимся, по сути, ORM системой. Для наглядности работы модуля Data c его помощью будет создано содержимое простого сайта. Предыдущая статья: Архитектура CMS. Модель данных. Часть 1.

Модуль Data состоит из классов Data, Object, Multy, Query и набора классов Cond*. Сам модуль – это статический класс Data, остальные классы используются для представления структур данных, с которыми он работает. Для представления сущностей в программном коде используется класс Object. Не важно, какого типа сущность – класс данных, объект данных или связь между ними – для всех Object. Класс Multy используется для ассоциации с набором сущностей, в частности, для представления множественных свойств. Классы Query и Cond* необходимы для осуществления поиска по объектной модели (в базе данных) с учетом гибких условий.

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

CMS может просто передавать данные по запросу клиентскому приложению, например сетевой программе, flash-клипу или AJAX-приложению. Но чаще всего, CMS предоставляет клиенту уже подготовленные для отображения данные в HTML формате. В этом случаи, для обеспечения доступности, легкости восприятия и удобства пользования содержимым, выполняется стилизация и объединение его с элементами оформления (темы, шаблоны), навигации (меню, ссылки) и управления (формы и ссылки тоже), и всем этим тоже нужно управлять.

Идея

Окружающий мир воспринимается нами объектным, мы мыслим «объектами», в наших умах выстраивается объектная модель мира. Поэтому нам не составит труда создать объектную модель содержимого сайта и управлять ею. Новости, товар в каталоге, сообщения на форуме и сами форумы, и все другое можно представить в виде объектов. Устанавливая связи между объектами, можно создавать структуры данных любой сложности, от добавления комментариев к статьям до создания социальных сетей и более.

Объекты, классы и связи данных – это информация, которую нужно уметь создавать, хранить, использовать, изменять и удалять. В нашем распоряжении реляционная база данных для хранения информации. Действия же совершаемые с информацией – часть логики функционирования CMS, которая в большей части будет реализована модулем данных Data.

После восьмой стопки поток сознания переключается с FreeBSD на Microsoft Bob. Давай, это будет весело!