Выбор архитектуры программного обеспечения

В технологии программирования нет четкого определения архитектуры ПО. Приведем некоторые из встречающихся в литературе.

Архитектурой программного обеспечения называют совокупность базовых концепций (принципов) его построения [1].

Архитектура ПС — это его строение, как оно видно (или должно быть видно) извне его, т. е. представление ПС как системы, состоящей из некоторой совокупности взаимодействующих подсистем [37].

Архитектура программы или компьютерной системы — это структура или структуры системы, которые включают элементы программы, видимые извне свойства этих элементов и связи между ними [50].

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

которые взаимодействуют через интерфейсы, включают классы, компоненты и подсистемы [51].

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

поддержки и обслуживания [52].

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

С точки зрения количества пользователей, работающих с одной копией ПО, различают:

• однопользовательскую архитектуру;

• многопользовательскую (сетевую) архитектуру.

Кроме того, в рамках однопользовательской архитектуры различают [1]:

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

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

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

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

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

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

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

справочную систему [1];

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

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

Многопользовательскую архитектуру реализуют системы, построенные по принципу «клиент — сервер».

Урок 18.

Предмет: Технология разработки программных продуктов.

Тема : Фазы процесса разработки ПО.Абстракции.

Цели:

Образовательная

Ознакомление с фазами процесса разработки ПО. Абстракции.

Развивающая:

Развивать умение слушать других, делать выводы и обобщать полученные знания

Воспитательная:

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

Межпредметные связи:

- Английский язык

- Операционные системы

- Информационные технологии

- Основы алгоритмизации и программирования

Оборудование: доска, мел, письменные принадлежности, проектор, ПК

Тип урока: комбинированный

Метод обучения: Объяснительно иллюстративный

Ход урока:

1.Организационный момент

- Проверка готовности кабинета

- Объявление темы

2. Постановка цели урока

3.Повторение пройденного материала

Функциональные требования

Эксплуатационные требования

Выбор архитектуры программного обеспечения

4.Сообщение новых знаний

Технология разработки ПО

Требования к современным технологиям разработки ПО

Этапы проектирования сложных программных средств

Использование абстракций и спецификаций при разработке программ

5. Восприятие и осознание учащимися нового материала

6. Осмысление обобщение и систематизация знаний

7. Подведение итогов урока и постановка домашнего задания

Выучить содержимое темы

Орлов С.А. стр. С.36-40

Ответить на вопросы:

1.2. Технология разработки ПО

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

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

1.3. Требования к современным технологиям разработки ПО

1. ТРПО должна обеспечивать отторжимость ПО от разработчика. Это необходимо для грамотного сопровождения, модификации и воспроизводства ПП в других условиях эксплуатации.
2. ТРПО и средства ее поддержки должны обеспечивать целенаправленную работу прежде всего коллектива программистов, а не отдельных исполнителей. Основные части любой современной технологии: сетевое планирование, система формализованных поручений и эффективный контроль за их исполнением.
3. ТРПО должна обеспечивать автоматизацию всех этапов работы коллектива программистов.
4. ТРПО не должна быть связана с языком программирования, т.к. не он является определяющим звеном ТРПО.
5. ТРПО должна быть простой в освоении, с автоматизированными средствами подсказки и обучения.
6. ТРПО должна иметь средства фиксации всех действий в процессе изготовления программного продукта (автоматизированное хранение системных журналов, дневников разработки). Это необходимо для восстановления состояния процесса разработки на любом его этапе (при комплексной отладке и сопровождении ПО).
7. ТРПО должна обеспечивать пользователю ПП доступ к документации на продукт (техническому описанию, инструкции пользователю, инструкции по эксплуатации и т.п.) на магнитных носителях. Доступ должен быть простым и автоматизированным. Работа пользователя должна обеспечиваться информационно-справочной системой.

1.4. Этапы проектирования сложных программных средств

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

1) программы с малой длительностью эксплуатации – создаются в основном для решения научных и инженерных задач, для получения конкретных результатов вычислений; они содержат от 1 до 10000 команд, разрабатываются одним специалистом или малой группой, не предназначены для тиражирования и передачи; жизненный цикл таких программ не превышает 3-х лет, время эксплуатации практически равно 0;

2) программы с большой длительностью эксплуатации – создаются для регулярной обработки информации и управления; такие программы содержат от 1 до 1000000 команд, обладают свойством независимости от разработчика, возможностью модификации в процессе сопровождения и использования различными программистами, допускают тиражирование, сопровождаются документацией как промышленное изделие, являются отчуждаемыми; жизненный цикл таких программ составляет 10 – 20 лет, из них 70 – 90 % занимает время эксплуатации.

Все последующее изложение ориентировано на ПО второй группы.

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

1.5. Содержание основных фаз жизненного цикла ПО

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

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

Спецификация – описание на языке разработчика внешне известных характерных особенностей поведения системы. Функциональная спецификация включает в себя:

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

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

Фаза 2. Проектирование.Входной информацией для проектирования являются спецификации, написанные по требованиям пользователя.

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

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

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

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

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

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

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

Примечания. Комментарии: временные характеристики, необычные ситуации, приводящие к ошибкам и т.п.

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

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

Фаза 4. Внедрение.Полное, упорядоченное, координируемое пользователем приобщение к реальной среде новой или измененной системы. Подтверждение соответствия требованиям.

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

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

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