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

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

Тренды будущего, которые меня интересуют. Тут я немного помечтаю, можно?

1. Распределенное роботизированное производство

В связи с российскими большими расстояниями, пробками на дорогах и качеством самих дорог весьма актуальным становится распределенное производство:
— создается интернет-сервис сбора заявок на изготовление деталей/прототипов
— менеджеры принимают оплату и заявки в виде чертежей либо моделей, делают необходимые уточнения по способу производства, допускам и пр, при необходимости подключают моделеров для создания 3D-модели
— уточненную заявку и оплату работ они направляют в центры обработки, находящиеся наиболее близко к расположению клиента. В центрах обработки находится современное ЧПУ оборудование (3D-принтеры, фрезеры, токарные станки, граверы, гибка металла, шлифовка-полировка, изготовление печатных плат, сборка и монтаж и пр), плюс операторы. Деталь/прототип изготавливается.
— после изготовления деталь/прототип отправляется клиенту по кратчайшему пути с помощью службы доставки
— процесс изготовления клиент может наблюдать онлайн (трансляция осуществляется вебкамерой)
— интерфейс системы геймифицирован (см. п.2)
— клиент, приславший фото или видео использования созданной вещи в своей работе, получает приз.

Задача

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

Имеется несколько удаленных объектов на просторах страны (Украина) электрифицированных, но не имеющих простых технических возможностей для подключения интернета. Объекты, как правило, расположены так что про 3G или WiMax заикаться не приходится. Доступен только GPRS. Нужно иметь возможность мониторить температуру в нескольких помещениях этих объектов. Причем желательно если не в реальном времени то с минимальной задержкой. Усложняется все еще тем что объекты хоть и недвижимость, но возможны ситуации что будет переезд. Поэтому капитальные методы установки оборудования отпадают.

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

Однажды, мне позвонили и спросили – могу ли я сделать маленькую автоматизацию для канализационной насосной станции (КНС)? Толком ничего не выспросив и положив трубку я стал раздумывать что и как сделать.

Являясь специалистом по SCADA более 10-ти лет, в основном по продуктам томской компании «Элеси», мне сразу пришло в голову использовать какой-нибудь известный пакет типа TraceMode и ему подобным. Однако, встретившись с заказчиком и узнав более подробно, что ему нужно, я решил не использовать готовые пакеты.

Задача была проста: исключить бабушку, сидящую в здании КНС и наблюдающую за периодическим процессом раскачки емкости со сточными водами. Насосами управлял ПЛК фирмы Modicon в составе какого-то российского щита управления. Бабушка требовалась на случай аварии насосов, чтобы сообщить ремонтной бригаде и не допустить перелива емкости. Контроль должен был осуществляться дистанционно, функций управления не требовалось.

Слишком часто стала мелькать в западных блогах и твиттере аббревиатура “DCI”. Меня удивил тот факт, что на хабре по данной тематике почти нету информации, лишь в Ruby NoName Podcast S04E09 упоминалось об этом. Любопытство взяло вверх, и я решил узнать об этом загадочном слове побольше. В процессе поиска я наткнулся на хорошую статью, написанную на английском моим земляком, Виктором Савкиным. Данная статья без обильной теории, на практических примерах показывает, что из себя представляет DCI. Далее повествование будет идти от лица Виктора.

Иногда очень хочется быстро найти нужный файл. С учетом того, что файлов — сотни тысяч, а ты не знаешь ни его названия, ни содержания, ни типа — ничего. Зато приблизительно знаешь категории. И хочется его быстро вычислить и сразу же отредактировать и записать.
На сегодня удобных кросс-платформенных open-source файлопомоек с прямым доступом к файлам — НЕТ.
Далее речь пойдет не о медиабиблиотеке и не о semaweb — а о простой и удобной системе управления громадной файлопомойкой с прямым доступом к файлам.

Декларативный подход и MDA ахритектура имеют целый ряд преимуществ, позволяющих существенно сократить издержки на разработку и поддержку информационных систем (ИС: CRM, WMS, Project Management, etc). Этот подход уже используется в ряде продуктов (таких как 1С, например). Тем не менее, декларативный подход в них используется для решения слишком узкого круга задач. В этой статье мы рассмотрим преимущества декларативного подхода, покажем как можно значительно расширить область его применения в построении ИС, проверим построенную модель на реальных задачах и продемонстрируем работу прототипа.

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

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

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

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

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

Написание качественной магистерской диссертации полноценно охватывающей все разделы проведенного исследования, основной работы, анализа и апробации результатов является сложной и комплексной задачей, ежедневно с различным успехом решаемой множеством студентов по всему миру. К сожалению, изучение существующей литературы [1, 2], посвященной тематике написания диссертационного исследования, указывает на отсутствие материалов описывающих практический опыт применения различных методов и инструментов, позволяющих не только оптимизировать работу над диссертацией, но и улучшить качество конечного результата.
В данной статье рассмотрим семь практических методов и инструментов, применение которых позволит обеспечить целостное структурирование и систематизацию задач, знаний и различных данных получаемых в ходе работы с диссертацией:

1. Формирование структуры задач.
2. Поиск литературы в каталогах.
3. Сбор, обработка и систематизация информации.
4. Формирование списка литературы.
5. Составление плана по вехам.
6. Определение предмета исследования.
7. «Summary» для научного руководителя.

Я рад приветствовать вас, дорогие читатели.

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

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

Эпиграф: Верблюд — это лошадь, сделанная по всем требованиям заказчика.

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

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

Как вы не знаю, но я себя на этой картинке узнал. Ведь, согласитесь, когда проектируется архитектура приложения, все красиво, логично и соответствует лучшим мировым практикам. Но в процессе работы, сталкиваясь с ограничениями предъявляемыми архитектурой, мы зачастую думаем: «Вот здесь немножко нарушу, это ведь сэкономит мне час времени разработки. Ну а потом, как будет время, поправлю». Но, почему-то, это время так никогда и не наступает. На мой взгляд, единственным способом заставить себя, как программиста, следовать разработанной архитектуре, это научить среду разработки все отклонения и костыли показывать как ошибки компиляции. В этом случае, если код плох, он сразу будет исправлен, ну а если архитектура устарела, то будет исправлена она. Т.е. в хранилище кода всегда будет код соответствующей запланированной архитектуре.
Пара слов, о том, что будет подкатом:
1. Небольшая преамбула.
2. Восстановление архитектуры по имеющемуся проекту.
3. Настройка Visual Studio и TFS для автоматического контроля архитектуры.
Под катом много картинок и желание все описанное попробовать.

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


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

• Бизнес архитектура
• Архитектура информационных систем (потоки данных)
• Технологическая архитектура

Таким образом, разработчики чаще всего говорят о технологической архитектуре приложения.

Бизнес архитектура, она же Enterprise, является представлением того, как эффективно воспроизвести цели бизнеса и стратегию путем создания, улучшения и объединения ключевых требований, принципов и моделей для успешного развития бизнеса и достижения поставленных целей. Определение взято из английской википедии.  Архитекторы уровня Enterprise должны ориентироваться на бизнес потребности и проводить анализ потоков данных, т.е. покрывают два указанных пункта. Архитекторы уровня Solution занимаются технологическими аспектами проектов. Так же стоит упомянуть не обозначенных здесь Infrastructure Architect, людей, которые занимаются глобальным развитием и анализом технических возможностей по реализации проектов.

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

Мы все живем в мире, где на любое наше действие либо следует какой-то ответ, либо не следует ответа. Если ответа нет – мы чувствуем, что что-то не так. Возможно, некоторые и не ощущают дискомфорта от отсутствия обратной связи. А действительно – чего переживать, если ограничения сняты и можно «быть собой», как иногда можно услышать от молодых людей.

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

«Мы работаем для того, чтобы вы не боялись летать»


рис 1. Модель Bombardier BD 500 в аэродинамической трубе

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

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

Автор рассказывает о перипетиях пивоваров, производителей СУБД, себя и кратко о том как правильно проектировать приложения. Мне показалась полезной поучительная часть статьи.

В основе разработки ПО авионики лежит основополагающий стандарт RTCA\DO-178B. Несмотря на первый взгляд на его отстранённость от непосредственной рутины программиста, он описывает весь процесс разработки и выдвигает требования к подобному ПО. Тем не менее, в данной статье речь пойдёт и о том, как всё происходит на самом деле, на основе личного опыта разработки систем контроля и управления полётом, систем посадки и пр. для самолётов и вертолётов.