Общесистемный подход к проектированию архитектуры системы
Одним из путей архитектурного проектирования является определение структуры создаваемой системы, состав компонентов, способов их представления и объединения. Фактически строится архитектура, которая состоит из четырех уровней, для каждого из которых определен набор компонентов, выполняюших определенную прикладную или общесистемную функции в системе (рис.4.4.).
| Прикладные программные системы |
| Специфические для бизнеса компоненты |
| Общесистемные компоненты Интерфейс с универсальными системами программной инженерии |
| Системные компоненты Интерфейс с оборудованием |
Рис.4.4. Поуровневая архитектура системы
Первый уровень – системные компоненты. Они осуществляют взаимодействие с периферийными устройствами оснащения компьютеров (принтеры, клавиатура, сканеры, манипуляторы и и т.п.), используются при построении операционных систем и не попадают в поле зрения разработчиков приложений.
Ко второму уровню относятся общесистемные компоненты. Они обеспечивают взаимодействие с универсальными сервисными системами, такими, как операционные системы, системы баз данных и знаний, системы управления сетями и т.п. Компоненты данного слоя используются во многих приложениях как их составляющие.
К третьему уровню относятся специфические компоненты определенной проблемной области. Они являются составляющими программных систем, предназначенных для решения ее задач (бизнес-задач). Их еще называют семейством программных систем.
И, наконец, к четвертому слою относятся прикладныепрограммные системы, которые построены для решения конкретных задач отдельных групп потребителей информации (офисные системы, системы бухгалтерского учета и др.) Они могут использовать компоненты упомянутых нижних уровней.
Компоненты любого из выделенных уровней используются, как правило, на своем уровне или на более верхнем. Для каждого уровня определен соответствующий набор профессиональных знаний, умений и навыков, необходимых для создания и использования его компонент, Этот набор определяет соответствующее разделение профессионалов в программной инженерии (системщики, прикладники, программисты и др.).
На уровне архитектурного проектирования система рассматривается как композиция компонент третьего уровня, имеющая доступ до компонентов первого и второго уровней.
Т.е. архитектурное проектирование – это разработка компонентов третьего уровня, определение входных и выходных данных, слоев иерархии компонентов и их связей.
Известными архитектурными схемами, определяющими стиль работы программной системы, являются распределенная, клиент-сервер и многоуровневая.
Распределенная схема обеспечивает взаимодействие компонентов системы, расположенных на разных компьютерах через стандартные интерфейсы и механизмы вызова, выполняемые промежуточными средами (COM/DCOM, CORBA, OLE, Java и др.): RPC (Remote Procedure Calls), RMI (Remote Method Invocation), tuple spaces, aplets и др.
В трехуровневой архитектурной схеме типа клиент/сервер сервер или брокеры объектных запросов (ORB) предоставляют общесистемный сервис и различные ресурсы, а также управляют распределенными объектами (компонентами). Архитектура такой системы может быть многоуровневой, если объекты предоставляют услуги и сами пользуются услугами других объектов, расположенных на разных уровнях этой схемы. Данная архитектурная схема отображает объектный стиль проектирования ПО, стиль моделирования проблемы с помощью UML и унифицированного процесса RUP [13, 14].
Объектный стиль проектирования ПО заключается в представлении объектной модели, абстрагировании ее сущностей объектами и в иерархической организации объектов с инкапсуляцией отдельных их возможностей.
Стиль моделирования UML заключается в декомпозиция проблемы на отдельные подсистемы (пакеты), каждая из которых отвечает проектным решениям и функциональным (и нефункциональным) требованиям и построении модели предметной области. Определяются носители интересов (акторов) и возможных прецедентов - последовательности действий акторов для получения результатов. В пакете задается модель прецендентов, описывающих важные функциональные возможности и представление требований. Разрабатываются варианты использования, в которых определяется состав объектов и принципы их взаимодействия. Для объектов определяются их структурные особенности – атрибуты и ассоциации, представляемые в диаграммах классов. Поведенческие аспекты системы отражаются диаграммами последовательности, в которых задается: последовательность взаимодействий объектов во времени, правила перехода от состояния к состоянию (диаграммы состояний) и к действию (диаграммы действий). Особенности кооперативного поведения объектов отражаются диаграммами кооперации.
Объекты проблемы и соответствующие им диаграммы использования задают общую архитектурную схему проблемы, в рамках которой осуществляется описание ее структуры и специфики поведения компонентов, для понимания того, как построена архитектура системы.
Стиль проектирования архитектуры в рамках унифицированного процесса RUP состоит в том, чтобы предоставить все виды деятельности, которые команда разработчиков системы использует на фазах процессов при построении моделей, способных охватить систему, определить ее структуру и поведение в нотации UML.
В зависимости от модели проектирования ПО (каскадная, спиральная, иерархическая и др.) созданная на начальном этапе архитектура ПО может расширяться и уточняться итеративно (например, при изменении требований заказчиком) на последующих этапах, что способствует получению полной и надежной архитектуры.
Результат проектирования – архитектура, т.е ее каркас и архитектурная инфраструктура, содержащая набор компонентов, из которых можно формировать некоторый конкретный вид архитектурной схемы для конкретной среды выполнения системы. Заканчивается проектирование описанием архитектуры ПО, в котором отображены зафиксированные проектные решения, принятые в ходе работы архитекторов системы, в том числе описание логической и физической структуры и данных, а также способов взаимодействия ее объектов.
В состав архитектура системы входят статические и динамические объекты, их связи и интерфейс между компонентами других архитектурных уровней. В ней представлены результаты анализа, декомпозиции системы на отдельные подсистемы и компоненты, а также набор справочников, словарей и т.д. Описание архитектуры имеет множество представлений, отражающих отдельные аспекты реализации системы. Каждое представление детализирует проблему и отдельные ее части, а также их связи и интерфейсы
Современные программные системы являются довольно сложными композициями разнообразных функций, вместе с тем имеются тысячи модулей, выполненных как готовые программные продукты, которые могут быть включены в любые программные системы для выполнения соответствующих им функций. При этом примитивные функции могут составлять композиции, которые выполняют определенные обобщенные функции. Они могут связываться в новые композиции и т.п. Для того, чтобы совокупность современных готовых к использованию средств можно было обозреть, введена определенная послойная их структуризация, суть которой состоит в следующем
На этапе инженерии требований создается совокупность объектов, которые привязываются к определенному сценарию для реализации определенных функций в этом сценарии.
В сложных программных системах количество выделенных объектов может насчитывать сотни, их композиции не будут иметь выразительного представления, даже с учетом того, что объекты разных сценариев могут совпадать, и потребуется дополнительный анализ для их отождествления.
Основными рекомендациями для декомпозиции сложной системы на компоненты или модули являются:
– четкое определение цели и возможность проверки их выполнимости;
– обязательное определение входные и выходные данных;
– задание иерархии, каждый уровень которой отвечает уровню абстракции системы и позволяет скрывать те детали, которые будут отработаны на следующих уровнях.
Такая пошаговая детализация принятия решений не только сводит решение сложной задачи к нескольким более простым, но и сосредоточиться на решении общих задач разработки компонентов отдельными членами команды с применением разных инструментальных средств, влияющих на эффективное их функционирование. При этом интерфейсы между компонентами должны быть согласованными для интеграции их в единую структуру.
Полученные совокупности объектов объединяются в подсистемы с учетом таких требований:
1) каждая создаваемая подсистема должна ассоциироваться с определенными элементами продукта инженерии требований (как, например, актер, сценарий, объект и т.п.);
2) необязательные функции или часто изменяемые функции выделятся в подсистемы так, чтобы каждая функция, для которой прогнозируются изменения требований, была как отдельная подсистема, связанная с одним актером (изменения вызывают актером);
3) интерфейс подсистемы понятен и имеет взаимосвязи с другими подсистемами. Каждая подсистема должна выполнять минимум услуг или функций и иметь фиксированное множество параметров интерфейса.
После отделения изменяемых и производных подсистемы проводится анализ связей и зависимостей, которые существуют между объектами с целью образования подсистем с внутренними связями и прозрачными внешними интерфейсами.
К способам объединения объектов в подсистему можно отнести:
– . сборка объектов в подсистему, которые ничем не связаны между собой;
– логическое объединение объектов в подсистему, которые являются функционально независимыми, имеют общее свойство, для которых можно установить определенное логическое отношение (например, одна и та же функция реализована для разных сред, как ввод данных для дисков и порта сети);
– объединение по времени, т.е. сборка объектов в подсистему, которые активизируются в общий промежуток времени;
– коммуникативное объединение, т.е. собираются объекты, которые имеют общий источник данных;
– процедурное объединение, т.е. в подсистему собираются объекты, которые последовательно передают друг другу управление;
– функциональное объединение объектов, каждый из которых входит в подсистему, выполняет часть работ для выполнения общей функции, которую выполняет подсистема.
Анализ приведенных выше способов объединения объектов в подсистемы с точки зрения стойкости к изменениям, показывает, что каждое изменение требует соответствующей корректировки минимального количества архитектурных компонент. Отсюда можно сделать вывод, что все способы не отличаются легкостью модификации требований. Что касается функционального объединения, то ему соответствуют определенные требования в модели.
Если вновь создаваемая система используется в готовой системе (унаследование системы), то ее целесообразно считать подсистемой создаваемой системы. Использование готовых компонентов или систем повторного использования снимает проблему дублирования и сокращает объем работ при проектировании архитектуры системы.
Повторным объектом может стать объект, поведение которого частично используется в нескольких подсистемах.
При выделении таких объектов и подсистем в большом проекте учитываются некоторые критерии. Например, если разработку будут ведут несколько групп разного уровня компетентности, или разного уровня обеспеченности ресурсами и они разъединены географически, то разделение на подсистемы ведется с учетом этих обстоятельств.
Результаты архитектурного проектирования представляются в нотациях, которые представлены в модели анализа требований средствами диаграмм (сущность-связь, переходов в состояния, потоков данных и действий, классов и т.п.). В указанных диаграммах задействованы объекты проекта, которые детализируют заданные требования к разработке и отображают решения, которые оказывают влияние на реализацию этих требований