В момента има малко хора, които ще спорят с твърдението, че нашият свят е все по-зависим от софтуера (софтуера). И това не е странно. Използва се в мобилни телефони, интегрирани системи за контрол на въздушното движение, персонални компютри, електроника за автомобили и много други. Много иновации, които възприемаме като дадени, както и голям брой различни организации като Yandex, Amazon или Google, са просто невъзможни без софтуер. Но дори в традиционните търговски, публични и финансови сектори е много трудно да се направи без софтуер.

Обща информация

Заслужава да се спомене само понятието за архитектура, така че едно нещо е ясно едновременно - липсата на дефиниции не съществува. Ето защо, за да не се обърка читателите, стандартите IEEE 1471 и IEEE Std 1472000 ще бъдат използвани като прототипи за разглеждане в статията. А сега да погледнем какво представлява архитектурата. Този термин се отнася до организацията на системата, въплътена в нейните компоненти, връзката между тях и околната среда, както и принципите, определящи нейното проектиране и развитие. Нека обаче първо да припомним онези, които допринесоха значително за развитието на теорията и концепцията за софтуера.


Преди всичко е необходимо да споменем Lance Bass. "Архитектурата на софтуера на практика - доста стара работа на този автор (руски превод е издаден през 2006 г.), но въпреки това ви позволява да получитевисококачествено разбиране на процеса на разработване на софтуер. Следващият интересен автор е Робърт Мартин и неговото творение "Чиста архитектура". Изкуство на разработка на софтуер ". Преводът и публикуването на книгата на руски език са направени още в началото на 2018 година. Ето защо е безопасно да се каже, че това е буквално новост, в която има много свежа и актуална информация. Книгата "Чиста архитектура. „Изкуството на разработката на софтуер” разказва как да достигнем височините на професионализма. Той описва какво и как да се направи и защо решението ще бъде от решаващо значение за успеха.

Малко терминология

Разгледайте някои понятия, които ще ни помогнат да разберем темата:

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

Мисия - заявление (действие), което една или повече заинтересовани страни ще направят в съответствие с необходимите условия.

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

И някои други интерпретации на основната тема:

Архитектура - набор от смислени решения, които засягат организацията на системата В. Набор от структурни елементи, както и техните интерфейси, чрез които се разполага.

Архитектурата на програмата (компютърна система) - структура, която включва някои елементи, видими отвън на техните свойства, както и връзките между тях. Състои се от всички важниприети дизайнерски решения. Тя осигурява желания набор от свойства, които са необходими за успешния бизнес.

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

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

Влияние на архитектурата върху структурата

Тук има един интересен момент. Струва си да поискаме да се опише думата "архитектура", тъй като повечето хора тук се позовават на структурата. И това не е странно. В крайна сметка, архитектурата на софтуера на практика често се гради върху схемата, която описва структурните аспекти на системата. Освен това няма значение какво е езикът - за нива, компоненти или разпределени възли. Структурата е най-важната характеристика на архитектурата. Неговите аспекти и характеристики се проявяват по много начини. Структурен елемент може да бъде база данни, библиотека, процес, подсистема, изчислителен възел и така нататък. Освен това трябва да се обърне внимание не само на тях поотделно, но и на съставите от тях, установени връзки, интерфейси и дялове. Трябва да се има предвид, че всеки от тези елементи може да бъде представен по различни начини. Като пример може да се намери свързваща връзка. Тя може да бъде: a /synchronous, socket, да бъде свързана с конкретен протокол и т.н.

Влияние на архитектурата върху поведението

Просто е невъзможно да се подценява.Проектирането на архитектурата на софтуера оказва голямо влияние върху неговата реализация и по-нататъшно изпълнение. Поведението, възможните висящи, проблеми и т.н. много зависи от това как всичко се е развило от самото начало. Архитектурата влияе върху взаимодействието между структурните елементи, трябва да осигурява пренос на данни точно там, където е необходимо да се получи желания резултат. Как става това с нашите стандарти? Можете да видите малка схема на дейност. Да предположим, че имаме предприятие. Необходимо е да се уверите, че служителят е взел поръчка, използвайки инстанция от клас "Форма". Той съдържа цялата необходима информация за клиента. Ако поръчката е направена за първи път, тогава информацията се въвежда в "Празната" с помощта на контролната система. След това се използва инстанция на класа "Обработка на поръчки", която изпълнява всички необходими процеси в предприятието. Има общо пет елемента. В същото време има определена зависимост. Например поръчката е невъзможна без служител. И ако не е попълнено, то няма да бъде прието.

Концентрация на архитектурата върху основни елементи

Затова вече разгледахме въздействието върху структурата и поведението. Но тук трябва да се отбележи един важен момент. А именно, архитектурата не дефинира цялата структура, а не цялото поведение. Тя засяга тези елементи, които се считат за значими. Какво е под тях? Значителни са тези елементи, които имат дълготраен ефект. Например,основни структурни Или тези, които зависят от надеждността и мащабируемостта на софтуера. В този случай архитектурата, като правило, няма отношение към подробните детайли на всички тези елементи. Основният атрибут, за който някои се оценяват повече от други, е цената на създаването и модифицирането. Архитектурата се фокусира върху значими елементи. Следователно тя трябва да предложи конкретна перспектива, нещо, което е най-значимо. Може да се каже, че архитектурата е определено обобщение на цялата софтуерна система, която позволява на разработчика да управлява съществуващата сложност. Важно е да се отбележи тук. А именно, наборът от смислени елементи не е статичен списък на нещо и може да се променя с времето. В какви случаи се случва това? Като пример, може да се цитира ситуация, в която настъпва резултатът от изискванията, идентифицирането на рисковете и други подобни моменти. Трябва да се отбележи, че относителната стабилност на архитектурата, въпреки направените промени, е знак за добре изпълнена работа и добре установен процес на развитие, както и опит и квалификация на персонала.

Балансиране на нуждите на заинтересованите страни

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

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

Системен администратор. Той се интересува от наличието на интуитивно управление, инструменти за наблюдение и поведение на целия комплекс.

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

Разработчик. Той се интересува от разбирането на изискванията и неконфликтните принципи на вътрешната система.

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

Архитектурата се основава на логическа обосновка

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

За архитектурния стил

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

Разпределени.

Канали и филтри.

С централизирано обработване на данни.

Изработени по правилата.

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

Относно влиянието на околната среда. И обратно

Или с други думи, за архитектурата в рамките на семантичното съдържание. Необходимо е да се определят границите, в които ще работи софтуерната система. Тя се занимава предимно с околната среда. Архитектурата на софтуерната система в такива случаи трябва да отчита факторите на влияние. По-конкретно, необходимо е да се съсредоточим върху заинтересованите страни на мисията, вътрешните и външните технически ограничения. В допълнение, архитектурата на софтуера може да повлияе на околната среда. Освен това, не само от технологична гледна точка, но също така ви позволява да използвате повторно активите и работната среда. За какво говорят стандартите? Ако говорим за преобладаващо софтуерни системи, тогава трябва да вземете под вниманиенякои аспекти на околната среда. Така че, така че програмата да е полезна, тя трябва да работи. За да направите това, трябва да го изпълните на определен хардуер. Тук архитектурата на компютъра е от голямо значение. Софтуерът, който е създаден за Windows, няма да работи с технологията, на която е инсталиран MacOS. Въпреки че, разбира се, можете да направите емулатор, да преминете през виртуална машина или да използвате друг медиатор и да стартирате софтуера. Но ефективността на работата му ще бъде много по-малка, отколкото в случая с работа с целеви системи. Следователно, архитектурата на компютъра и софтуера трябва да съответства на правилната работа. В крайна сметка, същият MacOS може да работи само при определена конфигурация. Така че Windows има определени ограничения, въпреки че е по-малко свързан с желязото.

Разнообразие на видовете

Какви модели можете да създадете? Накратко изброяваме видовете софтуерна архитектура, които са широко използвани:

Модел клиент-сървър.

Монолитно приложение.

Архитектура на случая.

Структурирани.

Три нива.

Архитектура, ориентирана към услугите.

Имплицитни предизвикателства.

Архитектура, ориентирана към търсене.

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