Лекция №5. Виды интерфейсов. Внешний интерфейс. Внутренний интерфейс

Поможем в ✍️ написании учебной работы

Имя

Поможем с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой

Нажимая кнопку "Продолжить", я принимаю политику конфиденциальности

Лекция №5. Виды интерфейсов. Внешний интерфейс. Внутренний интерфейс.

Интерфейс - это связь двух отдельных сущностей. Виды интерфейсов: языковые, программные, аппаратные, пользовательские, цифровые и т. п. Программный (API) и/или аппаратный интерфейс (port) - это способы преобразования входных/выходных данных во время объединения компьютера с периферийным оборудованием. В ЯП - это программа или часть программы, в которой определяются константы, переменные, параметры и структуры данных для передачи другим.

В программировании термин интерфейс олицетворяет собой набор операций, обеспечивающих определение видов услуг и способов их получения от программного объекта, предоставляющего эти услуги.

Виды интерфейсов в объектно-ориентированном программировании (ООП).

В ООП главным элементом является класс, включающий множество объектов с одинаковыми свойствами, операциями и отношениями. Класс имеет внутреннее (реализацию) и внешнее представление - интерфейс (табл. 8.1).

Таблица 8.1. Структура представления класса и интерфейса
Класс
Внешнее представление	Внутреннее представление
Интерфейсные операции: · публичные, доступные всем клиентам: · защищенные, доступные классу п подклассу: · приватные, доступные классу.	Реализация операций класса, определение поведения.

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

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

Внутренний интерфейс.

Для понимания и осознанного использования многих особенностей языка программирования полезны знания о внутреннем представлении программы и принципах ее исполнения. Преобразование текста программы и нечто «удобоваримое» с точки зрения компьютера включает в себя два процесса:

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

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

Различные языки программирования включают процессы компиляции и интерпретации в разных пропорциях и сочетаниях (подробнее см. 1.7). Разберемся, в каких взаимоотношениях находятся язык Си и компьютерная архитектура:

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

· язык Ассемблера представляет собой язык программирования, в котором система команд, способы адресации и машинные слова и их адреса обозначаются символическими именами. Таким образом, Ассемблер работает с компьютерной архитектурой, но ее элементы представлены не во внутренней (двоичной) форме, а в обычной текстовой;

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

· язык Си имеет прямой выход на компьютерную архитектуру, многие его компоненты напрямую на нее отображаются. Базовые типы данных совпадают с основными формами представления данных в процессоре, имеется прямое соответствие между переменными и машинными словами (см. 1.3), набор операций соответствует общепринятому минимуму для системы команд, указатели интерпретируются как адреса (см. 5.2), имеется возможность работы с памятью на низком (архитектурном) уровне (см.9.2). Поэтому Си можно назвать машинно-независимым Ассемблером;

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

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

Рис. 12-1. Организация памяти компьютера

Все данные представляются в двоичной системе счисления в виде машинных слов – наборов двоичных разрядов. Минимальный размер машинного слова для хранения, обработки и передачи данных – 8 разрядов (1 байт). Все остальные слова кратны ему. Стандартное машинное слово имеет разрядность, соответствующую разрядности процессора (32 разряда или 4 байта). Для представления содержимого машинных слов используется эквивалент двоичный системы - шестнадцатеричная (подробнее см. 1.3). В дальнейшем описании мы будем применять более привычные десятичные значения, не забывая, что в реальности имеем дело с двоичными (шестнадцатеричными) эквивалентами.

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

Процессор имеет в своем составе набор машинных слов – регистров. В зависимости от назначения они могут хранить как данные, так и адреса памяти.

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

В процессоре сегментация поддерживается при помощи регистров двух видов. Базовый регистр сегмента содержит его начальный адрес. Регистры, работающие с данными сегмента, содержат относительный адрес данных от начала сегмента, или смещение. Результирующий адрес получается путем сложения содержимого этих регистров. Таким образом, каждый сегмент имеет собственную «систему координат», связанную с его началом. Если программа использует только сегментную адресацию, то сегменты можно перемещать по памяти при сохранении работоспособности программы: достаточно перенастроить соответствующие им базовые регистры.

Рис. 12-2. Сегментация программы

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

Сегмент	Регистры	Что содержит	Когда создается
Сегмент команд	CS- сегментный, IP- адрес команды	Программный код (операции, операторы)	Трансляция
Сегмент данных	DS – сегментный	Глобальные (статические) данные	Трансляция
Сегмент стека	SS – сегментный,SP- указатель стека	Локальные данные функций, «история» работы программы	При загрузке
Динамическая память	DS – сегментный	Динамические переменные, создаваемые при работе программы	При загрузке, выполнении
Динамически связываемые библиотеки (DLL)	CS- сегментный, IP- адрес команды	Программный код разделяемых библиотек	При загрузке

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

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

И, наконец, посмотрим, как в общих чертах выглядит процесс исполнения программного кода. Действующими лицами этого процесса являются:

· программный код – последовательность команд, размещенная в сегменте команд (CS), на начало которого ссылается одноименный регистр процессора;

Рис. 12-3. Внутреннее представление программы

· каждая команд имеет в сегменте свой относительный адрес (от его начала), регистр процессора IP ( Instruction Pointer) содержит адрес очередной выполняемой команды. В программировании на языках высокого уровня с IP ассоциируется очень важное понятие – текущая точка выполнения программы;

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

1. команды перемещения и обработки данных выполняют перенос данных между ячейками памяти и регистрами данных процессора, а также все действия по их обработке (mov, add, sub);

2. команды проверки состояний (условий) проверяют результат выполнения операций, состояния регистров процессора, устройств ввода-вывода и т.п. (test);

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

· Вторым элементом команды являются операнды. Это могут быть регистры процессора, содержащие данные и ячейки памяти. В команде в явном или неявном виде должны содержаться их адреса. В ряде случаев операнды берутся «по умолчанию». Имеются различные способы адресации операндов, которые позволяют использовать различные способы доступа к данным, а также сократить размер поля адреса в команде;

· переменные, используемые в программы, при трансляции «становятся» областями памяти в различных сегментах данных (сегменты данных, стека, динамической памяти), где получают свои адреса. В командах, работающих с памятью, в том или ином виде имеется информация, позволяющая вычислить (или просто взять) этот адрес;

· в нашем примере большинство команд переноса и обработки данных являются двухадресными – результат операции совпадает с первым операндом (команду сложения add ax, 454 следует понимать как ax= ax+ b). В принципе, регистр процессора ax можно было бы сделать операндом «по умолчанию» и не упоминать его в команде (если бы операция не использовалась с другими регистрами);

· в нашем примере используется непосредственная адресация для констант (их значение находится в самой программе, add ax, #10) и прямая адресация для ячеек памяти (в команде содержится их адрес, add ax, 454);

· в командах безусловного (jmp) и условного (jmi - «переход, если меньше нуля») должен быть определен адрес следующей команды. В нашем примере он задан в относительной форме – в виде смещения (расстояния) от следующей команды до той, куда производится переход.

Выполнение программы происходит, в общих чертах, таким образом:

· процессор, используя регистры CS: IP выбирает из памяти очередную команду и расшифровывает ее. После этого IP увеличивается и ссылается на следующую команду (в зависимости от длины текущей, например, IP= IP+3);

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

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

· если в команде условного перехода проверяемое условие выполняется, то программа «переходит» по адресу, содержащемуся в команде. В нашем примере это смещение из команды просто добавляется к IP (IP= IP+<смещение>). Иначе ничего не происходит и выбирается следующая команда.

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

Внешний интерфейс.

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

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

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

Лекция №6.

Интерфейс ввода-вывода

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

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

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

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

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

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

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

Интерфейс вывода должен взаимодействовать с интерфейсом управления, справочным интерфейсом, информационным интерфейсом и обеспечивать:

· выделение окон и установку их атрибутов (форма, цвет, шрифт, границы);

· сохранение информации, отображаемой в окне, при перекрытии окон;

· восстановление информации в окне;

· вывод информации в указанное окно;

· распознавание, к какому окну относятся действия пользователя, и их отображения в соответствующем окне.

Лекция №7.

Лекция №8

Функциональность ПС

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

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

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

Процесс приобретения.

Он состоит из действий и задач заказчика, приобретающего ПО. Данный процесс охватывает следующие действия:

· инициирование приобретения;

· подготовку заявочных предложений;

· подготовку и корректировку договора;

· надзор за деятельностью поставщика;

· приемку и завершение работ.

- Инициирование приобретения включает следующие задачи:

ü определение заказчиком своих потребностей в приобретении, разработке или усовершенствовании системы, программных продуктов или услуг;

ü анализ требований к системе;

ü принятие решения относительно приобретения, разработки или усовершенствования существующего ПО;

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

ü подготовку и утверждение плана приобретения, включающего требования к системе, тип договора, ответственность сторон и т. д. Заявочные предложения должны содержать:

ü требования к системе;

ü перечень программных продуктов;

ü условия и соглашения;

ü технические ограничения (например, среда функционирования системы).

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

- Подготовка и корректировка договора включают следующие задачи:

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

ü выбор конкретного поставщика на основе анализа предложений;

ü подготовку и заключение договора с поставщиком;

ü внесение изменений (при необходимости) в договор в процессе его выполнения.

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

- В процессе приемки подготавливаются и выполняются необходимые тесты. Завершение работ по договору осуществляется в случае удовлетворения всех условий приемки.

Процесс поставки.

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

· инициирование поставки;

· подготовку ответа на заявочные предложения;

· подготовку договора;

· планирование;

· выполнение и контроль;

· проверку и оценку;

· поставку и завершение работ.

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

- Планирование включает следующие задачи:

ü принятие решения поставщиком относительно выполнения работ своими силами или с привлечением субподрядчика;

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

Процесс разработки.

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

Процесс разработки включает следующие действия:

· подготовительную работу;

· анализ требований к системе;

· проектирование архитектуры системы;

· анализ требований к ПО;

· проектирование архитектуры ПО;

· детальное проектирование ПО;

· кодирование и тестирование ПО;

· интеграцию ПО;

· квалификационное тестирование ПО;

· интеграцию системы;

· квалификационное тестирование системы;

· установку ПО;

· приемку ПО.

- Подготовительная работа начинается с выбора модели ЖЦ ПО, соответствующей масштабу, значимости и сложности проекта. Действия и задачи процесса разработки должны соответствовать выбранной модели. Разработчик должен выбрать, адаптировать к условиям проекта и использовать согласованные с заказчиком стандарты, методы и средства разработки, а также составить план выполнения работ.

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

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

- Анализ требований к ПО предполагает определение следующих характеристик для каждого компонента ПО:

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

ü внешних интерфейсов;

ü спецификаций надежности и безопасности;

ü эргономических требований;

ü требований к используемым данным;

ü требований к установке и приемке;

ü требований к пользовательской документации;

ü требований к эксплуатации и сопровождению.

- Требования к ПО оцениваются исходя из критериев соответствия требованиям к системе, реализуемости и возможности проверки при тестировании.

- Проектирование архитектуры ПО включает следующие задачи (для каждого компонента ПО):

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

ü разработку и документирование программных интерфейсов ПО и баз данных;

ü разработку предварительной версии пользовательской документации;

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

- Архитектура компонентов ПО должна соответствовать требованиям, предъявляемым к ним, а также принятым проектным стандартам и методам.

- Детальное проектирование ПО включает следующие задачи:

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

ü разработку и документирование детального проекта базы данных;

ü обновление (при необходимости) пользовательской документации;

ü разработку и документирование требований к тестам и плана тестирования компонентов ПО;

ü обновление плана интеграции ПО.

- Кодирование и тестирование ПО охватывают следующие задачи:

ü разработку (кодирование) и документирование каждого компонента ПО и базы данных, а также совокупности тестовых процедур и данных для их тестирования;

ü тестирование каждого компонента ПО и базы данных на соответствие предъявляемым к ним требованиям. Результаты тестирования компонентов должны быть документированы;

ü обновление (при необходимости) пользовательской документации;

ü обновление плана интеграции ПО.

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

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

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

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

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

Процесс эксплуатации.

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

· подготовительную работу;

· эксплуатационное тестирование;

· эксплуатацию системы;

· поддержку пользователей.

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

планирование действий и работ, выполняемых в процессе эксплуатации, и установку эксплуатационных стандартов;

определение процедур локализации и разрешения проблем, возникающих в процессе эксплуатации.

- Эксплуатационное тестирование осуществляется для каждой очередной редакции программного продукта, после чего она передается в эксплуатацию.

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

- Поддержка пользователей заключается в оказании помощи и консультаций при обнаружении ошибок в процессе эксплуатации ПО.

Процесс сопровождения.

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

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

Процесс сопровождения охватывает следующие действия:

· подготовительную работу;

· анализ проблем и запросов на модификацию ПО;

· модификацию ПО;

· проверку и приемку;

· перенос ПО в другую среду;

· снятие ПО с эксплуатации.

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

ü планирование действий и работ, выполняемых в процессе сопровождения;

ü определение процедур локализации и разрешения проблем, возникающих в процессе сопровождения.

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

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

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

ü утверждение выбранного варианта модификации.

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

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

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

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

Процесс документирования.

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

Процесс документирования включает следующие действия:

· подготовительную работу;

· проектирование и разработку;

· выпуск документации;

· сопровождение.

Процесс верификации.

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

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

Процесс верификации включает следующие действия:

· подготовительную работу;

· верификацию.

В процессе верификации проверяются следующие условия:

· непротиворечивость требований к системе и степень учета потребностей пользователей;

· возможности поставщика выполнить заданные требования;

· соответствие выбранных процессов ЖЦ ПО условиям договора;

· адекватность стандартов, процедур и среды разработки процессам ЖЦ ПО;

· соответствие проектных спецификаций ПО заданным требованиям;

· корректность описания в проектных спецификациях входных и выходных данных, последовательности событий, интерфейсов, логики и т.д.;

· соответствие кода проектным спецификациям и требованиям;

· тестируемость и корректность кода, его соответствие принятым стандартам кодирования;

· корректность интеграции компонентов ПО в систему;

· адекватность, полнота и непротиворечивость документации.

Процесс аттестации.

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

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

Процесс аттестации включает следующие действия:

· подготовительную работу;

· аттестацию.

Процесс совместной оценки.

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

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

Процесс совместной оценки включает следующие действия:

· подготовительную работу;

· оценку управления проектом;

· техническую оценку.

Процесс аудита.

Он представляет собой определение соответствия требованиям, планам и условиям договора. Аудит может выполняться двумя любыми сторонами, участвующими в договоре, когда одна сторона проверяет другую.

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

Процесс аудита включает следующие действия:

· подготовительную работу;

· аудит.

Процесс разрешения проблем.

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

Процесс разрешения проблем включает следующие действия:

1) подготовительную работу;

2) разрешение проблем.

Процесс управления.

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

Процесс управления включает следующие действия:

· инициирование и определение области управления;

· планирование;

· выполнение и контроль;

· проверку и оценку;

· завершение.

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

- Планирование подразумевает выполнение, как минимум, следующих задач:

ü составление графиков выполнения, работ;

ü оценку затрат;

ü выделение требуемых ресурсов;

ü распределение ответственности;

ü оценку рисков, связанных с конкретными задачами;

ü создание инфраструктуры управления.

Процесс усовершенствования.

Он предусматривает оценку, измерение, контроль и усовершенствование процессов ЖЦ ПО. Данный процесс включает следующие действия:

· создание процесса;

· оценку процесса;

· усовершенствование процесса.

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

Процесс обучения.

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

· подготовительную работу;

· разработку учебных материалов;

· реализацию плана обучения.

Лекция №13. Содержание и взаимосвязь процессов жизненного цикла ПО

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

Таблица 2.1. Содержание основных процессов ЖЦ ПО ИС (ISO/IEC 12207)

Содержание основных процессов ЖЦ ПО ИС (ISO/IEC 12207)

Процесс (исполнитель процесса) Действия Вход Результат Приобретение (заказчик) · инициирование · Подготовка заявочных предложений · Подготовка договора · Контроль деятельности поставщика · Приемка ИС · Решение о начале работ по внедрению ИС · Результаты обследования деятельности заказчика · Результаты анализа рынка ИС/ тендера · План поставки/ разработки · Комплексный тест ИС · Технико-экономическое обоснование внедрения ИС · Техническое задание на ИС · Договор на поставку/ разработку · Акты приемки этапов работы · Акт приемно-сдаточных испытаний Поставка (разработчик ИС) · инициирование · Ответ на заявочные предложения · Подготовка договора · Планирование исполнения · Поставка ИС · Техническое задание на ИС · Решение руководства об участии в разработке · Результаты тендера · Техническое задание на ИС · План управления проектом · Разработанная ИС и документация · Решение об участии в разработке · Коммерческие предложения/ конкурсная заявка · Договор на поставку/ разработку · План управления проектом · Реализация/ корректировка · Акт приемно-сдаточных испытаний Разработка (разработчик ИС) · Подготовка · Анализ требований к ИС · Проектирование архитектуры ИС · Разработка требований к ПО · Проектирование архитектуры ПО · Детальное проектирование ПО · Кодирование и тестирование ПО · Интеграция ПО и квалификационное тестирование ПО · Интеграция ИС и квалификационное тестирование ИС · Техническое задание на ИС · Техническое задание на ИС, модель ЖЦ · Техническое задание на ИС · Подсистемы ИС · Спецификации требования к компонентам ПО · Архитектура ПО · Материалы детального проектирования ПО · План интеграции ПО, тесты · Архитектура ИС, ПО, документация на ИС, тесты · Используемая модель ЖЦ, стандарты разработки · План работ · Состав подсистем, компоненты оборудования · Спецификации требования к компонентам ПО · Состав компонентов ПО, интерфейсы с БД, план интеграции ПО · Проект БД, спецификации интерфейсов между компонентами ПО, требования к тестам · Тексты модулей ПО, акты автономного тестирования · Оценка соответствия комплекса ПО требованиям ТЗ · Оценка соответствия ПО, БД, технического комплекса и комплекта документации требованиям ТЗ

Позднее был разработан и в 2002 г. опубликован стандарт на процессы жизненного цикла систем (ISO/IEC 15288 System life cycleprocesses). К разработке стандарта были привлечены специалисты различных областей: системной инженерии, программирования, управления качеством, человеческими ресурсами, безопасностью и пр. Был учтен практический опыт создания систем в правительственных, коммерческих, военных и академических организациях. Стандарт применим для широкого класса систем, но его основное предназначение - поддержка создания компьютеризированных систем.

Согласно стандарту ISO/IEC серии 15288в структуру ЖЦ следует включать следующие группы процессов:

1. Договорные процессы:

o приобретение (внутренние решения или решения внешнего поставщика);

o поставка (внутренние решения или решения внешнего поставщика).

2. Процессы предприятия:

o управление окружающей средой предприятия;

o инвестиционное управление;

o управление ЖЦ ИС;

o управление ресурсами;

o управление качеством.

3. Проектные процессы:

o планирование проекта;

o оценка проекта;

o контроль проекта;

o управление рисками;

o управление конфигурацией;

o управление информационными потоками;

o принятие решений.

4. Технические процессы:

o определение требований;

o анализ требований;

o разработка архитектуры;

o внедрение;

o интеграция;

o верификация;

o переход;

o аттестация;

o эксплуатация;

o сопровождение;

o утилизация.

5. Специальные процессы:

o определение и установка взаимосвязей исходя из задач и целей.

Стадии создания системы, предусмотренные в стандарте ISO/IEC 15288, несколько отличаются от рассмотренных выше. Перечень стадий и основные результаты, которые должны быть достигнуты к моменту их завершения, приведены в таблице 2.2.

Таблица 2.2. Стадии создания систем (ISO/IEC 15288)
№ п/п	Стадия	Описание
1	Формирование концепции	Анализ потребностей, выбор концепции и проектных решений
2	Разработка	Проектирование системы
3	Реализация	Изготовление системы
4	Эксплуатация	Ввод в эксплуатацию и использование системы
5	Поддержка	Обеспечение функционирования системы
6	Снятие с эксплуатации	Прекращение использования, демонтаж, архивирование системы

Примечание

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

Недели

Рис. Схема дифференциального резервного копирования для недельного цикла

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

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

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

• одноразовое копирование;

• простая ротация;

• «дед, отец, сын»;

• «Ханойская башня»;

• «10 наборов».

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

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

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

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

Схема ротации «Ханойская башня» для 5 наборов носителей

Каждый следующий по порядку набор используется в два раза реже, чем предыдущий. Таким образом, набор N1 перезаписывается каждые две недели, набор N2 - каждые четыре недели, и т. д.

Схема «10 наборов» также используется нечасто. Как следует из названия, схема рассчитана на использование 10 наборов носителей. Период из 40 недель делится на десять циклов. В пределах цикла за каждым набором закреплен один день недели. По прошествии четырехнедельного цикла осуществляется переход к следующему набору. Например, если в первом цикле понедельнику соответствовал набор 1, а за вторник - набор 2, то во втором цикле понедельнику будет соответствовать набор 2, а вторнику - набор 3. Такая схема позволяет равномерно распределить нагрузку и, как следствие, выровнять износ носителей.

Технология RAID

В достаточно крупных организациях для резервного копирования критически важных данных применяется технология RAID (Redundant Array of Independed Disks - избыточный массив независимых дисков), основанная на системе специальным образом сконфигурированных жестких дисков. Исходной целью создания технологии RAID являлось повышение производительности дисковой памяти за счет использования нескольких взаимосвязанных жестких дисков вместо одного.

Всего на сегодняшний день промышленными стандартами предусмотрено восемь уровней (модификаций) RAID:

RAID 1 - Mirrored Arrays

К этому классу (рис. 2) относятся подсистемы, применяющие методы зеркалирования и дублирования. Они отличаются максимальной стоимостью и избыточностью, зато в ряде случаев показывают самую высокую производительность среди классов 1-5. RAID 1 широко применяются в современных архитектурах систем хранения. Их основной недостаток - высокая цена, так как для любого приложения приходится удваивать объем необходимой дисковой памяти. Именно поэтому они наиболее эффективны в случае небольших объемов критической информации. Минимальное число дисков равно двум.

Лекция №5. Виды интерфейсов. Внешний интерфейс. Внутренний интерфейс.

Дата: 2019-02-02, просмотров: 398.

12 3 4 5 6 7 8 9 10 Следующая ⇒