Каждый шаблон проектирования, который используется при разработке информационной системы, представляет собой строго формализованное описание этапа проектирования успешного способа реализации поставленной задачи, решение которой предоставляет определенные выгоды. Кроме того, часть шаблонов содержит рекомендации по их использованию в различных ситуациях. Каждый паттерн проектирования должен обязательно иметь общеупотребимое наименование, которое характеризует его суть. "Правильно" сформулированный паттерн проектирования позволяет, отыскав однажды удачное решение, пользоваться им на постоянной основе.
При проектировании в качестве концептуальной структуры выступает информационная система. В подходе к проектированию с использованием шаблонов система конфигурируется из наиболее успешных подходов. Низшим уровнем представления системы является описание ее в терминах "микроскопических" элементов и отношений между ними. Самым высоким уровнем является интеграция отдельных систем, которые в данном случае рассматриваются в качестве "макроскопических" модулей. Нужно подчеркнуть, что на высоком уровне связи строятся на основе методик, отличных от тех, которые используются на предыдущих уровнях.
Важным начальным этапом при работе с паттернами является адекватное моделирование рассматриваемой предметной области. Это необходимо как для получения должным образом формализованной постановки задачи, так и для выбора подходящих паттернов проектирования.
Использование паттернов проектирования на практике дает проектировщику следующие неоспоримые преимущества:
Общеизвестны три фундаментальные и наиболее значимые аспекты объектно-ориентированного проектирования –инкапсуляция, наследование, полиморфизм. Очень важно, как проектировщик на практике применяет указанные концепции для построения архитектуры программных продуктов. Традиционный, классический подход к пониманию указанных терминов ограничивает возможности разработки программного обеспечения.
Для более детального понимания сути объектно-ориентированного проектирования, базиса, на котором построены шаблоны, сравним следующие подходы:
Затронем при рассмотрении различные уровни проектирования и то, как они соотносятся с данными и связями:
Именно "новый подход" позволил создателям шаблонов проектирования разработать
ту концепцию, которую сейчас принято называть "шаблоном проектирования".
Классическое представление об информационных объектах состоит в том, что они представляются в виде совокупности данных и методов их обработки. "Новым" определение базируется при взгляде на объекты с концептуальной точки зрения. В этом видении объект рассматривается как сущность, имеющая "некоторые обязательства". Именно они определяют дальнейшее поведение объекта, а в ряде случаев мы будем представлять объект в качестве сущности, обладающей конкретным поведением.
Это определение помогает сконцентрироваться на том, что объект должен делать, не задаваясь преждевременно вопросом реализации необходимой функциональности. Это помогает декомпозировать реализацию информационной системы на два этапа:
Такой подход позволяет более точно выбрать и определить основной объект проектирования.
Второе определение объекта является более гибким, поскольку позволяет сосредоточиться на том, что объект делает, а механизм наследования предоставляет инструмент реализации его поведения по мере необходимости. При взгляде на объект с точки зрения реализации также можно достичь этого, но гибкость в таком случае, как правило, обеспечивается более сложным путем.
Рассуждение в терминах обязательств помогает сосредоточиться на определении открытого интерфейса объекта. Обязательства объекта накладывают дополнительное требование на определение способа их вызова.
Предположим, что существует объект, имеющий ряд следующих обязательств:
Эти обязательства предполагают существование определенного набора методов, необходимых для их реализации. Для нас не имеет никакого значения, что именно находится внутри рассматриваемого объекта. Единственное, что необходимо, – это чтобы рассматриваемый объект обеспечивал требуемое "поведение". Для этой цели могут использоваться атрибуты внутри объекта или методы, вычисляющие требуемые результаты или даже обращающиеся к другим объектам за необходимыми для их функционирования данными. Этот подход предоставляет необходимую гибкость для эффективного моделирования процессов в конкретной бизнес-области.
Следует отметить, что перенос акцента с реализации на мотивацию – характерная черта описания шаблонов проектирования. Необходимо стремиться рассматривать автоматизируемые объекты в указанном ракурсе, как части техносоциосистемы. Выбор такого подхода позволит создавать успешные программные продукты.
Качество инкапсуляции следует понимать как "любой вид сокрытия". Другими словами, это механизм, способный скрывать данные. Преимущество использования инкапсуляции состоит в том, что она упрощает разбиение программы. Инкапсулированные уровни в этом случае становятся независимыми интерфейсами, которые необходимо будет спроектировать.
Когда объектно-ориентированная парадигма была впервые предложена, повторное использование классов понималось как одно из ее важнейших преимуществ.
Обычно оно достигалось посредством разработки классов с последующим созданием на их основе новых, производных классов. Для процедуры создания этих подклассов, порожденных от других, базовых классов, использовался термин "специализация" (а для обратного перехода к базовому классу –термин "генерализация").
Найдите то, что изменяется, и инкапсулируйте это.
При проектировании решения в первую очередь необходимо выделить то, что будет наиболее изменяемым в создаваемом продукте. Такой подход позволяет более гибко подходить к разработке. При нем не концентрируются на установлении причин возможных переделок, а сосредоточиваются на том, что хотят уметь изменять, не переделывая проект. Идея состоит в том, что следует инкапсулировать те концепции, которые могут изменяться. Шаблоны проектирования используют инкапсуляцию для распределения объектов по различным уровням приложения. Это позволяет разработчику вносить изменения на одном уровне, при этом не оказывая влияния на другой. Этим достигается слабая связанность между объектами разных уровней. Далее подобная стратегия использования инкапсуляции для реализации требуемого поведения класса будет продемонстрирована при описании нескольких шаблонов проектирования.
В завершении обсуждения постулатов объектно-ориентированного проектирования целесообразно выделить активности, идентифицирующие общие и изменчивые уровни разрабатываемых приложений:
Анализ общности проводится над концептуальным уровнем проекта системы, тогда как анализ изменчивости относится к уровню его реализации, т.е. к процедурам конкретного воплощения системы.
Спецификация занимает промежуточное положение между уровнями концепта и реализации. Она предусматривает выполнение одновременно как анализа общности, так и анализа изменчивости. На этом уровне определяется, как будет реализовываться взаимодействие множества объектов, которые концептуально схожи, т.е. каждый из них представляет конкретный вариант некоторой общей концепции. На уровне реализации каждая такая общая концепция описывается соответствующими параметрами и атрибутами.
Классическое понимание концепций инкапсуляции, наследования, полиморфизма очень ограниченно. Инкапсуляция представляет собой нечто большее, чем просто сокрытие данных. Расширение определения инкапсуляции до концепции сокрытия любых существующих категорий позволяет распределить объекты по разным уровням. На основе этого становится возможным вносить изменения на одном уровне, исключив нежелательное влияние этих действий на объекты другого уровня.
Наследование лучше использовать как метод определенной обработки различных конкретных объектов, являющихся концептуально идентичными, а не как средство проведения специализации.
После того как мы обсудили базис объектно-ориентированного проектирования и перед тем как мы преступим к подробному рассмотрению основной темы нашего курса, самое время осветить еще одну очень важную тему, которая, по мнению многих экспертов, является основной для самоопределения архитектуры как направления профессиональной деятельности. Это тема видов и типов стилей проектирования в деятельности профессиональных архитекторов программного обеспечения.
Обсуждая процесс проектирования, мы все время ходим "вокруг да около" программного обеспечения. Все существующие определения архитектуры не дают четкого и однозначного представления об объекте работы архитектора.
Методологии проектирования –это не проектирование. Они являются платформой, с помощью которой объединяются и структурируются усилия, направленные на создание адекватной программной архитектуры.
Ни методологии, ни языки программирования или другие средства разработки не дают ответа на вопрос, как проектируются информационные системы.
От архитекторов постоянно требуют нарисовать понятную всем "картинку", от взгляда на которую будет "все понятно". Но никто не требует ее исполнения, потому что требовать это от одного конкретного исполнителя было бы глупо. Когда приходит архитектор с "картинкой", непонятно, сколько тестовых прогонов данной архитектуры было мысленно произведено. Возможно, ни одного. Архитектура крупных информационных систем меняется в процессе фиксации.
Когда есть необходимость представить архитектуру, сначала начинается рассказ о том, как те или иные объекты друг с другом взаимодействуют. Довольно быстро оперативная память слушателя или же самого рассказчика заканчивается, и тогда появляется карандаш или маркер и начинается "картинизация". Процесс осознания архитектуры в этот момент прерывается. То же самое происходит, если на определенном шаге прервать рассказчика вопросом: "А что, если…?". В обоих случаях шансов вернуться к основному сценарию совсем немного. В общем, все довольно быстро запутываются (теряют нить рассуждений) и возвращаются к началу.
Программная архитектура возникла во времена структурного программирования Дейкстры, когда основной задачей разработки программного обеспечения было научиться упорядочивать данные и исходники программ. Инструменты архитектуры изначально были статичны и останутся таковыми еще довольно длительное время. На сегодня информационные системы – множество взаимодействующих друг с другом модулей, запустить которые очень непросто.
Разработка и проектирование успешных архитектур должны укладываться в "стандартные" проектные сроки и в дальнейшем поддерживаться достаточным количеством ресурсов, без крайних на то перегибов. В том числе и для этого выработано понятие архитектурного стиля.
Большинство информационных систем построено благодаря опыту и практикам, которые получены на основе опыта успешного создания программных продуктов со схожими параметрами. Сложно представить систему, для реализации которой нельзя было бы применить уже готовые решения или опыт, полученный при их создании. Сходство создаваемых архитектур определяется как архитектурный стиль, который можно рассматривать как особый вид совокупности шаблонов.
В качестве примеров архитектурного стиля можно перечислить распределенный стиль, стиль "каналы и фильтры", стиль с централизованной обработкой данных, стиль, построенный на правилах, и т. д.Конкретная система, что важно, может демонстрировать более одного архитектурного стиля, тем самым демонстрируя вклад, вносимый в систему различными профессионалами, занятыми в разработке информационной системы на протяжении ее жизненного цикла.
Архитектурный стиль определяет семейство систем в терминах шаблона организации структуры. Точнее, архитектурный стиль определяет номенклатуру компонентов и типов соединительных звеньев, а также набор условий, в соответствии с которыми они могут соединяться.
Можно перечислить следующие примеры архитектурных стилей, востребованных при разработке программного обеспечения на текущий момент:
Вышеперечисленные стили не претендуют на полноту. Безусловно, по ходу нашего курса мы упомянем еще ряд стилей, используемых сегодня, но в итоге следует отметить, что архитектурный стиль – это более комплексное и сложное понятие по сравнению с шаблоном. Именно стиль позволяет организовать различные шаблоны в единый монолит программного продукта. Шаблоны оптимизируют взаимодействие между различными информационными объектами, а стиль связывает шаблоны в единую информационную архитектуру.
Не нужно впадать в излишнюю эйфорию по поводу "все возможности" шаблонов, впервые знакомясь с этой идеологией проектирования. Зачастую излишняя концентрация на "шаблонных" решениях может сыграть злую шутку с неопытными проектировщиками. Шаблоны проектирования преподносятся как совокупность оптимальных решений разнообразных задач, но таковыми они являются только при наличии достаточного контекста окружения проектирования.
Изучение шаблонов проектирования преимущественно с точки зрения предлагаемых решений затрудняет понимание того, в каких ситуациях возможно применение тех или иных шаблонов. Шаблон сообщает только о том, что надо сделать. При этом обоснование этого должно быть продиктовано конкретной ситуацией и опытом проектировщика. К примеру, шаблон "Мост", с которым более подробно мы познакомимся позднее, полезен тогда, когда имеется некоторая абстракция и существует набор различных вариантов ее реализации. Шаблон предлагает решение, которое позволяет абстракции и реализации изменяться независимо друг от друга. На основе сути шаблона можно сделать вывод, что "Мост" можно использовать, не зная, как он реализуется на практике. Независимость изменений абстракции и ее реализации означает, что новые элементы абстракции можно будет добавлять без изменений на уровне реализации и наоборот. Не каждое бизнес-решение, реализуемое с помощью шаблонов проектирования, обеспечивает и поддерживает подобную независимость изменений.
Необходимо обратить дополнительное внимание на то, что, даже не зная конкретных способов реализации того или иного шаблона, можно прийти к выводу о возможности его применения. Это утверждение справедливо и подходит в отношении всех шаблонов проектирования. Более того, как правило, в качестве антишаблонов проектирования могут выступать рассматриваемые тут шаблоны проектирования, примененные в условиях, неоптимальных для выработанного решения.
В качестве примера наиболее популярных антишаблонов проектирования можно привести следующие:
Перечисленные типы антишаблонов, в отличие от шаблонов, сосредоточены не на описании конкретных структурных способов реализации программных продуктов, а на поведенческих аспектах зрелости разработчиков, реализующих информационные системы.
При изучении шаблонов полезнее сосредоточиться на общем бизнес-контексте их применения – т.е. на тех проблемах, которые пытаются решить. Это позволяет получить ответы на все необходимые вопросы.
Тему создания оптимальной архитектуры можно сравнить с пресловутой "серебряной пулей" области разработки программного обеспечения, обозначенной Фредериком Бруксом.
Постоянная интеграция различных модулей приложений и использование общих компонент информационных систем и сервисов– основной объект исследования программной инженерии и актуальный аспект архитектур современных программных продуктов. Подтверждением данного факта является тенденция выделения данных аспектов в отдельные области архитектуры предприятия в целом. Центральную роль при реализации этих областей играют стандартизованные элементы.
С одной стороны, подобный подход к разработке и поддержке программных продуктов позволяет значительно сократить сроки реализации решений, а с другой – уменьшить риски за счет использования фрагментов, проверенных в тестировании и на практике. То есть фактически речь идет о создании и использовании подходящих шаблонов корпоративных программных решений.
Шаблон – это общее решение некоторой повторяющейся проблемы в определенном контексте.
Как мы определились ранее, важный аспект, связанный с шаблонами,–это то, они сопровождаются обоснованным бизнес-контекстом.
Шаблоны – следующий шаг в понимании и применении моделей решения. Они демонстрируют, что делает некоторую модель хорошим решением и как создать решение для конкретной задачи.
Ряд современных методик построения архитектуры выделяет шаблоны в качестве отдельного "слоя" архитектуры.
Одна из целей работ Александера заключалась не в разработке новых идей, а, напротив, в анализе и последующем синтезе накопленного опыта строительства – как отдельных зданий, так и целых городов – с целью выявления удачных архитектурных решений и способствовавших этому факторов.
Связующим звеном между архитектурой, стилем и шаблонами является язык шаблонов, который представляет собой коллекцию шаблонов, взаимодействующих между собой и образующих в конечном итоге общее решение повторяющейся проблемы в определенном контексте. В приведенном выше определении имеется три ключевых словосочетания:
Важность применения шаблонов для построения оптимальной архитектуры обусловлена следующими причинами:
Также это позволяет создать долговременно работающие решения и придает гибкость. На следующем этапе эти достаточно постоянные конструкции могут быть связаны с конкретными технологическими решениями.
Надлежащее использование шаблонов является инструментом для быстрого и эффективного, с точки зрения затрат, создания моделей и реализации систем с минимальными рисками. Конечно, критерии удачности в области разработки программных продуктов во многом субъективны, но для объективной оценки могут быть использованы такие параметры, как полнота выполнения требований, долговечность, эффективность реализации, а также ориентация на расширение, а не на ограничение возможностей организации, использующей программные продукты. Как мы определим позже, использование шаблонов проектирования полностью поддерживает обозначенные метрики.
Организационное развитие компании и архитектура корпоративных информационных систем – это темы, взаимовлияние которых обсуждается на протяжении достаточно длительного периода времени. Интеграция и взаимодействие приложений в рамках общего информационного ландшафта предприятия или нескольких предприятий, объединенных в целую партнерскую цепочку, оказывают существенное влияние на используемые программные архитектуры и структуру компаний.
На сегодня есть множество различных методик, которые посредством различных шаблонов объединяют организации в единую информационную среду. Прежде всего, речь идет, о сервисной модели взаимодействия между приложениями общей системы в рамках сервис-ориентированной архитектуры (SOA) и о реализации архитектуры, управляемой на основе моделей (MDA).
Как сервис-ориентированная архитектура связана с вопросами организации и шаблонов проектирования программных продуктов?
Концепция сервис-ориентированной архитектуры была сформулирована в области ИТ, но в действительности это был ответ на актуальные потребности сегодняшнего дня, когда границы между бизнес-функциями организации и информационными технологиями размываются и они взаимопроникают. Лидеры отрасли информационных технологий, такие как Microsoft, IBM и другие, развивают SOA в рекомендациях по проектированию информационных систем на своих программных платформах. А такие гиганты консалтинга, как Gartner, полагают, что сервис-ориентированная архитектура –это ведущий принцип проектирования основных и прикладных систем для обеспечения бизнес-процессов.
В основе современной успешной компании должна лежать процессно-ориентированная модель его функций. Комбинация этой методологии с концепцией сервис-ориентированной архитектуры позволяет увязать процесс разработки программных продуктов и систем с миссией, основными задачами и функциями организаций. Применяя SOA, организации разрабатывают набор реализаций различных бизнес-процессов, которые могут многократно использоваться предприятием как готовые сервисы. Сервис-ориентированная методология –подход к проектированию прикладных информационных систем, для которого характерны следующие принципы:
SOA – модель взаимодействия, которая связывает различные функциональные модули приложений между собой с помощью четко определяемых наборов данных и механизмов.
Одним из интеграционных шаблонов, который лежит в основе сервис-ориентированной архитектуры, как раз и является шаблон "Сервис". Механизмы взаимодействия сервисов не зависят от используемых платформ, операционных систем или языков программирования, на которых разрабатываются эти приложения. Это позволяет организовать взаимодействие сервисов между собой одним и тем же стандартным, но в то же время универсальным способом. Эта особенность использования сервисов, независимая от окружения и платформы, получила название "модель слабой связи". Ее очевидным преимуществом является повышенная гибкость и адаптируемость, поскольку замена или модернизация одной из компонент не сказывается на остальных.
Понятие SOA не является чем-то принципиально новым, так как сходные возможности реализовывались и ранее. Принципиальным фактором успешности и независимости сервисов от сходных технологий, распространенных ранее, является то, что подход к реализации сервис-ориентированной архитектуры охватывает не только технологический уровень обмена данными, но и уровень бизнес-логики. SOA– определенный эталон архитектуры, построенной на основе шаблонов проектирования, которая может и должна способствовать развитию процессной зрелости организации относительно простого масштабирования по функциональному и численному признакам.
Дополнительным атрибутом, который подчеркивает значимость сервис-ориентированной архитектуры, является специализированный язык BPEL (Business Process Executable Language for Web Services) для описания аспектов взаимодействия различных сервисов с точки зрения реализации бизнес-логики. Внедрение SOA как архитектуры подразумевает конкретный подход к разработке приложений (SODA – Service-Oriented Development Architecture).
В этом подходе функциональность SOA реализуется на уровне ее компонентов –web-сервисов.
Под web-сервисами понимаются программные системы, которые используют:
Если посмотреть на современные тенденции перехода к бизнесу "реального времени" и создания сетей, объединяющих конкретное предприятие, его поставщиков, партнеров и клиентов в единую систему, становится очевидно, что сервис-ориентированная архитектура найдет свое применение на всех уровнях корпоративных информационных систем.
При условии развитии подхода SOA взаимодействие между приложениями, как в рамках одной информационной системы, так и между отдельными участниками определенных бизнес-процессов, будет осуществляться с использованием сервисов, так что достаточно критическими становятся вопросы согласованной работы. Для описания и регламентации такой работы были предложены специальные термины:
Интеграцию используемых приложений целесообразно проводить с применением рассматриваемой технологии, когда определенная, наиболее важная часть существующей функциональности изолируется и представляется стандартизированным интерфейсом. При наличии существующей инфраструктуры web-сервисов на предприятии можно ожидать существенного сокращения сроков и затрат на последующую интеграцию новых систем.
Влияние SOA на изменения в архитектуре можно охарактеризовать как сбалансированный переход от централизованной инфраструктуры ИТ и замкнутого на себе функционала прикладных систем в сторону архитектуры, обеспечивающей возможности быстрого создания новых систем из набора доступных сервисов, т.е. более гибкой, динамичной и способной к взаимодействию.
В сервис-ориентированной архитектуре следует выделить следующие уровни, обеспечивающие ее функционирование:
Взаимодействие между уровнями осуществляется не напрямую, а через сервисы, выделенные на уровень определенного типа обработки событий. Эти компоненты архитектуры обеспечивают сбор данных о событиях в масштабе всего предприятия, необходимое преобразование и их маршрутизацию, а также обратную связь между сервисами каждого отдельного уровня.
Данная модель выделяет дополнительную компоненту архитектуры, которая описывает аспекты, связанные с жизненным циклом сервисов. MDA (Model Driven Architecture) является еще одной важной архитектурной концепцией создания информационных систем.
MDA является как обобщением идей SOA, так и постулированием необходимости применения концепции повторно используемых программных компонент (шаблонов, паттернов), предназначенных для повышения гибкости разрабатываемых приложений масштаба предприятия, чтобы обеспечить простоту обеспечения соответствия требованиям бизнеса в условиях изменения используемых инфраструктурных платформ.
MDA по определению является открытой и "нейтральной" по отношению к используемым технологиям интеграции. Она основана на следующих принципах:
В рамках MDA сначала создается архитектура, которая описывает модель бизнес-функциональности и поведения прикладной системы независимо от технических деталей реализации. Эта разработка должна вестись в контексте всей организации. Метамодель, не зависящая от платформы реализации, может быть разработана в одном или нескольких специфических вариантах для конкретной платформы. Это зависит от важности уже используемых платформ. На основе этих моделей разрабатывается код конкретной прикладной системы.
Рассматриваемый подход к построению архитектуры через использование шаблонов проектирования не определяет, какие языки разработки, операционные системы или программное обеспечение будет использоваться на практике. Упор делается на описание того, как прикладные системы организованы с точки зрения процессов и как они интегрированы между собой.
Сервис-ориентированная архитектура с использованием MDA является примером построения адаптивной, изменяемой и гибкой архитектуры современного инновационного предприятия с помощью шаблонов проектирования.
Современный опыт реализации программных приложений демонстрирует, что с условием применения шаблонов проектирования повышается эффективность труда отдельных исполнителей и всей группы в целом. Это происходит по многим причинам.
Проблемы коммуникации зачастую имеют куда более серьезные последствия, чем ошибки в коде программного обеспечения. Самые серьезные и дорогие ошибки, как все знают, совершаются в архитектуре. Чтобы минимизировать наступление подобных последствий, сообщество разработчиков, путем метода проб, ошибок и извлечения конструктивных итогов из деструктивной деятельности, пришло к осознанию необходимости применения именно шаблонов проектирования.
Как правило, команда или группа, вовлеченная в процесс разработки, состоит как из опытных разработчиков, так и из новичков, только начинающих свой путь в создании программных продуктов. В подобной среде становится возможным организовать эволюционный процесс передачи знаний от более к менее опытным сотрудникам. Совместная работа дает новичкам стимул и реальную возможность быстрее изучить и освоить новые концепции. Более того, шаблоны проектирования способствуют созданию единого информационного рабочего пространства, в котором разные по профессиональному профилю и опыту сотрудники постепенно начнут общаться на едином "сленге", используя общий глоссарий. Шаблоны проектирования также существенно способствуют выработке общего понимания основных принципов объектно-ориентированного проектирования, которое необходимо для создания успешных программных продуктов.
Шаблоны проектирования, о которых пойдет речь далее, классифицируются по различным параметрам. К примеру, можно упомянуть следующие: уровень сложности, детализация, охват проектируемого функционала, способ взаимосвязи "дочерних компонентов" и пр.
Практически все паттерны можно реализовать на любом языке программирования. Факторами, которые помогут правильным образом выбрать шаблон для конкретной рабочей ситуации, являются структура, функциональность и способ взаимодействия компонентов различного уровня программного продукта. Анализ и синтез требований, предъявляемых для данных характеристик информационных систем, будет способствовать определению наиболее успешного шаблона проектирования.
Предложенная ниже классификация основана на анализе и синтезе богатого практического опыта применения паттернов проектирования. Она во многом соответствует классификациям, предлагаемым в авторитетных отечественных и зарубежных источниках, и подкреплена большим статистическим массивом использования шаблонов:
Далее, по ходу книги, мы будем придерживаться предложенной классификации. Данная классификация предлагает сначала изучение наиболее значимых, с практической точки зрения, для внедрения и поддержки программных продуктов шаблонов проектирования, которые являются базисом любой информационной системы. К ним относятся архитектурные шаблоны проектирования. Затем идут наиболее востребованные на сегодня с точки зрения применения интеграционные шаблоны. В последующих главах будут представлены паттерны, которые описывают самые базовые принципы организации эффективной функциональности программных продуктов.
Приступая к работе над архитектурой приложения, необходимо помнить об основных принципах проектирования. Это поможет создать архитектуру, которая будет следовать проверенным подходам, обеспечит минимизацию затрат, простоту обслуживания, удобство использования и расширяемость.
К подобным архитектурам относятся те, которые отвечают следующим принципам:
Важным фактором, который поможет созданию гибких приложений, является предельное уменьшение количества точек соприкосновения. Неверное разграничение может привести к высокой связанности и сложностям взаимодействия, даже несмотря на слабое перекрытие функциональности отдельных компонентов.
Каждый отдельно взятый компонент или модуль должен отвечать только за одно конкретное свойство/функцию или их совокупность.
Компоненту или объекту не должны быть известны внутренние детали других компонентов или объектов.
В применении к проектированию приложения это означает, что определенная функциональность должна быть реализована только в одном компоненте и не должна дублироваться ни в одном другом компоненте.
Проектируйте только то, что необходимо. В некоторых случаях, когда стоимость разработки или издержки в случае неудачного дизайна очень высоки, может потребоваться полное предварительное проектирование и тестирование. В других случаях, особенно при гибкой разработке, можно избежать масштабного проектирования наперед. Если требования к приложению четко не определены или существует вероятность изменения дизайна со временем, старайтесь не тратить много сил на проектирование раньше времени.
За счет использования шаблонов можно добиться следующих результатов, необходимых в ходе процессов разработки программного обеспечения для создания эффективных корпоративных информационных систем:
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.