Программная инженерия.Часть II. Учебное пособие
.pdf
изображены три класса, причем классы «Teacher» и «Student» наследуют свое поведение и данные от класса «Persona».
Рис. 11.9. Пример диаграммы классов
К преимуществам данного архитектурного стиля относятся:
–понятность – обеспечивается более близкое соответствие приложения реальным объектам, что и делает его более понятным;
–возможность повторного использования – реализуется через полиморфизм и абстракцию;
–тестируемость – улучшение тестируемости обеспечивается через инкапсуляцию;
–расширяемость – инкапсуляция, полиморфизм и абстракция гарантируют, что изменения в представлении данных не повлияют на интерфейсы, предоставляемые объектами, что могло бы ограничить возможности связи и взаимодействия с другими объектами;
–высокая связность – размещая в объекте функционально близкие методы (функции) и используя для разных наборов функций разные объекты, можно достичь высокого уровня связности.
К недостаткам объектного подхода можно отнести: высокую стоимость ошибок проектирования классов: при неправильно спроектированных классах необходимо делать это повторно, что может потребовать переписывания значительной части кода программы.
11.9. Сервисно ориентированная архитектура
Данная архитектура обеспечивает возможность предоставлять функциональность приложения в виде набора сервисов и создавать приложения, использующие эти программные сервисы. Сервисы слабо связаны, используют интерфейсы, основанные на определенных стандартах, могут быть опубликованы, обнаружены и вызваны. Основная задача сервисов – предоставление взаимодействия с приложением посредством сообщений через интерфейсы, областью действия которых является приложение, а не компонент или объект. Не следует рассматривать сервис как компонентный поставщик.
II Часть | пособие Учебное
31
Данная архитектура может обеспечить упаковку данных в сервисы, поддерживающие возможность взаимодействия с приложением и использующие для передачи информации широкий диапазон протоколов и форматов данных. Клиенты и другие сервисы могут осуществлять доступ к локальным сервисам того же уровня или к удаленным сервисам по сети.
Основные принципы данного архитектурного стиля:
– сервисы автономны – обслуживание, разработка, развертывание и контроль версий каждого сервиса происходит независимо;
– сервисы могут быть распределены – могут размещаться в любом месте сети, локально или удаленно, если сеть поддерживает необходимые протоколы связи;
– сервисы слабо связаны – каждый сервис совершенно не зависит от остальных и может быть заменен или обновлен без влияния на приложения, его использующие, при условии предоставления совместимого интерфейса;
– при обмене данными сервисы совместно используют контракты и схемы, но не внутренние классы, совместимость основана на политике (политика в данном случае означает описание характеристик, таких как транспорт, протокол и безопасность).
Типовые сервисно ориентированные приложения обеспечивают совместное использование информации, выполнение многоэтапных процессов (системы резервирования и онлайн-магазины), предоставление организациям специальных отраслевых данных или сервисов, создание составных приложений, которые объединяют данные из многих источников. В настоящее время практически все современные языки программирования поддерживают формат SOAP (Simple Object Access Protocol) сервисов, которые позволяют различным системам обмениваться информацией вне зависимости от языка программирования, на котором она была написана.
На рис. 11.10 изображен пример предоставления некоторой финансовой системой открытого сервиса для получения информации о курсах
ИНЖЕНЕРИЯ |
валют. |
|
К данному сервису могут обращаться любые программные продук- |
||
|
||
|
ты, в которых реализован программный код по получению этих данных. |
|
|
В рассматриваемом примере информацию получают: Web-сервер (воз- |
|
ПРОГРАММНАЯ |
можно, для отображения курсов валют на своих страницах); сервер по |
|
работе с мобильными устройствами (возможно, для предоставления |
||
|
||
|
курсов на мобильные устройства по запросу клиентов); программа на |
|
|
персональном компьютере (ПК); программа на карманном ПК. |
32
Рис. 11.10. Пример обмена информацией для сервисно ориентированных систем
Преимущества данного архитектурного стиля:
–согласование предметных областей – повторное использование общих сервисов со стандартными интерфейсами расширяет технологические и бизнес-возможности, а также сокращает стоимость;
–абстракция – сервисы являются автономными, доступ к ним осуществляется по формальному контракту, что обеспечивает слабое связывание и абстракцию;
–возможность обнаружения – сервисы могут предоставлять описания, что позволяет другим приложениям и сервисам обнаруживать их и автоматически определять их интерфейс;
–возможность взаимодействия – поскольку протоколы и форматы данных основываются на отраслевых стандартах, поставщик и потребитель сервиса могут создаваться и развертываться на разных платформах;
–рационализация – сервисы обеспечивают определенную функциональность, устраняя необходимость ее дублирования в приложениях.
Недостаток данной архитектуры заключается в том, что при любом изменении сервиса требуется перекомпиляция всех клиентов, которые его используют. Это накладывает серьезные ограничения, особенно в том случае, если сервисом пользуется большое количество сторонних программных продуктов.
Вывод
Нами рассмотрены типовые архитектурные стили, определяющие набор правил, которые задают типы компонентов, используемых для
II Часть | пособие Учебное
33
ПРОГРАММНАЯ ИНЖЕНЕРИЯ
компоновки системы, и типы отношений, применяемых при компоновке, а также ограничения по способам компоновки и допущения о ее семантике. Проанализированы достоинства и недостатки архитектурных стилей проектирования.
Вопросы для самопроверки
1.Дайте краткую характеристику архитектурным стилям проектирования.
2.Какие из архитектурных стилей можно совмещать в одном архитектурном решении и какие нельзя? Почему?
3.На какие ключевые вопросы следует обращать внимание при проектировании? Почему?
Литература
1.Программная инженерия: учебник / В. А. Антипов и др.; под ред.
Б.Г. Трусова. М.: Академия, 2014. 282 с.
2.Соммервилл И. Инженерия программного обеспечения. 6-е изд. / пер. с англ. М.: Изд. дом «Вильямс», 2002. 624 с.
3.Гецци К., Джазаейри М., Мандриоли Д. Основы инженерии программного обеспечения. 2-е изд. / пер. с англ. СПб.: БХВ-Петербург, 2005. 832 с.
Тема 12. ГРАФИЧЕСКОЕ ПРЕДСТАВЛЕНИЕ АРХИТЕКТУРЫ
План
12.1.Функциональный (логический) вид.
12.2.Физический вид, или вид развертывания.
12.3.Вид с точки зрения действий пользователя.
12.4.Интерфейс пользователя.
12.5.Анализ качества и оценка программного дизайна.
12.6.Программные средства.
12.1. Функциональный (логический) вид
Очень важно графически (визуально) представить разрабатываемую архитектуру. Независимо от того, делается ли это на бумаге или в виде слайдов, или в другом формате, главное – показать основные ограничения и принятые решения, для того чтобы обозначить границы и начать обсуждение. Невозможность наглядного представления архитектуры означает, что она полностью не понята.
34
Любая система может рассматриваться с разных точек зрения: поведенческой (динамической); структурной (статической); логической (соответствие функциональным требованиям); физической (распределенность, локальность); реализации (как детали архитектуры представляются в коде) и т. п.
В результате получаются различные архитектурные представления (View). Архитектурное представление может быть в виде частных аспектов программной архитектуры, рассматривающих специфические свойства программной системы. В свою очередь, дизайн системы – комплекс архитектурных представлений, достаточный для реализации системы и удовлетворения предъявляемых к ней требований. Для изображения большинства видов дизайна систем используются UML-диаграммы.
Рассмотрим основные виды представления (точки зрения) архитектуры приложений и диаграммы, которые можно использовать при их проектировании.
Функциональный (логический) вид. В данном случае архитектура представлена как набор функций и логических связей, которые отражают взаимодействие между различными частями системы и описывают механизм работы функционала. Рисовать можно в произвольном формате.
Рис. 12.1. Пример функционального вида архитектуры приложения
На рис. 12.1 показан пример функционального вида архитектуры ин- тернет-магазина по продаже сотовых телефонов. Выделены различные модули системы, кратко описаны их функционал и взаимодействие.
II Часть | пособие Учебное
35
12.2. Физический вид, или вид развертывания
Это архитектурное представление описывает (в произвольном виде) физическую структуру приложения (серверы, физические устройства и связи между ними). На рис. 12.2 приведен пример физического вида архитектуры для интернет-магазина по продаже сотовых телефонов.
ПРОГРАММНАЯ ИНЖЕНЕРИЯ
Рис. 12.2. Пример физического вида архитектуры.
Web-сервер и сервер БД физически располагаются на одном компьютере. Доступ к страницам будет осуществляться как по открытому соединению (HTTP), так и по закрытому (HTTPS). При этом у пользователей магазина и сотрудников компании будет разный доступ к магазину (пользователи будут работать через личный кабинет, а сотрудники магазина
через специальный Web-интерфейс управления магазином). Прямой до-
ступ к серверу будут иметь только администраторы системы.
12.3. Вид с точки зрения действий пользователя
Это описание системы с точки зрения выполнения действий поль-
зователем часто встречается под названием «бизнес-процесс». Для опи-
сания бизнес-процессов используют диаграммы активности, внешне
36
похожие на блок-схемы алгоритмов, но показывающие последовательность работы с системой с точки зрения действий пользователя. В диаграммах активности используются следующие элементы.
–начальное состояние 
;
–конечное состояние 
;
–состояние-действие
;
–условие 
;
–параллельное выполнение
.
Рис. 12.3. Пример диаграммы активности
Начальное состояние может быть только одним, это начало диаграммы. Конечное состояние может быть только одним, на нем заканчивается диаграмма. Состояние-действие определяет любое возможное в дан-
ном состоянии действие (внутри данного блока пишется производимое
действие). Условие позволяет изменять ход выполнения диаграммы по
II Часть | пособие Учебное
37
различным причинам, причины ветвления пишутся над линиями, исходящими из блока. Допускается параллельное выполнение процессов: либо в блок входит одна стрелка, а выходит несколько, каждая из которых означает начало параллельного выполнения процессов; либо в блок входит несколько стрелок, а выходит одна, что означает окончание параллельного выполнения процессов. Область построения диаграммы может разделяться вертикальными линиями, прямоугольник, который они образуют, выделяется как отдельная подсистема или пользователь, их названия пишутся в верхней части прямоугольника.
На рис. 12.3 представлена диаграмма активности запроса клиентом списка товаров интернет-магазина. Клиент запрашивает список товаров. Если Web-сервер недоступен, то он может либо еще раз запросить список товаров, либо отказаться от просмотра страницы. Если Web-сервер доступен, то он параллельно делает запрос данных из БД и информирует браузер клиента о том, что данные запрошены. Здесь целесообразно применение «асинхронного агента» для показа того, что ожидаются данные клиенту. Если время получения запрошенной информации будет большим, то клиент будет видеть, что его запрос обрабатывается. После получения данных Web-сервер формирует HTML страницу и отправляет ее браузеру клиента. Браузер клиента отображает полученную страницу.
12.4. Интерфейс пользователя
Проектирование интерфейса пользователя также влияет на архитектуру приложения. При проектировании используются различные программные средства: дизайнеры средств разработки, а также специализированные продукты. Проработка интерфейса пользователя на ранних этапах позволяет выявить пропущенные заказчиком требования и лучше проработать механизмы отображения информации пользователям.
ПРОГРАММНАЯ ИНЖЕНЕРИЯ
Рис. 12.4. Пример интерфейса пользователя
38
На этапе разработки интерфейса следует абстрагироваться от окончательного дизайна приложения и необходимо сконцентрировать внимание на функциональных возможностях, например, может ли клиент выполнить требуемые действия, используя конкретную форму.
На рис. 12.4 показан шаблон возможного интерфейса пользователя для интернет-магазина по продаже сотовых телефонов.
12.5. Анализ качества и оценка программного дизайна
Параметры качества – это общие свойства архитектуры, которые оказывают влияние на дизайн системы, ее поведение во время работы и взаимодействие с пользователем, такие как: удобство и простота использования, производительность, надежность и безопасность и др. Обеспечение приложением требуемого сочетания параметров качества определяет успешность его дизайна и общее качество программного продукта. В ходе проектирования приложения, отвечающего любому из этих параметров, необходимо учесть влияние и других требований, а также при этом должны быть проанализированы плюсы и минусы по отношению к другим параметрам качества.
Атрибуты качества дизайна. Существует целый спектр различных атрибутов, помогающих оценить разработку и добиться качественного дизайна. Эти атрибуты могут описывать многие характеристики системы и элементов дизайна: «тестируемость», «переносимость», «модифицируемость», «производительность», «безопасность» и т. п. Важно понимать, что обсуждаемые атрибуты касаются только дизайна (как результата), но не проектирования (как процесса). Все эти атрибуты принято объединять в следующие группы:
– применимые к run-time, т. е. ко времени выполнения системы, например, среднее время отклика системы, позволяющее оценить качество дизайна с точки зрения производительности;
– ориентированные на design-time, т. е. позволяющие оценивать качество получаемого дизайна еще на этапе проектирования и в общем случае, вплоть до тестирования включительно; например, средняя нагруженность классов бизнес-методами (в каждом классе бизнес-методов
«в среднем» или «много»); |
Учебное |
|
– атрибуты качества архитектурного дизайна как такового: концеп- |
||
|
||
туальная целостность дизайна, непротиворечивость, полнота, завер- |
|пособие |
|
шенность; например, любой определенный бизнес-метод является вы- |
||
|
||
зываемым, т. е. создан не потому, что может понадобиться в будущем, |
|
|
а определен в соответствии с требованиями или необходим для реализа- |
IIЧасть |
|
ции дизайна в выбранном архитектурном стиле. |
||
|
39
ПРОГРАММНАЯ ИНЖЕНЕРИЯ
Существуют атрибуты, которые сложно измерить, например, портируемость (переносимость на другие операционные системы и т. д.) или безопасность. Измеряемые атрибуты качества описываются определенными метриками. Метрика позволяет количественно оценить атрибут качества, например, «модифицируемость» и «сложность» системы.
Не надо путать атрибуты качества дизайна с атрибутами качества, используемыми в ряде требований, предъявляемых к системе. Часть из них может отображаться друг на друга и нести эквивалентную смысловую нагрузку, некоторые могут быть связаны, однако большая часть атрибутов качества дизайна является специфичной именно для дизайна и не связана с требованиями. Например, если используется платформа J2EE (Java 2 Enterprise Edition) и компонентная модель EJB (Enterprise JAVABEANS), существуют признаки хорошего дизайна, специфичные для данной платформы и компонентной модели, но абсолютно никак не связанные с какими-либо требованиями к создаваемой на этой платформе программной системе.
Анализ качества и техники оценки. В индустрии разработки ПО распространены многие инструменты, техники и практики, помогающие добиться качественного дизайна:
–обзор дизайна (software design review), например, неформальный обзор архитектуры членами проектной команды;
–статический анализ (static analysis), например трассировка с требованиями
–симуляция и прототипирование (simulation and prototyping) – динамические техники проверки дизайна в целом или отдельных его атрибутов качества, например, для оценки производительности используемых архитектурных решений при симуляции нагрузки, близкой к прогнозируемым пиковым.
12.6. Программные средства
При проектировании ПС можно пользоваться различными программными средствами, которые позволяют рисовать различные виды диаграмм. Из наиболее востребованных можно выделить следующие:
–Microsoft Visio – платный программный продукт, позволяющий рисовать любые диаграммы, а также схемы интерфейсов пользователя;
–Plant UML – бесплатный программный продукт, позволяющий автоматически рисовать диаграммы по написанным на специальном языке сценариям;
–Balsamiq Mockups – платный программный продукт, позволяющий проектировать Web-интерфейсы.
40