Презентацию к данной лекции Вы можете скачать здесь.
Современные программные приложения и информационные системы достигли такого уровня развития, что термин "
Когда речь заходит об "архитектуре информационной системы", обычно не возникает недостатка в определениях. Есть даже Web-сайты, которые собирают такие определения [2].
Рассмотрим определение "архитектуры информационной системы", которое дают различные источники:
Хотя определения несколько отличаются, можно заметить немалую степень сходства. Например, большинство определений указывают на то, что
Под архитектурой программных систем будем понимать совокупность решений относительно [1, 10]:
По мере развития программных систем все большее значение приобретает их интеграция друг с другом с целью построения единого информационного пространства предприятия. Как можно видеть из вышеприведенных определений интеграция является важнейшим элементом
Для того чтобы построить правильную и надежную
Рассмотрим классификацию программных систем по их
Следует заметить, что, как и любая классификация, данная классификация архитектур информационных систем не является абсолютно жесткой. В
Далее подробно рассмотрим особенности каждой
Достоинства такой
Главным недостатком для пользователя является то, что он полностью зависит от администратора хост-ЭВМ. Пользователь не может настроить рабочую среду под свои потребности – все используемое программное обеспечение является коллективным.
Использование такой
Классическое представление
(рис 5.1) Классическое представление централизованной архитектуры
Центральная ЭВМ должна иметь большую память и высокую производительность, чтобы обеспечивать комфортную работу большого числа пользователей.
Все приложения, работающие в такой
Файл-серверные приложения – приложения, схожие по своей структуре с локальными приложениями и использующие сетевой ресурс для хранения программы и данных [13].
Классическое представление информационной системы в
(рис 5.2) Классическое представление архитектуры "файл-сервер"
Организация информационных систем на основе использования выделенных файл-серверов все еще является распространенной в связи с наличием большого количества персональных компьютеров разного уровня развитости и сравнительной дешевизны связывания PC в локальные сети [14].
Конечно, основным достоинством данной
Достоинства такой
Простое, работающее с небольшими объемами информации и рассчитанное на применение в однопользовательском режиме, файл-серверное приложение можно спроектировать, разработать и отладить очень быстро [14]. Очень часто для небольшой компании для ведения, например, кадрового учета достаточно иметь изолированную систему, работающую на отдельно стоящем PC. Однако, в уже ненамного более сложных случаях (например, при организации информационной системы поддержки проекта, выполняемого группой) файл-серверные архитектуры становятся недостаточными.
Клиент-сервер (
Первоначально системы такого уровня базировались на классической двухуровневой клиент-серверной архитектуре (Two-
Схематически такую
(рис 5.3) Классическое представление архитектуры "клиент-сервер"
На стороне клиента выполняется код приложения, в который обязательно входят компоненты, поддерживающие интерфейс с конечным пользователем, производящие отчеты, выполняющие другие специфичные для приложения функции.
Клиентская часть приложения взаимодействует с клиентской частью программного обеспечения управления базами данных, которая, фактически, является индивидуальным представителем СУБД для приложения.
Заметим, что интерфейс между клиентской частью приложения и клиентской частью
Наконец, клиентская часть
Посмотрим теперь, что же происходит на стороне
Разработчики и пользователи информационных систем, основанных на архитектуре "клиент-сервер", часто бывают неудовлетворены постоянно существующими сетевыми накладными расходами, которые следуют из потребности обращаться от клиента к серверу с каждым очередным запросом. На практике распространена ситуация, когда для эффективной работы отдельной клиентской составляющей информационной системы в действительности требуется только небольшая часть общей базы данных. Это приводит к идее поддержки
Фактически, концепция локального кэширования базы данных является частным случаем концепции реплицированных баз данных. Как и в общем случае, для поддержки
Преимуществами данной
При проектировании информационной системы, основанной на
Увеличение масштабов информационной системы не порождает принципиальных проблем. Обычным решением является замена аппаратуры сервера (и, может быть, аппаратуры рабочих станций, если требуется переход к локальному кэшированию баз данных). В любом случае практически не затрагивается прикладная часть информационной системы.
Также данный вид
Многоуровневая архитектура клиент-сервер (
Среди многоуровневой архитектуры клиент-сервер наиболее распространена трехуровневая
Схематически такую
(рис 5.4) Представление многоуровневой архитектуры "клиент-сервер"
В простейшей конфигурации физически
В "правильной" (с точки зрения безопасности, надежности, масштабирования) конфигурации
Плюсами данной
Некоторые авторы (например, Мартин Фаулер [18]) представляют
(рис 5.5) Пять уровней многозвенной архитектуры "клиент-сервер"
К представлению относится вся информация, непосредственно отображаемая пользователю: сгенерированные html-страницы, таблицы стилей, изображения.
Уровень представления охватывает все, что имеет отношение к общению пользователя с системой. К главным функциям слоя представления относятся отображение информации и интерпретация вводимых пользователем команд с преобразованием их в соответствующие операции в контексте логики и данных.
Уровень логики содержит основные функции системы, предназначенные для достижения поставленной перед ним цели. К таким функциям относятся вычисления на основе вводимых и хранимых данных, проверка всех элементов данных и обработка команд, поступающих от слоя представления, а также передача информации уровню данных.
Уровень доступа к данным – это подмножество функций, обеспечивающих взаимодействие со сторонними системами, которые выполняют задания в интересах приложения.
Данные системы обычно хранятся в базе данных.
Такой тип систем является более сложным с точки зрения организации системы. Суть распределенной системы заключается в том, чтобы хранить локальные копии важных данных [19].
Схематически такую
(рис 5.6) Архитектура распределенных систем
Более 95 % данных, используемых в управлении предприятием, могут быть размещены на одном персональном компьютере, обеспечив возможность его независимой работы [16]. Поток исправлений и дополнений, создаваемый на этом компьютере, ничтожен по сравнению с объемом данных, используемых при этом. Поэтому если хранить непрерывно используемые данные на самих компьютерах, и организовать обмен между ними исправлениями и дополнениями к хранящимся данным, то суммарный передаваемый трафик резко снизится. Это позволяет понизить требования к каналам связи между компьютерами и чаще использовать асинхронную связь, и благодаря этому создавать надежно функционирующие распределенные информационные системы, использующие для связи отдельных элементов неустойчивую связь типа Интернета, мобильную связь, коммерческие спутниковые каналы. А минимизация трафика между элементами сделает вполне доступной стоимость эксплуатации такой связи. Конечно, реализация такой системы не элементарна, и требует решения ряда проблем, одна из которых своевременная синхронизация данных.
Каждый АРМ независим, содержит только ту информацию, с которой должен работать, а актуальность данных во всей системе обеспечивается благодаря непрерывному обмену сообщениями с другими АРМами. Обмен сообщениями между АРМами может быть реализован различными способами, от отправки данных по электронной почте до передачи данных по сетям.
Еще одним из преимуществ такой схемы эксплуатации и
Такая
Распределенные системы с репликацией
Данными между различными рабочими станциями и
(рис 5.7) Архитектура распределенных систем с репликацией
Распределенные системы с элементами удаленного исполнения
Существуют определенные особенности, которые невозможно качественно реализовать на обычной распределенной системе репликативного типа. К этим особенностям можно отнести [19]:
У каждого из описанных типов используется общий принцип: программа клиент или обращается к выделенному (удаленному) серверу непосредственно или обращается к локальной базе, которая инкапсулирует в себе обращение к удаленному серверу (рис. 5.8).
(рис 5.8) Архитектура распределенных систем с удаленным исполнением
Обычно Веб-приложения создаются как приложения в архитектуре "клиент-сервер", но серверная часть имеет различные архитектурные решения [20].
Изначально World Wide Web (WWW) представлялась ее создателям как "пространство для обмена информацией, в котором люди и компьютеры могут общаться между собой". Поэтому первые Веб-приложения представляли собой примитивные файловые серверы, которые возвращали статические HTML-страницы запросившим их клиентам. Таким образом, Веб начиналась как документо-ориентированная.
Следующим этапом развития Веб стало появление понятия приложений, которые базировались на таких интерфейсах, как CGI (или FastCGI), а в дальнейшем – на ISAPI. Common Gateway Interface (CGI) – это стандартный интерфейс работы с серверами, позволяющий выполнять серверные приложения, вызываемые через URL. Входной информацией для таких приложений служило содержимое HTTP-заголовка (и тело запроса при использовании протокола POST). CGI-приложения генерировали HTML-код, который возвращался браузеру. Основной проблемой CGI-приложений было то, что при каждом клиентском запросе сервер выполнял CGI-программу в реальном времени, загружая ее в отдельное адресное пространство.
Появление
Интерфейс ISAPI – это особенность Microsoft Internet Information Server. ISAPI-приложения представляют собой динамические загружаемые библиотеки (DLL), которые выполняются в адресном пространстве Веб-сервера. У других Веб-серверов через некоторое время также появилась возможность выполнять приложения, реализованные в виде библиотек. В случае Веб-серверов Netscape этот программный интерфейс назывался
Естественно, что при использовании как CGI-, так и ISAPI-приложений разработчики в основном решали одни и те же задачи, поэтому естественным шагом стало появление нового, высокоуровневого интерфейса, который упростил задачи генерации HTML-кода, позволил обращаться к компонентам и использовать базы данных. Таким интерфейсом стала объектная модель Active Server Pages (ASP), построенная на основе ISAPI-фильтра.
Основной идеей ASP с точки зрения создания интерфейса приложения является то, что на Веб-странице присутствуют фрагменты кода, который интерпретируется Веб-сервером и вместо которого пользователь получает результат выполнения этих фрагментов кода.
Вскоре после появления ASP были созданы и другие технологии, реализующие идею размещения внутри Веб-страницы кода, выполняемого Веб-сервером. Наиболее известная из них на сегодняшний день – технология JSP (Java Server Pages), основной идеей которой является однократная компиляция Java-кода (сервлета) при первом обращении к нему, выполнение методов этого сервлета и помещение результатов выполнения этих методов в набор данных, отправляемых в браузер.
Новейшая версия технологии Active Server Pages – ASP .NET, являющаяся ключевой в
В общем случае клиентом Веб-сервера может быть не только персональный компьютер, оснащенный обычным Веб-браузером. Одновременно с широким распространением мобильных устройств появилась и проблема предоставления Веб-серверами данных, которые могут быть интерпретированы этими устройствами. Поскольку мобильные устройства обладают характеристиками, отличными от характеристик персональных компьютеров (ограниченным размером экрана, малым объемом памяти, а нередко и невозможностью отобразить что-либо, кроме нескольких строк черно-белого текста), для них существуют и другие протоколы передачи данных (WAP –
Другим способом поддержки различных типов клиентов является создание "разумных" серверных компонентов, которые способны генерировать различный код в зависимости от типа клиента. Такой подход, в частности, реализован в Microsoft ASP .NET.
Другим направлением развития клиентских частей Веб-приложений стало размещение некоторой части логики приложения (такой как проверка корректности вводимых данных) в самом Веб-браузере. В частности, современные Веб-браузеры способны интерпретировать скриптовые языки (VBScript, JavaScript), код на которых, как и ASP-код, внедряется в Веб-страницу, но интерпретируется не Веб-сервером, а браузером и соответственно выполняется на клиентском устройстве. Кроме того, современные браузеры способны отображать и выполнять Java-аплеты – специальные Java-приложения, которые пользователь получает в составе Веб-страницы, а некоторые из браузеров могут также служить контейнерами для элементов управления ActiveX – выполняющихся в адресном пространстве браузера специальных COM-серверов, также получаемых в составе Веб-страницы. И в Java-аплетах, и в элементах управления ActiveX можно реализовать практически любую функциональность.
Отметим, что с ростом объема используемых данных и числа посетителей Веб-сайтов возрастают и требования к надежности, производительности и масштабируемости Веб-приложений. Следующим этапом эволюции подобных приложений стало отделение бизнес-логики, реализованной в Веб-приложении, а нередко и сервисов обработки данных и реализации транзакций от его интерфейса. В этом случае в самом Веб-приложении обычно остается так называемая презентационная часть, а бизнес-логика, обработка данных и реализация транзакций переносятся в
Нередко подобные бизнес-объекты предоставляют доступ к данным корпоративных информационных систем либо реализуют какую-либо часть их функциональности. Нередко они позволяют, например, интегрировать Веб-сайт с CRM-системами (Customer Relationship Management) или с ERP-системами (Enterprise Resource Planning), сохраняя в корпоративных системах сведения о посетителях сайта и предоставляя потенциальным клиентам сведения об имеющейся продукции для осуществления заказов.
Поскольку современный Интернет – это не столько средство демонстрации присутствия компании на рынке или инструмент маркетинга, сколько инструмент ведения бизнеса, достаточно важными становятся задачи реализации организации через Интернет таких взаимоотношений с клиентами, как продажа товаров и услуг. И здесь довольно важными становятся решения для электронной коммерции типа "предприятие-клиент" (
Отметим, что, будучи составной частью подобного решения, Веб-сервер должен уметь не только выполнять приложения и взаимодействовать с
Следующим шагом эволюции Веб-приложений, помимо доступа к корпоративным данным и данным партнеров, стало получение доступа к корпоративным приложениям. Для решения этой задачи интеграции Веб-приложений с внутренними информационными системами предприятий и с приложениями, обеспечивающими взаимодействие с клиентами и партнерами, используются специальные решения, называемые корпоративными порталами.
Нередко частью портального решения являются средства управления информационным наполнением Веб-сайта – ведь объем данных, доступных пользователям с помощью сайтов крупных компаний и порталов, сейчас таков, что управление этими данными "вручную" не представляется возможным.
Обобщая вышесказанное можно выделить основные особенности веб-архитектуры [19, 20]:
Схематически такую
(рис 5.9) Архитектура Веб-приложений
Решение многих описанных выше задач, возникающих при создании современных Веб-приложений, теперь начинает возлагаться на Веб-сервисы – не зависящие от платформы, объектной модели и клиента программные компоненты, которые можно вызывать из клиентских Веб-приложений (а также из самих Веб-сервисов) через основанный на протоколе HTTP и языке XML протокол SOAP [20]. Для описания Веб-сервисов используется XML-подобный язык WSDL, а для организации реестров Веб-сервисов, в которых разработчики и компании могут искать необходимые им сервисы, а также публиковать данные о своих сервисах – интерфейс
Поддержка Веб-сервисов стала одним из главных стратегических направлений для многих компаний, специализирующихся на выпуске
В основе SOA лежат принципы многократного использования функциональных элементов ИТ, ликвидации дублирования функциональности в ПО, унификации типовых операционных процессов, обеспечения перевода операционной модели компании на централизованные процессы и
Компоненты программы могут быть распределены по разным узлам сети, и предлагаются как независимые, слабо связанные, заменяемые сервисы-приложения. Программные комплексы, разработанные в соответствии с SOA, часто реализуются как набор веб-сервисов, интегрированных при помощи известных стандартных протоколов (SOAP, WSDL, и т. п.)
Интерфейс компонентов SОА-программы предоставляет инкапсуляцию деталей реализации конкретного компонента (ОС, платформы, языка программирования, вендора, и т. п.) от остальных компонентов. Таким образом, SOA предоставляет гибкий и элегантный способ комбинирования и многократного использования компонентов для построения сложных распределенных программных комплексов.
SOA хорошо зарекомендовала себя для построения крупных корпоративных программных приложений. Целый ряд разработчиков и интеграторов предлагают инструменты и решения на основе SOA (например, платформы IBM WebSphere, Oracle/BEA Aqualogic, Microsoft Windows Communication Foundation, SAP NetWeaver, ИВК Юпитер, TIBCO, Diasoft).
Основными целями применения SOA для крупных информационных систем, уровня предприятия, и выше являются [21]:
Принципы SOA:
Главное, что отличает SOA, это использование независимых сервисов, с четко определенными интерфейсами, которые, для выполнения своих задач, могут быть вызваны неким стандартным способом, при условии, что сервисы заранее ничего не знают о приложении, которое их вызовет, а приложение не знает, каким образом сервисы выполняют свою задачу.
SOA также может рассматриваться как стиль
Таким образом, системы, основанные на SOA, могут быть независимы от технологий разработки и платформ (таких как Java, .NET и т. д.). К примеру, сервисы, написанные на C#, работающие на платформах .Net и сервисы на Java, работающие на платформах
SOA может поддерживать интеграцию и консолидацию операций в составе сложных систем, однако SOA не определяет и не предоставляет методологий или фреймворков для документирования сервисов.
Языки высокого уровня, такие как BPEL, или спецификации, такие как WS-CDL и WS-Coordination, расширяют концепцию сервиса, предоставляя метод оркестрации, для объединения мелких сервисов в более обширные бизнес-сервисы, которые, в свою очередь, могут быть включены в состав технологических процессов и бизнес-процессов, реализованных в виде составных приложений или порталов.
В качестве основы проектирования информационных систем применяются "типовые решения" или "
В 1970-е годы архитектор Кристофер Александр составил набор
В 1987 году Кент Бэк и Вард Каннигем взяли идеи Александра и разработали шаблоны применительно к разработке программного обеспечения для разработки графических оболочек на языке Smalltalk.
В 1988 году Эрих Гамма начал писать докторскую диссертацию при Цюрихском университете об общей переносимости этой методики на разработку программ.
В 1989-1991 годах Джеймс Коплин трудился над разработкой идиом для программирования на C++ и опубликовал в 1991 году книгу Advanced C++
Другим видным деятелем в области проектирования программных систем, который поддержал использование
В книге Крейга Лармана "Применение UML и
Главная польза каждого отдельного шаблона состоит в том, что он описывает решение целого класса абстрактных проблем. Также тот факт, что каждый шаблон имеет свое имя, облегчает дискуссию об абстрактных структурах данных (
Правильно сформулированный
Однако иногда шаблоны консервируют громоздкую и малоэффективную систему понятий, разработанную узкой группой. Когда количество шаблонов возрастает, превышая критическую сложность, исполнители начинают игнорировать шаблоны и всю систему, с ними связанную. Нередко шаблонами заменяется отсутствие или недостаточность документации в сложной программной среде.
Есть мнение, что слепое применение шаблонов из справочника, без осмысления причин и предпосылок выделения каждого отдельного шаблона, замедляет профессиональный рост программиста, так как подменяет творческую работу механическим подставлением шаблонов. Люди, придерживающиеся данного мнения, считают, что знакомиться со списками шаблонов надо тогда, когда "дорос" до них в профессиональном плане – и не раньше. Хороший критерий нужной степени профессионализма – выделение шаблонов самостоятельно, на основании собственного опыта. При этом, разумеется, знакомство с теорией, связанной с шаблонами, полезно на любом уровне профессионализма и направляет развитие программиста в правильную сторону. Сомнению подвергается только использование шаблонов "по справочнику".
Шаблоны могут пропагандировать плохие стили разработки приложений, и зачастую слепо применяются.
Также на сегодняшний день существует ряд других шаблонов [22]:
Рассмотрим подробнее некоторые из
К структурным
Приведем примеры 2-х их данных
| Компоновщик (Composite) – GoF | |
|---|---|
| Проблема | Как обрабатывать группу или композицию структур объектов одновременно? |
| Решение | Определить классы для композитных и атомарных объектов таким образом, чтобы они реализовывали один и тот же интерфейс.  (рис 5.10) 04_10 |
| Фасад (Facade) – GoF | |
| Проблема | Как обеспечить унифицированный интерфейс с набором разрозненных реализаций или интерфейсов, например, с подсистемой, если нежелательно высокое связывание с этой подсистемой или реализация подсистемы может измениться? |
| Решение | Определить одну точку взаимодействия с подсистемой – фасадный объект, обеспечивающий общий интерфейс с подсистемой и возложить на него обязанность по взаимодействию с ее компонентами. Фасад – это внешний объект, обеспечивающий единственную точку входа для служб подсистемы. Реализация других компонентов подсистемы закрыта и не видна внешним компонентам. Фасадный объект обеспечивает реализацию  (рис 5.11) 04_11 |
К поведенческим
Приведем примеры 3-х их данных
| Итератор (Iterator) или Курсор (Cursor) – GoF | |
|---|---|
| Проблема | Составной объект, например, список, должен предоставлять доступ к своим элементам (объектам), не раскрывая их внутреннюю структуру, причем перебирать список требуется по-разному в зависимости от задачи. |
| Решение |
Создается класс "Итератор", который определяет интерфейс для доступа и перебора элементов, "КонкретныйИтератор" реализует интерфейс класса "Итератор" и следит за текущей позицией при обходе "Агрегата". "Агрегат" определяет интерфейс для создания объекта – итератора. "КонкретныйАгрегат" реализует интерфейс создания итератора и возвращает экземпляр класса "КонкретныйИтератор", "КонкретныйИтератор" отслеживает текущий объект в агрегате и может вычислить следующий объект при переборе. Данный паттерн поддерживает различные способы перебора агрегата, одновременно могут быть активны несколько переборов.  (рис 5.12) 04_12 |
| Посетитель (Visitor) – GoF | |
| Проблема | Над каждым объектом некоторой структуры выполняется операция. Определить новую операцию, не изменяя классы объектов. |
| Решение |
Клиент, использующий данный паттерн, должен создать объект класса "КонкретныйПосетитель", а затем посетить каждый элемент структуры. "Посетитель" объявляет операцию "Посетить" для каждого класса "КонкретныйЭлемент" (имя и сигнатура данной операции идентифицируют класс, элемент которого посещает "Посетитель" – то есть, посетитель может обращаться к элементу напрямую). "КонкретныйПосетитель" реализует все операции, объявленные в классе "Посетитель". Каждая операция реализует фрагмент алгоритма, определенного для класса соответствующего объекта в структуре. Класс "КонкретныйПосетитель" предоставляет контекст для этого алгоритма и сохраняет его локальное состояние. "Элемент" определяет операцию "Принять", которая принимает "Посетителя" в качестве аргумента, "КонкретныйЭлемент" реализует операцию "Принять", которая принимает "Посетителя" в качестве аргумента. "СтруктураОбьекта" может перечислить свои аргументы и предоставить посетителю высокоуровневый интерфейс для посещения своих элементов. Данный паттерн логично использовать, если в структуре присутствуют объекты многих классов с различными интерфейсами, и необходимо выполнить над ними операции, зависящие от конкретных классов, или если классы, устанавливающие структуру объектов, изменяются редко, но новые операции над этой структурой добавляются часто. Данный паттерн упрощается добавление новых операций, объединяет родственные операции в классе "Посетитель". В данном  (рис 5.13) 04_13 |
| Состояние (State) – GoF | |
| Проблема | Варьировать поведение объекта в зависимости от его внутреннего состояния |
| Решение |
Класс "Контекст" делегирует зависящие от состояния запросы текущему объекту "КонкретноеСостояние" (хранит экземпляр подкласса "КонкретноеСостояние", которым определяется текущее состояние), и определяет интерфейс, представляющий интерес для клиентов. "КонкретноеСостояние" реализует поведение, ассоциированное с неким состоянием объекта "Контекст". "Состояние" определяет интерфейс для инкапсуляции поведения, ассоциированного с конкретным экземпляром "Контекста". Данный паттерн локализует зависящее от состояния поведение и делит его на части, соответствующие состояниям, переходы между состояниями становятся явными.  (рис 5.14) 04_14 |
К порождающим
Приведем примеры 2-х их данных
| Одиночка (Singleton) – GoF | |
|---|---|
| Проблема | Какой специальный класс должен создавать "Абстрактную фабрику" и как получить к ней доступ? Необходим лишь один экземпляр специального класса, различные объекты должны обращаться к этому экземпляру через единственную точку доступа. |
| Решение |
Создать класс и определить статический метод класса, возвращающий этот единственный объект. Разумнее создавать именно статический экземпляр специального класса, а не объявить требуемые методы статическими, поскольку при использовании методов экземпляра можно применить механизм наследования и создавать подклассы. Статические методы в языках программирования не полиморфны и не допускают перекрытия в производных классах. Решение на основе создания экземпляра является более гибким, поскольку впоследствии может потребоваться уже не единственный экземпляр объекта, а несколько.  (рис 5.15) 04_15 |
| Фабричный метод (Factory Method) или Виртуальный конструктор (Virtual Constructor) – GoF | |
| Проблема | Определить интерфейс для создания объекта, но оставить подклассам решение о том, какой класс инстанцировать, то есть, делегировать инстанцирование подклассам. |
| Решение |
Абстрактный класс "Создатель" объявляет Фабричный Метод, возвращающий объект типа "Продукт" (абстрактный класс, определяющий интерфейс объектов, создаваемых фабричным методом). "Создатель" также может определить реализацию по умолчанию Фабричного Метода, который возвращает "КонкретныйПродукт". "КонкретныйСоздатель" замещает Фабричный Метод, возвращающий объект "КонкретныйПродукт". "Создатель" "полагается" на свои подклассы в определении Фабричного Метода, возвращающего объект "КонкретныйПродукт".
Данный паттерн избавляет проектировщика от необходимости встраивать в код зависящие от приложения классы.
Однако при применении данного  (рис 5.16) 04_16 |
К структурным
Приведем пример одного их данных
| Многоуровневая система (Layers) или абстрактная машина | |
|---|---|
| Описание |
В соответствии с На рисунке показаны типичные уровни логической архитектуры системы.  (рис 5.17) 04_17
Слой представления охватывает все, что имеет отношение к общению пользователя с системой. К главным функциям слоя представления относится отображение информации и интерпретация вводимых пользователем команд с преобразованием их в соответствующие операции в контексте домена (бизнес – логики) и источника данных. Источник данных – подмножество функций, обеспечивающих взаимодействие со сторонними системами, которые выполняют В отличие от архитектурного Многоуровневая система может быть разработана пошагово (итеративно). Недостатками данного |
К
В данной лекции примеры
К
Приведем пример 4-х их данных
| Модель-представление-контроллер (Model View Controller) | |
|---|---|
| Описание |  (рис 5.18) 04_18
Типовое решение модель-представление-контроллер подразумевает выделение трех отдельных ролей. Модель – это объект, предоставляющий некоторую информацию о домене. У модели нет визуального интерфейса, она содержит в себе все данные и поведение, не связанные с пользовательским интерфейсом. В объектно-ориентированном контексте наиболее "чистой" формой модели является объект модели предметной области. В качестве модели можно рассматривать и сценарий транзакции, если он не содержит в себе никакой логики, связанной с пользовательским интерфейсом. Подобное определение не очень расширяет понятие модели, однако полностью соответствует распределению ролей в рассматриваемом типовом решении. Представление отображает содержимое модели средствами графического интерфейса. Таким образом, если модель – это объект покупателя, соответствующее представление может быть фреймом с кучей элементов управления или HTML-страницей, заполненной информацией о покупателе. Функции представления заключаются только в отображении информации на экране. Все изменения информации обрабатываются третьим "участником" системы – контроллером. Контроллер получает входные данные от пользователя, выполняет операции над моделью и указывает представлению на необходимость соответствующего обновления. В этом плане графический интерфейс можно рассматривать как совокупность представления и контроллера. Говоря о типовом решении модель-представление-контроллер, нельзя не подчеркнуть два принципиальных типа разделения: отделение представления от модели и отделение контроллера от представления. Отделение представления от модели – это один из фундаментальных принципов проектирования программного обеспечения. Наличие подобного разделения весьма важно по ряду причин: Ключевым моментом в отделении представления от модели является направление зависимостей: представление зависит от модели, но модель не зависит от представления. Это означает, что изменение представления не требует изменения модели. Отделение контроллера от представления. Классическим примером необходимости подобного разделения является поддержка редактируемого и нередактируемого поведения. Этого можно достичь при наличии одного представления и двух контроллеров (для двух вариантов использования), где контроллеры являются стратегиями, используемыми представлением. Между тем на практике в большинстве систем каждому представлению соответствует только один контроллер, поэтому разделение между ними не проводится. О данном решении вспомнили только при появлении Web-интерфейсов, где отделение контроллера от представления оказалось чрезвычайно полезным. |
| Контроллер страниц (Page Controller) | |
| Описание |  (рис 5.19) 04_19
В основе контроллера страниц лежит идея создания компонентов, которые будут выполнять роль контроллеров для каждой страницы Веб-сайта. На практике количество контроллеров не всегда в точности соответствует количеству страниц, поскольку иногда при щелчке на ссылке открываются страницы с разным динамическим содержимым. Если говорить более точно, контроллер необходим для каждого действия, под которым подразумевается щелчок на кнопке или гиперссылке. Контроллер страниц может быть реализован в виде сценария (сценария CGI, сервлета и т.п.) или страницы сервера (ASP, PHP, JSP и т.п.). Использование страницы сервера обычно предполагает сочетание в одном файле контроллера страниц и представления по шаблону. Это хорошо для представления по шаблону, но не очень подходит для контроллера страниц, поскольку значительно затрудняет правильное структурирование этого компонента. Данная проблема не столь важна, если страница применяется только для простого отображения информации. Тем не менее, если использование страницы предполагает наличие логики, связанной с извлечением пользовательских данных или выбором представления для отображения результатов, страница сервера может заполниться кодом "скриптлета", т.е. внедренного сценария. Чтобы избежать подобных проблем, можно воспользоваться вспомогательным объектом (helper object). При получении запроса страница сервера вызывает вспомогательный объект для обработки всей имеющейся логики. В зависимости от ситуации, вспомогательный объект может вернуть управление первоначальной странице сервера или же обратиться к другой странице сервера, чтобы она выступила в качестве представления. В этом случае обработчиком запросов является страница сервера, однако большая часть логики контроллера заключена во вспомогательном объекте. Возможной альтернативой описанному подходу является реализация обработчика и контроллера в виде сценария. В этом случае при поступлении запроса Веб-сервер передает управление сценарию; сценарий выполняет все действия, возложенные на контроллер, после чего отображает полученные результаты с помощью нужного представления. Ниже перечислены основные обязанности контроллера страниц. Контроллер страниц не обязательно должен представлять собой единственный класс, зато все классы контроллеров могут использовать одни и те же вспомогательные объекты. Это особенно удобно, если на Веб-сервере должно быть несколько обработчиков, выполняющих аналогичные задания. В этом случае использование вспомогательного объекта позволяет избежать дублирования кода. При необходимости одни адреса URL можно обрабатывать с помощью страниц сервера, а другие – с помощью сценариев. Те адреса URL, у которых нет или почти нет логики контроллера, хорошо обрабатывать с помощью страниц сервера, потому что последние представляют собой простой механизм, удобный для понимания и внесения изменений. Все остальные адреса, для обработки которых необходима более сложная логика, требуют применения сценариев. |
| Контроллер запросов (Front Controller) | |
| Описание |  (рис 5.20) 04_20
Контроллер запросов обрабатывает все запросы, поступающие к Веб-сайту, и обычно состоит из двух частей: Веб-обработчика и иерархии команд. Веб-обработчик – это объект, который выполняет фактическое получение POST- или GET-запросов, поступивших на Веб-сервер. Он извлекает необходимую информацию из адреса URL и входных данных запроса, после чего решает, какое действие необходимо инициировать, и делегирует его выполнение соответствующей команде. Веб-обработчик обычно реализуется в виде класса, а не страницы сервера, поскольку он не генерирует никаких откликов. Команды также являются классами, а не страницами сервера; более того, им не нужно знать о наличии Веб-окружения, несмотря на то, что им часто передается информация из HTTP-запросов. В большинстве случаев Веб-обработчик – это довольно простая программа, функции которой заключаются в выборе нужной команды. Выбор команды может происходить статически или динамически. Статический выбор команды подразумевает проведение синтаксического анализа адреса URL и применение условной логики, а динамический – извлечение некоторого стандартного фрагмента адреса URL и динамическое создание экземпляра класса команды. Преимущества статического выбора команды состоят в использовании явного кода, наличии проверки времени компиляции и высокой гибкости возможных вариантов написания адресов URL. В свою очередь, использование При динамическом выборе команд имя класса команды можно поместить непосредственно в адрес URL либо воспользоваться файлом свойств, который будет привязывать адреса URL к именам классов команд. Разумеется, это потребует создания дополнительного файла свойств, однако позволит легко и непринужденно изменять имена классов, не просматривая все имеющиеся на сервере Веб-страницы. |
| Представление по шаблону (Template View) | |
| Описание |  (рис 5.21) 04_21
Основная идея, лежащая в основе типового решения представление по шаблону, – вставка маркеров в текст готовой статической HTML-страницы. При вызове страницы для обслуживания запроса эти маркеры будут заменены результатами некоторых вычислений (например, результатами выполнения запросов к базе данных). Подобная схема позволяет создавать статическую часть страницы с помощью обычных средств, например текстовых редакторов, работающих по принципу WYSIWYG, и не требует знания языков программирования. Для получения динамической информации маркеры обращаются к отдельным программам. Представление по шаблону используется целым рядом программных средств. Таким образом, задача состоит не столько в том, чтобы разработать данное решение самому, сколько в том, чтобы научиться его эффективно использовать и познакомиться с возможными альтернативами. |
К структурным
В данной лекции примеры структурных
К
В данной лекции примеры
К
В данной лекции примеры
Рассмотрим в качестве дополнительной темы способы передачи данных в Веб. Эти знания понадобятся при рассмотрении следующих лекций.
Протокол HTTP имеет два самых часто используемых вида запросов GET и POST [26].
Основное различие методов GET и POST состоит в способе передачи данных веб-формы обрабатывающему скрипту, а именно [27]:
Используется для запроса содержимого указанного ресурса.
GET http://www.example.com/index.html HTTP/1.1
Данная команда говорит серверу "Дай мне файл index.html, который находится в директории (на сайте) http://www.example.com/".
С помощью метода GET можно также начать какой-либо процесс. В этом случае в тело ответного сообщения следует включить информацию о ходе выполнения процесса.
Клиент может передавать параметры выполнения запроса в URI целевого ресурса после символа "?":
GET /path/resource?param1=value1param2=value2 HTTP/1.1
Согласно стандарту HTTP, запросы типа GET считаются идемпотентными – многократное повторение одного и того же запроса GET должно приводить к одинаковым результатам (при условии, что сам ресурс не изменился за время между запросами). Это позволяет кэшировать ответы на запросы GET.
Кроме обычного метода GET, различают еще условный GET и частичный GET. Условные запросы GET содержат заголовки If-Modified-Since, If-Match, If-Range и подобные. Частичные GET содержат в запросе Range. Порядок выполнения подобных запросов определен стандартами отдельно.
Итак, все, что отображается в адресной строке и любые ссылки, на которые можно нажать или скопировать – все они используют GET. Этот вид запроса позволяет вам посылать информацию на сервер, делать с ней что-то на сервере, и возвращать результат.
POST, так как вся информация находится в заголовках.
GET ограничивает объем передаваемой информации (максимальная длина URL не оговаривается спецификациями протокола HTTP, но на практике она в каждом конкретном случае зависит как от версии браузера, так и от настроек сервера).
GET открыто пересылает введенную информацию в обрабатывающий сценарий, что может неблагоприятно сказаться на безопасности. Например, каждый человек, которому виден монитор вашего компьютера, может заметить введенный в форму пароль.
Применяется для передачи пользовательских данных заданному ресурсу.
Например, в блогах посетители обычно могут вводить свои комментарии к записям в HTML-форму, после чего они передаются серверу методом POST и он помещает их на страницу. При этом передаваемые данные включаются в тело запроса. Аналогично с помощью метода POST обычно загружаются файлы.
В отличие от метода GET, метод POST не считается идемпотентным, то есть многократное повторение одних и тех же запросов POST может возвращать разные результаты (например, после каждой отправки комментария будет появляться одна копия этого комментария).
Сообщение ответа сервера на выполнение метода POST не кэшируется.
POST может "симулировать" GET запрос, можно указывать параметры, как и в заголовке запроса, так и в теле.
POST в отличие от метода GET позволяет передавать запросу файлы.
GET, так как анализируются заголовки и тело запроса.
POST, нельзя добавить в закладки (СЕО-недружелюбен).
POST, после перехода с нее куда бы то ни было еще, довольно трудно. Internet Explorer, например, выдаст сообщение: "Внимание: страница устарела" с требованием нажать на кнопку "Обновить".
POST, для локального просмотра. Отмечаются также проблемы с распечаткой подобных документов.
В HTML формах можно указать, как отправлять информацию на сервер при помощи атрибута method:
<form method="get"> или <form method="post">
По умолчанию всегда используется GET.
При выборе использования методов POST и GET можно следовать следующим рекомендациям [30]:
GET.
Например:
ID записи/категории/новости и т.п.
POST и после записи данных, делать перенаправление (редирект) на страницу, где уведомлять, к примеру, что данные сохранены.
GET, POST.
Архитектура информационной системы – концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы.
Классификация программных систем по их архитектуре:
Протокол HTTP имеет два самых часто используемых вида запросов GET и POST. Основное различие методов GET и POST состоит в способе передачи данных веб-формы обрабатывающему скрипту.
Презентацию к данной лекции Вы можете скачать здесь.
Современные программные приложения и информационные системы достигли такого уровня развития, что термин "
Когда речь заходит об "архитектуре информационной системы", обычно не возникает недостатка в определениях. Есть даже Web-сайты, которые собирают такие определения [2].
Рассмотрим определение "архитектуры информационной системы", которое дают различные источники:
Хотя определения несколько отличаются, можно заметить немалую степень сходства. Например, большинство определений указывают на то, что
Под архитектурой программных систем будем понимать совокупность решений относительно [1, 10]:
По мере развития программных систем все большее значение приобретает их интеграция друг с другом с целью построения единого информационного пространства предприятия. Как можно видеть из вышеприведенных определений интеграция является важнейшим элементом
Для того чтобы построить правильную и надежную
Рассмотрим классификацию программных систем по их
Следует заметить, что, как и любая классификация, данная классификация архитектур информационных систем не является абсолютно жесткой. В
Далее подробно рассмотрим особенности каждой
Достоинства такой
Главным недостатком для пользователя является то, что он полностью зависит от администратора хост-ЭВМ. Пользователь не может настроить рабочую среду под свои потребности – все используемое программное обеспечение является коллективным.
Использование такой
Классическое представление
(рис 5.1) Классическое представление централизованной архитектуры
Центральная ЭВМ должна иметь большую память и высокую производительность, чтобы обеспечивать комфортную работу большого числа пользователей.
Все приложения, работающие в такой
Файл-серверные приложения – приложения, схожие по своей структуре с локальными приложениями и использующие сетевой ресурс для хранения программы и данных [13].
Классическое представление информационной системы в
(рис 5.2) Классическое представление архитектуры "файл-сервер"
Организация информационных систем на основе использования выделенных файл-серверов все еще является распространенной в связи с наличием большого количества персональных компьютеров разного уровня развитости и сравнительной дешевизны связывания PC в локальные сети [14].
Конечно, основным достоинством данной
Достоинства такой
Простое, работающее с небольшими объемами информации и рассчитанное на применение в однопользовательском режиме, файл-серверное приложение можно спроектировать, разработать и отладить очень быстро [14]. Очень часто для небольшой компании для ведения, например, кадрового учета достаточно иметь изолированную систему, работающую на отдельно стоящем PC. Однако, в уже ненамного более сложных случаях (например, при организации информационной системы поддержки проекта, выполняемого группой) файл-серверные архитектуры становятся недостаточными.
Клиент-сервер (
Первоначально системы такого уровня базировались на классической двухуровневой клиент-серверной архитектуре (Two-
Схематически такую
(рис 5.3) Классическое представление архитектуры "клиент-сервер"
На стороне клиента выполняется код приложения, в который обязательно входят компоненты, поддерживающие интерфейс с конечным пользователем, производящие отчеты, выполняющие другие специфичные для приложения функции.
Клиентская часть приложения взаимодействует с клиентской частью программного обеспечения управления базами данных, которая, фактически, является индивидуальным представителем СУБД для приложения.
Заметим, что интерфейс между клиентской частью приложения и клиентской частью
Наконец, клиентская часть
Посмотрим теперь, что же происходит на стороне
Разработчики и пользователи информационных систем, основанных на архитектуре "клиент-сервер", часто бывают неудовлетворены постоянно существующими сетевыми накладными расходами, которые следуют из потребности обращаться от клиента к серверу с каждым очередным запросом. На практике распространена ситуация, когда для эффективной работы отдельной клиентской составляющей информационной системы в действительности требуется только небольшая часть общей базы данных. Это приводит к идее поддержки
Фактически, концепция локального кэширования базы данных является частным случаем концепции реплицированных баз данных. Как и в общем случае, для поддержки
Преимуществами данной
При проектировании информационной системы, основанной на
Увеличение масштабов информационной системы не порождает принципиальных проблем. Обычным решением является замена аппаратуры сервера (и, может быть, аппаратуры рабочих станций, если требуется переход к локальному кэшированию баз данных). В любом случае практически не затрагивается прикладная часть информационной системы.
Также данный вид
Многоуровневая архитектура клиент-сервер (
Среди многоуровневой архитектуры клиент-сервер наиболее распространена трехуровневая
Схематически такую
(рис 5.4) Представление многоуровневой архитектуры "клиент-сервер"
В простейшей конфигурации физически
В "правильной" (с точки зрения безопасности, надежности, масштабирования) конфигурации
Плюсами данной
Некоторые авторы (например, Мартин Фаулер [18]) представляют
(рис 5.5) Пять уровней многозвенной архитектуры "клиент-сервер"
К представлению относится вся информация, непосредственно отображаемая пользователю: сгенерированные html-страницы, таблицы стилей, изображения.
Уровень представления охватывает все, что имеет отношение к общению пользователя с системой. К главным функциям слоя представления относятся отображение информации и интерпретация вводимых пользователем команд с преобразованием их в соответствующие операции в контексте логики и данных.
Уровень логики содержит основные функции системы, предназначенные для достижения поставленной перед ним цели. К таким функциям относятся вычисления на основе вводимых и хранимых данных, проверка всех элементов данных и обработка команд, поступающих от слоя представления, а также передача информации уровню данных.
Уровень доступа к данным – это подмножество функций, обеспечивающих взаимодействие со сторонними системами, которые выполняют задания в интересах приложения.
Данные системы обычно хранятся в базе данных.
Такой тип систем является более сложным с точки зрения организации системы. Суть распределенной системы заключается в том, чтобы хранить локальные копии важных данных [19].
Схематически такую
(рис 5.6) Архитектура распределенных систем
Более 95 % данных, используемых в управлении предприятием, могут быть размещены на одном персональном компьютере, обеспечив возможность его независимой работы [16]. Поток исправлений и дополнений, создаваемый на этом компьютере, ничтожен по сравнению с объемом данных, используемых при этом. Поэтому если хранить непрерывно используемые данные на самих компьютерах, и организовать обмен между ними исправлениями и дополнениями к хранящимся данным, то суммарный передаваемый трафик резко снизится. Это позволяет понизить требования к каналам связи между компьютерами и чаще использовать асинхронную связь, и благодаря этому создавать надежно функционирующие распределенные информационные системы, использующие для связи отдельных элементов неустойчивую связь типа Интернета, мобильную связь, коммерческие спутниковые каналы. А минимизация трафика между элементами сделает вполне доступной стоимость эксплуатации такой связи. Конечно, реализация такой системы не элементарна, и требует решения ряда проблем, одна из которых своевременная синхронизация данных.
Каждый АРМ независим, содержит только ту информацию, с которой должен работать, а актуальность данных во всей системе обеспечивается благодаря непрерывному обмену сообщениями с другими АРМами. Обмен сообщениями между АРМами может быть реализован различными способами, от отправки данных по электронной почте до передачи данных по сетям.
Еще одним из преимуществ такой схемы эксплуатации и
Такая
Распределенные системы с репликацией
Данными между различными рабочими станциями и
(рис 5.7) Архитектура распределенных систем с репликацией
Распределенные системы с элементами удаленного исполнения
Существуют определенные особенности, которые невозможно качественно реализовать на обычной распределенной системе репликативного типа. К этим особенностям можно отнести [19]:
У каждого из описанных типов используется общий принцип: программа клиент или обращается к выделенному (удаленному) серверу непосредственно или обращается к локальной базе, которая инкапсулирует в себе обращение к удаленному серверу (рис. 5.8).
(рис 5.8) Архитектура распределенных систем с удаленным исполнением
Обычно Веб-приложения создаются как приложения в архитектуре "клиент-сервер", но серверная часть имеет различные архитектурные решения [20].
Изначально World Wide Web (WWW) представлялась ее создателям как "пространство для обмена информацией, в котором люди и компьютеры могут общаться между собой". Поэтому первые Веб-приложения представляли собой примитивные файловые серверы, которые возвращали статические HTML-страницы запросившим их клиентам. Таким образом, Веб начиналась как документо-ориентированная.
Следующим этапом развития Веб стало появление понятия приложений, которые базировались на таких интерфейсах, как CGI (или FastCGI), а в дальнейшем – на ISAPI. Common Gateway Interface (CGI) – это стандартный интерфейс работы с серверами, позволяющий выполнять серверные приложения, вызываемые через URL. Входной информацией для таких приложений служило содержимое HTTP-заголовка (и тело запроса при использовании протокола POST). CGI-приложения генерировали HTML-код, который возвращался браузеру. Основной проблемой CGI-приложений было то, что при каждом клиентском запросе сервер выполнял CGI-программу в реальном времени, загружая ее в отдельное адресное пространство.
Появление
Интерфейс ISAPI – это особенность Microsoft Internet Information Server. ISAPI-приложения представляют собой динамические загружаемые библиотеки (DLL), которые выполняются в адресном пространстве Веб-сервера. У других Веб-серверов через некоторое время также появилась возможность выполнять приложения, реализованные в виде библиотек. В случае Веб-серверов Netscape этот программный интерфейс назывался
Естественно, что при использовании как CGI-, так и ISAPI-приложений разработчики в основном решали одни и те же задачи, поэтому естественным шагом стало появление нового, высокоуровневого интерфейса, который упростил задачи генерации HTML-кода, позволил обращаться к компонентам и использовать базы данных. Таким интерфейсом стала объектная модель Active Server Pages (ASP), построенная на основе ISAPI-фильтра.
Основной идеей ASP с точки зрения создания интерфейса приложения является то, что на Веб-странице присутствуют фрагменты кода, который интерпретируется Веб-сервером и вместо которого пользователь получает результат выполнения этих фрагментов кода.
Вскоре после появления ASP были созданы и другие технологии, реализующие идею размещения внутри Веб-страницы кода, выполняемого Веб-сервером. Наиболее известная из них на сегодняшний день – технология JSP (Java Server Pages), основной идеей которой является однократная компиляция Java-кода (сервлета) при первом обращении к нему, выполнение методов этого сервлета и помещение результатов выполнения этих методов в набор данных, отправляемых в браузер.
Новейшая версия технологии Active Server Pages – ASP .NET, являющаяся ключевой в
В общем случае клиентом Веб-сервера может быть не только персональный компьютер, оснащенный обычным Веб-браузером. Одновременно с широким распространением мобильных устройств появилась и проблема предоставления Веб-серверами данных, которые могут быть интерпретированы этими устройствами. Поскольку мобильные устройства обладают характеристиками, отличными от характеристик персональных компьютеров (ограниченным размером экрана, малым объемом памяти, а нередко и невозможностью отобразить что-либо, кроме нескольких строк черно-белого текста), для них существуют и другие протоколы передачи данных (WAP –
Другим способом поддержки различных типов клиентов является создание "разумных" серверных компонентов, которые способны генерировать различный код в зависимости от типа клиента. Такой подход, в частности, реализован в Microsoft ASP .NET.
Другим направлением развития клиентских частей Веб-приложений стало размещение некоторой части логики приложения (такой как проверка корректности вводимых данных) в самом Веб-браузере. В частности, современные Веб-браузеры способны интерпретировать скриптовые языки (VBScript, JavaScript), код на которых, как и ASP-код, внедряется в Веб-страницу, но интерпретируется не Веб-сервером, а браузером и соответственно выполняется на клиентском устройстве. Кроме того, современные браузеры способны отображать и выполнять Java-аплеты – специальные Java-приложения, которые пользователь получает в составе Веб-страницы, а некоторые из браузеров могут также служить контейнерами для элементов управления ActiveX – выполняющихся в адресном пространстве браузера специальных COM-серверов, также получаемых в составе Веб-страницы. И в Java-аплетах, и в элементах управления ActiveX можно реализовать практически любую функциональность.
Отметим, что с ростом объема используемых данных и числа посетителей Веб-сайтов возрастают и требования к надежности, производительности и масштабируемости Веб-приложений. Следующим этапом эволюции подобных приложений стало отделение бизнес-логики, реализованной в Веб-приложении, а нередко и сервисов обработки данных и реализации транзакций от его интерфейса. В этом случае в самом Веб-приложении обычно остается так называемая презентационная часть, а бизнес-логика, обработка данных и реализация транзакций переносятся в
Нередко подобные бизнес-объекты предоставляют доступ к данным корпоративных информационных систем либо реализуют какую-либо часть их функциональности. Нередко они позволяют, например, интегрировать Веб-сайт с CRM-системами (Customer Relationship Management) или с ERP-системами (Enterprise Resource Planning), сохраняя в корпоративных системах сведения о посетителях сайта и предоставляя потенциальным клиентам сведения об имеющейся продукции для осуществления заказов.
Поскольку современный Интернет – это не столько средство демонстрации присутствия компании на рынке или инструмент маркетинга, сколько инструмент ведения бизнеса, достаточно важными становятся задачи реализации организации через Интернет таких взаимоотношений с клиентами, как продажа товаров и услуг. И здесь довольно важными становятся решения для электронной коммерции типа "предприятие-клиент" (
Отметим, что, будучи составной частью подобного решения, Веб-сервер должен уметь не только выполнять приложения и взаимодействовать с
Следующим шагом эволюции Веб-приложений, помимо доступа к корпоративным данным и данным партнеров, стало получение доступа к корпоративным приложениям. Для решения этой задачи интеграции Веб-приложений с внутренними информационными системами предприятий и с приложениями, обеспечивающими взаимодействие с клиентами и партнерами, используются специальные решения, называемые корпоративными порталами.
Нередко частью портального решения являются средства управления информационным наполнением Веб-сайта – ведь объем данных, доступных пользователям с помощью сайтов крупных компаний и порталов, сейчас таков, что управление этими данными "вручную" не представляется возможным.
Обобщая вышесказанное можно выделить основные особенности веб-архитектуры [19, 20]:
Схематически такую
(рис 5.9) Архитектура Веб-приложений
Решение многих описанных выше задач, возникающих при создании современных Веб-приложений, теперь начинает возлагаться на Веб-сервисы – не зависящие от платформы, объектной модели и клиента программные компоненты, которые можно вызывать из клиентских Веб-приложений (а также из самих Веб-сервисов) через основанный на протоколе HTTP и языке XML протокол SOAP [20]. Для описания Веб-сервисов используется XML-подобный язык WSDL, а для организации реестров Веб-сервисов, в которых разработчики и компании могут искать необходимые им сервисы, а также публиковать данные о своих сервисах – интерфейс
Поддержка Веб-сервисов стала одним из главных стратегических направлений для многих компаний, специализирующихся на выпуске
В основе SOA лежат принципы многократного использования функциональных элементов ИТ, ликвидации дублирования функциональности в ПО, унификации типовых операционных процессов, обеспечения перевода операционной модели компании на централизованные процессы и
Компоненты программы могут быть распределены по разным узлам сети, и предлагаются как независимые, слабо связанные, заменяемые сервисы-приложения. Программные комплексы, разработанные в соответствии с SOA, часто реализуются как набор веб-сервисов, интегрированных при помощи известных стандартных протоколов (SOAP, WSDL, и т. п.)
Интерфейс компонентов SОА-программы предоставляет инкапсуляцию деталей реализации конкретного компонента (ОС, платформы, языка программирования, вендора, и т. п.) от остальных компонентов. Таким образом, SOA предоставляет гибкий и элегантный способ комбинирования и многократного использования компонентов для построения сложных распределенных программных комплексов.
SOA хорошо зарекомендовала себя для построения крупных корпоративных программных приложений. Целый ряд разработчиков и интеграторов предлагают инструменты и решения на основе SOA (например, платформы IBM WebSphere, Oracle/BEA Aqualogic, Microsoft Windows Communication Foundation, SAP NetWeaver, ИВК Юпитер, TIBCO, Diasoft).
Основными целями применения SOA для крупных информационных систем, уровня предприятия, и выше являются [21]:
Принципы SOA:
Главное, что отличает SOA, это использование независимых сервисов, с четко определенными интерфейсами, которые, для выполнения своих задач, могут быть вызваны неким стандартным способом, при условии, что сервисы заранее ничего не знают о приложении, которое их вызовет, а приложение не знает, каким образом сервисы выполняют свою задачу.
SOA также может рассматриваться как стиль
Таким образом, системы, основанные на SOA, могут быть независимы от технологий разработки и платформ (таких как Java, .NET и т. д.). К примеру, сервисы, написанные на C#, работающие на платформах .Net и сервисы на Java, работающие на платформах
SOA может поддерживать интеграцию и консолидацию операций в составе сложных систем, однако SOA не определяет и не предоставляет методологий или фреймворков для документирования сервисов.
Языки высокого уровня, такие как BPEL, или спецификации, такие как WS-CDL и WS-Coordination, расширяют концепцию сервиса, предоставляя метод оркестрации, для объединения мелких сервисов в более обширные бизнес-сервисы, которые, в свою очередь, могут быть включены в состав технологических процессов и бизнес-процессов, реализованных в виде составных приложений или порталов.
В качестве основы проектирования информационных систем применяются "типовые решения" или "
В 1970-е годы архитектор Кристофер Александр составил набор
В 1987 году Кент Бэк и Вард Каннигем взяли идеи Александра и разработали шаблоны применительно к разработке программного обеспечения для разработки графических оболочек на языке Smalltalk.
В 1988 году Эрих Гамма начал писать докторскую диссертацию при Цюрихском университете об общей переносимости этой методики на разработку программ.
В 1989-1991 годах Джеймс Коплин трудился над разработкой идиом для программирования на C++ и опубликовал в 1991 году книгу Advanced C++
Другим видным деятелем в области проектирования программных систем, который поддержал использование
В книге Крейга Лармана "Применение UML и
Главная польза каждого отдельного шаблона состоит в том, что он описывает решение целого класса абстрактных проблем. Также тот факт, что каждый шаблон имеет свое имя, облегчает дискуссию об абстрактных структурах данных (
Правильно сформулированный
Однако иногда шаблоны консервируют громоздкую и малоэффективную систему понятий, разработанную узкой группой. Когда количество шаблонов возрастает, превышая критическую сложность, исполнители начинают игнорировать шаблоны и всю систему, с ними связанную. Нередко шаблонами заменяется отсутствие или недостаточность документации в сложной программной среде.
Есть мнение, что слепое применение шаблонов из справочника, без осмысления причин и предпосылок выделения каждого отдельного шаблона, замедляет профессиональный рост программиста, так как подменяет творческую работу механическим подставлением шаблонов. Люди, придерживающиеся данного мнения, считают, что знакомиться со списками шаблонов надо тогда, когда "дорос" до них в профессиональном плане – и не раньше. Хороший критерий нужной степени профессионализма – выделение шаблонов самостоятельно, на основании собственного опыта. При этом, разумеется, знакомство с теорией, связанной с шаблонами, полезно на любом уровне профессионализма и направляет развитие программиста в правильную сторону. Сомнению подвергается только использование шаблонов "по справочнику".
Шаблоны могут пропагандировать плохие стили разработки приложений, и зачастую слепо применяются.
Также на сегодняшний день существует ряд других шаблонов [22]:
Рассмотрим подробнее некоторые из
К структурным
Приведем примеры 2-х их данных
| Компоновщик (Composite) – GoF | |
|---|---|
| Проблема | Как обрабатывать группу или композицию структур объектов одновременно? |
| Решение | Определить классы для композитных и атомарных объектов таким образом, чтобы они реализовывали один и тот же интерфейс. (рис 5.10) 04_10 |
| Фасад (Facade) – GoF | |
| Проблема | Как обеспечить унифицированный интерфейс с набором разрозненных реализаций или интерфейсов, например, с подсистемой, если нежелательно высокое связывание с этой подсистемой или реализация подсистемы может измениться? |
| Решение | Определить одну точку взаимодействия с подсистемой – фасадный объект, обеспечивающий общий интерфейс с подсистемой и возложить на него обязанность по взаимодействию с ее компонентами. Фасад – это внешний объект, обеспечивающий единственную точку входа для служб подсистемы. Реализация других компонентов подсистемы закрыта и не видна внешним компонентам. Фасадный объект обеспечивает реализацию (рис 5.11) 04_11 |
К поведенческим
Приведем примеры 3-х их данных
| Итератор (Iterator) или Курсор (Cursor) – GoF | |
|---|---|
| Проблема | Составной объект, например, список, должен предоставлять доступ к своим элементам (объектам), не раскрывая их внутреннюю структуру, причем перебирать список требуется по-разному в зависимости от задачи. |
| Решение |
Создается класс "Итератор", который определяет интерфейс для доступа и перебора элементов, "КонкретныйИтератор" реализует интерфейс класса "Итератор" и следит за текущей позицией при обходе "Агрегата". "Агрегат" определяет интерфейс для создания объекта – итератора. "КонкретныйАгрегат" реализует интерфейс создания итератора и возвращает экземпляр класса "КонкретныйИтератор", "КонкретныйИтератор" отслеживает текущий объект в агрегате и может вычислить следующий объект при переборе. Данный паттерн поддерживает различные способы перебора агрегата, одновременно могут быть активны несколько переборов. (рис 5.12) 04_12 |
| Посетитель (Visitor) – GoF | |
| Проблема | Над каждым объектом некоторой структуры выполняется операция. Определить новую операцию, не изменяя классы объектов. |
| Решение |
Клиент, использующий данный паттерн, должен создать объект класса "КонкретныйПосетитель", а затем посетить каждый элемент структуры. "Посетитель" объявляет операцию "Посетить" для каждого класса "КонкретныйЭлемент" (имя и сигнатура данной операции идентифицируют класс, элемент которого посещает "Посетитель" – то есть, посетитель может обращаться к элементу напрямую). "КонкретныйПосетитель" реализует все операции, объявленные в классе "Посетитель". Каждая операция реализует фрагмент алгоритма, определенного для класса соответствующего объекта в структуре. Класс "КонкретныйПосетитель" предоставляет контекст для этого алгоритма и сохраняет его локальное состояние. "Элемент" определяет операцию "Принять", которая принимает "Посетителя" в качестве аргумента, "КонкретныйЭлемент" реализует операцию "Принять", которая принимает "Посетителя" в качестве аргумента. "СтруктураОбьекта" может перечислить свои аргументы и предоставить посетителю высокоуровневый интерфейс для посещения своих элементов. Данный паттерн логично использовать, если в структуре присутствуют объекты многих классов с различными интерфейсами, и необходимо выполнить над ними операции, зависящие от конкретных классов, или если классы, устанавливающие структуру объектов, изменяются редко, но новые операции над этой структурой добавляются часто. Данный паттерн упрощается добавление новых операций, объединяет родственные операции в классе "Посетитель". В данном (рис 5.13) 04_13 |
| Состояние (State) – GoF | |
| Проблема | Варьировать поведение объекта в зависимости от его внутреннего состояния |
| Решение |
Класс "Контекст" делегирует зависящие от состояния запросы текущему объекту "КонкретноеСостояние" (хранит экземпляр подкласса "КонкретноеСостояние", которым определяется текущее состояние), и определяет интерфейс, представляющий интерес для клиентов. "КонкретноеСостояние" реализует поведение, ассоциированное с неким состоянием объекта "Контекст". "Состояние" определяет интерфейс для инкапсуляции поведения, ассоциированного с конкретным экземпляром "Контекста". Данный паттерн локализует зависящее от состояния поведение и делит его на части, соответствующие состояниям, переходы между состояниями становятся явными. (рис 5.14) 04_14 |
К порождающим
Приведем примеры 2-х их данных
| Одиночка (Singleton) – GoF | |
|---|---|
| Проблема | Какой специальный класс должен создавать "Абстрактную фабрику" и как получить к ней доступ? Необходим лишь один экземпляр специального класса, различные объекты должны обращаться к этому экземпляру через единственную точку доступа. |
| Решение |
Создать класс и определить статический метод класса, возвращающий этот единственный объект. Разумнее создавать именно статический экземпляр специального класса, а не объявить требуемые методы статическими, поскольку при использовании методов экземпляра можно применить механизм наследования и создавать подклассы. Статические методы в языках программирования не полиморфны и не допускают перекрытия в производных классах. Решение на основе создания экземпляра является более гибким, поскольку впоследствии может потребоваться уже не единственный экземпляр объекта, а несколько. (рис 5.15) 04_15 |
| Фабричный метод (Factory Method) или Виртуальный конструктор (Virtual Constructor) – GoF | |
| Проблема | Определить интерфейс для создания объекта, но оставить подклассам решение о том, какой класс инстанцировать, то есть, делегировать инстанцирование подклассам. |
| Решение |
Абстрактный класс "Создатель" объявляет Фабричный Метод, возвращающий объект типа "Продукт" (абстрактный класс, определяющий интерфейс объектов, создаваемых фабричным методом). "Создатель" также может определить реализацию по умолчанию Фабричного Метода, который возвращает "КонкретныйПродукт". "КонкретныйСоздатель" замещает Фабричный Метод, возвращающий объект "КонкретныйПродукт". "Создатель" "полагается" на свои подклассы в определении Фабричного Метода, возвращающего объект "КонкретныйПродукт".
Данный паттерн избавляет проектировщика от необходимости встраивать в код зависящие от приложения классы.
Однако при применении данного (рис 5.16) 04_16 |
К структурным
Приведем пример одного их данных
| Многоуровневая система (Layers) или абстрактная машина | |
|---|---|
| Описание |
В соответствии с На рисунке показаны типичные уровни логической архитектуры системы. (рис 5.17) 04_17
Слой представления охватывает все, что имеет отношение к общению пользователя с системой. К главным функциям слоя представления относится отображение информации и интерпретация вводимых пользователем команд с преобразованием их в соответствующие операции в контексте домена (бизнес – логики) и источника данных. Источник данных – подмножество функций, обеспечивающих взаимодействие со сторонними системами, которые выполняют В отличие от архитектурного Многоуровневая система может быть разработана пошагово (итеративно). Недостатками данного |
К
В данной лекции примеры
К
Приведем пример 4-х их данных
| Модель-представление-контроллер (Model View Controller) | |
|---|---|
| Описание | (рис 5.18) 04_18
Типовое решение модель-представление-контроллер подразумевает выделение трех отдельных ролей. Модель – это объект, предоставляющий некоторую информацию о домене. У модели нет визуального интерфейса, она содержит в себе все данные и поведение, не связанные с пользовательским интерфейсом. В объектно-ориентированном контексте наиболее "чистой" формой модели является объект модели предметной области. В качестве модели можно рассматривать и сценарий транзакции, если он не содержит в себе никакой логики, связанной с пользовательским интерфейсом. Подобное определение не очень расширяет понятие модели, однако полностью соответствует распределению ролей в рассматриваемом типовом решении. Представление отображает содержимое модели средствами графического интерфейса. Таким образом, если модель – это объект покупателя, соответствующее представление может быть фреймом с кучей элементов управления или HTML-страницей, заполненной информацией о покупателе. Функции представления заключаются только в отображении информации на экране. Все изменения информации обрабатываются третьим "участником" системы – контроллером. Контроллер получает входные данные от пользователя, выполняет операции над моделью и указывает представлению на необходимость соответствующего обновления. В этом плане графический интерфейс можно рассматривать как совокупность представления и контроллера. Говоря о типовом решении модель-представление-контроллер, нельзя не подчеркнуть два принципиальных типа разделения: отделение представления от модели и отделение контроллера от представления. Отделение представления от модели – это один из фундаментальных принципов проектирования программного обеспечения. Наличие подобного разделения весьма важно по ряду причин: Ключевым моментом в отделении представления от модели является направление зависимостей: представление зависит от модели, но модель не зависит от представления. Это означает, что изменение представления не требует изменения модели. Отделение контроллера от представления. Классическим примером необходимости подобного разделения является поддержка редактируемого и нередактируемого поведения. Этого можно достичь при наличии одного представления и двух контроллеров (для двух вариантов использования), где контроллеры являются стратегиями, используемыми представлением. Между тем на практике в большинстве систем каждому представлению соответствует только один контроллер, поэтому разделение между ними не проводится. О данном решении вспомнили только при появлении Web-интерфейсов, где отделение контроллера от представления оказалось чрезвычайно полезным. |
| Контроллер страниц (Page Controller) | |
| Описание | (рис 5.19) 04_19
В основе контроллера страниц лежит идея создания компонентов, которые будут выполнять роль контроллеров для каждой страницы Веб-сайта. На практике количество контроллеров не всегда в точности соответствует количеству страниц, поскольку иногда при щелчке на ссылке открываются страницы с разным динамическим содержимым. Если говорить более точно, контроллер необходим для каждого действия, под которым подразумевается щелчок на кнопке или гиперссылке. Контроллер страниц может быть реализован в виде сценария (сценария CGI, сервлета и т.п.) или страницы сервера (ASP, PHP, JSP и т.п.). Использование страницы сервера обычно предполагает сочетание в одном файле контроллера страниц и представления по шаблону. Это хорошо для представления по шаблону, но не очень подходит для контроллера страниц, поскольку значительно затрудняет правильное структурирование этого компонента. Данная проблема не столь важна, если страница применяется только для простого отображения информации. Тем не менее, если использование страницы предполагает наличие логики, связанной с извлечением пользовательских данных или выбором представления для отображения результатов, страница сервера может заполниться кодом "скриптлета", т.е. внедренного сценария. Чтобы избежать подобных проблем, можно воспользоваться вспомогательным объектом (helper object). При получении запроса страница сервера вызывает вспомогательный объект для обработки всей имеющейся логики. В зависимости от ситуации, вспомогательный объект может вернуть управление первоначальной странице сервера или же обратиться к другой странице сервера, чтобы она выступила в качестве представления. В этом случае обработчиком запросов является страница сервера, однако большая часть логики контроллера заключена во вспомогательном объекте. Возможной альтернативой описанному подходу является реализация обработчика и контроллера в виде сценария. В этом случае при поступлении запроса Веб-сервер передает управление сценарию; сценарий выполняет все действия, возложенные на контроллер, после чего отображает полученные результаты с помощью нужного представления. Ниже перечислены основные обязанности контроллера страниц. Контроллер страниц не обязательно должен представлять собой единственный класс, зато все классы контроллеров могут использовать одни и те же вспомогательные объекты. Это особенно удобно, если на Веб-сервере должно быть несколько обработчиков, выполняющих аналогичные задания. В этом случае использование вспомогательного объекта позволяет избежать дублирования кода. При необходимости одни адреса URL можно обрабатывать с помощью страниц сервера, а другие – с помощью сценариев. Те адреса URL, у которых нет или почти нет логики контроллера, хорошо обрабатывать с помощью страниц сервера, потому что последние представляют собой простой механизм, удобный для понимания и внесения изменений. Все остальные адреса, для обработки которых необходима более сложная логика, требуют применения сценариев. |
| Контроллер запросов (Front Controller) | |
| Описание | (рис 5.20) 04_20
Контроллер запросов обрабатывает все запросы, поступающие к Веб-сайту, и обычно состоит из двух частей: Веб-обработчика и иерархии команд. Веб-обработчик – это объект, который выполняет фактическое получение POST- или GET-запросов, поступивших на Веб-сервер. Он извлекает необходимую информацию из адреса URL и входных данных запроса, после чего решает, какое действие необходимо инициировать, и делегирует его выполнение соответствующей команде. Веб-обработчик обычно реализуется в виде класса, а не страницы сервера, поскольку он не генерирует никаких откликов. Команды также являются классами, а не страницами сервера; более того, им не нужно знать о наличии Веб-окружения, несмотря на то, что им часто передается информация из HTTP-запросов. В большинстве случаев Веб-обработчик – это довольно простая программа, функции которой заключаются в выборе нужной команды. Выбор команды может происходить статически или динамически. Статический выбор команды подразумевает проведение синтаксического анализа адреса URL и применение условной логики, а динамический – извлечение некоторого стандартного фрагмента адреса URL и динамическое создание экземпляра класса команды. Преимущества статического выбора команды состоят в использовании явного кода, наличии проверки времени компиляции и высокой гибкости возможных вариантов написания адресов URL. В свою очередь, использование При динамическом выборе команд имя класса команды можно поместить непосредственно в адрес URL либо воспользоваться файлом свойств, который будет привязывать адреса URL к именам классов команд. Разумеется, это потребует создания дополнительного файла свойств, однако позволит легко и непринужденно изменять имена классов, не просматривая все имеющиеся на сервере Веб-страницы. |
| Представление по шаблону (Template View) | |
| Описание | (рис 5.21) 04_21
Основная идея, лежащая в основе типового решения представление по шаблону, – вставка маркеров в текст готовой статической HTML-страницы. При вызове страницы для обслуживания запроса эти маркеры будут заменены результатами некоторых вычислений (например, результатами выполнения запросов к базе данных). Подобная схема позволяет создавать статическую часть страницы с помощью обычных средств, например текстовых редакторов, работающих по принципу WYSIWYG, и не требует знания языков программирования. Для получения динамической информации маркеры обращаются к отдельным программам. Представление по шаблону используется целым рядом программных средств. Таким образом, задача состоит не столько в том, чтобы разработать данное решение самому, сколько в том, чтобы научиться его эффективно использовать и познакомиться с возможными альтернативами. |
К структурным
В данной лекции примеры структурных
К
В данной лекции примеры
К
В данной лекции примеры
Рассмотрим в качестве дополнительной темы способы передачи данных в Веб. Эти знания понадобятся при рассмотрении следующих лекций.
Протокол HTTP имеет два самых часто используемых вида запросов GET и POST [26].
Основное различие методов GET и POST состоит в способе передачи данных веб-формы обрабатывающему скрипту, а именно [27]:
Используется для запроса содержимого указанного ресурса.
GET http://www.example.com/index.html HTTP/1.1
Данная команда говорит серверу "Дай мне файл index.html, который находится в директории (на сайте) http://www.example.com/".
С помощью метода GET можно также начать какой-либо процесс. В этом случае в тело ответного сообщения следует включить информацию о ходе выполнения процесса.
Клиент может передавать параметры выполнения запроса в URI целевого ресурса после символа "?":
GET /path/resource?param1=value1param2=value2 HTTP/1.1
Согласно стандарту HTTP, запросы типа GET считаются идемпотентными – многократное повторение одного и того же запроса GET должно приводить к одинаковым результатам (при условии, что сам ресурс не изменился за время между запросами). Это позволяет кэшировать ответы на запросы GET.
Кроме обычного метода GET, различают еще условный GET и частичный GET. Условные запросы GET содержат заголовки If-Modified-Since, If-Match, If-Range и подобные. Частичные GET содержат в запросе Range. Порядок выполнения подобных запросов определен стандартами отдельно.
Итак, все, что отображается в адресной строке и любые ссылки, на которые можно нажать или скопировать – все они используют GET. Этот вид запроса позволяет вам посылать информацию на сервер, делать с ней что-то на сервере, и возвращать результат.
POST, так как вся информация находится в заголовках.
GET ограничивает объем передаваемой информации (максимальная длина URL не оговаривается спецификациями протокола HTTP, но на практике она в каждом конкретном случае зависит как от версии браузера, так и от настроек сервера).
GET открыто пересылает введенную информацию в обрабатывающий сценарий, что может неблагоприятно сказаться на безопасности. Например, каждый человек, которому виден монитор вашего компьютера, может заметить введенный в форму пароль.
Применяется для передачи пользовательских данных заданному ресурсу.
Например, в блогах посетители обычно могут вводить свои комментарии к записям в HTML-форму, после чего они передаются серверу методом POST и он помещает их на страницу. При этом передаваемые данные включаются в тело запроса. Аналогично с помощью метода POST обычно загружаются файлы.
В отличие от метода GET, метод POST не считается идемпотентным, то есть многократное повторение одних и тех же запросов POST может возвращать разные результаты (например, после каждой отправки комментария будет появляться одна копия этого комментария).
Сообщение ответа сервера на выполнение метода POST не кэшируется.
POST может "симулировать" GET запрос, можно указывать параметры, как и в заголовке запроса, так и в теле.
POST в отличие от метода GET позволяет передавать запросу файлы.
GET, так как анализируются заголовки и тело запроса.
POST, нельзя добавить в закладки (СЕО-недружелюбен).
POST, после перехода с нее куда бы то ни было еще, довольно трудно. Internet Explorer, например, выдаст сообщение: "Внимание: страница устарела" с требованием нажать на кнопку "Обновить".
POST, для локального просмотра. Отмечаются также проблемы с распечаткой подобных документов.
В HTML формах можно указать, как отправлять информацию на сервер при помощи атрибута method:
<form method="get"> или <form method="post">
По умолчанию всегда используется GET.
При выборе использования методов POST и GET можно следовать следующим рекомендациям [30]:
GET.
Например:
ID записи/категории/новости и т.п.
POST и после записи данных, делать перенаправление (редирект) на страницу, где уведомлять, к примеру, что данные сохранены.
GET, POST.
Архитектура информационной системы – концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы.
Классификация программных систем по их архитектуре:
Протокол HTTP имеет два самых часто используемых вида запросов GET и POST. Основное различие методов GET и POST состоит в способе передачи данных веб-формы обрабатывающему скрипту.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.