Работа посвящена анализу программных средств, которые используются в ходе образовательного процесса. Описываются особенности экспертного подхода.
Ключевые слова: образовательный процесс, программа, экспертный метод, архитектура ПО.
Архитектура программного обеспечения (ПО) должна описывать использование или взаимодействие главных компонентов и элементов в приложении. Поиск подходящих алгоритмов обработки и структур данных или деталей реализации тех или иных компонентов — это вопросы проектирования. Архитектурные вопросы и вопросы проектирования часто пересекаются. Наиболее рационально может быть комбинирование этих двух областей, а не их разграничение.
Создавая архитектуру, нужно ориентироваться на такие изменения, для возможности адаптации их к требованиям, которые не были известны в начале процесса проектирования. Рекомендуется создавать открытую для изменений архитектуру. И определить: фундаментальные части архитектуры, ошибки в реализации которых несут наибольшие риски; части, которые вероятнее всего подвергнутся модификации, и возможность отложить реализацию этих частей на более поздние этапы разработки; каким образом будут проверяться допущения; условия, при которых, вероятно придется изменять дизайн. Основные принципы при разработке архитектуры: создание, для изменения (необходимо учесть, как со временем может потребоваться модернизировать приложение, для того чтобы оно соответствовало вновь появившимся задачам и требованиям и предусмотреть гибкость приложения, для соответствия новым требованиям); создание модели для снижения рисков и анализа (рекомендовано использование средств проектирования, систем моделирования; использование моделей и визуализации для общения и обмена информации (это поможет ускорить процесс проектирования и разработки и упростить принятие решений о вносимых изменениях); выявление ключевых инженерных решений [1] (выделение достаточного количества времени, в начале проекта, на ключевые инженерные решения, где наиболее вероятны ошибки, поможет создать более гибкий дизайн и в дальнейшем при внесении изменений с меньшей вероятностью потребует его полной переработки). При разработке архитектуры, необходимо оценить возможность использовать инкрементный и итеративный подходы. Начиная с базовой архитектуры, и воссоздавая полную картину, далее прорабатывать различные варианты в процессе итеративного тестирования и доработки. Усложнение дизайна должно происходить постепенно, за счет многократных пересмотров, для того чтобы быть уверенным в правильности принятых наиболее ключевых решений и лишь после этого сосредотачиваться на деталях. Наиболее частой ошибкой является переход к деталям, не имея грамотно выработанных ключевых решений, из-за ошибок в допущениях или неспособности корректно оценить свою архитектуру.
К основным архитектурным стилям относятся, например, следующие стили. Компонентная архитектура, в которой описывается подход к разработке и проектированию системы используя методы проектирования ПО. В этом подходе разделение дизайна на отдельные логические или функциональные компоненты, относящиеся к четко определенным интерфейсам, содержащим методы свойства и события, представляется особо важным и создает более высокий уровень абстракции, при сравнении с объектно-ориентированным стилем [2], также не концентрируется внимание на вопросах общего состояния или протоколах связи. Основные принципы — это использование компонентов, обладающих такими характеристиками как: замещаемость; возможность повторного использования; расширяемость; независимость от среды и контекста; независимость от других компонентов; инкапсуляция. Применяется чаще всего при создании компонентов пользовательского интерфейса; также при создании ресурсоемких компонентов доступ, к которым осуществляется не часто, а активация выполняется «на лету»; и для создания компонентов с очередью вызовов методов, которые могут асинхронно выполняться благодаря применению очереди сообщений, для пересылки и хранения. К преимуществам подхода можно отнести: простоту разработки; простоту развертывания; упрощение системы с технической точки зрения; меньшую стоимость разработки и обслуживания; возможность повторного использования. Многоуровневая архитектура группирует связанную функциональность ПО в различных слоях, выстраивая их вертикально друг над другом, функциональность объединяется по общей ответственности или роли. При этом слои слабо связаны между собой и между ними осуществляют обмен данными. Слои приложения могут физически располагаться на одном компьютере или на разных. Общие принципы: инкапсуляция; абстракция; возможность повторного использования слоя; высокая связанность внутри слоя; слабая связанность между слоями; четкое разделение функциональности.
К преимуществам можно отнести: масштабируемость; гибкость; доступность; удобство поддержки.
Примеры приложений: Веб-приложение с высокими требованиями к безопасности, насыщенный клиент.
Клиент/серверная архитектура дает описание распределенным системам, состоящим из отдельных сервера и клиента и сети, которая их соединяет. Примерами приложения могут быть: веб-приложение, выполняемое во внутренних сетях компании или в Интернет, настольные приложения, работающие с удаленными ресурсами. Основные преимущества: простота обслуживания, большая безопасность, централизованный доступ к данным, к минусам можно отнести сложность расширяемости, масштабирования и зависимость от центрального сервера. Основанная на шине сообщений архитектура описывает вариант использования программной системы, в которой отправляются и принимаются сообщения по одному или нескольким каналам связи, позволяя взаимодействовать приложениям без детальных знаний друг о друге.
Взаимодействие реализуется путем передачи сообщений через шину, как правило асинхронной. Типично использование маршрутизатора сообщений или шаблона Основные преимущества: гибкость, расширяемость, слабое связывание, масштабируемость, простота приложений, невысокая сложность. Сервисно-ориентированная архитектура (СОА, SOA) дает возможность создавать приложения использующие программные сервисы и позволяет предоставлять функциональность ПО в виде набора сервисов. Сервисы слабо связаны благодаря использованию основанных на стандартах интерфейсов, которые можно вызвать опубликовать и обнаружить. СОА позволяет упаковать бизнес-процессы в сервисы, поддерживающие возможность взаимодействия и использования различных форматов данных и протоколов.
Основные принципы: Совместимость основана на политике, сервисы слабо связаны, автономны, совместно используют контракт, схему, но не класс, сервисы могут быть распределены. Преимущества: абстракция; возможность обнаружения и автоматического подключения через интерфейс, согласование предметных областей, рационализация, возможность взаимодействия.
Литература:
- Москальчук Ю. И. Проблемы оптимизации инновационных процессов в организациях. Моделирование, оптимизация и информационные технологии. 2013. № 2. С.10.3
- Преображенский Ю. П. Формулировка и классификация задач оптимального управления производственными объектами. Вестник Воронежского государственного технического университета. 2010. Т. 6. № 5. С. 99–102.
