Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
PAGE 15
Лекция 4. Системное проектирование программных средств
4.1. Цели и принципы системного проектирования сложных программных средств
Комплекс формально организованных мероприятий по достижению единой цели создания сложной системы с требуемыми характеристиками качества при ограниченных ресурсах получил название проект. Цель управления проектом рациональное использование и предупреждение потери ресурсов путем сбалансированного распределения их по частным работам на протяжении всего жизненного цикла объекта с заданным качеством. Управление проектом это особый вид деятельности, включающий постановку задач, подготовку решений, планирование, организацию и стимулирование специалистов, контроль хода работ и использования ресурсов при создании сложных систем.
Целевое управление проектами возникло из необходимости разрабатывать и реализовывать сложные системы с заданными функциями в максимально короткие сроки при ограниченных ресурсах. Критическим параметром планирования и управления проектами обычно является время. Поэтому в лекциях по программной инженерии большое внимание сосредоточено на конкретном планировании сложных проектов, длительность разработки которых могут составлять несколько месяцев или даже годы. Задачи целевого управления такими работами сводить воедино усилия исполнителей специалистов разной квалификации, подрядчиков и субподрядчиков, добиваясь, чтобы они выступали как команда при создании компонентов систем, а не как разрозненная группа функциональных специалистов. В результате должны обеспечиваться концептуальная целостность системы и высокое качество решения главных задач при сбалансированном использовании ресурсов на все функциональные задачи.
Для интеграции усилий специалистов и эффективного использования ресурсов проекта должен выделяться лидер менеджер, управляющий проектом. Он должен активно участвовать в планировании, организации и контроле основных внутренних и внешних организационных мероприятий, необходимых для достижения основной цели проекта. Все ресурсы и исходные данные, необходимые для эффективного выполнения проекта, управляющий получает от функциональных подразделений и специалистов. Задача менеджера проекта наряду с прямыми воздействиями на подчиненных и координацией их работ стимулировать и контролировать активность прямых горизонтальных связей между исполнителями частных работ. Для того чтобы процесс достижения целей был рациональным, лицо, принимающее решение (управляющий) должно иметь выбор среди альтернативных действий, ведущих к цели. Наличие альтернатив и сомнения по поводу того, какая из них лучше, определяют возможность эффективного решения проблем и оптимизации путей их достижения.
Методологической базой целевого планирования и управления проектами ПС является системный анализ, который предполагает:
Чтобы найти и проанализировать все разумные альтернативы, обычно недостаточно одного специалиста, и необходимо участие в системном анализе специалистов разной квалификации. Не во всех системах и задачах оказывается доступным точный количественный анализ. Во многих, чаще всего особенно сложных случаях, приходится ограничиваться качественным анализом свойств, факторов и их влияния на конечный результат и возможный эффект проекта. Поэтому оптимизация решений и выбора альтернатив может ограничиваться оценкой логических суждений экспертов. Базой эффективного управления проектом является план, в котором задачи исполнителей частных работ должны быть согласованы с выделяемыми для них ресурсами, а также между собой по результатам и срокам их достижения.
Основная цель системного проектирования в программной инженерии подготовить, обосновать и согласовать замыслы и решения заказчика (потребителя) и разработчика (поставщика) о необходимости, направлениях и концепции создания или модернизации существующего ПС и изменениях его качества. Методы и средства системного проектирования должны подготавливать эффективную технологическую базу для обеспечения всего жизненного цикла ПС требуемого качества. Характеристики комплексов программ должны анализироваться и формулироваться в начале их жизненного цикла и определять эффективность всех последующих процессов. Результатом этих работ должны быть системный проект, техническое задание и контракт на продолжение разработки ПС или решение о её нецелесообразности и прекращении.
Системное проектирование сложных комплексов программ является фундаментом для обеспечения функциональной адекватности требованиям всего жизненного цикла ПС. От полноты и тщательности системного проектирования зависит эффективность реализации функций системы и степень удовлетворения ожиданий и требований заказчика и пользователей. В последовательности выработки и подготовки к реализации этих требований далее рассматриваются в основном три крупных этапа:
На этих этапах при относительно небольших затратах должна определяться экономическая эффективность и рентабельность всех последующих больших затрат ресурсов в жизненном цикле системы и могут быть предотвращены значительные потери ресурсов вследствие плохого планирования и неопределенностей при реализации проекта. Системное проектирование способно остановить нерентабельное развитие проектов систем и избежать заказчикам и разработчикам на них крупных затрат. В то же время, на базе рекомендуемых при проектировании методов, инструментальных средств и стандартов, может и должен быть подготовлен и обеспечен длительный, эффективный жизненный цикл и совершенствование множества версий высококачественных ПС и их компонентов при реализации на различных аппаратных и операционных платформах. Конечный результат системного проектирования должен также положительно отражаться на системах обеспечения качества, безопасности и защиты, на рационально организованных коллективах квалифицированных специалистов, способных обеспечить весь жизненный цикл ПС.
Тщательное и полноценное системное проектирование выгодно с позиции ускорения разработок, предотвращения ошибок, обеспечения эффективности всего жизненного цикла и высокого качества сложных проектов комплексов программ в условиях ограниченных ресурсов. Инициализация системного проектирования может осуществляться заказчиками, потенциальными пользователями или разработчиками проектов ПС, которые желают получить достаточно четкое представление о возможных функциях и будущем жизненном цикле определенного проблемно-ориен-тированного комплекса программ и базы данных.
Системное проектирование далее структурировано, и методология его реализации отражает следующие проблемы, процессы и методы:
Непрерывное повышение уровня автоматизации в ряде систем при подготовке и принятии ответственных решений возлагает все большие функции на программные средства с соответствующими базами данных. В результате проблема обеспечения качества и безопасности их функционирования сдвигается к лицам, разрабатывающим системные проекты, методы и программные средства для автоматизации, подготовки и реализации ответственных решений. Одновременно повышаются требования к уровню ответственности и системной квалификации лиц, реализующих комплексы программ, от которых зачастую зависят ошибки стратегически важных решений, так как некоторые простейшие системные и технические ошибки этих лиц при создании программ могут приводить к большому ущербу или даже катастрофам.
Непредусмотренные при системном проектировании ситуации и возможные дефекты программ являются потенциальными источниками отказов и аварий при применении ряда систем. Массовая практика, когда заказчик не может сформулировать четкие требования к функциям и безопасности ПС, а разработчик не понимает, что нужно заказчику, приводит к длительному процессу разработки проектов с множеством дефектов и ошибок, на устранение которых расходуются большие ресурсы. В результате многие системы не соответствовали исходному назначению и первоначальным спецификациям, не укладывались в графики и бюджет разработки. Поэтому значительно возросла необходимость освоения всех современных методов и методик предупреждения системных дефектов, обеспечения высокого качества программ с самого начала их разработки. Многие ошибки, обусловленные неопределенностью или некорректностью технических заданий и спецификаций, могут и должны быть выявлены на ранних стадиях системного проектирования, что способствует его ускорению и повышению качества. Обширной практикой доказано, что обнаружение и устранение ошибок и дефектов в комплексах программ на начальных этапах системного проектирования в десятки и сотни раз быстрее и дешевле, чем в процессе завершения разработки и испытаний.
В последние десятилетия быстро возрастает сложность объектов и систем, создаваемых в различных областях индустрии. Для их разработки привлекаются специалисты разной квалификации и большие финансовые и материальные ресурсы. Использование этих ресурсов должно координироваться и объединяться комплексом мероприятий для достижения общей цели создания соответствующего сложного объекта или системы с заданным качеством в условиях ограниченных ресурсов. Современные сложные системы и соответственно проекты, обеспечивающие их создание, имеют ряд важных особенностей:
Одной из особенностей сложных систем является трудность выбора и формализации единого критерия качества и оценки эффективности функционирования, адекватно отражающего главные цели системы. Обычно выделяется несколько более или менее равнозначных характеристик, каждая из которых может стать доминирующей для оценки эффективности системы в зависимости от этапа ее проектирования, состояния или некоторых внешних условий. Это обусловлено тем, что каждая сложная система, зачастую, является частью системы большего масштаба и высшего уровня, и подчинена ей.
Для управления проектом системы, прежде всего, должен быть адекватно описаны цели и объект проектирования. Для сложных систем формализация и детализация характеристик объекта разработки происходит одновременно с процессом его проектирования. Последовательно уточняются архитектура объекта, основные функции и их характеристики, требующиеся показатели качества функционирования и методы решения задач. Все эти данные отражаются в концепции, техническом задании, спецификации требований и описании проекта, которые детализируются и конкретизируются по мере развития проекта. Это определяет принципиальную особенность планирования проектов сложных систем, состоящую в наличии влияния на план изменяющихся значений и достоверности знаний разработчиков о требуемых характеристиках объекта разработки. С этим связана необходимость итерационного уточнения планов на всех этапах проектирования, разработки и совершенствования систем.
План проекта должен отражать рациональное сочетание целей, стратегий действий, конкретных процедур и доступных ресурсов, необходимых для достижения поставленной основной цели проекта с заданным качеством. Планирование проектов должно обеспечивать компромисс между требующимися характеристиками создаваемой системы и ограниченными ресурсами, необходимыми на ее разработку и применение. По мере уточнения исходных данных об объекте разработки, внешней среде применения и ресурсах, в процессе системного анализа и проектирования возрастает достоверность планирования.
Первичное прогнозирование характеристик проекта и подготовка плана при системном проектировании происходит при некоторых фиксированных исходных данных, не полностью учитывающих динамику возможного исполнения плана. На этой стадии отсутствует оперативная обратная связь процесса реального выполнения плана с его первичным вариантом. Важнейшая задача при разработке такого плана минимизировать число связей и сложность взаимодействия между компонентами проекта, а также между исполнителями отдельных компонентов. Уже при первичном прогнозировании развития системного проекта оцениваются альтернативные характеристики объекта и среды разработки и выбираются наиболее подходящие в соответствии с поставленными целями и имеющимися ресурсами.
После создания системного проекта появляется и действует динамическая обратная связь на план со стороны процесса его исполнения. Реализация проекта зависит от результатов выполнения частных работ и может требовать оперативной корректировки плана. При реализации плана определяющими являются координация, стимулирование и контроль развития проекта. Для этого необходимо следить за ходом исполнения проекта на всем протяжении его жизненного цикла и сравнивать запланированные и фактические результаты работ. Контроль является органической функцией управления и должен иметь средства регулирования поведения отдельных личностей и коллектива проектировщиков в целом. Одновременно обеспечивается наблюдение за состоянием системы и ее характеристиками качества, что позволяет устанавливать частные компромиссы с используемыми ресурсами. Объектами контроля при этом являются:
Для получения, накопления и применения достоверных данных об объектах управления и альтернативах необходима информационная система обеспечения проекта. Такая система представляет собой комплекс формальных и неформальных каналов обмена информацией между участниками проекта, её накопления и обработки. Следует учитывать, что любая групповая деятельность связана со сложным комплексом неформальных отношений между исполнителями. Степень формализации может варьироваться от утверждаемых руководителями планов и подробных технических заданий до личных бесед между разработчиками. Регулярный обмен информацией позволяет осуществлять:
Таким образом, целевое системное управление проектами позволяет планировать, контролировать и анализировать информацию о состоянии и тенденциях изменения объекта разработки, его качестве и затраченных ресурсах. При этом непрерывно должны сохраняться основные цели проекта и главные пути ее достижения. Это позволяет рассматривать альтернативы технических решений и предотвращает от сосредоточения внимания на частных задачах или вариантах решений, которые кажутся полезными и интересными, но мало отражаются на достижении главной цели проекта ПС.
4.2. Процессы системного проектирования программных средств
Системное проектирование в программной инженерии охватывает период жизненного цикла сложных комплексов программ, начиная от формулирования первичного замысла на создание или модернизацию системы и до начала детального проектирования и разработки ПС. Результатом этого периода работ должно быть согласованное и формализованное разработчиком и заказчиком представление о целях, назначении, функциональных задачах и качестве будущего программного продукта, способного удовлетворить надежды и запросы пользователей. В системном проекте должны быть обобщены и отражены следующие основные результаты выполненных системных исследований и разработок (рис. 4.1):
Системное проектирование сложных ПС начинается с обследования объекта информатизации, системного анализа предметной области и выявления потребности в создании или модернизации комплекса программ с определенными функциями и качеством. При создании сложных ПС важно учитывать, что только заказчик и потенциальный пользователь системы вправе и способен корректно формулировать требования и впоследствии судить насколько успешно проведена разработка соответствующего ПС. Аналитики-консультанты совместно с потенциальными разработчиками и заказчиком или пользователями должны проводить анализ прикладной области и объекта информатизации, разрабатывать стратегию разработки и технико-экономическое обоснование реализуемости выдвигаемых требований.
Разработка исходных требований для технического задания на проект ПС начинается с анализа результатов обследования объекта информатизации и оценки доступных ресурсов для реализации проекта. Эта деятельность требует специальной организации специалистов наивысшей квалификации и тесной совместной работы представителей заказчика и разработчика. Они должны подготовить исходные данные и документы, в которых содержатся предварительные требования и пожелания к функциональным и конструктивным характеристикам качества программного комплекса. Далее ими должна проводиться сложная работа по предварительному упорядочению, селекции, обобщению и ранжированию приоритетов требований для их реализации в проекте. Наличие обычно ряда неформализованных, неструктурированных и противоречивых содержательных требований заказчика и разработчика требует их совместной обработки, согласования и корректировки.
Функциональные требования заказчика к процессам и результатам обработки информации необходимо скоординировать с конструктивными требованиями и возможностями их эффективной реализации разработчиками в спецификациях требований к комплексу программ и его программным и информационным компонентам. Должна быть предусмотрена корректировка, конкретизация и развитие совокупности предварительных требований в процессе системного проектирования и в дальнейшем по мере реализации проекта при тесном взаимодействии заказчика и разработчика. Для крупных проектов ПС целесообразно использовать специальный инструментарий и хранилище решений в процессе отработки требований, которые следует учесть в системном проекте и техническом задании, а также применять для контроля их реализации.
Предварительный анализ и моделирование процессов обработки данных при системном проектировании должны проходить этапы от простого установления базовых отношений между понятиями, через определение интерфейсов доступа и атрибутов, к проекту модели состояний и взаимодействий между реальными объектами и процессами ПС. Эти модели должны служить базой при разработке схем потоков управления и данных, описывающих процессы их обработки, а впоследствии интегрироваться с отработанными моделями процессов для комплексного исследования функционирования прототипов пилотных проектов ПС в целом. Итеративный характер построения формализованного описания проекта системы, предопределен изначально не только потому, что не удается сразу получить непротиворечивое и полное описание из-за неясностей в исходном описании, но и потому, что сложную систему можно описывать только, начиная с основной части ее предметной области, которая затем постепенно расширяется и детализируется.
Моделирование процессов обработки данных при системном проектировании преследует две основные цели:
При построении формализованного описания системы, выполняемом её разработчиком, принципиальными являются два организационных момента: специалисты заказчики или пользователи создаваемой системы должны активно участвовать в процессе анализа и реализации её описания; каждый шаг описания должен обязательно документироваться. Наглядными и удобными в работе являются графические представления описаний проектных решений, которые позволяют создавать прототипы ПС. Они обеспечивают эффективную визуализацию и обратную связь между разработчиком и потенциальным пользователем с целью оценки реализации требований, корректировки функций и качества компонентов, а также форм пользовательского интерфейса. Для этого разработана целая гамма методологий для моделирования, структурного анализа и визуального проектирования. Современные инструментальные CASE-средства обеспечивают широкие возможности выбора процессов моделирования, автоматизированного анализа системных предложений и выработки первичных требований к предполагаемому проекту ПС. Схемы потоков данных, потоков управления, сущность-связь и другие – составляют комплекс удобных и гибких графических методов и средств описания систем, облегчающих взаимопонимание между разработчиками и заказчиками на разных уровнях детализации функций, качества и архитектуры ПС.
Концепция создаваемого комплекса программ (см. рис. 4.1) на естественном языке данной предметной области должна включать предварительные требования к ПС, основные понятия и термины. Она является первым исходным документом, согласуемым с заказчиком для создания комплекса программ. На основе этого описания формируется предварительное техническое задание на систему и её основные компоненты. При использовании формализованных методов разработки программных средств текстуальное описание системы подлежит переводу на соответствующий, возможно, графический язык. Наряду с разработчиками, специалисты-заказчики или пользователи создаваемой концепции ПС должны активно участвовать в процессе анализа и реализации её описания.
Одним из наиболее эффективных направлений сокращения затрат и повышения качества комплексов программ является активное использование методического, технологического, алгоритмического и программного задела из предшествующих проектов, которое может быть названо прототипированием в широком смысле слова. Математические модели и прототипы различных компонентов и функций систем обеспечивают возможность применять готовые апробированные решения, а также выделять и исследовать принципиально новые методы и процессы для реализации их в ПС. Прототипирование позволяет наглядно представить заказчику и пользователю функции системы, виды и динамику применения экранов, меню, отчетов и форм запросов, а также откорректировать их для развития ПС на всех этапах ЖЦ. Методами математического моделирования должны создаваться варианты, фрагменты и компоненты прототипа ПС и выделяться возможные методы реализации предполагаемых функций и обеспечения их качества. Для этого следует анализировать и выбирать прототипы комплексов программ, характеристики которых наиболее близки к создаваемой версии ПС и которые позволили бы получить в результате объекты с необходимыми характеристиками. На их основе, возможно прогнозировать процессы разработки и достигаемые показатели качества вновь создаваемого ПС. Этим же целям способствует предварительное распределение ресурсов, доступных для создания проекта.
Стратегическое планирование проекта должно содержать долгосрочные цели развития ЖЦ ПС определенного функционального назначения. Планы должны отражать предварительные проекты всего будущего жизненного цикла ПС, обеспечения их качества, защиты и безопасности функционирования, верификации и тестирования, управления конфигурацией и сопровождения. На базе требований к ПС и первичных планов появляется возможность оценить объем подлежащих разработке компонентов программ и баз данных, а также некоторые дополнительные характеристики возможного объекта и среды разработки. На этом этапе инструментальные средства должны обеспечить наглядное представление каждого плана, оценку возможной трудоемкости и длительности разработки, необходимого числа специалистов и других ресурсов для их реализации. По этим данным руководителем разработки и заказчиком принимается решение о целесообразности продолжения проектирования и осуществляется стратегическое планирование проекта, которое формализуется в системном проекте и в техническом задании на ПС.
Такое постепенное повышение достоверности прогнозов приводит к целесообразности оценки достигаемых значений качества по этапам и к возможности разработки укрупненного, поэтапного плана выполнения всего комплекса работ в ЖЦ ПС. Эти данные позволяют принимать решения по корректировке требований к ПС, по изменению среды разработки или состава коллектива специалистов. Таким образом, последовательное прогнозирование, планирование и системное управление проектом обеспечивают рациональное использование ресурсов в процессе создания сложных ПС гарантированного качества.
Прогнозы и анализ вариантов технологических процессов проектирования ПС, их технико-экономических показателей и характеристик объекта разработки являются основой для выбора, предварительного планирования и последующего системного анализа всего жизненного цикла ПС. Достоверность планов и прогнозов определяется точностью сведений об объекте разработки, характеристиках технологической среды и прототипов, принятых за основу при планировании. Таким образом, производится технико-экономическое обоснование проекта (см. лекцию 5), определяются приближенные значения трудоемкости и длительности всей разработки ПС, а также число необходимых специалистов, что позволяет оценить предварительный укрупненный план создания ПС в заданных условиях, ресурсах и сроках. Вследствие творческого характера большинства работ на этом этапе невозможно составить жесткий план их выполнения. Помочь может типовой перечень частных работ, представленный в стандартах ЖЦ ПС и ориентировочный график, иллюстрирующий их взаимосвязь.
Проведенные таким образом оценки проекта ПС позволяют осуществить предварительный выбор основных методов и инструментальных средств для проведения последующего детального и рабочего проектирования и поддержки всего ЖЦ ПС. Кроме того, должна подготавливаться адаптация средств автоматизации, применительно к особенностям объекта и среды проектирования. Разрабатываются проекты руководств для специалистов, выделяемых на данный проект, и осуществляется их обучение. Интегрированные инструментальные средства служат для формализации знаний заказчика на этапе проведения обследования, анализа и подготовки технического задания, а также для проектирования концептуальной и логической структуры комплекса программ и базы данных. При этом должно активно использоваться моделирование и тестирование корректности системных решений. Благодаря высокому качеству проработки и документирования системного проекта, создается основа для снижения трудоемкости тестирования, испытаний, а также сопровождения и модификации ПС.
В процессе системного проектирования должны предварительно определяться состав и структура основных технологических и эксплуатационных документов для поддержки всего ЖЦ ПС. Эти документы должны обеспечивать реализацию процессов жизненного цикла ПС, планирования и управления, регистрировать выполнение требуемых действий, формализовать систему качества. При этом следует подготовить первоначальные требования к документации и обеспечить их реализацию, которая должна быть однозначной написана в стандартизированных терминах, которые допускают только единственную интерпретацию, уточняемую, если необходимо, соответствующими комментариями.
Системный проект программного средства новой или модернизированной системы должен содержать достаточно полные требования к функциям и характеристикам качества комплекса программ, описание и графическое представление его архитектуры, базы данных и взаимодействия компонентов, предполагаемую модель жизненного цикла, предварительные планы последующих этапов и работ. Кроме того, в него должны входить проекты технического задания и контракта на детальное проектирование и весь жизненный цикл ПС. Если заказчик удовлетворен результатами системного проектирования, то возможно оформление акта завершения работ и утверждение системного проекта комплекса программ с требуемыми характеристиками качества новой или модернизированной системы, а также контракта (договора) на детальное проектирование или на весь жизненный цикл ПС.
4.3. Структурное проектирование сложных программных средств
При разработке структуры программного средства в процессе системного проектирования, прежде всего, необходимо сформулировать критерии её формирования. Важнейшими критериями могут быть: модифицируемость, отлаживаемость и удобство управления разработкой ПС, обеспечение возможности контролируемого изменения конфигурации, состава и функций компонентов с сохранением целостности структурного построения базовых версий ПС. В зависимости от особенностей проблемной области, критериями при выборе архитектуры ПС могут также применяться: эффективное использование памяти или производительности реализующей ЭВМ, трудоемкость или длительность разработки, надежность, безопасность и защищенность. В соответствии с целями и задачами проектирования на стадии системного анализа и формирования структуры ПС необходимо ранжировать и выделить доминирующие критерии.
Гибкость модификации и расширяемость комплексов программ при их совершенствовании обеспечивается рядом принципов и правил структурного построения ПС и их компонентов, а также взаимодействия между ними. Эти правила направлены на стандартизацию и унификацию структуры и взаимодействия компонентов ПС разного ранга и назначения в пределах проблемной области. Некоторая часть принципов и правил имеет достаточно общий характер, и может применяться практически всегда. Другая часть отражает проблемную и/или машинную ориентированность класса ПС и подлежит отработке при системном проектировании для эффективного применения в соответствующей области. Основные принципы
и правила структурирования ПС и БД можно объединить в группы, которые отражают:
Методология структурного анализа и предварительного структурного проектирования ПС начинается с общего обзора функций системы. Далее функции должны детализироваться сверху вниз в виде иерархической структуры таким образом, чтобы процедуры сбора, хранения и переработки информации, рассматриваемые сначала как нечто единое целое, расчленялись на отдельные элементы данных, компонентов и действия, совершаемые над этими данными. Структурный анализ, исходя из функционального описания системы в целом, позволяет разделить её на функциональные части, выделить функциональные описания отдельных частей, исследовать в них информационные потоки и формализовать структуры данных.
Разделение общей задачи системы и программного средства на компоненты это использование принципа здравого смысла, который должен быть применен в системной разработке крупного ПС для преодоления свойственной ему сложности. Очень часто многие решения прочно взаимосвязаны и взаимозависимы. Когда различные проектные решения прочно взаимосвязаны, то бывает полезно, чтобы всеми ими сразу занимались в одно и то же время одни и те же люди, но на практике это обычно невозможно. Единственный способ справиться со сложностью проекта разделить задачи. Прежде всего, необходимо пытаться изолировать функции, которые менее всего связаны с другими. Затем рассматривать раздельно функции, учитывая имеющие отношения между собой и детали связанных проблем.
Спецификация требований к предварительной архитектуре комплекса программ формируется в процессе детализации и уточнения спецификации требований к характеристикам ПС в результате проверки последних на непротиворечивость и полноту. Задача спецификации требований архитектуры состоит в том, чтобы представить достаточно ясное и удобное общее описание внешнего поведения системы и свойств, а также её внутренней структуры и механизмов функционирования. В общем случае формализованные методы, применяемые при специфицировании системной архитектуры ПС, должны обеспечивать:
Описания проектных решений должны содержать первичные спецификации крупных функциональных компонентов ПС, подлежащих разработке в детальном проекте создаваемой системы, и спецификаций используемых готовых компонентов, состав которых определяется при декомпозиции общей структуры системы. В требованиях спецификации к системной архитектуре комплекса программ должно обеспечиваться:
Таким образом, для обеспечения эффективного управления разработкой программ необходимо при системном проектировании стандартизировать и соблюдать ряд принципов архитектурного построения ПС. Эти принципы могут иметь особенности для проектов ПС в различных проблемно-ориентированных областях. Однако их стандартизация обеспечивает значительный эффект в снижении трудоемкости и длительности последующей детальной разработки программного продукта и версий. Частичная потеря гибкости архитектуры ПС, некоторое возрастание ресурсов, необходимых для реализации этих принципов, обычно полностью компенсируются повышением управляемости процесса разработки, а также качества ПС.
Структурное проектирование программных средств основано на модульном принципе. Многоуровневое, иерархическое построение сложных программных комплексов позволяет ограничивать и локализовать на каждом из уровней соответствующие ему компоненты. Нижнему иерархическому уровню представления программ соответствуют программные и информационные модули (модули данных). Эти компоненты объединяются в группы программ определенного функционального назначения с автономной целевой задачей. Несколько групп функциональных программ образует комплекс программ. В особо сложных случаях возможно создание программного средства из нескольких взаимодействующих комплексов. Всем иерархическим системам (в частности, ПС) присущ ряд общих свойств, важнейшими из которых являются:
В результате в иерархических структурах ПС образуются два потока взаимодействий между компонентами разных уровней: сверху вниз координирующие и управляющие воздействия верхних уровней и снизу вверх информация о состоянии и реализации предписанных сверху функций компонентами нижних уровней. Координируемые компоненты обычно имеют некоторую автономность поведения и подготовки локальных решений. Степень автономности компонентов и интенсивность координирующих воздействий устанавливаются в результате компромисса при выделении числа и размеров иерархических уровней. Взаимодействие компонентов в пределах уровня целесообразно максимально ограничивать, что позволяет упростить общее координирование компонентов и проводить его только по вертикали.
Менее наглядными являются иерархия данных, обрабатываемых ПС, и их взаимодействие с программными компонентами. Функциональная иерархия данных отражается расстоянием между расчетом или изменением переменной и её использованием, или условной длительностью хранения неизменяемых значений переменной. Взаимодействие двух программных модулей может осуществляться так, что некоторые переменные используются только этими модулями. Такие обменные переменные имеют более широкую область применения и должны храниться все время, пока не будут вызваны взаимодействующие модули. Ряд переменных и массивов используется многими модулями и группами программ в комплексе это глобальные переменные. Они характеризуются наиболее широким использованием и соответствуют высшему иерархическому уровню среди данных.
Анализ концепции, требований технического задания и технико-экономических оценок должен позволять выполнить предварительное структурное проектирование ПС и оценку вычислительных ресурсов необходимых для решения основных функциональных задач. Повышению эффективности структурирования могут значительно способствовать заимствование из предыдущих проектов спецификаций прототипов, версий и отдельных компонентов ПС. Для обеспечения системного проектирования на этом этапе большое значение имеют графические методы визуализации технических решений и логического контроля проекта.
Характеристики внешней среды применения ПС и особенности реализующей ЭВМ в значительной степени определяют архитектуру и структуру применяемой операционной системы, средств контроля и организации вычислительного процесса. При разработке версий ПС для некоторой прикладной области целесообразно выбирать и унифицировать внешний интерфейс и операционную систему. Это обеспечивает многократное использование одних и тех же организующих программ, дисциплинирует структурное построение версий ПС и способствует унификации межмодульного интерфейса. Переход на новую операционную систему, так же как и переход на реализующую ЭВМ другого типа, может привести к необходимости некоторого изменения структурного построения ПС и базы данных. Это способно повлиять на возможность использования готовых компонентов, а, следовательно, и на эффективность всей разработки.
Учет возможности изменений это принцип, который более всего отличает программное средство от большинства других типов промышленных продуктов. Во многих случаях структура ПС разрабатывается, когда требования заказчика к нему осознаны не полностью. Позже, при детализации и после поставки, ПС должно развиваться на основе откликов заказчика и пользователей, поскольку обнаруживаются новые требования, а старые уточняются. В дополнение к этому, программный продукт часто встраивается в среду, которая воздействует на него, и это воздействие генерирует новые требования, которые не были изначально известны. Таким образом, возможности изменений это принцип, который следует использовать при системном проектировании структуры для достижения способности к её развитию эволюционности структуры ПС.
Повторная применимость является еще одним качеством структуры программного продукта, на которое заметно воздействует принцип возможности изменений. Компонент является многократно применимым, если он может быть непосредственно использован для производства нового продукта или версии. На практике, компонент может претерпеть некоторые изменения прежде, чем будет использован повторно. Отсюда, многократное использование можно рассматривать как эволюционность системной структуры ПС на уровне компонентов. Если можно предвидеть изменения контекста, в который будет встроен программный компонент, то и компонент можно спроектировать таким образом, что изменения будут им учтены.
Сложная система обычно может быть разделена на более простые части модули. Модульность является важным качеством инженерных процессов и продуктов. Большинство промышленных процессов являются модульными и составлены из комплексов работ, которые комбинируются простыми способами (последовательными или перекрывающимися) для достижения требуемого результата. Главное преимущество модульности заключается в том, что она позволяет применять принцип разделения задач на двух этапах:
Если данные этапы выполняются в последовательности, предусматривающей сначала концентрацию процессов на модулях, а затем их объединение, то система проектируется снизу вверх. Если сначала систему разбивают на модули, а потом работают над их индивидуальным проектированием, то это проектирование сверху вниз.
При структурном построении комплексов программ важное значение имеет размер и сложность компонентов для каждого уровня иерархии и соответственно число иерархических уровней для крупных ПС. По принципам построения, языку описания, размеру и другим характеристикам компонентов в структуре ПС можно выделить иерархические уровни:
С повышением иерархического уровня увеличивается размер текста программ, реализующих компоненты этого уровня и количество обрабатываемых переменных. Одновременно совокупности команд все более специализируется и снижается возможность повторного применения компонентов в различных комбинациях для решения аналогичных задач.
Программные модули решают относительно небольшие функциональные задачи, и каждый реализуется 10-100 операторами языка программирования. Каждый модуль может использовать на входе около десятка типов переменных. Если для решения небольшой функциональной задачи требуется более 100 операторов, то обычно целесообразно проводить декомпозицию задачи на несколько более простых модулей.
Функциональные группы программ (компоненты) формируются на базе нескольких или десятков модулей и решают достаточно сложные автономные задачи. На их реализацию целесообразно использовать до десятка тысяч строк текста программы. Соответственно возрастают число используемых типов переменных и разнообразие выходных данных. При этом быстро растет число типов переменных, обрабатываемых модулями и локализующихся в пределах одного или нескольких модулей.
Комплексы программ – программные продукты создаются для решения сложных задач управления и обработки информации. В комплексы объединяются несколько или десятки функциональных групп программ для решения общей целевой задачи системы. Размеры ПС зачастую исчисляются сотнями модулей, десятками и сотнями тысяч операторов. Встречаются ПС, содержащие до двух-трех десятков структурных иерархических уровней, построенных из модулей.
Проектирование модулей включает в себя разработку локальных функций и подробных описаний алгоритмов обработки данных; межмодульных интерфейсов; внутренних структур данных; структурных схем передач управления; средств управления в исключительных ситуациях. С их помощью определяются функции: порядок следования отдельных шагов обработки, ситуации и типы данных, вызывающие изменения процесса обработки, а также повторно используемые функции программы. Программные модули для их многократного использования должны базироваться на унифицированных правилах структурного построения, оформления спецификаций требований и описаний текстов программ и комментариев. Кроме того, целесообразно для каждого проекта директивно ограничивать размеры модулей по числу строк текста с учетом языка программирования, например, 30-ю или 50-ю операторами (см. лекцию 13).
Основная цель такой унификации облегчить разработку модулей, обеспечение их качества и тестирования, а также упростить управление их функциями и характеристиками. Эти правила в значительной степени стандартизированы в современных языках программирования. Однако при их применении целесообразно выделять типовые ассоциации операторов и ограничения их использования, а также, вводить правила описания текстов программ, комментариев, данных и заголовков модулей, ограничения их размеров и сложности. Эти правила наиболее полно должны соблюдаться при разработке основной массы функциональных программ, подлежащих повторному использованию в модифицируемых версиях программных продуктов. Компоненты организации вычислительного процесса, контроля функционирования, ввода-вывода и некоторые другие могут иметь отличия в правилах структурного построения модулей.
Для обеспечения управляемой модификации и развития конфигураций версий программного продукта важно стандартизировать структуру базы данных, в которой накапливается и хранится исходная, промежуточная и результирующая информация в процессе функционирования ПС. Основными компонентами этой структуры являются информационные модули или пакеты данных. В них также целесообразно использовать типовые структуры, ориентированные на эффективную обработку данных в конкретной проблемной области. Объединение информационных модулей позволяет создавать более сложные структуры данных определенного целевого назначения. Иерархия связей между этими компонентами в некоторой степени соответствует процессу обработки и потокам данных и относительно слабо связана со структурой программных компонентов в ПС. Структуры информационных модулей целесообразно координировать между собой с учетом цели и места их использования программными компонентами.
Особое значение для качества модулей и компонентов крупных ПС имеет стандартизация структуры межмодульных интерфейсов по передачам управления и по информации. Эти правила формируются на базе описаний языков программирования или оформляются на основе правил структурного построения программ и базы данных конкретных проектов ПС. В последнем случае соглашения о связях конкретизируются в макрокомандах межмодульного взаимодействия. Структурное проектирование сложных комплексов программ активно развивается на основе концепции и стандартов открытых систем. Применение стандартов открытых систем следует начинать при создании архитектуры исходных модулей мобильных ПС и БД, а далее неукоснительно использоваться при всех процессах ЖЦ. Во всех случаях создание архитектуры модулей и компонентов современных сложных систем целесообразно вести с использованием профилей международных стандартов, значительная часть которых обеспечивает мобильность и возможность повторного использования готовых программных средств и баз данных (см. лекцию 3).
Основными целями создания и применения концепции, методов и стандартов открытых систем является повышение общей экономической эффективности разработки и функционирования систем, а также логической и технической совместимости их компонентов, обеспечение мобильности и повторного применения готовых программ и данных. Они реализуют спецификации на интерфейсы, процессы и форматы данных, достаточные для того, чтобы обеспечить:
Для достижения этих целей развиваются и применяются различные проблемно-ориентированные технологии и комплексы средств автоматизации ЖЦ мобильных программ и баз данных, основанные на повторном использовании готовых апробированных модулей, программных компонентов и данных, их эффективном переносе на различные аппаратные и операционные платформы и согласованном взаимодействии в распределенных информационных системах. Профессионалы в области открытых систем акцентируют усилия на поиске и создании гибкой, способной к наращиванию среды, что базируется на трех направлениях стандартизации в области систем (см. лекцию 2):
Методы открытых систем обеспечивают эффективные по трудоемкости и качеству структурное проектирование, расширение и перенос готовых программных средств обработки информации и баз данных на различные аппаратные и операционные платформы. Эти методы можно разделить на три части:
Первая группа методов создавалась с ограниченной и определенной целью локализовать и унифицировать интерфейсы программных компонентов между собой, с заранее выделенными операционными системами и с внешней средой. Интерфейсные стандарты являются базой для обеспечения структурного проектирования, свободного перемещения и расширения программных продуктов и компонентов в различные по архитектуре и функциям операционные окружения и аппаратные платформы. Эти методы позволяют разделить функциональную часть комплексов программ и их связи с организационным окружением, обеспечивая технологическую, архитектурную и языковую независимость функциональной части программ и данных. Тем самым они являются базой для реализации концепции открытости в системах и обеспечивают свободу разработчикам при выборе методов структурного проектирования и языков программирования для создания компонентов программ и описаний данных. Стандарты этой группы включают группу стандартов POSIX, в которой определены концепция и функции интерфейсов переносимых операционных систем, команды управления и сервисные программы, а также расширение для переносимых операционных систем.
Вторая группа методов имеет целью поддержать мобильность программных продуктов в открытых системах путем унификации их интерфейсов с внешней средой. Они обеспечивают совместимость обмена данными в различных файловых системах и базах данных, унификацию административного управления и взаимодействия с пользователями, а также методов обеспечения безопасности и защиты информации. Таким образом, создается стандартизированная по интерфейсам внешняя среда на различных гетерогенных аппаратных платформах, в которую могут эффективно погружаться различные программы, согласованные по интерфейсам с этими стандартами. Стандарты этой группы регламентируют функции и процессы, поддерживающие взаимодействие с внешней средой:
Третья группа методов создавалась в значительной степени независимо от первой и второй. Эти методы преследуют цель унифицировать тексты программных модулей, компонентов и описания данных, создаваемых для различных аппаратных платформ при любой их архитектуре, независимо от операционной и внешней среды. Первоначальное огромное число языков программирования (свыше 200), каждый из которых имел несколько диалектов, в результате сократилось до 6 10 массовых языков, ограниченных стандартами, не допускающими диалектов. Создание современных модулей и компонентов ПС и БД поддерживается методами и инструментальными средствами технологий, методами тестирования и аттестации программ и их интерфейсов, а также стандартизированным составом и содержанием документации на программы и базы данных. Эти методы и средства обеспечивают необходимое качество модулей и компонентов сложных ПС и БД. В результате обеспечена мобильность функциональной части текстов программ, однако они могут требовать доработок интерфейсов для сопряжения с новой средой аппаратного и операционного окружения систем.