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

Обновлено: 05.07.2024

Аннотация: Рассматривается понятие архитектуры ПО, влияние архитектуры на свойства ПО, а также методы оценки архитектуры. Рассказывается об основных элементах унифицированного языка моделирования UML.

Анализ области решений

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

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

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

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

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

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

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

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

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

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

Моделировать определенные условия полета и создавать некоторые события, к которым относятся следующие:

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

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

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

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

Рубрика	Программирование, компьютеры и кибернетика
Вид	реферат
Язык	русский
Дата добавления	15.02.2014
Размер файла	85,0 K

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

1. Что такое архитектура программного обеспечения?

1.1 Языки описания архитектуры

1.3 Базовые фреймворки для архитектуры ПО

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

3. Разработчики структуры программного обеспечения

4. Навыки для разработчика программного обеспечения

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

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

На все эти параметры оказывает влияние архитектура программного обеспечения, которая является темой данной статьи. В статье рассматриваются "преимущественно-программные системы", которые IEEE определяет следующим образом:

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

1. Что такое архитектура программного обеспечения?

Архитектура программного обеспечения (англ. software architecture) -- это структура программы или вычислительной системы, которая включает программные компоненты, видимые снаружи свойства этих компонентов, а также отношения между ними.

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

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

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

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

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

1.1 Языки описания архитектуры

Языки описания архитектуры (ADLS) используются для описания архитектуры программного обеспечения. Различными организациями было разработано несколько различных ADLS, в том числе AADL (стандарт SAE), Wright (разработан в университете Carnegie Mellon), Acme (разработан в университете Carnegie Mellon), xADL (разработан в UCI), Darwin (разработан в Imperial College в Лондоне), DAOP-ADL (разработан в Университете Малаги), а также ByADL (Университет L'Aquila, Италия). Общими элементами для всех этих языков являются понятия компонента, коннектора и конфигурации.

1.2 Виды (views)

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

Вид разработки (development)/структурный

Вид параллельности выполнения/процесс/поток

Физический вид/вид развертывания

Вид с точки зрения действий пользователя

Вид с точки зрения данных

1.3 Базовые фреймворки для архитектуры ПО (software architecture frameworks)

Существуют следующие фреймворки, относящихся к области архитектуры ПО:

RM-ODP (Reference Model of Open Distributed Processing)

Service-Oriented Modeling Framework (SOMF)

Такие примеры архитектур как фреймворк Захмана (Zachman Framework), DODAF и TOGAF относятся к области архитектуры предприятия (enterprise architectures).

2. В чем важность архитектуры программного обеспечения?

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

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

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

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

3. Чем занимаются разработчики архитектуры программного обеспечения?

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

Рис. 1. -- конфликтные требования типичного клиента

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

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

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

Рис. 2. -- поэтапный процесс архитектурного проектирования

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

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

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

4. Какие навыки требуются разработчику архитектуры программного обеспечения?

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

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

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

Литература

2. Богумирский Б.С. Руководство пользователя ПЭВМ: В 2-х ч. - СПб.: Ассоциация OILCO, 1992. - 357 с.

3. Головкин Б.А. Параллельные вычислительные системы. М.: Наука, 1980. - 520 с.

5. Касаткин А.И., Вальвачев А.Н. Профессиональное программирование на языке Си: От Turbo C к Borland С++: Мн.: Выш.шк., 1992. -240 с.

6. Кручинин С. Архитектура компьютера. Hard и Soft №4 1995.

Подобные документы

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

курсовая работа [253,3 K], добавлен 23.04.2011

Обзор существующих объектных архитектур. Архитектура программного обеспечения. Создание веб-сервиса "Библиотека", предоставляющего механизмы работы с данными на стороне клиентского приложения. WEB-сервис и трехуровневая архитектура в основе приложения.

лабораторная работа [1,5 M], добавлен 16.06.2013

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

курсовая работа [401,4 K], добавлен 12.01.2015

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

курсовая работа [1,2 M], добавлен 30.04.2012

Архитектура предприятия как инструмент управления изменениями. Проектирование архитектуры данных по TOGAF. Описание потоков и источников данных. Синхронизация данных по времени. Описание этапов и рекомендации по использованию инструментов проектирования.

дипломная работа [2,8 M], добавлен 09.09.2017

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

реферат [100,7 K], добавлен 20.09.2009

Цели и задачи программной инженерии. Понятие программного обеспечения. Шесть принципов эффективного использования программного обеспечения. Виды программного обеспечения: общесистемное, сетевое и прикладное. Принципы построения программного обеспечения.

Архитектура программного обеспечения ( реферат , курсовая , диплом , контрольная )

1. Что такое архитектура программного обеспечения?

1.1 Языки описания архитектуры

1.3 Базовые фреймворки для архитектуры ПО

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

3. Разработчики структуры программного обеспечения

4. Навыки для разработчика программного обеспечения Список литературы

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

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

1. Что такое архитектура программного обеспечения?

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

1.1 Языки описания архитектуры

Языки описания архитектуры (ADLS) используются для описания архитектуры программного обеспечения. Различными организациями было разработано несколько различных ADLS, в том числе AADL (стандарт SAE), Wright (разработан в университете Carnegie Mellon), Acme (разработан в университете Carnegie Mellon), xADL (разработан в UCI), Darwin (разработан в Imperial College в Лондоне), DAOP-ADL (разработан в Университете Малаги), а также ByADL (Университет L’Aquila, Италия). Общими элементами для всех этих языков являются понятия компонента, коннектора и конфигурации.

1.2 Виды (views)

Архитектура ПО обычно содержит несколько видов, которые аналогичны различным типам чертежей в строительстве зданий. В онтологии, установленной ANSI / IEEE 1471—2000, виды являются экземплярами точки зрения, где точка зрения существует для описания архитектуры с точки зрения заданного множества заинтересованных лиц.

1.3 Базовые фреймворки для архитектуры ПО (software architecture frameworks)

Существуют следующие фреймворки, относящихся к области архитектуры ПО:

RM-ODP (Reference Model of Open Distributed Processing)

Service-Oriented Modeling Framework (SOMF)

2. В чем важность архитектуры программного обеспечения?

3. Чем занимаются разработчики архитектуры программного обеспечения?

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

Рис. 2. — поэтапный процесс архитектурного проектирования

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

4. Какие навыки требуются разработчику архитектуры программного обеспечения?

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

2. Богумирский Б. С. Руководство пользователя ПЭВМ: В 2-х ч. — СПб.: Ассоциация OILCO, 1992. — 357 с.

3. Головкин Б. А. Параллельные вычислительные системы. М.: Наука, 1980. — 520 с.

5. Касаткин А. И. , Вальвачев А. Н. Профессиональное программирование на языке Си: От Turbo C к Borland С++: Мн.: Выш.шк., 1992. -240 с.

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

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

Рисунок 1 – Pipes and Filters

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

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

Рисунок 2 – Принцип ROT13

Его достаточно просто реализовать с помощью стандартной терминальной утилиты Unix tr:

А вот код на Python:

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

В качестве примера использования этой архитектуры может служить оболочка UNIX Shell, одним из дизайнеров которой был Дуглас Макилрой (Douglas McIlroy). Другим примером может стать архитектура компилятора, если рассматривать её как последовательность фильтров: лексера, парсера, семантического анализатора и генератора кода.

Дополнительную информацию по этому типу архитектуры можно найти здесь и здесь.

Многоуровневая архитектура

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

Рисунок 2 – Многоуровневая архитектура

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

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

Скотта Хансельмана (Scott Hanselman), Хендри Люка (Hendry Luk), Йоханнеса Бродвалла (Johannes Brodwall).

Архитектура, управляемая событиями (EDA)

Это популярный адаптивный паттерн, широко используемый для создания масштабируемых систем. Чтобы ознакомиться с принципами событийно-ориентированной архитектуры, можете посмотреть вот это видео от Complexity Academy:

Рисунок 3 – Событийно-ориентированная архитектура

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

Посредник может быть реализован несколькими способами. Самый просто способ – это воспользоваться фреймворками для интеграции Apache Camel, Spring Integration или Mule ESB. Для больших приложений, которым требуется более сложные функции управления, вы можете реализовать посредника, используя концепцию управления бизнес-процессами (например движок jBPL).

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

Подробнее о событийно-ориентированной архитектуре можно почитать здесь.

Микроядерная архитектура

Паттерн состоит из двух компонентов: основной системы (ядра) и плагинов. Ядро содержит минимум бизнес-логики, но руководит загрузкой, выгрузкой и запуском необходимых плагинов. Таким образом, плагины оказываются несвязанными друг с другом.

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

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

Подробнее о микроядерной архитектуре можно узнать здесь и здесь.

Микросервисная архитектура

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

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

Дополнительные материалы

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

: серия статей об архитектурах программного обеспечения; : лучшие книги по теме архитектуры программного обеспечения; : пять лучших книг по архитектуре ПО, которые должен прочесть каждый; : блог Вернера Вогелса (Werner Vogels), технического руководителя Amazon, о построении масштабируемых и надежных распределённых систем; : лучшие книги, статьи и блоги для архитекторов ПО.

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

Содержание

3. Архитектура компонента установки и поддержки серверного программного обеспечения

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

5. Инструменты администрирования

Работа содержит 1 файл

курсовик.docx

3. Архитектура компонента установки и поддержки серверного программного обеспечения

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

5. Инструменты администрирования

Данная курсовая работа посвящена теме "Серверное программное обеспечение". Эта тема в настоящее время является не только актуальной, но и довольно интересной. В ней рассматриваются теоретические вопросы программного обеспечения, а также и практическая часть.

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

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

Объектом исследования данного курсового проекта является программное обеспечения

Предметом – серверное программное обеспечение.

Теоретическая часть

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

В теоретической части все рассматривается на примерах серверов (установка, утилиты, администрирование, настройка, управление).

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

Windows NT Server – сетевая операционная система;
System Management Server – система администрирования сети;
SQL Server – сервер управления базами данных;
SNA Server – сервер для соединения с хост-компьютерами;
Exchange Server – сервер системы электронной почты;
Internet Information Server – сервер для работы с Internet.

Windows NT/2000 Server способна обеспечить совместное использование файлов, печатающих устройств, предоставить услуги по соединению с рабочими станциями (клиентскими компьютерами) и другой сервис.

Windows NT Server целесообразно использовать в случаях, когда предполагается наличие нескольких процессоров (обычно до четырех). Кроме того, Windows NT Server обеспечивает совместное использование ресурсов многими пользователями, возможность соединения с удаленными сетями через сервис удаленного доступа – RAS (Remote Access Service), а также через средства связи с сетями других фирм (Novell, Digital Pathworks и Apple).

System Management Server (SMS) позволяет сетевому администратору централизованно управлять всей сетью. При этом обеспечивается возможность администрирования каждого компьютера, подключенного к сети, включая установленное на нем программное обеспечение. SMS предоставляет следующий сервис:

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

Internet Information Server обеспечивает возможность создания Web-, FTP- и Gopher-серверов для сети Internet, поддерживает управление ими с помощью встроенной программы Internet Service Manager.

Архитектура компонента установки и поддержки серверного программного обеспечения

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

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

Компоненту установки и поддержки ПО для работы требуется наличие Windows 2000 Server, службы каталогов Active Directory, групповой политики и ОС Windows 2000 Professional. За подробной информацией об архитектуре групповой политики и ее объектах обратитесь к технической документации по групповой политике.

Компоненты Windows 2000 Server

клиент сервер инструмент администрирование установка

В Таблице 2 представлены серверные компоненты установки и поддержки ПО

Этап подготовки программного обеспечения

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

Этап распространения программного обеспечения

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

Рисунок 2 – Этап распространения ПО с точки зрения администратора

Для создания точки распространения ПО администраторы выполняют следующие действия:

Создают необходимые сетевые папки
Разрешают общий доступ пользователям к этим папкам
Копируют программное обеспечение на созданные общие сетевые ресурсы
Дают пользователям разрешение на чтение для общих сетевых ресурсов

Примечание: Многие программные продукты обладают возможностью административной установки, которая подготавливает приложение для установки из точки распространения ПО. Во время административной установки производится распаковка сжатых файлов, администратор получает возможность ввести регистрационный ключ, а также выполняются другие подготовительные действия. Например, для установки Microsoft Office 2000 в точку распространения ПО необходимо запустить программу установки из командной строки с параметром /a.

Этап целевого назначения программного обеспечения

Область управления установкой программного обеспечения задается при помощи групповой политики – именно таким образом определяется, для каких пользователей будет производиться установка. Администраторы задействуют расширение Установка программ (Software Installation) для распространения программного обеспечения пользователям и компьютерам, которыми управляет объект групповой политики, связанный с доменом, сайтом или подразделением. Для этого администратору нужно запустить оснастку Групповая политика (Group Policy) и выбрать объект, которым необходимо управлять. Затем в узле Конфигурация пользователя (User Configuration) или в узле Конфигурация компьютера (Computer Configuration) нужно раскрыть узел Конфигурация программ (Software Settings) и установить требуемые параметры в расширении Установка программ (Software Installation).Компонент установки и поддержки ПО в Windows 2000 позволяет администраторам назначать или публиковать программное обеспечение. Администраторы назначают программное обеспечение в тех случаях, когда оно необходимо пользователям для выполнения их рабочих обязанностей. Например, если все работники должны пользоваться электронной почтой, администратор может назначить им почтовую программу.

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

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

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

Действия, которые нужно выполнить в расширении Установка программ (Software Installation) для назначения приложения по сути очень похожи на действия, выполняемые в этом расширении для публикации приложения. За подробной информацией об этих действиях обратитесь к разделам интерактивной справки Windows 2000 Server, посвященным расширению Установка программ, а также к Пошаговому руководству по установке и поддержке программного обеспечения Step-by-Step Guide to Software Installation and Maintenance (EN).

Администратор назначает или публикует программное обеспечение при помощи оснастки Групповая политика (Group Policy) и расширения Установка программ (Software Installation). Как правило, для этого необходимо выполнить все или некоторые действия, перечисленные ниже.

2. Откройте оснастку Групповая политика (Group Policy) для создания нового объекта групповой политики или внесения изменений в уже существующий объект. Если продолжить рассмотрение примера из пункта 1, то для открытия оснастки Групповая политика Вам потребуется выполнить следующие действия. Щелкните правой кнопкой мыши по подразделению Accounts и выберите команду Свойства (Properties), а затем в открывшемся диалоговом окне Свойства: Accounts перейдите на вкладку Групповая политика (Group Policy). Для создания нового объекта групповой политики нажмите кнопку Создать (New), либо внесите изменения в существующий объект. Для этого выберите его из списка Ссылки на объекты групповой политики (Group Policy Object Links) и нажмите кнопку Изменить (Edit).

Читайте также: