Практикум для выполнения лабораторных работ состоит из семнадцати лабораторных работ по дисциплинам Спецификация, архитектура и проектирование программных систем
 Скачать 2.9 Mb.
|
|
Лабораторная работа 8. Проектирование архитектуры программного комплекса Цель работы Целью работы является изучение базовых принципов и шаблонов построения архитектуры приложений, выбор стра- тегии и шаблона проектирования, которые помогут при про- ектировании слоев, компонентов и сервисов решения, а также визуальное проектирование архитектуры приложения с ис- пользованием Microsoft Visio. Теоретические сведения Создание архитектуры приложения — это процесс фор- мирования структурированного решения, отвечающего всем техническим и операционным требованиям и обеспечивающе- го оптимальные общие атрибуты качества, такие как произво- дительность, безопасность и управляемость. Он включает принятие ряда решений на основании широкого диапазона факторов. Каждое из этих решений может иметь существенное влияние на качество, производительность, удобство обслужи- вания и общий успех приложения. Как и любая другая сложная структура, программное обес- печение (ПО) должно строиться на прочном фундаменте. Непра- вильное определение ключевых сценариев, неправильное проектирование общих вопросов или неспособность выявить долгосрочные последствия основных решений могут поставить под угрозу все приложение. Современные инструменты и плат- формы упрощают задачу по созданию приложений, но не устра- няют необходимости в тщательном их проектировании на основании конкретных сценариев и требований. Неправильно выработанная архитектура обусловливает нестабильность ПО, невозможность поддерживать существующие или будущие биз- нес-требования, сложности при развертывании или управлении в среде производственной эксплуатации. Проектирование систем должно осуществляться с учетом потребностей пользователя, системы (ИТ-инфраструктуры) и бизнес-целей. Для каждой из этих составляющих определяются ключевые сценарии и выделяются важные параметры качества 84 (например, надежность или масштабируемость), а также ос- новные области удовлетворенности и неудовлетворенности. По возможности необходимо выработать и учесть показатели успешности в каждой из этих областей. Основное назначение архитектуры — описание исполь- зования или взаимодействия основных элементов и компо- нентов приложения. Выбор структур данных и алгоритмов их обработки или деталей реализации отдельных компонентов являются вопросами проектирования. Часто вопросы архитек- туры и проектирования пересекаются. Вместо того чтобы вводить жесткие правила, разграничивающие архитектуру и проектирование, имеет смысл комбинировать эти две области. В некоторых случаях, принимаемые решения, очевидно, явля- ются архитектурными по своей природе, в других — больше касаются проектирования и реализации архитектуры. Приступая к работе над архитектурой приложения, необ- ходимо помнить об основных принципах проектирования. Это поможет создать архитектуру, которая будет следовать прове- ренным подходам, обеспечит минимизацию затрат, простоту обслуживания, удобство использования и расширяемость. Рассмотрим основные принципы: 1. Разделение функций. Разделите приложение на от- дельные компоненты, по возможности, минимальным пере- крытием функциональности. Важным фактором является предельное уменьшение количества точек соприкосновения, что обеспечит высокую связность (high cohesion) и слабую связанность (low coupling). Неверное разграничение функцио- нальности может привести к высокой связанности и сложно- стям взаимодействия, даже несмотря на слабое перекрытие функциональности отдельных компонентов. 2. Принцип единственности ответственности. Каждый отдельно взятый компонент или модуль должен отвечать только за одно конкретное свойство/функцию или совокуп- ность связанных функций. 3. Принцип минимального знания (также известный как Закон Деметера (Law of Demeter, LoD)). Компоненту или объекту не должны быть известны внутренние детали других компо- нентов или объектов. 4. Не повторяйтесь. Намерение должно быть обозначено только один раз. В применении к проектированию приложения 85 это означает, что определенная функциональность должна быть реализована только в одном компоненте и не должна дублироваться ни в одном другом компоненте. 5. Минимизируйте проектирование наперед. Проекти- руйте только то, что необходимо. В некоторых случаях, когда стоимость разработки или издержки в случае неудачного дизайна очень высоки, может потребоваться полное предвари- тельное проектирование и тестирование. В других случаях, особенно при гибкой разработке, можно избежать масштабно- го проектирования. Если требования к приложению четко не определены, или существует вероятность изменения дизайна со временем, старайтесь не тратить много сил на проектирова- ние раньше времени. Цель архитектора ПО при проектировании приложения или системы — максимальное упрощение дизайна через его разбиение на функциональные области. Например, пользова- тельский интерфейс (user interface, UI), выполнение бизнес- процессов или доступ к данным — все это разные функцио- нальные области. Компоненты в каждой из этих областей должны реализовывать данную конкретную функциональ- ность и не должны смешивать в себе код разных функцио- нальных областей. Так в компонентах UI не должно быть кода прямого доступа к источнику данных; для извлечения данных в них должны использоваться либо бизнес-компоненты, либо компоненты доступа к данным. Также необходимо проанализировать соотношение за- трат/выгод для инвестиций в приложение. В некоторых случаях может быть целесообразным упростить структуру и разрешить, например, связывание элементов UI с результирующими данны- ми. В общем, оценивайте реализацию функциональности также и с коммерческой точки зрения. Далее приводятся обобщенные рекомендации, которые помогут учесть широкий диапазон фак- торов, влияющих на проектирование, реализацию, развертыва- ние, тестирование и обслуживание приложения. Архитектура программного обеспечения заключает в себе ряд важных решений об организации программной системы, среди которых выбор структурных элементов и их интерфейсов, составляющих и объединяющих систему в единое целое; пове- дение, обеспечиваемое совместной работой этих элементов; организацию этих структурных и поведенческих элементов 86 в более крупные подсистемы, а также архитектурный стиль, которого придерживается данная организация. Выбор архитектуры ПО также касается функционально- сти, удобства использования, устойчивости, производительно- сти, повторного использования, понятности, экономических и технологических ограничений, эстетического восприятия и поиска компромиссов. Архитектурный стиль, иногда называемый архитектур- ным шаблоном — это набор принципов, высокоуровневая схема, обеспечивающая абстрактную инфраструктуру для семейства систем. Архитектурный стиль улучшает секциони- рование и способствует повторному использованию дизайна благодаря обеспечению решений часто встречающихся про- блем. Архитектурные стили и шаблоны можно рассматривать как набор принципов, формирующих приложение. Понимание архитектурных стилей обеспечивает не- сколько преимуществ. Самое главное из них — общий язык. Также они дают возможность вести диалог, не касаясь техно- логий, т. е. обсуждать схемы и принципы, не вдаваясь в детали. Например, архитектурные стили позволяют сравнивать схему клиент/сервер с n-уровневой схемой приложения. Архитек- турные стили можно организовать по их фокусу. В табл. 8.1 приведен список типовых архитектурных стилей, и дается краткое описание каждого из них. Таблица 8.1 Типовые архитектурные стили Архитектурный стиль/парадигма Описание Клиент/сервер Система разделяется на два приложения, где клиент выполняет запросы к серверу. Во многих случаях в роли сервера выступает база данных, а логика приложения представлена процедура- ми хранения Компонентная архитектура Дизайн приложения разлагается на функцио- нальные или логические компоненты с возмож- ностью повторного использования, предоставляющие тщательно проработанные интерфейсы связи 87 Окончание табл. 8.1 Архитектурный стиль/парадигма Описание Дизайн на основе предметной области 4 Объектно-ориентированный архитектурный стиль, ориентированный на моделирование сферы деловой активности и определяющий бизнес-объекты на основании сущностей этой сферы Многослойная архитектура Функциональные области приложения разде- ляются на многослойные группы (уровни) Шина сообщений Архитектурный стиль, предписывающий ис- пользование программной системы, которая может принимать и отправлять сообщения по одному или более каналам связи, так что при- ложения получают возможность взаимодей- ствовать, не располагая конкретными сведениями друг о друге N- уровневая / 3-уровневая Функциональность выделяется в отдельные сегменты, во многом аналогично многослойно- му стилю, но в данном случае сегменты физиче- ски располагаются на разных компьютерах. Объектно- ориентированная Парадигма проектирования, основанная на распределении ответственности приложения или системы между отдельными многократно используемыми и самостоятельными объекта- ми, содержащими данные и поведение Сервисно- оринетрированная архитектура (SOA) Описывает приложения, предоставляющие и потребляющие функциональность в виде сервисов с помощью контрактов и сообщений Архитектура программной системы практически нико- гда не ограничена лишь одним архитектурным стилем, зача- стую она является сочетанием архитектурных стилей, образующих полную систему. Например, может существовать SOA-дизайн, состоящий из сервисов, при разработке которых использовалась многослойная архитектура и объектно- ориентированный архитектурный стиль. 88 Рассмотрим основные базовые типы приложений: 1. Мобильные приложения. Приложения этого типа мо- гут разрабатываться как тонкий клиент или насыщенное кли- ентское приложение. Насыщенные клиентские мобильные приложения могут поддерживать сценарии без постоянного подключения или без подключения вообще. Веб-приложения или тонкие клиентские приложения поддерживают только сценарии с подключением. Ограничением при разработке мобильных приложений могут быть устройства, на которых их предполагается выполнять. 2. Насыщенные клиентские приложения. Приложения этого типа обычно разрабатываются как самодостаточные приложения с графическим пользовательским интерфейсом, который обеспечивает отображение данных с помощью набора элементов управления. Насыщенные клиентские приложения могут поддерживать сценарии без подключения или без по- стоянного подключения, если должны выполнять доступ к удаленным данным или функциональности. 3. Насыщенные Интернет-приложения. Приложения этого типа могут поддерживать множество платформ и брау- зеров. Насыщенные Интернет-приложения выполняются в изолированной программной среде браузера, которая огра- ничивает доступ к некоторым возможностям клиента. 4. Сервисные приложения. Сервисы предоставляют биз- нес-функциональность для совместного использования и позволяют клиентам доступ к ней из локальной или удаленной системы. Вызов операций сервиса осуществляется с помощью сообщений, соответствующих XML-схемам и передаваемых по транспортным каналам. Целью данного типа приложений является обеспечение слабой связанности между клиентом и сервером. 5. Веб-приложения. Приложения этого типа, как прави- ло, поддерживают сценарии с постоянным подключением и различные браузеры, выполняющиеся в разнообразнейших операционных системах и на разных платформах. 6. Существует множество других более специализиро- ванных типов приложений. Как правило, эти типы являются специализациями или сочетаниями базовых типов, перечис- ленных в данном списке. 89 В табл. 8.2 перечислены преимущества и недостатки об- щих архетипов приложений. Таблица 8.2 Преимущества и недостатки архетипов приложений Тип приложения Преимущества Недостатки Насыщенные клиентские приложения Возможность использова- ния ресурсов клиента. Лучшее время отклика, насыщенная функцио- нальность UI и улучшен- ное взаимодействие с пользователем. Очень динамичное взаи- модействие с коротким временем отклика. Поддержка сценариев без подключения и сценариев без постоянного подклю- чения Сложность развер- тывания; при этом широкий выбор вариантов установ- ки, таких как ClickOnce, Windows Installer и XCOPY. Сложности обеспе- чения совместимо- сти версий. Зависимость от платформы Мобильные приложения Поддержка портативных устройств. Доступность и простота использования для мо- бильных пользователей. Поддержка сценариев без подключения и сценариев без постоянного подклю- чения Ограниченные возможности ввода и навигации. Ограниченная область отображе- ния экрана Насыщенные Интернет- приложения (RIA) Такие же насыщенные возможности пользова- тельского интерфейса, как и для насыщенных клиентов. Поддержка насыщенных и потоковых мультимедиа и графики Больший объем памяти, занимае- мый на клиенте, по сравнению с Веб- приложением 90 Окончание табл. 8.2 Тип приложения Преимущества Недостатки Простота развертывания с возможностями распреде- ления (насыщенными) такими же, как и для Веб- клиентов. Простота обновления и смены версий. Поддержка различных платформ и браузеров Ограниченное ис- пользование ресур- сов клиента по сравнению с насыщенным клиентским прило- жением. Необходимость развертывания на клиенте подходящей среды выполнения Сервисные приложения Слабо связанное взаимо- действие между клиентом и сервером. Могут использоваться раз- личными и невзаимосвязан- ными приложениями. Поддержка для обеспече- ния возможности взаимо- действия Отсутствие под- держки UI. Зависимость от возможности сете- вого подключения Веб- приложения Широко доступный и осно- ванный на стандартах UI, поддерживаемый на многих платформах. Простота развертывания и внесения изменений Необходимость устойчивого сете- вого подключения. Сложно обеспечить насыщенный поль- зовательский интерфейс Каждый тип приложения может быть реализован с исполь- зованием одной или более технологий. Выбор технологии будет определяться сценариями и ограничениями технологий, а также возможностями и опытом группы разработки. Ход работы Визуальное проектирование может быть осуществлено с помощью программ, поддерживающих базовые функции по построению диаграмм. Рассмотрим основные элементы, которые можно использовать для построения архитектуры в Microsoft Visio. 91 При разработке основные элементы можно взять из шаб- лонов «Программы и базы данных» (рис. 8.1). Рис. 8.1. Шаблоны диаграмм группы «Программы и базы данных» Дополнительно можно использовать элементы из шаб- лонов «Сеть» (рис. 8.2). Рис. 8.2. Шаблоны диаграмм группы «Сеть» При проектировании архитектуры используются блоки: «Процесс», «Объект», «Компонент», «Линия связи» и т. п. ( рис. 8.3). 92 Рис. 8.3. Фигуры для построения диаграммы «Корпоративное приложение» Пример разработанной архитектуры приложения пред- ставлен на рис. 8.4. Рис. 8.4. Пример архитектуры программного комплекса Индивидуальные задания В соответствии с вариантом задания (вариант выбирается и обсуждается с преподавателем) определить и описать особен- ности реализации системы (подходы, технологии и т. п.). На основе описанных особенностей системы обосновать выбор вида архитектуры, наиболее подходящей для реализа- ции данной системы. Произвести визуальное проектирование архитектуры си- стемы (рекомендуется использовать программу Microsoft Visio). Добавить текстовое описание к архитектуре, поясняющее ее структуру и связи. Контрольные вопросы 1. Что подразумевается под созданием архитектуры при- ложения? 2. Каково основное назначение архитектуры приложения? 3. Перечислите основные принципы разработки архитек- туры программного обеспечения. 4. Перечислите основные типовые архитектурные стили. 5. Перечислите основные архетипы приложений. 6. Перечислите основные элементы, которые можно ис- пользовать для построения архитектуры программного обес- печения. 94 Лабораторная работа 9.UML. Диаграмма классов Цель работы Применить диаграмму классов для описания структуры выбранного решения. Ознакомиться с инструментами, позво- ляющими строить диаграмму классов. Теоретические сведения Вспомним, что подход Rational предлагает нам следую- щие представления модели: − Use Case View — представление требований к системе, описывает, что система должна делать; − Logical View — логическое представление системы, опи- сывает, как система должна быть построена; − Component View — представление реализации, описы- вает зависимость между программными компонентами; − Deployment View — представление развертывания, опи- сывает аппаратные элементы, устройства и программные компоненты и размещение компоненов. Основной диаграммой логического представления си- стемы является диаграмма классов (рис. 9.1). Для каждой системы может строиться несколько диа- грамм классов. Например, на разных этапах разработки можно построить диаграммы необходимой детальности: на началь- ном этапе наметить состав классов, без проработки операций и атрибутов, позже подробно описать используемые классы. Нотация UML предоставляет широкие возможности для отображения дополнительной информации (абстрактные опера- ции и классы, стереотипы, статические методы, детализирован- ные интерфейсы, параметризованные классы). При этом возможно использование графических изображений для ассоциа- ций и их специфических свойств, таких как отношение агрегации, когда составными частями класса могут выступать другие классы. Диаграмма классов представляет собой некоторый граф, вершинами которого являются элементы типа «классификатор», которые связаны различными типами структурных отноше- ний. Диаграмма классов может также содержать интерфейсы, пакеты, отношения и объекты. 95 Диаграмме классов показывает статическую структур- ную модель проектируемой системы. Поэтому диаграмму классов принято считать графическим представленном таких структурных взаимосвязей логической модели системы, кото- рые не зависят от времени. Рис. 9.1. Логическое представление и диаграмма классов |