Практическая работа 2,1. Лабораторная работа Проектирование архитектуры программного средства
 Скачать 197.25 Kb.
|
|
Лабораторная работа 2. Проектирование архитектуры программного средства Цельработы Целью работы является изучение базовых принципов ишаблонов построения архитектуры приложений, выбор стратегии и шаблона проектирования, которые помогут при проектировании слоев, компонентов и сервисов решения, а такжевизуальноепроектированиеархитектурыприложениясис-пользованиемMicrosoftVisio. Теоретическиесведения Создание архитектуры приложения — это процесс фор-мированияструктурированногорешения,отвечающеговсемтехническим и операционным требованиям и обеспечивающего оптимальные общие атрибуты качества, такие как производительность, безопасность и управляемость. Онвключаетпринятиерядарешенийнаоснованииширокогодиапазонафакторов. Каждое из этих решений может иметь существенноевлияние на качество, производительность, удобство обслуживания и общий успех приложения. Какилюбаядругаясложнаяструктура,программноеобес-печение(ПО)должностроитьсянапрочномфундаменте.Непра-вильноеопределениеключевыхсценариев,неправильноепроектирование общих вопросов или неспособность выявить долгосрочные последствия основных решений могут поставить под угрозу все приложение. Современные инструменты и плат-формыупрощаютзадачупосозданиюприложений,нонеустра-няютнеобходимостивтщательномихпроектированиинаосновании конкретных сценариев и требований. Неправильновыработанная архитектура обусловливает нестабильность ПО,невозможность поддерживать существующие или будущие бизнес требования, сложности при развертывании или управлении в среде производственной эксплуатации. Проектирование систем должно осуществляться с учетомпотребностей пользователя, системы (ИТ-инфраструктуры) ибизнес-целей. Для каждой из этих составляющих определяются ключевые сценарии выделяются важные параметры качества (например, надежность или масштабируемость), а также ос-новныеобластиудовлетворенностиинеудовлетворенности.По возможности необходимо выработать и учесть показателиуспешностивкаждойизэтихобластей. Основноеназначениеархитектуры —описаниеисполь-зованияиливзаимодействияосновныхэлементовикомпо-нентов приложения. Выбор структур данных и алгоритмов ихобработкиилидеталейреализацииотдельныхкомпонентовявляются вопросами проектирования. Часто вопросы архитек-турыипроектированияпересекаются.Вместотогочтобывводитьжесткиеправила,разграничивающиеархитектуруипроектирование, имеет смысл комбинировать эти две области.В некоторых случаях, принимаемые решения, очевидно, явля-ются архитектурными по своей природе, в других — большекасаютсяпроектированияиреализацииархитектуры. Приступая к работе над архитектурой приложения, необ-ходимо помнить об основных принципах проектирования. Этопоможет создать архитектуру, которая будет следовать прове-реннымподходам,обеспечитминимизациюзатрат,простотуобслуживания,удобствоиспользованияирасширяемость. Рассмотримосновныепринципы: Разделениефункций.Разделитеприложениенаот-дельныекомпоненты,повозможности,минимальнымпере-крытиемфункциональности.Важнымфакторомявляетсяпредельноеуменьшениеколичестваточексоприкосновения,чтообеспечитвысокуюсвязность(highcohesion)ислабуюсвязанность (lowcoupling). Неверное разграничение функцио-нальности может привести к высокой связанности и сложно-стямвзаимодействия,даженесмотрянаслабоеперекрытиефункциональностиотдельныхкомпонентов. Принцип единственности ответственности. Каждыйотдельновзятыйкомпонентилимодульдолженотвечатьтолькозаодноконкретноесвойство/функциюилисовокуп-ностьсвязанных функций. Принципминимальногознания(такжеизвестныйкакЗаконДеметера(LawofDemeter,LoD)).Компонентуилиобъектуне должны быть известны внутренние детали других компо-нентовилиобъектов. Не повторяйтесь. Намерение должно быть обозначенотолькоодинраз.Вприменениикпроектированиюприложения этоозначает,чтоопределеннаяфункциональностьдолжнабытьреализованатольководномкомпонентеинедолжнадублироватьсяниводномдругом компоненте. Минимизируйте проектирование наперед. Проекти-руйте только то, что необходимо. В некоторых случаях, когдастоимостьразработкиилииздержкивслучаенеудачногодизайна очень высоки, может потребоваться полное предвари-тельноепроектированиеитестирование.Вдругихслучаях,особенно при гибкой разработке, можно избежать масштабно-го проектирования. Если требования к приложению четко неопределены, или существует вероятность изменения дизайнасо временем, старайтесь не тратить много сил на проектирова-ниераньше времени. Цель архитектора ПОпри проектировании приложенияилисистемы —максимальноеупрощениедизайначерезегоразбиение на функциональные области. Например, пользова-тельскийинтерфейс(userinterface,UI),выполнениебизнес-процессовилидоступкданным —всеэторазныефункцио-нальныеобласти.Компонентывкаждойизэтихобластейдолжныреализовыватьданнуюконкретнуюфункциональ-ностьинедолжнысмешиватьвсебекодразныхфункцио-нальных областей. Так в компонентах UI не должно быть кодапрямогодоступакисточникуданных;дляизвлеченияданныхв них должны использоваться либо бизнес-компоненты, либокомпонентыдоступа к данным. Такженеобходимопроанализироватьсоотношениеза-трат/выгоддляинвестицийвприложение.Внекоторыхслучаяхможет быть целесообразным упростить структуру и разрешить,например,связываниеэлементовUIсрезультирующимиданны-ми. В общем, оценивайте реализацию функциональности также ис коммерческой точки зрения. Далее приводятся обобщенныерекомендации, которые помогут учесть широкий диапазон фак-торов, влияющих на проектирование, реализацию, развертыва-ние,тестированиеиобслуживаниеприложения. Архитектурапрограммногообеспечениязаключаетвсеберяд важных решений об организации программной системы,средикоторыхвыборструктурныхэлементовиихинтерфейсов,составляющих и объединяющих систему в единое целое; пове-дение,обеспечиваемоесовместнойработойэтихэлементов;организациюэтихструктурныхиповеденческихэлементов в более крупные подсистемы, а также архитектурный стиль,которогопридерживаетсяданнаяорганизация. Выбор архитектуры ПО также касается функционально-сти, удобства использования, устойчивости, производительно-сти, повторного использования, понятности, экономических итехнологическихограничений,эстетическоговосприятияипоискакомпромиссов. Архитектурныйстиль,иногданазываемыйархитектур-нымшаблоном —этонаборпринципов,высокоуровневаясхема,обеспечивающаяабстрактнуюинфраструктурудлясемейства систем. Архитектурный стиль улучшает секциони-рованиеиспособствуетповторномуиспользованиюдизайнаблагодаряобеспечениюрешенийчастовстречающихсяпро-блем. Архитектурные стили и шаблоны можно рассматриватькакнаборпринципов, формирующихприложение. Пониманиеархитектурныхстилейобеспечиваетне-сколькопреимуществ.Самоеглавноеизних —общийязык.Также они дают возможность вести диалог, не касаясь техно-логий, т. е. обсуждать схемы и принципы, не вдаваясь в детали.Например, архитектурные стили позволяют сравнивать схемуклиент/серверсn-уровневойсхемойприложения.Архитек-турныестилиможноорганизоватьпоих фокусу. Втабл. 8.1приведенсписоктиповыхархитектурныхстилей,идаетсякраткоеописание каждогоиз них. Таблица8.1 Архитектурный'>Типовыеархитектурныестили
Окончаниетабл.8.1
Архитектурапрограммнойсистемыпрактическинико-гда не ограничена лишь одним архитектурным стилем, зача-стуюонаявляетсясочетаниемархитектурныхстилей,образующих полную систему. Например, может существоватьSOA-дизайн, состоящий из сервисов, при разработке которыхиспользоваласьмногослойнаяархитектураиобъектно-ориентированныйархитектурный стиль. Рассмотримосновныебазовыетипыприложений: Мобильные приложения. Приложения этого типа мо-гут разрабатываться как тонкий клиент или насыщенное кли-ентскоеприложение.Насыщенныеклиентскиемобильныеприложениямогутподдерживатьсценариибезпостоянногоподключения или без подключения вообще. Веб-приложенияилитонкиеклиентскиеприложенияподдерживаюттолькосценариисподключением.Ограничениемприразработкемобильных приложений могут быть устройства, на которых ихпредполагаетсявыполнять. Насыщенные клиентские приложения. Приложенияэтоготипаобычноразрабатываютсякаксамодостаточныеприложениясграфическимпользовательскиминтерфейсом,который обеспечивает отображение данных с помощью набораэлементов управления. Насыщенные клиентские приложениямогутподдерживатьсценариибезподключенияилибезпо-стоянногоподключения,еслидолжнывыполнятьдоступкудаленнымданным илифункциональности. НасыщенныеИнтернет-приложения.Приложенияэтого типа могут поддерживать множество платформ и брау-зеров.НасыщенныеИнтернет-приложениявыполняютсявизолированнойпрограммнойсредебраузера,котораяогра-ничиваетдоступкнекоторымвозможностямклиента. Сервисные приложения. Сервисы предоставляют биз-нес-функциональностьдлясовместногоиспользованияипозволяют клиентам доступ к ней из локальной или удаленнойсистемы. Вызов операций сервиса осуществляется с помощьюсообщений, соответствующих XML-схемам и передаваемых потранспортнымканалам.Цельюданноготипаприложенийявляется обеспечение слабой связанности между клиентом исервером. Веб-приложения. Приложения этого типа, как прави-ло,поддерживаютсценарииспостояннымподключениемиразличныебраузеры,выполняющиесявразнообразнейшихоперационныхсистемах ина разныхплатформах. Существуетмножестводругихболееспециализиро-ванных типов приложений. Как правило, эти типы являютсяспециализациямиилисочетаниямибазовыхтипов,перечис-ленныхвданномсписке. Втабл.8.2перечисленыпреимуществаинедостаткиоб-щихархетиповприложений. Таблица8.2 Преимущества и недостаткиархетиповприложений
Окончаниетабл.8.2
Каждыйтипприложенияможетбытьреализовансиспользованиемоднойилиболеетехнологий.Выбортехнологиибудетопределятьсясценариямииограничениямитехнологий,атакжевозможностямииопытомгруппыразработки. Ходработы Визуальное проектирование может быть осуществлено спомощьюпрограмм,поддерживающихбазовыефункциипопостроению диаграмм. Рассмотрим основные элементы, которыеможно использовать для построения архитектуры в MicrosoftVisio.  Приразработкеосновныеэлементыможновзятьизшаблонов «Программы ибазыданных»(рис.8.1).Рис.8.1. Шаблоны диаграмм группы «Программыибазыданных»  Дополнительноможноиспользоватьэлементыизшаблонов «Сеть»(рис.8.2).Рис.8.2.Шаблоныдиаграммгруппы«Сеть» Припроектированииархитектурыиспользуютсяблоки: «Процесс», «Объект», «Компонент», «Линия связи» и т.п. (рис.8.3).  Рис.8.3.Фигурыдляпостроениядиаграммы «Корпоративноеприложение»  Примерразработаннойархитектурыприложенияпредставленна рис.8.4.Рис.8.4.Примерархитектурыпрограммногокомплекса Индивидуальныезадания В соответствии с вариантом задания (вариант выбираетсяи обсуждается с преподавателем) определить и описать особенностиреализациисистемы(подходы,технологииит.п.). На основе описанных особенностей системы обосноватьвыбор вида архитектуры, наиболее подходящей для реализацииданнойсистемы. Произвести визуальное проектирование архитектуры системы(рекомендуетсяиспользоватьпрограммуMicrosoftVisio). Добавить текстовое описание к архитектуре, поясняющееееструктуруисвязи. Контрольныевопросы Что подразумевается под созданием архитектуры приложения? Каковоосновноеназначениеархитектурыприложения? Перечислите основные принципы разработки архитектурыпрограммногообеспечения. Перечислитеосновныетиповыеархитектурныестили. Перечислитеосновныеархетипыприложений. Перечислите основные элементы, которые можно использовать для построения архитектуры программного обеспечения. |