VI Международная студенческая научная конференция Студенческий научный форум - 2014

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• IEEE 1016-1998 Recommended Practice for Software Design Descriptions.

• IEEE 1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems .

Основное содержание данного стандарта сводится к нужному определению набора всех понятий, связанных с архитектурой программной системы. Изначально само понятие термина архитектуры как набора основных принципов организации всей системы, воплощенных в наборе ее различных компонентов, всех связях между ними, а также ними и окружением системы, а также многих принципов проектирования и развития всей системы. Данное определение, делает основной акцент не на наборе всех структур в основе архитектуры, а на многих принципах ее создания. Стандарт IEEE 1471 показывает все представление архитектуры, как организованный набор документов, который должен описывать архитектуру с точки зрения определенной части всех заинтересованных организаций с помощью набора моделей. Архитектура должна иметь по возможности несколько представлений, отражающих различные интересы всевозможных групп . Этот стандарт рекомендует все представления фиксировать отраженные в нем мнения и интересы, роли всех заинтересованных лиц, имеющее интересы в таком взгляде на данную систему, причины, объясняющую всю важность такого рассмотрения системы и различную служебную информацию обо всех источниках данной информации, датах создания её документов и пр. Стандарт IEEE 1471 отмечает необходимость использование архитектуры для решения таких задач, как следующие:

• проведение анализа обзоров и оценку качества системы;

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

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

• разработка и моделирование некоторых фрагментов системы;

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

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

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

• выработка различных параметров приемки системы при ее сдаче в эксплуатацию;

• анализ альтернативных проектов всей системы.

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

К большинству человеческих аспектов принадлежат:

А) эволюционное построение архитектуры;

Б) социальные особенности возможного применения различных шаблонов проектирования;

В) существенное влияние человеческих качеств на выполнение функций архитектора.

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

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

Библиографический список

1. Электронный ресурс http://panda.ispras.ru/~RedVerst/RedVerst/Lectures%20and%20training%20courses/Software%20Development%20Technologies/All.pdf

2. Электронный ресурс http://www.intuit.ru/studies/courses/64/64/lecture/1876?page=2

3. Электронный ресурс http://dic.academic.ru/dic.nsf/fin_enc/20189

4. Электронный ресурс http://venec.ulstu.ru/lib/disk/2008/Sosnin_2008.pdf

5. Электронный ресурс http://window.edu.ru/library/pdf2txt/174/56174/27137/page2