Шпаргалка по "Программированию и компьютерам"

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

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

 

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

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

Основные задачи, стоящие перед разработкой архитектуры программного средства:

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

2. Определение  способов взаимодействия между  выделенными программными подсистемами.

 

41. Основные классы архитектур программных средств.

На практике выделяют следующие классы архитектур программных средств:

1. Программное  средство как цельная программа.

Представляет  вырожденный случай архитектуры программного средства, т.е. в состав входит только одна программа. Данную архитектуру выбирают в том случае, если программа должна выполнить четко выраженную последовательность действий или алгоритмов и нет необходимости выделять эти части в отдельные компоненты. Такая архитектура, как правило, не требует подробного описания.

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

2. Комплекс  автономно-выполняемых программ.

Состоит из набора программ такого, что:

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

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

- все  программы программного средства  применяются к одной и той  же информационной среде.

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

3. Слоистая  программная система.

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

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

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

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

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

1. Корректное  и последовательное обращение  к памяти в избежание ошибок  чтения и записи внутренних  данных программ.

2. Управление, диспетчеризация и синхронизация  вычислительных процессов программного  средства (особенно если выбрана  архитектура «комплекс независимо  выполняемых программ»).

3. Управление  и контроль вводимых данных  во все программы программного средства, т.е. контролируется объем вводимых данных, тип, формат и корректность данных для внесения в БД (конкретные алгоритмы по преобразованию данных).

4. Осуществление  связи с пользователем корректным  для программного средства способом. Здесь подразумевается продуманный  пользовательский интерфейс.

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

4. Комплекс  параллельно выполняющихся программ.

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

 

42. Архитектурные функции. Контроль архитектуры программного средства.

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

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

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

Создание дополнительных компонент может потребоваться в следующих случаях:

1. Когда  программной системе необходим  свой командный интерпретатор (функции  которого отличаются от функций  интерпретатора ОС).

2. Когда  необходима дополнительная тонкая  настройка внешней информационной  среды (как при локальной обработке  данных, так и при распределенной) с привлечением сетевых технологий.

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

Пример: подсистема преподавателя по учету и контролю учебного процесса.

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

Контроль архитектуры программных систем

Есть только 2 способа контроля:

- составной (смежный) контроль

- ручная  имитация

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

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

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

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

 

43. Понятие модульного программирования.

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

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

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

Не всякий программный модуль будет взаимодействовать и упрощать систему в целом. В 1997 году было предложено 2 критерия оценки качественности модуля:

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

2. Качественный  модуль проще использовать, чем  построить.

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

 

44. Основные характеристики программного модуля.

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

Он вводит следующие характеристики: