Липаев В.В. Программная инженерия

Лекция 4. Системное проектирование программных средств

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

Менее наглядными являются иерархия данных, обрабатываемых

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

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

Характеристики внешней среды применения ПС и особенности реа­ лизующей ЭВМ в значительной степени определяют архитектуру и струк-

120

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

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

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

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

121

Лекция 4. Системное проектирование программных средств

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

икомпонентов

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

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

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

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

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

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

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

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

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

122

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

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

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

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

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

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

123

Лекция 4. Системное проектирование программных средств

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

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

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

124

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

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

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

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

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

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

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

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

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

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

Методы открытых систем обеспечивают эффективные по трудоемко­ сти и качеству структурное проектирование, расширение и перенос гото-

125

Лекция 4. Системное проектирование программных средств

вых программных средств обработки информации и баз данных на различ­ ные аппаратные и операционные платформы. Эти методы можно разде­ лить на три части:

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

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

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

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

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

126

Л Е К Ц И Я 5

ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ ПРОЕКТОВ ПРОГРАММНЫХ СРЕДСТВ

5.1. Цели и процессы технико-экономического обоснования проектов программных средств

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

128

5.1. Цели и процессы технико-экономического обоснования проектов...

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

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

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

129