2.7 Стратегия разработки мпс

ЦЕЛЬ – дать и обосновать стратегическое направление разработок МПС.

Как указывалось ранее, любой тип связи является частным случаем СРВ, которые имеют объект управления (ОУ) и устройство управления (УУ).

В качестве УУ в СРВ используются компьютеры. Все компьютеры сейчас построены на фон – неймановской структуре. Таким образом, принципиальное единообразие построения УУ (фон – неймановская структура) определяет и принципиальное однообразие операционных систем УУ (см. раздел 1.5).

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

Анализ взаимосвязи компонент СРВ. Так как в СРВ имеются две взаимосвязанных компоненты (УУ и ОУ), то, естественно, возникает вопрос: откуда вести разработку?:

►от УУ к ОУ;

►или от ОУ к УУ.

►Разработка от УУ к ОУ. Обоснованием для такой стратегии разработки служит следующая «железная логика»: ФПО находится в компьютере, значит, нужен специалист, знающий компьютер. Но согласно такой «логике» и любой настройщик фортепьяно должен профессионально сыграть фортепьянный концерт потому, что фортепьянные концерты исполняются на фортепьяно, а он его великолепно знает. К сожалению, именно такой тип рассуждений, естественно, считающихся «логичными», распространён при разработках СРВ, в которых УУ является компьютером. Данное образное сравнение показывает нелепость принципа разработки «от УУ к ОУ». Значит, остаётся принцип «от ОУ к УУ», но не ясно, «почему так нужно, почему именно с ОУ?».

►Разработка от ОУ к УУ. Для логического обоснования такого направления разработки рассмотрим следующее образное сравнение. Нужно перевести какой – то груз. С чего начать решение данной задачи: с варианта «на чём перевести?» или с варианта «что перевести?». Элементарная логика подсказывает вариант: «что перевести?». Почему? Да всё зависит от груза. Если этот груз по габаритам и весу мал, то его может перевести (перенести) человек в сумке, если более крупный, то на машине, причем в зависимости от веса это может быть машина разной грузоподъёмности. Таким образом, только после того как определились с грузом, можно приступить к решению варианта «на чём перевести?».

В исходных алгоритмах ФПО реализуются специфические для данного ОУ процессы. Безграничное терминологическое разнообразие ОУ в различных СРВ не даёт возможности создать единые алгоритмы в конкретных терминах для всех типов ОУ (как например, в операционных системах УУ). Для специалиста, работающего с данным типом ОУ, вытащить логику работы (а именно она является базой алгоритмов ФПО) из физики конкретных процессов - трудная проблема, требующая времени и знания физики процессов ОУ («что перевести?»), а не УУ («на чём перевести?»). Но только после того, как будет качественно (начиная с системного уровня) алгоритмизирована логика процессов, к ней нужно подключать специалиста по УУ (компьютерщика)

Таким образом, акцент при разработках СРВ должен быть сделан именно на ФПО, т.е. ведущими в проектировании таких систем должны быть разработчики ОУ, а не УУ (хотя в созданной системе УУ управляет ОУ). При этом разработчику ФПО знание компьютера необходимо, но не так углублённо, как компьютерщику.

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

Почему в Интернете и сетях нужен только компьютерщик? Интенсивно развивающиеся в последнее время различные типы сетей и Интернет также являются СРВ. Таким образом, и там есть ОУ и УУ, но именно при их разработке знание компьютера и необходимо и достаточно, т.е. разработчику сетей и Интернета нужно знать только компьютер. Почему так происходит? Дело всё в том, что ОУ в них является другой компьютер, и специалисту по компьютерам известно, не только сигналы из другого компьютера, но и как их обрабатывать, а также отдельные специфические нюанса такого ОУ. К сожалению, именно массовость развития этих направлений и выработала устойчивый стереотип мышления в виде необходимости вести разработки СРВ, в которых ОУ не является другим компьютером, от компьютера, т.е. для разработки программного ОУ привлекать специалистов по компьютерам как основных разработчиков.

Методологический принцип разработки ФПО. В условиях рыночной экономики разработку необходимо вести так, как это выразил основатель конвейерной системы в производстве Фредерик Тейлор (США): «Поймите точно, что Вы хотите сделать, и затем следите, чтобы это делалось наилучшим и самым дешёвым способом».

Методология разработки должна основываться на «бритве Оккама» – методологическом принципе, сформулированном английским философом Уильямом Оккамом в 14 веке в виде: «То, что можно объяснить посредством меньшего, не следует выражать посредством большего» (принцип бережливости или экономии гипотез). Этот принцип требует, чтобы любая научная гипотеза, объясняющая ряд фактов, основывалось на наименьшем числе предположений, т.е. наиболее правдоподобной является та гипотеза, которая основывается на меньшем количестве допущений. Как этот принцип применим к разработкам технических систем?

На начальных стадиях разработок прорабатываются несколько вариантов реализации системы. После этого возникает вопрос выбора варианта реализации. Но как выбрать, когда система ещё не готова? В этом случае необходимо использовать «бритву Оккама» в виде следующей модификации: «Из нескольких технических решений, обеспечивающих данные требования, наиболее простое в реализации является наиболее правильным». Синонимы «бритвы Оккама» в западных разработках известны как «принцип простоты». «элегантное решение», «максимум при минимуме». «Упрощайте сложное и вы получите самый существенный результат». / Английский историк и социолог Генри Бокль 19 век/.

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

Типология построения МПС. Типовая структура и типовая, структурная схема ПО базируется на положениях для СРВ, данных в разделе 1.5. Выбор варианта снятия информации от датчиков /например, телефонных аппаратов или мобильников/ (прерывание или сканирование) основывается на положениях, данных в разделе 2.4. Вообще, в сложных системах всё должно быть предсказуемо, а прерывания непредсказуемы. Сложные системы не должны «гоняться» за каждым прерыванием от датчиков СРВ, обрабатывая их.

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

Архитектура и структура МПС. Слово архитектура в строительстве означает потребительские характеристики строительного объекта, т.е. те, которые важны для проживающих или работающих в этих объектах. Аналогично под архитектурой МПС понимают совокупность её свойств и характеристик, которые должен знать пользователь.

К ним относятся:

♦ сопряжения основных устройств системы.

♦ представление передачи информации при взаимодействии пользователя с системой;

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

В МПС термин архитектура используется для описания принципа действия, конфигурации и взаимного соединения их основных логических узлов. Если рассматривать архитектуру определенного класса таких систем, то реализация конкретной системы из данного класса, может отличаться как на уровне физических компонентов аппаратных средств, так и на уровне способов реализации подсистем. Те или иные реализации также отличаются по производительности и стоимости. Детали реализации «невидимые» для пользователя не оказывают влияния на архитектуру. Общность архитектуры класса обеспечивает их совместимость с точки зрения пользователя.

Принципы разбивки ПО СРВ. Как с точки зрения функциональной реализации разбивается программное обеспечение (ПО) СРВ? Почему это важно? Анализ этого вопроса сразу же даёт стратегическое направление разработки, а правильно выбранное стратегическое направление резко снижает время и затраты на разработку. Образное сравнение: можно из СПб в Москву поехать как обычно, а можно и через Париж. Ясно, что если выбрано стратегическое направление через Париж, то не укладываются и в сроки и в деньги. При этом некого винить, что они бездельничают, (ведь человек то не сачкует, а едет).

Традиционной «разбивкой» ПО СРВ является деление его на:

♦ функциональное ПО (ФПО);

♦ операционную систему (ОС).

ФПО реализует функциональные процессы (т.е. процессы ОУ).

ОС реализует управление функциональных процессов в реальном времени.

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

Более правильной является следующее разделение.

ПО СРВ имеет следующие базовые компоненты (своего рода фундамент):

►функциональные процессы в ОУ, которые подлежат управлению в реальном времени;

►функциональные процессы в реальном времени (управление процессами ОУ в реальном времени);

►база данных (БД) функциональных процессов в реальном времени.

На основе такого «фундамента» строится всё программное обеспечение СРВ.

►Функциональные процессы в ОУ. Например, это установление различного рода соединений в различных АТС. Причём, это сами процессы без «привязки» их к УУ. Описание алгоритмов здесь идёт, естественно, в терминах функциональных процессов.

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

►Функциональные процессы в реальном времени. Здесь уже ставятся задачи «привязки» разработанных функциональных процессов к УУ. Алгоритмы исходных процессов, разработанные выше, здесь являются «базой» для их реализации в реальном времени, т.е. на компьютере. Естественно, в этих алгоритмах кроме терминов функциональных процессов используются компьютерные термины.

►База данных (БД) функциональных процессов в реальном времени. Здесь реализуются БД процессов в ОУ.

Что даёт такое деление? Оно чётко разграничивает работу:

♦ по направлению;

♦ и по специализации.

Что это такое?

Функциональные процессы в ОУ должен делать специалист в данном ОУ. Он и только он, а не компьютерщик. Для связи это специалист, знающий данный тип связи!

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

База данных (БД) функциональных процессов в реальном времени. Здесь опять компьютерщик, но он должен реализовать то, что даст ему специалист по функциональным процессам. Таким образом, стратегией разработки на данном этапе «владеет» компьютерщик, но смыслом данных – специалист по ОУ.

Резюме. Таким образом, ведущим при разработках СРВ должен являться специалист по ОУ, а не по УУ. Такой специалист должен качественно знать свою область (ОУ) и понимать принципы построения ПО в компьютерах (но он не обязан знать досконально их реализацию). Если он не понимает ни того, ни другого, то тогда «власть» перехватывают компьютерщики и, набив шишек, что-то делают (именно «что-то», ибо они не освоят качественно ОУ, а просто «нахватаются по верху»).