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

Все чаще и чаще я слышу от разработчиков и читаю в статьях, что шаблоны проектирования (они же дизайн-паттерны) никому не нужны. Мол, они появились во времена «цветения» UML, RUP, CASE систем и прочих чересчур «сложных» инструментов, подходов и практик. А сейчас самое важное — это код рабочий написать, да побыстрее. На умные толстые книжки ни у кого нет времени, разве что для прохождения собеседования. Тех, кто хочет обсудить данную тему, прошу под кат.

Здравствуй, хабрасообщество.
Идея данной темы для обсуждения пришла ко мне довольно давно, но поводом, толкнувшим к собственно тому, чтобы открыть редактор и написать текст, послужило недавнее собеседование. Но обо всём по порядку.

Введение

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

Эрик Липперт — ветеран Microsoft, проработавший в компании 16 лет и стоящий за разработкой VBScript, JScript и C#.

На прошлой неделе в комментариях к одной из статей разгорелся спор о роли низкоуровневой оптимизации в программировании, и я вспомнил относящуюся к этому статью Эрика. Она была написана в конце 2003, и хотя реалии с тех пор несколько изменились — принципы остались теми же самыми. Можете мысленно заменить ASP и VBScript на PHP, JavaScript, или на другой скриптовый язык по вашему вкусу.

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

---

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

Например, за семь лет в Microsoft я получил десятки вопросов, аналогичных по своей сути этому, заданному в конце 1990-х:

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

Какой интересный вопрос! В компилируемом языке, таком как Си, объявление локальных переменных общим размером n байт всего лишь вычитает n из указателя стека при входе в функцию. Если n будет чуть больше или чуть меньше, затраты времени на вычитание никак не изменятся. Наверное, в VBScript точно так же? Оказалось, что нет! Вот что я написал автору вопроса:

Доброго времени суток, хабраюзеры.
Как-то, года три назад, гуляя по центру Санкт-Петербурга (сам из Екатеринбурга), я подумал — почему центр Петербурга в разы приятней? Сравнил с Москвой, Афинами, другими крупными городами… Пришёл к промежуточному выводу, что человеку необходимо место для прогулок и широкая перспектива.

Полный же вывод сформировался чуть позже, когда мы шли с другом уже по нашему городу. Он немного технарь (в плане интереса к точным наукам), но скорее музыкант и художник. Он говорил об архитектуре: «Одно с другим не сочетается! Они вообще смотрят на окружающие дома?!» Я думал о системологии или, когда не говорят о науке, о системном подходе.
Тут в голове промелькнула мысль: «А что, если… Хотя почему если?! Город — это система, её нужно проектировать, а не развивать по мере необходимости». Я поделился мыслями с другом. Он их поддержал. Так бы всё и забылось, если бы не объявление о каком-то конкурсе, который уже исчез из названия.

Важно не это: мы решили проанализировать крупные города и рассмотреть их как систему: какие предъявляются требования, как они могут быть удовлетворены, как одно влияет на другое и так далее… Кому интересно — добро пожаловать под кат.

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

Я работаю программистом более 5 лет (web), и хотел бы поделиться методикой, которая экономит силы, время и помогает автоматизировать процесс проектирования.

Методика основана на объектно-ориентированном проектировании, но несколько необычна. Зато имеет очевидные плюсы:
— в идеале, программирование по CORE сводится к описанию задачи (код близок к бизнес-логике)
— чётко разделяет систему на слабосвязанные компоненты
— легко автоматизируема, позволяет генерировать осмысленный код

Почему методика называется CORE и как это расшифровывается? Отчасти потому, что у меня тяга к красивым названиям. По буквам:
Context — контекст вычислений (что инициировало вычисления)
Object — объект, который производит вычисления
Request — действие, которое нужно совершить, чтобы объект смог продолжить вычисления
Event — событие, которое происходит с объектом

Плюсы по сравнению со стандартными способами разработки:
— ускорение стадии проектирования за счёт формализованной схемы проектирования
— ускорение стадии разработки за счёт умной генерации кода
— автоматизация создания юнит-тестов
— неглючная реализация бизнес-логики практически любой сложности
— простая поддержка кода
— простота совместного владения кодом

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

Данная короткая заметка будет полезна людям, занимающимся автоматизацией инженерных систем(ИС) зданий и сооружений. Я заметил, что на сайте есть люди знающие о компании «Болид» и ее интегрированной системах охраны – «Орион». Но буквально совсем недавно я узнал. Что ИСО «Орион» это не единственная рих азработка. Оказывается товарищи из славного города Королёва разработали свою SCADA и контроллер для автоматизации ИС здания. О них вам в вкратце и хотел бы рассказать в данной заметке.

Вступление

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

Здесь и далее имеются в виду компоненты в смысле частей одного процесса. Компоненты, являющиеся отдельными процессами или сервисами, работа с которыми идет через RPC или еще как-то, здесь не рассматриваются. Хотя в большой мере все нижесказанное относится и к ним.

Пример первый:
Мне нужен компонент, давно разработанный и протестированный в другом отделе. Подхожу к разработчику. Завязывается диалог:
— Вот мне нужна вот эта штука. Как мне ее использовать в своем проекте?
— Да, вот нужно залить проект из CVS вот по этой метке. Скомпилить. Получится либа, и вот с ней нужно линковаться.
— Ок, спасибо.
Выкачиваешь проект. Компилишь. Вылезает куча ошибок, не хватает каких-то инклудов. Начинаешь выяснять. Оказывается для сборки проекта надо выкачать из CVS еще кучу проектов, их тоже собрать. Некоторые собираются стандартно студией, некоторые с бубном, вроде autoconf, make и иже с ними. Все. Собралось. Начинаются проблемы с линковкой. Не линкуется одно, второе, третье. Сторонних библиотек не хватает. В итоге — куча потерянного времени на непроизводительный труд и вникание в использованные библиотеки, сторонние компоненты и технологии.

Основное назначение сетей ZigBee – связь между устройствами в автоматизированных системах. Области применения сетей ZigBee – самые различные. Типы и назначение связываемых устройств – также весьма разнообразны. Связь может устанавливаться между выключателем и светильником в «умном доме», приборами учета и сервером сетевой обслуживающей компании, датчиком движения и пультом охраны. Возможно, просматривая этот топик, Вы, сами того не подозревая, пользуетесь сетью ZigBee – многие беспроводные мыши с USB адаптером 2,4 ГГц соответствуют ZigBee RF4CE specification.

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

Взгляд на функциональные требования к интеграционной системе

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

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

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

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

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

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 и полицейское управление Нью-Йорка.