Рис. 5 Цена исправления ошибок, обнаруженных при эксплуатации ПО, по этапам работ, на которых они совершены.
Например, была рассмотрена статистика по 25 проектам NASA и построена зависимость в координатах относительного перерасхода средств на проект – отношение затрат на стадиях определения требований и ранних стадиях проектирования к общим затратам. Если последние находятся в диапазоне до 5%, то перерасход средств в большинстве случаев составлял 100 - 160%. Если отношение затрат на ранние стадии проектирования к общим затратам составляло 10 – 25%, то перерасход средств составил всего 20-40 процентов. Аппроксимация этих данных плавной кривой методом наименьших квадратов даёт кривую, напоминающую кривую закона Рамамурти.
Уменьшить число ошибок проектирования может широкое использование математического моделирования на этапах проектирования. Математическая модель – это цифровое описание некоторых особенностей системы и при моделировании она используется для прогнозирования некоторых свойств и особенностей системы. Например, система управления СТС и её программное обеспечение могут быть успешно спроектированы и эффективность алгоритма управления может быть подтверждена до появления реального электронного или механического оборудования и проведения экспериментов с ним. Точно также при проектировании ПО необходимо моделирование, как действия по проверки правильности построения структуры и взаимодействия структурных единиц. Это является основой для развивающейся парадигмы системного проектирования, основанного на численном моделировании (Model-Based Systems Engineering, MBSE).
19. CASE технологии разработки ПО.
Исторически технологии разработки ПО развивались под эгидой создания средств автоматизации, с помощью которых можно облегчить рутинные и просто трудные виды деятельности путем использования
[Введите текст]
программных инструментов. Первая стадия этой автоматизации связана с поддержкой этапа программирования жизненного цикла путем использования систем программирования с языками высокого уровня.
Очень быстро ,а точнее после формулирования понятия жизненного цикла ПО было установлено, что поддержка программирования, хотя и повысила производительность труда, но не является достаточной для промышленной технологии производства программ. При этом сразу же обнаружились следующие узкие места технологии - неразвитость методологии этапов определения требований, проектирования ПО и слабая поддержка средствами автоматизации перехода от сконструированной программы к процессу ее тестирования.
Технология разработки ПО с использованием программных инструментов для комплексной автоматизированной поддержки получили название САSЕ технологий. ( Computer Aided Software Engineering – компьютерно -поддержанная разработка ПО).
«Предельная» или идеализированная CASE технология, к которой должны стремиться все технологии разработки ПО, - код программы для встроенной в систему ЦВМ получается автоматически после завершения проектирования системы и введения проектных данных и алгоритма функционирования желательно в естественном виде и на естественном языке в инструментальный компьютер.
Таким образом, в предельной CASE технологии язык программирования, как таковой отсутствует и программирование задачи осуществляется в терминах языка естественных высказываний предметной области и записей алгоритмов и схем, в том числе, и графической форме. Следует заметить, что естественный язык обладает неоднозначностью и на нём до сих пор затруднительно с необходимой полнотой описать сложную задачу. Сколько значений имеет слово «коса»? Поэтому такая технология может быть создана в проблемно ориентированном виде, для сравнительно узких предметных областей. В этом случае возможно описание задачи предметной области специализированной задачи на «ограниченном естественном языке».
Например, Excel имеет аппарат макросов и макрорекордер, встроенный ЯВУ VBA. Системы Maple, Mathcad имеют проблемно-ориентированный язык решения математических задач весьма близкий к естественному языку математических описаний.
SCADA системы – системы управления и контроля и сбора данных в системах промышленной автоматизации имеют язык FBD – графический язык функциональных блоковых диаграмм, обширную библиотеку функций управления и обработки данных, обширную библиотеку драйверов устройств ввода вывода системной ЦВМ. Создание ПО для системы управления в рамках такой технологии может состоять в создании структурной схемы системы с привязкой информации из/в ПО к каналам ввода – вывода информации из ЦВМ, в наборе FBD программ ПО из библиотечных блоков установления соединений между ними, введением выбранных настроек и компиляции ПО после завершения этих работ за экраном монитора. При этом можно говорить не о программировании - такового по сути нет, а скорее о проектировании задачи
в проблемно-ориентированной среде.
Однако, высказывания на этих проблемно-ориентированных языках однозначны, так как за внешне «естественными» высказываниями определен строго формализованный смысл.
28
Задачи и результаты архитектурного проектирования ПО.
С помощью модели мы можем упростить сложность проблемы, отбросив несущественные детали и сосредоточив внимание на главном. На протяжении тысяч лет строители, военные, ремесленники, инженеры предпринимали попытки конструировать те, или иные модели, предваряющие исполнение творческих замыслов. При этом первоначальные модели обрисовывали главные свойства создаваемого объекта, плана и т.п. в дальнейшем опущенные детали прорабатывались в других более подробных моделях, которые дополняли первоначальную модель, чаще всего являясь её частью.
Рассматривая понятие архитектуры ПО, как видимый набор решений по организации и построению ПО, продолжим аналогию со строительством зданий, откуда, собственно, и пришло словосочетание «архитектура ПО»(архитектураот греческого строитель).
Первоначально архитектор создает уменьшенную и упрощенную модель здания в виде набора не слишком детальных чертежей. Эту модель в состоянии принять и понять заказчик. Когда в строительство вовлекаются различные виды рабочих – плотники, каменщики, водопроводчики, электрики, они нуждаются в более детальных чертежах. Эти чертежи выпускаются в согласованном друг с другом виде. При этом все
они базируются на первоначальных укрупненных архитектурных чертежах, которые без деталей охватывают наиболее существенные части здания и способствуют «пониманию» здания строителями и заказчиками.
Первым результатом архитектурного проектирования ПО является документ, отображающий структуру системы. Он состоит из набора графических схем различных представлений моделей структуры системы – состава выделенных частей и связей между ними с соответствующими описаниями.
Подавляющее большинство сложных систем как технических, так и биологических и социальных имеет иерархическую структуру. Это связано с тем, что структуризация приводит к большому количеству структурных элементов и потоки управления ими, будучи напрямую замкнуты на управляющий элемент структуры загрузят его чрезмерно. Поэтому возникает необходимость в промежуточных слоях управляющих элементов, каждый из которых берет на себя управление подчиненных ему частью структурных элементов системы, образуя иерархическую пирамиду и разгружая тем самым верхние уровни управления. Так в основном устроено жизнеспособное человеческое общество, технические системы, которые создает человек в соответствии со своими возможностями представлять сложность. Обычно связи между элементами различны по типу и по силе, что приводит к группированию сильно связанных элементов в подсистемы и т.п. Будучи своеобразным отражением моделей природных систем в интеллекте человека программные системы также часто являются иерархически построенными.
20. Технология Ration Rose,UML
Работа ПО протекает в пространстве и во времени. Временной аспект работы ПО так же важен разработчику и также является предметом проектирования ПО. На структурных схемах ПО временной аспект работы ПО отобразить трудно и временному аспекту ПО соответствуют свои графические представления в виде временных диаграмм взаимодействия работы отдельных частей ПО и ПО в целом. Эти два вида представ-
[Введите текст]
ления архитектуры ПО могут называться по разному в различных технологиях разработки, но они всегда существуют.
Таким образом, перед началом реализации ПО необходимо разработать ряд моделей чаще всего графических, представляющих работу ПО с разных сторон и с разных точек зрения. По мере получения в процессе проектирования системы и ПО дополнительной информации эти модели уточняются в инкрементном итеративном процессе проектирования, который нами уже рассмотрен.
Изложенные принципы архитектурного проектирования ПО формализованы в технологии визуального моделирования с помощью системы Rational Rose и языка UМL В технологии RR представлены формализованные правила построения структурных диаграмм ПО, временных диаграмм работы ПО или диа-
грамм взаимодействия во времени структурных элементов ПО и диаграмм переходов ПО из состояния в состояние.
Диаграммы взаимодействия рассматриваются по вариантам использования(функционирования) систе-
мы некоторым актором. В то время как диаграммы перехода программной единицы из состояния в состояние рассматриваются для всех вариантов использования.
21. Структура системы, иерархия управления и структура ПО
Проектирование системы и ПО надо начинать с разработки структуры. Этот процесс имеет также названия структурирование, декомпозиция. При декомпозиции сложной системы на ряд подсистем естественным образом происходит и декомпозиция (структуризация) ПО. Получаемые части ПО имеют названия – синонимы: программы, структурные единицы ПО, модули, компоненты ПО, подсистемы. Иерархическая декомпозиция уменьшает до приемлемого уровня сложность разработки и отладки ПО системы, поскольку при разработке структурной единицы ПО на каждом уровне можно отвлечься от деталей работы ПО верхнего и нижнего уровней, а также программных модулей того же уровня иерархии.
Рассмотрим пример управления от ЦВМ стиральной машины, устройство которой представим в упрощенном виде. Управление работой стиральной машиной представляется сложным, поскольку необходимо координировать работу во времени множество агрегатов. При этом это надо делать различным образом для множества режимов стирки. По управления такой машиной благодаря такому разнообразию также представляется сложным.
Проведем черту, ниже которой последовательно запишем наименования оборудования, которое должно управляться от ЦВМ ( Рис.6).
Сразу над чертой запишем задачи по управлению каждой единицей оборудования. Каждой из этих задач управления в ЦВМ соответствует программа ПО. выполняющая только данную элементарную задачу. Например, программа, которая умеет включать и выключать двигатель на заданную угловую скорость вращения или программа, умеющая открывать и закрывать клапан холодной воды, конечно, когда ее об этом «попросят» – передадут на нее управление. Кто же это сделает? Это должна сделать специальная программа ,обеспечивающая последовательное в нужном для проведении стирки порядке включение аппаратуры стиральной машины .
30
Рис.6 Иерархическая структурная схема ПО управления стиральной машиной и метод её получения
Эта специальная программа работает не напрямую с аппаратурой, а через рассмотренные нами программы, решающие задачи элементарного управления оборудованием, запуская их в определенном порядке. Совокупность рассмотренных программ позволяет реализовать сложное и безопасное управление.
Таким образом, ПО управления стиральной машины предстает в виде двухуровневой иерархической
структуры.
Программа «управление циклом выполнения заданного режима стирки» имеет задачу реализации заданной последовательности работы устройств стиральной машины (в необходимых случаях параллельной работы) при выполнении выбранного оператором режима стирки.
Таких программ, которые мы назвали ПКФ, должно быть столько сколько режимов стирки имеется у машины. Программа реализует эту последовательность путем обращения и инициализации по определенной временной диаграмме программ нижнего уровня, управляющих работой отдельных устройств машины
Далее приведен более сложный пример управления подсистемами спутника. Рассмотренный принцип естественного формирования структуры ПО справедлив и здесь. Отличия - в масштабе системы, сложности алгоритмов управления и потребных ресурсах ЦВМ.
Другое отличие связано с автоматическим выбором необходимой ПКФ программами ПО планирования работы спутника по информации, переданной с земли. Это образует еще один уровень иерархии ПО. Тогда как в стиральной машине выбор режима – ПКФ осуществляется напрямую оператором.
Способность ПО к развитию и изменению не возникает сама собой и не является следствием удачного стечения обстоятельств. Она требует определенных умственных усилий для анализа и предвидения, чтобы определить, где и каким образом потребуется необходимость изменений, требует определенной стратегии структуризации ПО. В основном изменения должны быть изолированы в особых частях ПО и не затрагивать остальные части при их проведении.
[Введите текст]
В данных структурных схемах ПКФ тот самый элемент структурной схемы, который должен аккумулиро-
вать в себе все функциональные изменения при развитии системы и ПО путем создания новых «вариантов использования» системы. С другой стороны, при таком иерархическом структурировании модернизация отдельных агрегатов, затрагивающая и ПО управления ими, также локализована в программных модулях управления только модернизируемым агрегатом.
Функциональные задачи и декомпозиция СТС на подсистемы. Иерархическая структура ПО СТС
Имеются следующие функциональные задачи для спутника, которые решаются последовательно путем включения в работу того или иного набора бортовых систем:
После отделения от ракеты-носителя перейти в ориентированное антеннами на Землю угловое положение и поддерживать его в течении полета;
Проводить сеансы связи по целевому назначению при нахождении в зоне видимости наземного пункта приема - передачи. При этом спутник должен быть ориентирован осью остро направленных антенн на землю, а точнее на наземные пункты приема и передачи информации
В заданное время провести коррекцию орбиты путем включения бортовой двигательной установки для поддержания требуемых параметров орбиты, которые непрерывно меняются под действием возмущений, действующих на спутник в полете;
Решения целевой задачи спутника путем управления в необходимые моменты времени включениями целевой аппаратуры и соответствующим управлением угловым движением с наведением целевой аппаратуры наблюдения (оси спутника) на цель наблюдения.
Отдельно стоит задача управления спутником в случае возникновения нештатных ситуаций – решение задачи безопасности, что связано с необходимостью переключения соответствующей бортовой аппаратуры (БА) на резерв, с возможным восстановлением впоследствии утраченного ориентированного состояния ( см. первую задачу) и т. п.
Можно сказать, что этим функциональным задачам соответствуют «варианты использования» спутника некоторым оператором.
При декомпозиции спутника можно выделить ряд подсистем, выполняющих определенные функции во всех перечисленных функциональных задачах:
система угловой ориентации продольной оси антенны (оси спутника при неподвижных антенах) на Землю и управления угловым движением спутника в соответствии с определенной ориентацией (СУУД);
система автономной навигации для определения параметров орбиты спутника и его положения на ней - параметров движения его центра масс, что необходимо для вхождения с ним в связь и для управления включениями целевой аппаратуры над заданной целью(САН);
радиоканал управления для связи с наземным комплексом управления, обеспечивающий управление со стороны Земли, - командная радиолиния(КРЛ);
корректирующая бортовая двигательная установка (КДУ) для изменения параметров орбиты;
32
система телеконтроля (СТК) для сбора и передачи на Землю контрольной информации о функционировании бортовых систем со спутника;
система энергоснабжения бортовой аппаратуры (СЭС);
система терморегулирования состояния внутренней среды для обеспечения условий рабо ты БА(СТР).
При этом все подсистемы СТС представлены в памяти системной БЦВМ (одной или сети БЦВМ), своей программной частью. ПО каждой из подсистем управляет работой своей подсистемы. ПО управления таким спутником содержит ПО управления работой каждой подсистемы и системная БЦВМ своими устройствами ввода-вывода связана со всей аппаратурой систем спутника. Поэтому взаимодействие подсистем КА, передача информации между подсистемами и взаимосвязанного управление ими может быть обеспечено на программном уровне. Для этой цели также, как и в предыдущем примере целесообразно выделить специальные программы ПО - программы комплексного функционирования (ПКФ), обеспечивающие выполнение функциональных задач спутника.
Этим функциональным задачам соответствуют «варианты использования» спутника.
При этом ПКФ выполняют функции супервизора функциональной задачи. Каждой функциональной задаче соответствует свой супервизор – ПКФ.
[Введите текст]