Процессы системного проектирования программных средств

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

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

- совокупность предварительных исходных требований к функциям и характеристикам комплекса программ;

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

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

- цели, задачи и функции предполагаемой новой или модернизированной системы, обобщенные в концепции создания соответствующего программного средства;

- проекты планов жизненного цикла, гарантирования требуемого качества ПС, защиты и обеспечения безопасности его функционирования;

- результаты технико-экономического обоснования целесообразности и основных направлений продолжения проектирования и всего ЖЦ ПС;

- результаты анализа существующей и возможной инструментальной среды разработки, а также системы обеспечения качества, перспективы их развития и совершенствования;

- предварительный план организации работ, требования к составу и квалификации специалистов для выполнения проекта и всего жизненного цикла ПС;

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

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

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

Разработка исходных требований для технического задания на проект ПС начинается с анализа результатов обследования объекта информатизации и оценки доступных ресурсов для реализации проекта. Эта деятельность требует специальной организации специалистов наивысшей квалификации и тесной совместной работы представителей заказчика и разработчика. Они должны подготовить исходные данные и документы, в которых содержатся предварительные требования и пожелания к функциональным и конструктивным характеристикам качества программного комплекса. Далее ими должна проводиться сложная работа по предварительному упорядочению, селекции, обобщению и ранжированию приоритетов требований для их реализации в проекте. Наличие обычно ряда неформализованных, неструктурированных и противоречивых содержательных требований заказчика и разработчика требует их совместной обработки, согласования и корректировки.

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

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

Моделирование процессов обработки данныхпри системном проектировании преследует две основные цели:

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

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

При построении формализованного описания системы, выполняемом её разработчиком, принципиальными являются два организационных момента: специалисты - заказчики или пользователи создаваемой системы должны активно участвовать в процессе анализа и реализации её описания; каждый шаг описания должен обязательно документироваться. Наглядными и удобными в работе являются графические представления описаний проектных решений, которые позволяют создавать прототипы ПС. Они обеспечивают эффективную визуализацию и обратную связь между разработчиком и потенциальным пользователем с целью оценки реализации требований, корректировки функций и качества компонентов, а также форм пользовательского интерфейса. Для этого разработана целая гамма методологий для моделирования, структурного анализа и визуального проектирования. Современные инструментальные CASE-средства обеспечивают широкие возможности выбора процессов моделирования, автоматизированного анализа системных предложений и выработки первичных требований к предполагаемому проекту ПС. Схемы потоков данных, потоков управления, сущность-связь и другие – составляют комплекс удобных и гибких графических методов и средств описания систем, облегчающих взаимопонимание между разработчиками и заказчиками на разных уровнях детализации функций, качества и архитектуры ПС.

Концепция создаваемого комплекса программ (см. рис. 4.1) на естественном языке данной предметной области должна включать предварительные требования к ПС, основные понятия и термины. Она является первым исходным документом, согласуемым с заказчиком для создания комплекса программ. На основе этого описания формируется предварительное техническое задание на систему и её основные компоненты. При использовании формализованных методов разработки программных средств текстуальное описание системы подлежит переводу на соответствующий, возможно, графический язык. Наряду с разработчиками, специалисты-заказчики или пользователи создаваемой концепции ПС должны активно участвовать в процессе анализа и реализации её описания.

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

Стратегическое планирование проекта должно содержать долгосрочные цели развития ЖЦ ПС определенного функционального назначения. Планы должны отражать предварительные проекты всего будущего жизненного цикла ПС, обеспечения их качества, защиты и безопасности функционирования, верификации и тестирования, управления конфигурацией и сопровождения. На базе требований к ПС и первичных планов появляется возможность оценить объем подлежащих разработке компонентов программ и баз данных, а также некоторые дополнительные характеристики возможного объекта и среды разработки. На этом этапе инструментальные средства должны обеспечить наглядное представление каждого плана, оценку возможной трудоемкости и длительности разработки, необходимого числа специалистов и других ресурсов для их реализации. По этим данным руководителем разработки и заказчиком принимается решение о целесообразности продолжения проектирования и осуществляется стратегическое планирование проекта, которое формализуется в системном проекте и в техническом задании на ПС.

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

Прогнозы и анализ вариантов технологических процессов проектирования ПС, их технико-экономических показателей и характеристик объекта разработки являются основой для выбора, предварительного планирования и последующего системного анализа всего жизненного цикла ПС. Достоверность планов и прогнозов определяется точностью сведений об объекте разработки, характеристиках технологической среды и прототипов, принятых за основу при планировании. Таким образом, производится технико-экономическое обоснование проекта (см. лекцию 5), определяются приближенные значения трудоемкости и длительности всей разработки ПС, а также число необходимых специалистов, что позволяет оценить предварительный укрупненный план создания ПС в заданных условиях, ресурсах и сроках. Вследствие творческого характера большинства работ на этом этапе невозможно составить жесткий план их выполнения. Помочь может типовой перечень частных работ, представленный в стандартах ЖЦ ПС и ориентировочный график, иллюстрирующий их взаимосвязь.

Проведенные таким образом оценки проекта ПС позволяют осуществить предварительный выбор основных методов и инструментальных средств для проведения последующего детального и рабочего проектирования и поддержки всего ЖЦ ПС. Кроме того, должна подготавливаться адаптация средств автоматизации, применительно к особенностям объекта и среды проектирования. Разрабатываются проекты руководств для специалистов, выделяемых на данный проект, и осуществляется их обучение. Интегрированные инструментальные средства служат для формализации знаний заказчика на этапе проведения обследования, анализа и подготовки технического задания, а также для проектирования концептуальной и логической структуры комплекса программ и базы данных. При этом должно активно использоваться моделирование и тестирование корректности системных решений. Благодаря высокому качеству проработки и документирования системного проекта, создается основа для снижения трудоемкости тестирования, испытаний, а также сопровождения и модификации ПС.

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

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

4.3. Структурное проектирование сложных программных средств

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

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

и правила структурирования ПС и БД можно объединить в группы, которые отражают:

- стандартизированную структуру целостного построения ПС и/или БД определенного класса;

- унифицированные правила структурного построения функциональных программных компонентов и модулей;

- стандартизированную структуру базы данных, обрабатываемых программами;

- унифицированные правила структурного построения информационных модулей, заполняющих базу данных;

- унифицированные правила организации и структурного построения межмодульных интерфейсов программных компонентов;

- унифицированные правила внешнего интерфейса и взаимодействия компонентов ПС и БД с внешней средой, с операционной системой и другими типовыми средствами организации вычислительного процесса, защиты и контроля системы.

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

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

Спецификация требований к предварительной архитектуре комплекса программ формируется в процессе детализации и уточнения спецификации требований к характеристикам ПС в результате проверки последних на непротиворечивость и полноту. Задача спецификации требований архитектуры состоит в том, чтобы представить достаточно ясное и удобное общее описание внешнего поведения системы и свойств, а также её внутренней структуры и механизмов функционирования. В общем случае формализованные методы, применяемые при специфицировании системной архитектуры ПС, должны обеспечивать:

- эффективные и удобные средства описания свойств и особенностей структуры создаваемой системы – нотации описания;

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

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

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

- соответствие функций и структуры ПС аппаратной и операционной среде, их ресурсам и интерфейсам;

- сов­местимость ПС с другими системами по источникам и пот­ребителям информации;

- соответствие стандартам структурного построения и интерфейсов комплекса программ, функциональных компонентов и модулей;

- предварительная организация информационного обеспечения и структура базы данных;

- состав, структура и способы обмена данными между функциональными компонентами и внешней средой ПС;

- временной регламент и предварительные характеристики процессов реализации функций, интенсивность и объемы потоков информации базы данных;

- контроль, хранение, обновление, защита и восстановление программ и данных;

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

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

Структурное проектирование программных средств основано на модульном принципе. Многоуровневое, иерархическое построение сложных программных комплексов позволяет ограничивать и локализовать на каждом из уровней соответствующие ему компоненты. Нижнему иерархическому уровню представления программ соответствуют программные и информационные модули (модули данных). Эти компоненты объединяются в группы программ определенного функционального назначения с автономной целевой задачей. Несколько групп функциональных программ образует комплекс программ. В особо сложных случаях возможно создание программного средства из нескольких взаимодействующих комплексов. Всем иерархическим системам (в частности, ПС) присущ ряд общих свойств, важнейшими из которых являются:

- вертикальная соподчиненность, заключающаяся в последовательном упорядоченном расположении взаимодействующих компонентов, составляющих ПС;

- право вмешательства и приоритетного воздействия сверху вниз на компоненты нижних уровней;

- взаимозависимость действий компонентов верхних уровней от реакций на воздействия и от функционирования компонентов нижних уровней, информация о которых передается верхним уровням.

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

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

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

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

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

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

4.4. Проектирование программных модулей и компонентов

Сложная система обычно может быть разделена на более простые части - модули. Модульность является важным качеством инженерных процессов и продуктов. Большинство промышленных процессов являются модульными и составлены из комплексов работ, которые комбинируются простыми способами (последовательными или перекрывающимися) для достижения требуемого результата. Главное преимущество модульности заключается в том, что она позволяет применять принцип разделения задач на двух этапах:

- при работе с элементами каждого модуля отдельно (игнорируя элементы других модулей);

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

Если данные этапы выполняются в последовательности, предусматривающей сначала концентрацию процессов на модулях, а затем - их объединение, то система проектируется снизу вверх. Если сначала систему разбивают на модули, а потом работают над их индивидуальным проектированием, то это - проектирование сверху вниз.

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

- программных модулей, оформляемых как законченные компоненты текста программ;

- функциональных групп (компонентов) или пакетов программ;

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

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

Программные модули решают относительно небольшие функциональные задачи, и каждый реализуется 10-100 операторами языка программирования. Каждый модуль может использовать на входе около десятка типов переменных. Если для решения небольшой функциональной задачи требуется более 100 операторов, то обычно целесообразно проводить декомпозицию задачи на несколько более простых модулей.

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

Комплексы программ – программные продукты создаются для решения сложных задач управления и обработки информации. В комплексы объединяются несколько или десятки функциональных групп программ для решения общей целевой задачи системы. Размеры ПС зачастую исчисляются сотнями модулей, десятками и сотнями тысяч операторов. Встречаются ПС, содержащие до двух-трех десятков структурных иерархических уровней, построенных из модулей.

Проектирование модулей включает в себя разработку локальных функций и подробных описаний алгоритмов обработки данных; межмодульных интерфейсов; внутренних структур данных; структурных схем передач управления; средств управления в исключительных ситуациях. С их помощью определяются функции: порядок следования отдельных шагов обработки, ситуации и типы данных, вызывающие изменения процесса обработки, а также повторно используемые функции программы. Программные модули для их многократного использования должны базироваться на унифицированных правилах структурного построения, оформления спецификаций требований и описаний текстов программ и комментариев. Кроме того, целесообразно для каждого проекта директивно ограничивать размеры модулей по числу строк текста с учетом языка программирования, например, 30-ю или 50-ю операторами (см. лекцию 13).

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

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

Особое значение для качества модулей и компонентов крупных ПС имеет стандартизация структуры межмодульных интерфейсов по передачам управления и по информации. Эти правила формируются на базе описаний языков программирования или оформляются на основе правил структурного построения программ и базы данных конкретных проектов ПС. В последнем случае соглашения о связях конкретизируются в макрокомандах межмодульного взаимодействия. Структурное проектирование сложных комплексов программ активно развивается на основе концепции и стандартов открытых систем. Применение стандартов открытых систем следует начинать при создании архитектуры исходных модулей мобильных ПС и БД, а далее неукоснительно использоваться при всех процессах ЖЦ. Во всех случаях создание архитектуры модулей и компонентов современных сложных систем целесообразно вести с использованием профилей международных стандартов, значительная часть которых обеспечивает мобильность и возможность повторного использования готовых программных средств и баз данных (см. лекцию 3).

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

- возможность расширения ПС, а также переноса (мобильность) программных компонентов и систем, разработанных должным образом, с минимальными изменениями на широкий диапазон аппаратных и операционных платформ;

- совместную работу с другими программными продуктами и системами на локальных и удаленных платформах;

- взаимодействие с пользователями в стиле, облегчающем последним, переход от системы к системе (мобильность пользователей).

Для достижения этих целей развиваются и применяются различные проблемно-ориентированные технологии и комплексы средств автоматизации ЖЦ мобильных программ и баз данных, основанные на повторном использовании готовых апробированных модулей, программных компонентов и данных, их эффективном переносе на различные аппаратные и операционные платформы и согласованном взаимодействии в распределенных информационных системах. Профессионалы в области открытых систем акцентируют усилия на поиске и создании гибкой, способной к наращиванию среды, что базируется на трех направлениях стандартизации в области систем (см. лекцию 2):

- аппаратных и операционных платформ;

- методов и технологии обеспечения жизненного цикла прикладных программных средств и баз данных;

- интерфейсов компонентов и модулей между собой, с операционной и внешней средой.

Методы открытых систем обеспечивают эффективные по трудоемкости и качеству структурное проектирование, расширение и перенос готовых программных средств обработки информации и баз данных на различные аппаратные и операционные платформы. Эти методы можно разделить на три части:

- общая концепция и методы непосредственного обеспечения мобильности компонентов программных средств и баз данных в процессе разработки систем за счет унификации интерфейсов с операционной и аппаратной средой;

- методы, поддерживающие мобильность компонентов и комплексов программ и данных в распределенных системах и совместимость их взаимодействия с внешней средой;

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

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

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

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

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

- административное управление локальными и распределенными компонентами систем в процессе решения функциональных задач обработки информации.

Третья группа методов создавалась в значительной степени независимо от первой и второй. Эти методы преследуют цель унифицировать тексты программных модулей, компонентов и описания данных, создаваемых для различных аппаратных платформ при любой их архитектуре, независимо от операционной и внешней среды. Первоначальное огромное число языков программирования (свыше 200), каждый из которых имел несколько диалектов, в результате сократилось до 6 - 10 массовых языков, ограниченных стандартами, не допускающими диалектов. Создание современных модулей и компонентов ПС и БД поддерживается методами и инструментальными средствами технологий, методами тестирования и аттестации программ и их интерфейсов, а также стандартизированным составом и содержанием документации на программы и базы данных. Эти методы и средства обеспечивают необходимое качество модулей и компонентов сложных ПС и БД. В результате обеспечена мобильность функциональной части текстов программ, однако они могут требовать доработок интерфейсов для сопряжения с новой средой аппаратного и операционного окружения систем.

Дата добавления: 2014-01-13