Сложни софтуерни интегрирани системи. Основни понятия.


Категория на документа: Информатика



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

Глава 1. Обща характеристика

1.1. Стандарт ISO/IEC/IEEE 42010. Системи и софтуерно инжинерство - архитектурно описание.

ISO / IEC / IEEE 42010 определя изискванията относно описанието на системата, софтуера и корпоративните архитектури. Той има за цел да стандартизира практиката на архитектурното описание, чрез определяне на стандартни условия, представяне на концептуална основа за изразяване, комуникация и преглед на архитектури и уточняване на изискванията, които се прилагат към архитектурни описания, архитектурни рамки и езици за архитектурно описание.2

Стандартът дефинира редица термини:
> Проектиране (architecting) - процес на определяне, изразяване, документиране, общуване, удостоверяващо правилното прилагане, поддържане и подобряване на архитектурата през целия жизнен цикъл на дадена система;
> Архитектура (architecture): основни понятия или свойства на дадена система в заобикалящата я среда, въплътена в нейните елементи, взаимоотношения и в принципите на нейния дизайн и еволюция;
> Архитектурно описание (architecture description) - работния продукт използван за изразяване на архитектурата;
> Език за архитектурно описание (architecture description language) - всяка форма на изразяване, използвана в архитектурното описание;
> Архитектурна рамка (architecture framework) - конвенции, принципи и практики за описание на архитектури, установени в рамките на определена област на приложение и / или общност от заинтересовани страни;
> Ахитектурна гледна точка (architecture viewpoint) - работен продукт установяващ конвенциите за конструирането, тълкуването и използването на архитектурни гледни точки с цел да се обособят специфичните системни интереси;
> Архитектурен изглед (architecture view) - работен продукт, изразяващ системната архитектура от гледна точка на специфичните системни интереси;
> Загриженост (concern) - интерес в система, свързан с един или повече от нейните заинтересовани страни. Интересът се отнася до някакво влияние върху системата в нейната среда, включително развитието, технологични, бизнес, оперативни, организационни, политически, икономически, правни, регулаторни, екологични и социални въздействия;
> Вид на модела - конвенции за типа моделиране. Архитектурния изглед съдържа няколко метода, като всеки следва определен модел;
> Заинтересовани страни (stakeholder): личност, екип, организация, или групи от тях, които имащи интерес в една система.
1.2. Софтуерна архитектура

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

Терминът софтуерна архитектура се използва за означаване на трите понятия:
> Структура на високо ниво на софтуерната система;
> Дисциплина за създаване на такава структура;
> Документация на тази структура.

Софтуерната архитектура може да бъде описана като набор от структури, който съдържа софтуерни елементи, отношенията между тях и характеристиките, както на елементите, така и на отношенията им.

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

Описанията на софтуерната архитектура често се организират в гледни точки (изгледи), които са аналогични на различните видове чертежи, направени при изграждането на архитектурата. Всяка гледна точка е адресирана към набор от системни компоненти, следвайки условията на неговата спецификация или т.нар. viewpoint. В случая viewpoint е спецификация, която описва означенията, моделирането и техниките за анализиране използвани в изгледа, които описват архитектурата от гледна точка на определен набор от заинтересовани страни и техните изисквания (ISO / IEC / IEEE 42010). Viewpoint уточнява не само възможните проблеми, които ще бъдат разгледани, но и представянето, видовете модели, които ще бъдат използвани, използваните конвенции, както и правилата за кореспонденция, които да запазят изгледа в съответствие с другите изгледи.

Софтуерната архитектура има следните характеристики:
> Множество заинтересовани страни: софтуерните системи трябва да отговарят на изискванията на различни заинтересовани страни, като например бизнес мениджъри, собственици, ползватели и оператори. Тези заинтересовани страни всички имат свои собствени опасения по отношение на системата. Балансирането на тези опасения и да покажат как те са адресирани е част от проектирането на системата. Това означава, че архитектурата включва справяне с широка гама от проблеми и заинтересовани страни, и има мултидисциплинарен характер;
> Разделяне на изискванията: установения от архитектите начин за намаляване на сложността е, чрез разделяне на изискванията, които определят дизайна. Документацията на архитектурата показва, че всички изисквания на заинтересованите лица са адресирани, чрез моделиране и описание на архитектурата от отделни изгледи, свързани с опасенията на различните заинтересовани страни. Тези отделни описания са наречени архитектурни гледки (architectural viewpoint). Пример за това е моделът 4+1 създаден от Philippe Kruchten, който "описва архитектурата на софтуерни интензивни системи, базирани на използването на многобройни, конкурентни изгледи"3;

Фиг.1. 4+1 Architectural View Модел
> Качеството като движеща сила - досега класическите подходи за софтуерен дизайн са били водени от необходимата функционалност и потока данни минаващ през системата, но днешните разбирания са, че архитектурата на софтуерната система е по-тясно свързана с нейните качествени характеристики като толерантност към грешки, обратна съвместимост, разширяемост, надеждност, лесна поддръжка, сигурност, използваемост и други. Тези качествени атрибути са наричани още нефункционални изисквания, екстра-функционални изисквания, изисквания за качество на системата или ограничения;
> Повтарящи стилове: както строителната архитектура, дисциплината "софтуерна архитектура" е разработила стандартни начини за справяне с повтарящите се проблеми. Тези стандартни начини се наричат ​​с различни имена на различните нива на абстракция. Общите условия за повтарящи се решения са архитектурен стил, стратегия или тактика, референтна архитектура (софтуерна архитектура, където структурите и съответните елементи и връзки предоставят шаблони за конкретни архитектури в определена област, или в семейство софтуерни системи) и архитектурен модел;
> Концептуална цялост: термин, въведен от Фред Брукс, за да се обозначи идеята, че архитектурата на софтуерна система представлява цялостна визия, за това, какво трябва да се направи и как трябва да се направи. Тази визия трябва да бъде отделена от нейното изпълнение. Архитектът поема ролята на "пазител на визията", като се увери, че допълнения към системата са съобразени с архитектурата, а оттам и запазването на концептуалната цялост.

Глава 2. Интегриране на софтуерните системи

2.1. Що е то системно интегриране?

Интеграцията на една система не е нито софтуерна интеграция, нито интеграция на отделни инструменти и определено, не е процесът по тестване на интегрирането.

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



Сподели линка с приятел:





Яндекс.Метрика
Сложни софтуерни интегрирани системи. Основни понятия. 9 out of 10 based on 2 ratings. 2 user reviews.