Проектирование программных продуктов

Современный мир с каждым днем все более и более зависит от информационных систем. Программы – это основа, "цифровое сердце" повсеместно используемых электронных устройств, транспортных средств, финансовых сервисов, инфраструктурных объектов и пр.

Недавние инновации, которые стали частью нашей жизни и операционной деятельности, теперь воспринимаются как данность. Многих современных организаций просто не существовало бы, если бы программное обеспечение не достигло своего актуального уровня. Более того, нынешние гиганты различных традиционных и фундаментальных областей деятельности человечества все больше и больше зависят от программного обеспечения и качества его реализации. Трудно отыскать компанию, в которой не применялось бы ни одного программного продукта. В таких условиях только программное обеспечение, отвечающее самым высоким стандартам качества, может гарантировать компаниям мощный базис последующего развития и процветания. Но также важно, чтобы эти системы обладали доступной и обоснованной стоимостью.

Таким образом, становится очевидным, что для достижения необходимых параметров информационные системы должны обладать соответствующей архитектурой, поддерживающей заданные свойства. Для того чтобы достичь нужных характеристик, необходимо оптимальным образом организовать процесс проектирования будущей архитектуры создаваемых информационных систем. Решения, принимаемые на стадии проектирования, во многом являются определяющими для последующего жизненного цикла программного продукта.

Именно поэтому стадия проектирования предопределяет те фундаментальные параметры, которыми будет обладать разрабатываемая система в будущем. Тому, как организовать процесс проектирования, какой инструментарий использовать и как управлять необходимыми атрибутами, будет посвящена эта книга.

Введение

Такие понятия, как архитектура, проектирование и пр., ассоциируются в первую очередь с отраслью строительства, т.е. созданием сооружений. Эти термины используются для того, чтобы, с одной стороны, кратко, а с другой – полно выразить ощущения от восприятия конкретных сооружений: внешний вид, внутренняя обстановка, сочетание с окружающим ландшафтом и пр.

С программным обеспечением дело обстоит примерно так же. Под архитектурой и предваряющей ее стадией проектирования понимаются все те необходимые параметры, которые предопределяют создаваемые программные продукты.

"Для того чтобы уберечь бизнес от дезинтеграции, концепция создания архитектуры информационных систем перестает быть просто одной из возможных опций, а становится настоятельной необходимостью".

Дж. Захман

Для специалиста в области разработки программного обеспечения стадия проектирования и используемый инструментарий означают намного больше. Профессионал сразу сможет оценить все идеи и наработки, используемые для достижения необходимого результата. Также немаловажным фактором является и личность самого проектировщика.

В архитектуре информационных систем, так же как и в классической архитектуре, состав, структура и назначение компонент информационной системы, ее реальный эффект в том числе определяется субъективными аспектами восприятия со стороны конечных пользователей. Проработанный интерфейс, поддержка и развитие реально используемых функциональных возможностей создадут предпосылки для успеха и обеспечат его организации, эксплуатирующей информационную систему. Устаревшие приложения и архаичные технические средства станут тормозом продуктивной работы. Они должны будут разделить судьбу сооружений, канувших в лету обломков и руин.

Современный уровень развития информационных технологий с точки зрения стандартизации и совместимости сейчас, по мнению многих экспертов, соответствует уровню развития процессов урбанизации, промышленного производства примерно 80-х годов XIX века. В это время господствовали мелкие магазины, предлагающие товар, который требовалось подгонять под заказчика, поскольку единых стандартов не существовало. Изделия изготавливались под заказ в мастерских. Эта ситуация начала меняться, когда появилось массовое производство с применением сборочных линий и развитием сети железных дорог. Это привело к бурному росту распространения стандартизированных товаров.

Очевидно, что и в сфере IT предстоит пережить переход к новому уровню развития систем. Новый уровень будет характеризоваться повышением значимости стадии проектирования, увеличением взаимодействия между стандартными компонентами и пр.

Приведенные аналогии являются всего лишь авторским взглядом на затрагиваемый в данной книге предмет исследования. В определенном смысле сравнение со смежными областями, развитие которых занимает более высокий уровень зрелости, полезно – как для изучения возможностей предмета, так и для получения новых знаний.

Понятие архитектуры информационной системы не является чем-то принципиально новым, но в настоящее время наблюдается своеобразный ренессанс – достаточно обратить внимание на число публикаций в прессе и сети Интернет. Для этого должны существовать объективные причины, и главная из них, вероятно, связана с возможностью увеличения эффективности использования информационных технологий для основной деятельности организации.

Перед тем как перейти к процессу проектирования и, как следствие, к разработке оптимальной архитектуры, необходимо сформулировать цели, которых должна достигнуть создаваемая архитектура и способы ее разработки. Это поможет использовать уже имеющийся опыт в данной области и рекомендации отраслевых экспертов.

Одна из задач, которую предстоит решить на данном пути, состоит в том, что не существует простого, однозначного определения понятия IT-архитектуры. Акцент и трактовка данного предмета изменяются в зависимости от автора или издательства, поэтому важность отработанной дисциплины проектирования и ее инструментария выходят на первый план.

Можно утверждать, что дальнейшее развитие различных бизнес-направлений деятельности человечества приведет к соответствующим изменениям в IT-системах, а также целях и задачах их использования.

Высокая зрелость процессов проектирования информационных технологий позволит обеспечить определенный уровень стабильности, возможность "адаптировать" информационные системы под актуальные потребности бизнеса.

Основной принцип системного мышления гласит: "То, что является в меру хорошим для каждой части, обычно является наилучшим для всей системы в целом. Если одна часть изменяется, то это приводит к изменению остальных частей".

Качественная архитектура и зрелый процесс проектирования – компромисс между такими факторами, как:

В данной книге предпринята попытка систематизировать информацию о проектировании в целом и применяемых шаблонах в частности. Зачем они нужны? Как они могут помочь в ходе проектирования? Что нужно делать для того, чтобы в компаниях была возможность реализовывать оптимальные для бизнеса программные продукты?

Немного об архитектуре и истории проектирования программных продуктов

Архитектура программного обеспечения своими корнями связана с архитектурой зданий и сооружений и развивается по сходным канонам и принципам.

Шаблоны проектирования – это инструмент, разработанный в области архитектуры и культурологии. В 70-х годах XX века архитектор Кристофер Александер задумался над радом вопросов:

Александер, как истинный профессионал в своей области, размышлял о красоте с точки зрения архитектуры. Прежде всего его интересовало, по каким показателям оцениваются архитектурные проекты. Если кто-то вознамерился спроектировать крыльцо дома, то:

Александер в качестве постулата принял, что в области архитектуры такое объективное

основание существует. Утверждение, что здание является красивым,–это не вопрос вкуса. "Красоту" можно описать и измерить с помощью объективных критериев.

Похожими выводами закончилось схожее исследование, но в области культурологии.

В пределах одной культуры большинство индивидуумов имеют схожие представления о том, что является сделанным хорошо и что является красивым. В основе их суждений есть нечто более общее, чем сугубо индивидуальные представления о красоте.

Все это приводит к выводам о существовании "мета"-образов или шаблонов, которые могут являться объективными "шкалами" для оценки предметов в различных сферах деятельности.

Предпосылки к созданию шаблонов проектирования сферы разработки программного обеспечения заключались в потребности объективной оценки качества создаваемого программного обеспечения. Замысел оценки и описания программного обеспечения, которое отвечало бы заданным требованиям, оказался полностью воплотим на практике.

Но для этого необходимо ответить на следующий вопрос(более того, ответы на него следует воспринимать как "дорожную карту" процесса разработки программного обеспечения):

Качество продукта, без сомнения, является объективной категорией, поэтому можно явно отделить хорошее от плохого. Александер, изучая эту проблему, обследовал множество зданий, городов, улиц и всего прочего, что люди возводили для собственного проживания. В результате он обнаружил, что все, что было построено хорошо, имело между собой ряд общих признаков. Архитектурные структуры различны, даже если они относятся к одному и тому же типу объекта. Но это не является определяющим фактором, когда мы говорим о качестве создаваемого объекта.

К примеру, крыльцо в различных типах зданий может быть спроектировано и построено по-разному, но тем не менее обладать высоким качеством, решая при этом различные функциональные задачи: одно для прохода с тротуара ко входной двери, другое для создания мощной тени. В другом случае два крыльца могут решать одну и ту же задачу, но различными способами. Таким образом, стало очевидно, что сооружения нельзя рассматривать обособленно от проблемы, для решения которой они предназначены. Если сфокусировать внимание на структурах, предназначенных для решения подобных задач, можно обнаружить сходство между различными объектами, которым присуще высокое качество. Александер назвал такие структуры шаблонами.

Он определил шаблон как "решение проблемы в контексте". Каждый шаблон описывает проблему, которая возникает в определенной среде снова и снова, а затем предлагает принцип ее решения таким способом, который можно будет применять многократно, получая ожидаемый результат.

По мнению Александера, когда речь заходит о шаблонах проектирования, то в обязательном порядке должны присутствовать следующие атрибуты, характеризующие каждый шаблон:

Александер, подтвердив свое предположение на изученном массиве примеров и образцов, принял, что с помощью шаблонов может быть решена любая архитектурная задача. Затем он высказал утверждение о том, что совместное использование нескольких шаблонов позволит решать комплексные архитектурные проблемы. О способе применения нескольких шаблонов в одном решении мы поговорим немного позже. Стоит отметить, что вся сложность транспонирования понятия архитектуры на область информационных технологий заключается еще и в том, что помимо понятия "архитектура программного обеспечения" мы постоянно будем сталкиваться с такими понятиями, как "корпоративная архитектура", "системная архитектура", "организационная архитектура", "архитектура информации", "архитектура аппаратного обеспечения", "архитектура приложения", "архитектура инфраструктуры" и т. д.

На сегодня в отрасли не существует однозначного понимания значения каждого из этих терминов или их взаимоотношений. В результате одни и те же термины могут иметь разные значения, а два или более терминов могут обозначать одно и то же. Просто примем, что эти разные термины существуют и призваны описывать разные материальные или информационные объекты.

Актуальность темы "шаблонного" проектирования

Современный мир сложно представить себе без мобильного или стационарного девайса. Они созданы для облегчения каждодневных, операционных и других потребностей отдельных людей или определенных сообществ и групп.

Сами по себе девайсы – не более чем куски высококачественного пластика с добавлением металлических элементов. Но вот их "начинка" во многом является тем преимуществом, которое позволяет им выйти в лидеры профильных рынков или занять свою коммерческую нишу.

Почему же вопросы применения эффективных шаблонов проектирования при последующей разработке программных продуктов становятся особенно актуальны именно сейчас?

Объяснение может основываться на целой совокупности факторов, основные из которых связаны с:

По результатам опроса руководителей информационных служб было получено представлений о наиболее существенном изменении роли информационных технологий для бизнеса.

Создание "более совершенных" процессов стоит на первом месте и получило специальное название "слияние бизнес-процессов". Фактически в результате такого слияния осуществляется преобразование бизнеса с помощью объединения ранее существовавших автономных процессов (например, поставка, сбыт, управление клиентами) на основе интенсивного использования возможностей IT.Однако именно существующие информационные системы, наряду с корпоративной культурой, являются одним из важнейших ограничений на пути таких преобразований – часто из-за ошибок, допущенных при их проектировании и последующей эксплуатации.

К числу характерных изменений бизнеса, которые оказывают существенное влияние на использование информационных технологий, относятся:

Последний фактор нуждается в более подробном рассмотрении. Сейчас активно обсуждаются такие понятия, как "Интернет вещей", "цифровая трансформация бизнеса".

Под ними понимается способность и возможность к реализации бизнес-инициатив с широким использованием интеграции между сотрудниками отдельно взятого предприятия, клиентами, партнерами, материальными объектами, задействованными в формировании результата деятельности организации.

На практике фактически это означает следование следующим основным принципам:

Современные условия осуществления бизнеса характеризуются существенным сокращением времени выполнения всех процессов. Операции должны занимать секунды вместо дней, сроки жизни продуктов снижаются с десятилетий до десятков месяцев, преобразования в организациях становятся все более частыми и реализуются в течение нескольких месяцев вместо нескольких лет, требовавшихся ранее.

Изменения в окружающей бизнес-среде все чаще происходят за более короткие промежутки времени, чем организация способна отреагировать. Это и является причиной того, что время, требующееся для перехода на новые бизнес-процессы и для реализации бизнес-стратегии, является новым "узким местом".

С другой стороны, при планировании инвестиций в IT критичным становится факт существенного сокращения характерного времени изменения для бизнес-процессов и организационной структуры компании – с 10 лет до порядка 3 лет, с перспективой дальнейшего сокращения до полутора-двух лет. В связи с этим наблюдается очевидное несоответствие между временными рамками краткосрочного планирования IT в рамках годовых бюджетов и реализацией крупных IT-проектов – таких как внедрение ERP-систем, требующее 2–3 лет.

Понятие "Предприятие реального времени" (RTE – RealTimeEnterprise) было предложено для отражения стиля осуществления бизнеса, когда "актуальная на каждый момент времени информация о критичных для бизнеса процессах используется для получения конкурентных преимуществ за счет постоянного сокращения задержек в управлении". Само это определение не содержит никакого упоминания об информационных технологиях, так как характеризует прежде всего основную деятельность компании. Однако нет сомнения в том, что достижение данной цели возможно только на основе широкого использования IT.

На сегодня организации столкнулись с увеличением количества данных реального времени, используемых для управления компаниями, т.е. данных о деятельности организации, получаемых с запаздыванием всего в несколько часов. Акцентируем внимание на том, что речь идет о управлении предприятия в целом (продажи, доставка, склад, управление и т.д.), а не об управлении отдельными процессами.

Основной критический фактор для обеспечения функциональности предприятия реального времени будет связан с оперативным развитием коммуникационных возможностей. Это потребует как революционных изменений в одних подсистемах, например широкого внедрения беспроводных технологий или обеспечения изменения пропускной способности по запросу, так и существенного увеличения пропускной способности или качества традиционно используемых каналов связи. Другими важными технологиями в свете развития такого стиля ведения бизнеса будут являться электронный документооборот, взаимодействие и обмен сообщениями в реальном времени, системы позиционирования/слежения за объектами по меткам, хранилища данных реального времени и т.п. Ведущие производители аппаратного и программного обеспечения, такие как Microsoft, IBM, Oracle, выступили в последнее время со стратегическими инициативами, направленными на поддержку новых стилей ведения бизнеса, включая RTE. Концепция предприятия реального времени базируется на интеграции практически всего, что связано с деятельностью организации:

Основой этого являются информационные технологии, в более широком смысле – архитектура предприятия в целом.

Другое важное следствие – предпосылки к реализации сервис-ориентированной архитектуры (SOA). Суть этого понятия составляет все более модульная реализация прикладных систем и доступность отдельных функций, реализуемых этими системами, в виде сервисов (услуг) для других информационных систем. Технологической основой такого взаимодействия между системами по принципу предоставления друг другу услуг является технология web-сервисов, влияние которой на будущую архитектуру IT предприятий можно сравнить разве что с влиянием Интернета на мировые коммуникации.

Успешная реализация этих принципов основана на широком использовании возможностей и средств информационных систем организации. Критическим условием для обеспечения работы информационных систем является определенный уровень развития IT-архитектуры. В противном случае цели бизнеса просто не будут достигнуты из-за ограничений в технологии и несовместимости между информационными системами разных участников процесса.

Вначале фокус применения IT был связан с "кусочной" автоматизацией отдельных наиболее понятных или же выгодных в ближайшей перспективе операций. При этом основной эффект достигался за счет сокращения времени или стоимости выполнения существующих функций. Сейчас же на первый план выходит возможность изменения самого бизнеса или деловых процессов организации за счет внедрения соответствующих сервисов или продуктов.

На сегодня существует множество разнообразных способов и подходов к реализации качественного программного обеспечения, способного оправдатьлюбые, самые смелые ожидания. Трудно выделить какой-то единый фактор, который будет являться определяющим на пути достижения конечного успешного результата от внедрения и эксплуатации программного обеспечения. При этом существуют характеристики, которые вносят весомый вклад в создание успешных информационных систем настоящего и будущего:

Часть этих факторов –взаимозависимые и оказывают влияние на другие характеристики разрабатываемого программного обеспечения. Некоторые из них на данном этапе развития сферы информационных технологий являются фундаментальными. Основным фактором, по ряду параметров, является гибкость, которая обеспечивает надежность и качество разрабатываемого программного обеспечения. По определению, ненадежность и низкий уровень качества разработки препятствует ее гибкости и уменьшает ее. Создаваемая архитектура, которая в последующем будет препятствовать внесению необходимых изменений, в итоге сведет на нет и отработанный процесс разработки, и качественную архитектуру. Данный постулат предопределяет важность формирования адекватной целевой архитектуры и необходимость отражения в ней тех характеристик, которые критичны для конкретного программного продукта. Откуда же появляется "оптимальная" архитектура?

Архитектура – это проявление человеческих знаний.

Разработка программного обеспечения – наукоемкий труд, который влечет за собой процесс обучения: обучения методологиям, пониманию желаний заказчика, общению с разработчиками требований к продуктам, наиболее эффективным способам разработки решений (от практических методик до подбора вариантов), а также совместной работе.

Наиболее важным и значимым этапом в создании архитектуры программных продуктов является стадия проектирования, которая является началом пути любой разработки. Учитывая этот факт, будет неразумно и безответственно заранее принимать все самые важные решения касательно развития информационной системы. С другой стороны, при завершении проекта мы получаем наибольшее количество знаний, но и наименьшую возможность применения их на практике, так как продукт, по сути, уже разработан.

От процесса архитектуре нужно временное "пространство" и время на обучение, что само по себе не приемлет спешки в начале работы. Ни в коем случае нельзя рассматривать процесс как готовый продукт в самом начале его создания.

Понимание наиболее правильных и оптимальных решений, как правило, приходит во время попыток классифицировать наиболее значимые факторы и рассуждать о них.

То, что вы можете построить, находится в прямой зависимости от того, как вы будете это строить; а то, как вы будете это строить, напрямую зависит от специфических конструктивных особенностей и ограничивается ими. Эта тесная взаимосвязь между архитектурой и процессом означает, что разработчики архитектуры должны мыслить за пределами технологий. В связи с этим значимость шаблонов проектирования, эффективность которых проверена на большом временном интервале и большом количестве разработанных систем, только повышается. Шаблоны проектирования не говорят о том, как надо развивать продукт, –они задают рамки, очерченные определенными потребностями, в которых становится возможным развить продукт в соответствии с заложенными в него ожиданиями и потребностями пользователей. Применение шаблонов проектирования позволит создать гибкие и надежные продукты, которые могут стать базисом последующего инновационного и успешного развития любой компании.

Применение шаблонов проектирования – это достаточно важный выбор не столько специалистов в области анализа или разработки программных продуктов, сколько руководства, которое должно отдавать себе отчет в том, что использование паттернов задает определенный уровень сложности, который должны поддерживать и развивать специалисты. В награду за это компания получит продукт, который сможет быстро реагировать на изменяющиеся внутренние и внешние условия функционирования предприятия и приносить этим прибыль организации.

Основы проектирования архитектуры информационных систем

Архитектура, как основной объект проектирования, нуждается в продуманных и эффективных шаблонах, которые смогут позволить реализовать оптимальные программные продукты, учитывающие все необходимые детали, обеспечивающие ее успешность.

Она определяется наиболее важными и значимыми решениями по поводу структуры программы и взаимодействия модулей в ее предполагаемых рамках. Другими словами, можно сказать, что архитектура состоит из наиболее значимых и определяющих решений, принятых во время процесса проектирования, которые должны обеспечить свойства и характеристики, реализующие основные ожидания пользователей.

Архитектура связана со структурой и взаимодействием модулей и компонентов.

Вместе с определением структурных элементов любая архитектура определяет взаимодействия между этими структурными элементами. Эти взаимодействия должны обеспечивать желаемое поведение системы.

Стоит отметить, что архитектура определяет не все в структуре и в ее поведении. Она занимается только такими элементами, которые оцениваются как значимые на текущий период ее жизненного цикла. Под значимыми элементами понимаются те, которые имеют продолжительное и устойчивое действие– например, главные структурные элементы, связанные с основным поведением и определением значимых свойств, такие как надежность, масштабируемость и пр.

Архитектура не имеет отношения к мелким деталям программных продуктов. Архитектурную значимость можно также назвать экономической значимостью, поскольку главный признак, по которому некоторые элементы оцениваются выше остальных, – это стоимость создания и стоимость изменения.

Архитектура фокусируется только на самых значимых элементах и характеристиках, она предлагает нам конкретную перспективу оцениваемой системы – перспективу, которая наиболее значима для разработчика архитектуры. Именно поэтому шаблоны проектирования, т.е. решения, учитывающие необходимые детали разрабатываемых систем, получают дополнительную значимость, когда речь идет о создании продуктов, поддерживающих заданный уровень качества.

Архитектура – это некое шаблонное обобщение системы, помогающее управлять комплексной сложностью программного продукта.

Набор значимых элементов не является статичным понятием и изменяется во время создания или эксплуатации конкретного программного продукта. Он может меняться при следующих событиях:

Стабильность разработанной архитектуры, несмотря на возможные изменения требований и условий, в которых она будет эксплуатироваться, в определенной степени является признаком "хорошей" архитектуры, отлаженного процесса разработки, хорошего разработчика. Если архитектура требует постоянного пересмотра при относительно небольших изменениях, это плохой признак. Но необходимо помнить о том, что любая архитектура призвана также обеспечить и уравновесить потребности заинтересованных сторон. Она во многом создается для удовлетворения комплекса потребностей профильных пользователей. Но, с другой стороны, возникают ситуации, когда затруднительно выполнить все выраженные пожелания. В этом случае необходимо задуматься о компромиссе в отношении высказанных требований и ресурсных возможностей для достижения наиболее вероятного результата деятельности.

Аналогично, различные заинтересованные лица могут иметь совершенно разные потребности, и здесь также должно быть достигнуто определенное равновесие. Именно поэтому достижение компромиссных решений является главным аспектом процесса разработки архитектуры, а преодоление трудностей – неотъемлемой чертой каждого успешного архитектора. Кроме всего прочего, важный аспект на пути достижения конечного результата, представленного в виде оптимальной архитектуры, – это ее логическое обоснование. Необходимо обеспечить документирование решений, которые привели к созданию архитектуры. Эта информация является значимой для многих заинтересованных лиц, особенно для тех, кто должен обслуживать систему в дальнейшем. Она часто имеет ценность для разработчика архитектуры, когда ему нужно пересмотреть логические обоснования принятых решений, чтобы избежать ненужного повторения своих действий.

Каждая логически обоснованная архитектура соответствует определенному стилю, который рассматривается как определенный вид шаблона. Архитектурный стиль – система шаблонов, представляющая собой осознанный и синтезированный опыт проектировщика.

Архитектурный стиль определяет набор компонентов и типов звеньев, а также набор условий, в соответствии с которыми они могут соединяться.

Шаблон проектирования– это решение конкретной проблемы/задачи в четко определенном контексте. Применение и использование шаблонов при создании архитектуры позволит сосредоточиться на принятии особо важных решений, определяющих архитектуру и ее успех, а необходимые для реализации детали, их взаимосвязь и количество определяется конкретным шаблоном, выбранным для реализации архитектуры.

Для чего необходимо изучать шаблоны проектирования

После того как мы попытались однозначно и обоснованно донести, что такое шаблоны проектирования и какова их значимость для реализации информационных систем, целесообразно попытаться ответить на вопрос: "Зачем их нужно изучать?".

Среди наиболее популярных предпосылок к изучению шаблонов проектирования и последующему их применению выделяют следующие:

Применение шаблонов проектирования в процессах разработки программного обеспечения позволят "увидеть лес за деревьями". Когда удается подняться на более высокий уровень абстракции при обсуждении рабочих вопросов, становятся доступны новые методы проектирования. Именно в этом состоит основное преимущество использования шаблонов проектирования.

Постоянное применение на практике знаний и принципов проектирования

Утверждение о том, что технологии и их применение на сегодняшний день –одна из основных составляющих успеха любой компании, уже неоспоримо. Успешные организации вынуждены подстраиваться под высокий ритм изменений, диктуемый актуальным состоянием экотехнологических процессов, пронизывающих современный мир.

Именно то, как быстро компании смогут адаптироваться под динамично меняющиеся условия глобальных и локальных рынков, будет определять их способность функционирования.

Руководителей компаний волнуют такие темы, как технологии, цифровая трансформация компаний и связь между этими двумя вещами. При этом очень часто, будучи специалистами в своих предметных областях, они не понимают технологий, а иногда и боятся их. Все, что они знают, – это то, что технологии приводят к серьезным переменам в бизнесе, и лучше им уделять должное внимание, поскольку всегда есть опасность, что какая-нибудь новая технология подкрадется незаметно сзади и ударит по голове.

Шаблоны проектирования приложений, описанные в этой книге, обеспечат руководителям некоторую гарантию того, что инновационная информационная технология не будет безальтернативным выходом из складывающихся обстоятельств конкретной организации.

Самая насущная проблема в области разработки корпоративных информационных систем–необходимость синхронизации и последующей модернизации информационного ландшафта компании с целями бизнеса. Руководство мыслит в терминах бизнес-моделей, процессов и функций, а сотрудников IT беспокоят вопросы того, как конкретные технологии интегрировать в общую архитектуру предприятия. В результате очень часто образуется разрыв между ожиданиями и конкретной реализацией.

Очевидно, что способ обеспечения связей между бизнес-целями и ITнеобходим каждой компании. Крупным организациям нужен единый синхронный подход, который позволит создать согласованные между собой программные продукты.

Распространяемый сегодня подход к построению эффективного бизнеса сосредоточивается на концепции "архитектура предприятия", одной из частей которых является архитектура программных продуктов. Без понимания основного источника преимуществ организации и их развития достаточно затруднительно сформировать ясные базисные требования для "архитектуры предприятия".В связи с этим повышается важность постоянного, поточного использования подходов, которые смогут трансформировать высокоуровневые требования, отраженные в концептуальных документах в вид понятных задач для реализации в конкретных программных продуктах.

Стратегия компании должна однозначно определять направления развития бизнеса организации и причины движения в данном направлении.

Задачи архитектуры и шаблонов проектирования должны идентифицировать информационные системы и их компоненты, которые требуются для поддержки бизнес-процессов. Шаблоны проектирования приложений определяют архитектуру компании, которая при надлежащей степени зрелости, определяемой не только технологической развитостью, но и косвенными процессами, такими как документирование и совершенствование, гарантирует быстрое и надежное внесение изменений, необходимых для поддержки бизнес-деятельности.

Одним из основных факторов на пути достижения коммерческого успеха является постоянное и повсеместное использование шаблонов проектирования, сочетающихся между собой. Только при условии стандартизированного применения концепции "шаблонного проектирования" можно гарантировать ступенчатую и качественную трансформацию бизнес-замыслов на уровень информационных систем без значительной потери сути смысла выполняемых разработок. Когда "шаблоны проектирования" станут частью "гена" архитектуры организации и будут использоваться на всех этапах жизненного цикла программных продуктов – с момента внедрения до стадии утилизации, – компания сможет прогнозировать и планировать свою информационную трансформацию с высокой степенью достоверности последующей реализации. В этой связи значимость шаблонов проектирования как "переходного звена" трансформации концептуальных замыслов в рабочую автоматизированную функциональность приобретает дополнительную значимость и ценность.

Размышление о будущем проектирования

Факторы, которые составляют базис архитектуры организации, будут способствовать ее дальнейшему совершенствованию или станут основным препятствием в развитии.

Эти факторы определяются ожиданиями и требованиями бизнес-пользователей для достижения быстрых результатов, поддержки изменяющихся стилей работ и процессов.

Можно выделить следующие направления, которые должны поддерживаться шаблонами проектирования приложения для достижения оптимальной информационной архитектуры:

Предложенный список факторов не является полным и достаточным. Текущие условия развития архитектур программных продуктов отличаются высокой динамикой и степенью изменчивости, и это приводит к тому, что отдельные информационные системы подвергаются полному, но постепенному эволюционному реинжинирингу методом рефакторинга один раз в несколько лет.

Можно с уверенностью сказать, что это – реалии современного рынка программных продуктов, которые бесполезно игнорировать и к которым необходимо адаптироваться. Шаблоны проектирования – средство, которое сможет позволить реализовывать поэтапную трансформацию программных продуктов, поддерживая при этом высокий уровень качества информационных систем за счет детальной проработки основной функциональности, необходимой для их целостной реализации.

Выводы

При использовании шаблонов проектирования следует руководствоваться набором следующих принципов:

В самом начале проекта уделите достаточное количество времени и внимания для принятия правильных решений– это обеспечит создание более гибкого дизайна, внесение изменений в который не потребует полной его переработки. Следует начинать с базовой архитектуры, создавая над ней полную картину, после чего прорабатывая возможные варианты. Не следует пытаться сделать все и сразу. Проектировать следует настолько "глубоко", насколько это необходимо для начала использования программного продукта. Усложнять продукт следует постепенно, в процессе многократного рефакторинга, чтобы убедиться прежде всего в правильности принятых крупных решений и лишь затем сосредоточиваться на деталях. Общей ошибкой, свойственной всем начинающим проектировщикам, является быстрый переход к деталям при ошибочном представлении о правильности крупных решений.

Шаблоны проектирования — это один из инструментов разработчика, который помогает ему сэкономить время и создать более качественное решение.

Нужно помнить о том, что шаблоны проектирования не связаны с каким-то конкретным языком программирования. Это подход к проектированию, который представляет исполнителю средство для итеративной проработки деталей с условием сохранения целостного и полного взгляда на решение в целом.