Sdm-модель клиент-серверной системы

Тип работы:
Реферат
Предмет:
ТЕХНИЧЕСКИЕ НАУКИ


Узнать стоимость

Детальная информация о работе

Выдержка из работы

sdm-модель клиент-серверной системы
А. О. Зверев, Б.Д. Тимченко
Рассматривается возможность применения технологии SDM для представления модели архитектуры клиент-серверной системы. В работе анализируется состояние вопроса и особенно состояние инструментальных средств создания моделей приложений. Иллюстрируется применение SDM-технологии на примере восстановления архитектуры фрагмента клиент-серверной системы, реализованной на платформе. Net.
Введение
В архитектуре современных распределенных систем (РИС) [1] повсеместно и в различных формах используется клиент-серверная организация, согласно которой сервер предоставляет клиенту обслуживание, определяемое как сервис. Данная абстракция применима на любом уровне рассмотрения — от нижнего уровня взаимодействия компонент до системы в целом. В соответствии с этим РИС стремятся рассматривать как совокупность IT-сервисов, из которых создается архитектура, обеспечивающая потребности бизнес-процессов и определяемая как сервис-ориентированная архитектура (Service-Oriented Architecture — SOA).
Движение к SOA означает не только отказ от «монолитных» и «жестких» информационных систем, но и дальнейшее существенное усложнение систем как в разработке, так и в управлении их использованием. Управляемость становится важнейшим эксплуатационным качеством современных РИС. Преодоление сложности в управлении IT-сервисами, создание соответствующих инструментальных средств всегда было в центре внимания компаний-разработчиков [2, 3], предлагающих различные решения для управления качеством обслуживания, анализа, управления изменениями. Это направление, определяемое как Information Technology Service Management (ITSM) -управление IT-сервисами, активно развивается в последние годы как методически, так и инструментально. Другое движение в преодолении сложности и обеспечении качества состоит в повсеместном использовании моделей: от моделирования бизнес-процессов до генеративных методов создания приложений на основе моделей. Данное направление — не новое, достаточно вспомнить многочисленные средства моделирования бизнес-процессов (IDEF, BPL, Windows Workflow и многие другие) или UML-базированные решения [4, 5]. Имеются впечатляющие результаты и не менее внушительные сложности. Одной из главных считается проблема слабой связи модельных решений, применяемых на различных этапах жизненного цикла систем, а также недостаточное внимание к проблеме управляемости.
В последнее время активную работу в развитии модельного подхода ведет компания Microsoft, что выразилось в объявлении инициативы DSI (Dynamic Systems Initiative) и масштабной работе по развитию методов и инструментов ее обеспечения. Основой подхода является концепция System Definition Model (SDM) и реализующий ее язык, инструментальные и технологические средства. В совокупности образована новая SDM-технология, впервые представленная в России в конце прошлого года в составе Visual Studio 2005 Team System (VS2005 TS).
Опыт использования технологии SDM еще только нарабатывается, в самой технологии еще неизбежны изменения, однако и в настоящем виде она заслуживает внимания и обобщения опыта. В данной работе представляется реализация SDM-модели одной из компонент клиент-серверного приложения, обладающего многими характерными признаками распределенных систем и разработанного на платформе. Net.
Жизненный цикл приложения
Создание и использование современных распределенных систем требует внимания к модельному обеспечению всех этапов жизненного цикла приложений. В идеале
необходим некий унифицированный подход, поддерживающий не только отдельные этапы, а жизненный цикл приложения в целом. Замысел SDM и его предварительное рассмотрение позволяет говорить как о перспективности технологии в указанном выше отношении, так и о необходимости детального исследования возможностей и выявления ограничений.
Будем рассматривать жизненный цикл приложения состоящим из этапов:
• разработка-
• развертывание-
• функционирование.
Заметим, что в таком же виде можно представить и жизненный цикл системы в целом. Полная переработка, крупные изменения в релизах и постоянные изменения, типичные для РИС, могут вызвать повторения этапов 1 и 2. Рассмотрим модельную и инструментальную обеспеченность отдельных этапов.
Разработка (Development) приложений, несомненно, является этапом, наилучшим образом обеспеченным моделями. В CASE-системе IBM Rational, базирующейся на UML, модельный подход реализован наиболее последовательно. Можно сослаться на многие другие реализации, например, Oracle Designer [6]. Разработка на основе моделей совершенствуется, и по этому вопросу имеется огромное количество публикаций. Полезно заметить, что модели, ориентированные на разработку, в той или иной степени связаны с моделированием бизнес-процессов. Другая деталь состоит в том, что модели этапа разработки пока не отражают свойств инфраструктуры, в которой приложения будут функционировать.
На стадии развертывания (Deployment) происходит в той или иной степени связывание приложения с ресурсами РИС в результате конфигурирования и действий по настройку параметров операционной системы и промежуточного ПО. Конфигурационные данные по различным причинам подвержены изменениям, что влечет за собой трудно предсказуемые изменения в работе приложений (качестве IT-сервисов). Обеспечение контроля за изменениями в методологии ITSM считается сложнейшей задачей и выделяется в отдельную составную часть Configuration and Change Management (Конфигурирование и управление изменениями). Важно заметить, что эта работа выполняется чаще всего без учета архитектуры приложений и модели этапа разработки.
На стадии функционирования (Operations) сервис реализуется, и здесь же проявляется влияние всех факторов, присущих конкретной инфраструктуре. Сервис существует как конкретный системный экземпляр ранее абстрактного приложения. На этой стадии возникают многочисленные проблемы и задачи — оценивание качества обслуживания сервиса, выявление проблем и оптимизация приложений, контроль за изменениями и воздействие на конфигурацию с целью достижения необходимых значений показателей функционирования. Распределенность многократно усложняет эти задачи по сравнению с централизованными системами.
Основной технологией обеспечения этапа функционирования является мониторинг и соответствующая обработка первичных данных для получения показателей функционирования. Это может быть обеспечено только на основе рациональной архитектуры мониторинга, которая, в свою очередь, должна учитывать архитектуру приложения и конфигурацию развернутого экземпляра.
Состояние модельно-инструментального обеспечения
В оценке перспектив использования любой новой технологии необходимо учитывать состояние и использование уже существующих средств. Наличие большого числа инструментов и подходов к рассматриваемым проблемам сильно усложняет получение аналитических оценок, являющихся к тому же в основном чисто качественными. В свя-
зи с этим для анализа нами избраны только наиболее масштабные и устоявшиеся подходы.
Не вызывает сомнения тот факт, что модельные подходы и решения, основывающиеся на UML, должны быть признаны наиболее распространенными. Имеется также значительный опыт их использования, который и дает основания для выводов. Применительно к обеспечению жизненного цикла приложений UML-технологии доказали эффективность на этапе проектирования и разработки. Их эффективность как инструмента бизнес-моделирования не столь очевидна, но это вопрос индивидуальных предпочтений. Что касается последующих этапов жизненного цикла приложений, то ситуация иная. Формально UML обеспечивает этап развертывания, предлагая для этого диаграммы развертывания (Deployment Diagrams), однако они практически являются средством иллюстрации, а не модельным инструментом, и далее никак не затрагивают конфигурирование. Этап функционирования UML-технологии не обеспечивают вообще. Универсальность UML в связи с этим практически проявляется в отношении предметных областей, для которых создаются приложения, а не этапов их жизненного цикла. Активным сторонником UML-технологии является фирма IBM, владеющая ведущим продуктом этого направления — CASE-платформой IBM Rational. Имеются многочисленные реализации технологий других разработчиков, оценка которых выходит за рамки нашей работы.
Этап функционирования всегда был предметом внимания как крупнейших, так и многих иных фирм. Вновь ограничимся лишь наиболее значительными решениями -HP OpenView и IBM Tivoli, решающими такие ключевые задачи, как конфигурирование, управление изменениями, мониторинг/оценивание и управление качеством обслуживания. Это мощные ITSM-ориентированные решения, прошедшие испытания временем. Оставляя подробности, отметим, что в этих решениях этап разработки никак не затрагивается.
Microsoft, позднее других развернувшая работы по обеспечению управляемости РИС, несомненно, учитывает имеющийся опыт. Амбициозное стремление реализовать некий унифицированный подход (этапы жизненного цикла) выражается в призыве создавать приложения с «мыслью» об их функционировании (Design for Operations). По нашему мнению, это дает основания для самого серьезного внимания к SDM-технологии, ее активной апробации и исследованиям в этом направлении.
Эксперимент на примере решения задачи обратного проектирования
SDM-технология [7, 8], реализованная в составе VS2005 TS, прежде всего ориентирована на применение в прямом проектировании и последующей жизни приложений. В этом случае SDM-модели создаются в ходе проектного процесса, естественным образом развиваясь и обеспечивая последовательные этапы жизненного цикла. Такой опыт, однако, ограничен самой новизной подхода, на освоение и накопление опыта нужно время.
Представляется, что общность подхода позволяет искать его применение и вне рамок прямого проектирования, в частности, в задаче обратного проектирования. Будем понимать под ней задачу восстановления архитектуры приложения на уровне выше исходного документированного текста. Практическую значимость этой задачи трудно переоценить: на этапах развертывания и функционирования документированная архитектура приложений часто вообще отсутствует.
Ориентация на сервисное представление, по нашему мнению, может быть достигнута, если модель (представление) архитектуры строить в терминах workflow. Это важно еще и потому, что этот механизм представление процессов реализован в Microsoft Windows Workflow Foundation и интегрирован в VS2005 TS. Ниже представляется экс-
перимент по обратному проектированию с использованием SDM-технологии, в котором исходной является одна из составляющих конкретной клиент-серверной системы, разработанной на платформе. Net без использования моделей.
В качестве конкретного примера восстановления архитектуры системы был взят один из этапов процесса инициализации системы. Этот процесс предполагает создание персистентных объектов всех типов и загрузку в них значений из базы данных. Следует понимать, что эти объекты взаимосвязаны, а, следовательно, имеется строгая последовательность в создании объектов.
На начальном этапе имеется исходный код приложения и набор инструментальных средств, обеспечивающих SDM-технологию. Рассмотрим предложенную последовательность действий решения поставленной задачи.
1. Производится построение диаграммы классов с использованием стандартного средства VS2005 Class Diagram (рис. 1). По диаграмме классов и исходному коду системы можно найти методы, образующие основу сервисов системы, с целью получения знания алгоритмов работы сервисов. Следует отметить, что полученная диаграмма имеет нотацию, отличную от UML, который в составе SDM-технологии не используется.
$-%
PersistentFacade А
. Class
MarshalByReFObject
В Fields
Connection ¦??Ф instance gt objectCacne Ь Methods
AddObject
** AddObject ToCache
CurrentDonnainFri…
а* FindObjectlnCache
* GetChangedOtgs…
V Getlnstance
* getlntSqlResult
GetObject
• GetObjectAil
• GetObjectsByType
¦ GetReferencGByC.
V GetUID
V IsObjectExist
% LoadObjectsFrom…
PersistentFacade
RermoveObject
Reset
• SetObjectChanged
Ы Events
/ ObjectChanged Ш Nested Types
v_J
InfoPullLogic 5]
Class
Id Fields
??ifoPull ^ persistentFacade Ь Properties
^ InfoPull ta Methods
AddObject
GetChangedObje…
* GetChangedGbje…
GetDocumentList
GetElementBylD
¦V GetElernentByType
GetNanne
GetObject
V GetObjectList
V GetObjectListByR.
V GetReferenceEiyC…
V GetRefUID
J* InfoPullLogic
V Reset
Рис. 1. Диаграмма классов
По полученной диаграмме представляется возможным сделать следующие выводы. В алгоритме задействованы класс логики InfoPullLogic и классы механизмов поддержки персистентных объектов: PersistentFacade, PersistentObject, InfoOb-jectBase, ЦГО. Как видно из диаграммы классов, эти классы не имеют между собой отношений типа наследования.
Рис. 2. Диаграмма последовательности вызовов
2. Производится построение диаграммы последовательности вызовов с использованием инструмента CodeLogic (рис. 2). Также при помощи этого инструмента можно построить необходимые представления диаграммы классов и блок-схемы работы метода. Целью является понимание алгоритма работы с использованием визуального представления работы метода. На полученной диаграмме последовательности вызовов видно, что при запуске конструктора класса InfoPullLogic выполняется получение экземпляра объекта PersistentFacade (Getlnstance). Далее, используя полученный экземпляр, выполняется последовательная загрузка данных по типам объектов (LoadObjectsFromDatabase).
3. Производится проектирование модели Workflow на основе полученных знаний и моделей на предшествующих этапах. Эта модель может быть разработана на основе двух типов шаблонов — последовательной модели и модели конечных автоматов, из которых нами была выбрана последовательная модель представления. Исходя из описания алгоритма, на основе полученных представлений выбираются два объекта, существующих независимо: InfoPullLogic и PersistentFacade. Изначально запускается конструктор класса InfoPullLogic. Во время его выполнения вызывается метод получения экземпляра класса PersistentFacade. При положительном результате в цикле происходит вызов функции LoadObjectsFromDatabase с передачей в качестве параметра необходимого типа объекта. После успешного завершения цикла процесс загрузки данных считается завершенным.
Полученная WF-модель может иметь графическое и текстовое представления, приведенные на рис. 3, 4, соответственно.

S)
Рис. 3. Workflow модель
iSequentialHorkflowActivity х: Иатае=& quot- S e quenc e & quot-
xmlns: x=, rhttp: yy schemas, microsoft. com/Kinfx/. SuOe/xaml"- xmlns-& quot-http: //schemas. microsoft. com/winfx/20G6/xaml/wcEkfiowrr& gt- & lt-СоdeActivity x: IJsme=rr se tins tance& quot- ExecuteСоde=& quot-setPFinstance"- /& gt- ClfE LseActivity x: Name= rrcheckP Fins tance& quot->-
ClfElseBranchActivity x: ±iame="-instanceTruere:'- I f E1 я eB eanchActi vity. Сondition& gt-
& lt-RuleConditionReference Conditionilame^'-instanceTrue& quot- fiA--& lt-?/IfElseBi:anchActivitY. Condition& gt- KjIЕЕ1seSгanchActivity& gt-
ClfElseEranckActivity x: Uame="- ins tance False & lt-IEE1seBranchActivity, Condition>-
& lt-RuleConditionRefenence С ondi tiohtiaiae=, r ins tance False& quot- /& gt- & lt-/IfElseBranchActivity. Ccndj.:, ion>-. ¦^TerminateActivity x- Нэпе=& quot-Exception"-
Erroi: = rr{ActivitYBind checkPFIn3tance, Path--iiame. }"- 1 /& gt- & lt-/1fE1 seBlanchActivity& gt- & lt-/IfElseActiviti>-
& lt-Whi1eAc tivi ty x: Каше-& quot-whi1eTyp e s & quot-«'- & lt-iihi le Activity. Condition& gt-
& lt-RuleConditiohReference С wiiii- titaicisiS /& gt- & lt-/WhiieActivity. Condition>-
& lt- С ode Activity x: IJame="-Load01i-jects"- ExacuteCode=rrLoadOb-jectsFEcmDataBase& quot- '- /& gt-'- & lt- /till i .1 e Ac ti vi ty& gt- '-.i / S e (?uenti allJo rk f 1 owAc tivi ty& gt-
Рис. 4. XML-описание Workflow-модели
Заключение
Технология SDM является перспективной как модельное обеспечение этапов жизненного цикла приложения. Хотя в настоящем виде технология реализуема только в среде. Net и, следовательно, только для однородных систем на платформе Microsoft, в будущем положение может измениться. Стандартизация языка, лежащего в основе SDM, происходит с участием ведущих компьютерных фирм, и в настоящее время имеется версия 1. 0, получившая название Service Modeling Language (SML). Весьма вероятно, что не только Microsoft, но и другие фирмы будут его использовать. Это открывает перспективу использования подхода и для гетерогенных систем.
Литература
1. Распределенные системы. Принципы и парадигмы. Э. Таненбаум, М. Ван Стеен. -СПб: Питер, 2003.
2. IBM On Demand Workplace & lt-http://www. ibm. com/ondemand/workplace>-
3. HP OpenView & lt-www. hp. ru/openview/>-
4. IBM Rational Software & lt-http://www-306. ibm. com/software/rational/>-
5. Современные методы и средства проектирования информационных систем. А. М. Вендров. & lt-http://www. citforum. ru/database/case/>-
6. Oracle Designer & lt-www. oracle. com/technology/products/designer>-
7. System Definition Model Overview White Paper & lt-www. microsoft. com/windowsserversystem/dsi/sdmwp. mspx>-
8. Overview of System Definition Model (SDM) & lt-http://msdn2. microsoft. com/en-us/library/ms181772(VS. 80). aspx>-

ПоказатьСвернуть
Заполнить форму текущей работой