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

В данной статье я бы хотел рассказать об одном из вариантов организации сетевого взаимодействия в программах, написанных на Qt, используя библиотеку QexRemint. Эта библиотека позволяет сериализовать/десериализовать сигналы и слоты. Дописав к ней сетевую часть, можно получить отличный и удобный механизм для удаленного вызова процедур (Remote Procedure Call).

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

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

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

Многие читатели Хабра знакомы с внутренней кухней разработки ПО, а ведь железо — это совсем другая история. Готовы? Тогда поехали.

Английский термин compliance означает соответствие одному из высокоуровневых стандартов (таким как SOX, PCI DSS, Basel II, GLBA). Проводить проверку на соответствие этим документам необходимо для того, чтобы определить, насколько хорошо в вашей организации соблюдаются требования, описанные данными стандартами (разрешенная длина паролей, наличие внутренних регламентов и политик, время устранения уязвимостей и т. п.).

Помимо международных стандартов существуют их отечественные аналоги, корпоративные политики и требования NIST.Проводить оценку соответствия этим документам также необходимо. Стандарты содержат наборы требований: выполнение всех требований стандарта фактически означает соответствие ему. Пример отдельного требования: «Должен иметься дисциплинарный процесс для служащих, которые произвели нарушение защиты» (ИСО/МЭК 2005 A.8.2.3).

Классический подход обязывает руководителя проекта, в ускоренном режиме, проводить приоритезацию задач используя для этого категоризацию требований на основе классификации Эйзенхауэра. Результатом всей этой «приоритезации» может стать упущенная выгода, потеря конкурентного преимущества и 100% удовлетворенность процессом руководителя проекта. Другое дело, когда команда реализует требования, которые клиент с восторгом готов принять!
Личностей типа «сноллигостер» хочется предупредить, что они могут этот топик не читать, дабы не травмировать свою психику.
Всем остальным: Добро пожаловать в новый мир!

Рассказывая людям на встречах и презентациях про технологию, относящуюся к области баз данных, я поражаюсь, какая огромная пропасть может быть между тем, чем человек занимается и в какой области он работает. Еще больше поражает, что такая пропасть может присутствовать и у технических специалистов. Я попробую пояснить – например, в карточке человека написано «Специалист по работе с базами данных», а на деле оказывается, что этот человек умеет настраивать бэкапы в RMAN-е, создавать индексы и перестартовывать инстансы. Все его знания в области баз данных умещаются в знание, как использовать эти три инструмента. Ах да, еще, конечно же, знание SGA. Поразительно, но возникает такое чувство, что человек определил себе рамки, в границах которых он что-то знает, а что происходит за этими рамками, ему кажется неинтересным и недостойным внимания.

Навеяно недавним постом.

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

Хочу написать мини-обзор о совсем не новом, но верном помощнике — SQL Power Architect'е. Опенсорсном кроссплатформенном приложении написанном на java, с поддержкой различных БД.

Все чаще и чаще я слышу от разработчиков и читаю в статьях, что шаблоны проектирования (они же дизайн-паттерны) никому не нужны. Мол, они появились во времена «цветения» 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. Нужно иметь возможность мониторить температуру в нескольких помещениях этих объектов. Причем желательно если не в реальном времени то с минимальной задержкой. Усложняется все еще тем что объекты хоть и недвижимость, но возможны ситуации что будет переезд. Поэтому капитальные методы установки оборудования отпадают.

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