KNOW INTUIT, Лекция, Методи за анализ на обекти и изграждане на модели на домейн

4.2.2. Системен подход към архитектурния дизайн

Един от начините за архитектурно проектиране е традиционният неформален подход за определяне на архитектурата на системата, състава на нейните компоненти, как те са представени и комбинирани във взаимосвързана система. Всъщност създаваната архитектура се състои от четири нива, които включват:

1. Системни компоненти, които установяват интерфейс с оборудване и апарати;
2. Общи системни компоненти, които установяват интерфейс с универсални компютърни системи;
3. Специфични бизнес компоненти;
4. Приложни софтуерни системи.

1во ниво- компоненти на системата. Те взаимодействат с периферните устройства на компютрите (принтери, клавиатури, скенери, манипулатори и др.) и се използват при изграждането на операционни системи.

2-ро ниво- компоненти за цялата система. Те осигуряват взаимодействие със системите за универсално обслужване на операционната среда на приложната система, като операционни системи, СУБД, системи за база знания, системи за управление на мрежата и др. Компонентите на този слой се използват в много приложения като основни градивни елементи.

3-то ниво- специфични компоненти на определена проблемна област, са съставни компоненти на софтуерни системи и са предназначени за решаване на различни проблеми (например бизнес проблеми).

4-то ниво- приложни софтуерни системи, които изпълняват специфични задачи на отделни групи потребители на информация от различни предметни области (офис системи, счетоводни системи и др.), могат да използват компоненти от по-ниско ниво.

Компоненти на всеки от избранитенивата се използват, като правило, на тяхното ниво или по-високо. Всяко ниво отразява съответния набор от знания, умения и способности на специалисти, които създават или използват компоненти. Този набор определя подходящото разделение на специалистите по софтуерно инженерство (системни инженери, приложни инженери, програмисти и др.).

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

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

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

Архитектурната схема може да бъде: разпределена, клиент-сървър и многостепенна.

Разпределената схемаосигурява взаимодействие между системни компоненти, разположени на различни компютри чрез стандартни RPC (Remote Procedure Calls), RMI (Remote Method Invocation) механизми, които се изпълняват от междинни среди (COM/DCOM, CORBA, Java и др.) [4.15, 4.16]. Взаимодействащите компоненти могат да бъдат разнородни, в различни езици за програмиране (C, C++, Pascal, Java, Basic, Smalltalk и т.н.), които са разрешени в междинната среда на системата CORBA (фиг. 4.6). За всяка двойка езици на взаимодействащи компоненти се създават интерфейси от типа Li, Ln според броя на двойките PL на системата, които позволяват взаимодействие помежду си.

Схемата клиент-сървър етри ниваОсновният проблем на тази схема е достъпът до ресурси (хардуер, софтуер и данни) и тяхното разделяне. В архитектурата клиент-сървър сървърът управлява и осигурява достъп до ресурсите, а клиентът ги използва. Архитектурата се основава на разпределени обекти, които капсулират ресурс и предоставят услуги на други обекти.

Обектите, предоставящи услуги, също могат да използват услугите на други обекти. Функцията за взаимодействие на обекта се изпълнява от брокера на заявки за обекти (ORB) чрез интерфейса клиент-сървър, той също така предоставя услуги за цялата система, услуги и различни ресурси. Процесът на разработване на разпределени обекти започва с формирането на изисквания, проектирането на сървърни обекти, които могат да предоставят услуги на клиентски обекти.

UML или Unified Process се използва като инструмент за проектиране на обектиRUP [4.17, 4.18]. Връзките между обектите и техните типове (операции и атрибути) на сървъра и клиента се дефинират чрез диаграми на класове. Взаимодействието на обекта се моделира с помощта на сценарии на взаимодействие или диаграми на последователност. Диаграмите на състоянието задават ограничения върху операциите към сървърни обекти, се преобразуват (генерират) в интерфейси (stubs), които определят структурата и поведението на сървърните обекти (фиг. 4.7).

Клиентските пънове се използват в класове, чиито екземпляри са клиентски обекти. При внедряване на сървърни обекти се използва пън, чийто тип е наследен от типа на сървърния пън. Интерфейсите са описани на езика IDL и са поставени в междинния слой на системата CORBA. Stubs предоставят операции и съответните списъци с формални параметри. При извикване клиентът предава действителните параметри, които съответстват на формалните параметри. Обектите клиент и сървър са обекти на стандартния архитектурен модел OMA.

Същността на стила на проектиране в рамките на унифицирания RUP процес е да осигури всички дейности, извършвани върху модели (анализ, проектиране, разработка и тестване) на процеса на жизнения цикъл.

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

Логическата структура на проектираната система е композиция от обекти и готови програмни продукти, които изпълняват съответните функции на системата. Съставът се основава на следните разпоредби:

1. всяка подсистема трябва да отразява изискванията и начина, по който те се изпълняват (сценарий, случай на употреба,актьор и др.);
2. променливите функции ще бъдат разпределени на подсистеми, така че промените в изискванията и отделните обекти, свързани с актьора, да бъдат предвидени за тях;
3. комуникацията на обектите се осъществява чрез интерфейса;
4. всяка подсистема трябва да изпълнява минимум услуги или функции и да има фиксиран набор от интерфейсни параметри.

Резултатите от архитектурния дизайн са представени чрез нотации под формата на диаграми (обект-връзка, преходи на състояния, потоци от данни и действия и т.н.) в модела за анализ на изискванията. Диаграмните обекти детайлизират зададените функционални изисквания за разработване на системата и показват процеса на решаване на проблемите на проекта.

Обектите, избрани в модела за анализ, се комбинират в система чрез:

• монтаж на предмети;
• логическо асоцииране на обекти;
• агрегиране по време, т.е. монтаж за определен период от време;
• комуникативно асоцииране на обекти чрез общ източник на данни;
• процедурна асоциация с помощта на изрази за повикване;
• функционална асоциация на обекти;

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

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

Техническият дизайн се състои в картографиране на архитектурата на системата в операционната среда чрез свързване на системните елементи към характеристиките на платформата за внедряване: СУБД, ОС, оборудване и т.н. Прехвърляне на произведения ПС на другПлатформата изисква промяна на параметрите, настройка на услуги за нови условия на околната среда и адаптиране на използваните бази данни.

За реализиране на такива свойства се дефинират обекти, които взаимодействат със системните услуги, по отношение на които е декларирана преносимост. Всеки обект, дефиниран по този начин, се заменя с обект, който не взаимодейства директно с услугата, а с някакъв абстрактен междинен обект, който трансформира абстрактния интерфейс в интерфейс на конкретна услуга на системата. В този случай междинният обект има свойството да се настройва към конкретна среда.

В същото време всеки аспект на прехода към нова платформа може да изисква изграждането на спомагателни интерфейсни или контролни обекти и коригиране на съществуващите. Освен това може да се наложи да се използват готови подсистеми, чиято структура се различава от онези подсистеми, които са определени въз основа на анализа на системните изисквания. В този случай се правят подходящи промени в модела за анализ на изискванията и в системната архитектура.

---