Компонентно оријентисано програмирањеКомпонентно оријентисано програмирање (КОП) (такође познато као развојна компонента на бази (РКБ)) је огранак софтверског инжењерства која истиче одвајање проблема у погледу функционалности широко доступним током одређеног софтверског система. То је поновни приступ заснован на дефинисању, имплементацији и компоновања лабаво спрегнутих независних компоненти у системима. Ова пракса има за циљ да доведе до једнако широког степена користи и у кратком року и дугорочно за само софтвер и за организације које спонзоришу такав софтвер. Софтверско инжењерски практиканти сматрају компоненте као део почетне платформе за сервис оријентацију. Компоненте играју ову улогу, на пример, у веб сервисима, а однедавно, у сервис оријентисаној архитектури (СОА), при чему компоненту конвертује веб сервис у сервис, а потом наследи даље карактеристике које превазилазе обичне компоненте. Компоненте могу произвести или конзумирати догађаје и могу се користити и у догађај-покретној архитектури (ДПА). Дефиниција и карактеристике компонентиПојединачна софтверска компонента је софтверски пакет, веб сервис, извор на интернету, или модул који сажима скуп повезаних Функција (или података). Сви процеси система су постављени у одвојене компоненте, тако да сви подаци и функције унутар сваке компоненте су семантички повезане (као са садржајем наставе). Због овог принципа, за компоненте се често каже да су модуларне и кохезивне. Што се тиче системске координације, компоненте комуницирају једне са другима преко интерфејса. Када компонента пружа услуге остатку система, она их усваја под условом да интерфејс наводи услуге које друге компоненте могу да се користе, и како оне могу да раде. Овај интерфејс се може посматрати као потпис компоненте - клијент не треба да зна о унутрасњим пословима компоненте (имплементација) како би користио то. Овај принцип резултата у компоненти називају енкапсулирани. УМЛ илустрације у оквиру овог члана представљају обезбеђен интерфејсе од стране lollipop-симбола прикљученог на спољашње ивице компоненте. Међутим, када компонента треба да користити неку другу компоненту у циљу функције, она усваја да се користи интерфејс који наводи услуге које су му потребне. У УМЛ илустрацијама у овом чланку, користе се интерфејси у представљању отворене утичнице пикључене на спољашње ивице компоненте.  Још једна важна особина компоненти је да су заменљиве, тако да компонента може да замени другу (на дизајн времена или компоненти), ако је компонента наследник и испуњава захтеве почетне компоненте (изражена преко интерфејса). Према томе, компоненте се могу заменити било са ажурираном верзијом или алтернативом без нарушавања система у којој компонента дјелује. Као опште правило за инжењере заменом компоненте, компонента Б може одмах да замени компоненту А, ако компонента Б обезбеђује барем оно што компонента А, и не користи више од онога што компонента А користи. Софтверске компоненте су често у облику објеката (не класе) или колекције предмета (из Објектно-оријентисаног програмирања), у неком бинарном или текстуалном облику, придржавајући се неки опис интерфејс језика (ОИЈ), тако да компонента може постојати самостално од других компоненти у компјутеру. Другим речима, компонента делује без промене свог изворног кода. Иако понашање изворног кода компоненте може да се мења на основу проширења апликације, под условом свог писца. Када се компоненти приступи или дели у извршењу контекста или мрежним везама, технике, као што су серијализације у Макишу се често користе да доставе компоненту свог одредишта. Употребљивост је важна карактеристика за квалитетну софтверску компоненту. Програмери треба да осмисле и спроведу софтверске компоненте на такав начин да многи различити програми могу да их поново користите. Осим тога, компонента базирана на тестирању употребљивости треба узети у обзир када софтверске компоненте директно комуницирају са корисницима. Потребно је уложити значајне напоре да се напише софтверска компонента која је ефикасна за вишекратну употребу. Компонента треба да буде:
Године 1960, е, програмери су изградили научне подрутинске библиотеке које су за вишекратну употребу у широком спектру инжењеринга и научних апликација. Иако ове подрутинске библиотеке поново користе добро дефинисане алгоритме на ефикасан начин, оне су имале ограничен домен примене. Комерцијални сајтови рутински стварају апликације за вишекратну употребу модула написаних на Асемблер-у, КОБОЛ, ПЛ/1 друге и треће генерације језика који користе оба система и корисничке апликационе библиотеке. Од 2010. године, модерну вишекратну употребу компоненте обухватају обе структуре података и алгоритме који се примењују на структурама података. То [појашњење потребno] се надовезује на претходне теорије софтверских објеката, софтверске архитектуре, софтверских рамова и дезена софтвера, као и опсежне теорије објектно оријентисаног програмирања и објектно оријентисано пројектовање свих њих. Она тврди да софтверске компоненте, као што је идеја о хардверској компоненти, која се користи на пример у области телекомуникација,[1] може на крају бити заменљива и поуздана. С друге стране, тврди да је грешка што се фокусира на независне компоненте уместо оквире (без којих не би постојала).[2] ИсторијаИдеја да софтвер треба да буде компонента - изграђена од монтажних елемената - први пут је истакнута на обраћању Дагласа Мекилроиа на конференцији о НАТО софтверском инжењерингу у Гармиш-Партенкирхену, Немачкој, 1968. године, под називом Масовна производња софтверских компоненти.[3] Конференција је кренули да се супротстави тзв софтверској кризи. Следеће укључивање Мекилрои је било о цевима и филтерима у Јуниксу оперативном систему прва имплементација инфраструктуре за ову идеју. Бред Кокс од Стептоне у великој мери дефинише савремени концепт софтверских компоненти. Он их је назвао Софтвер ICs и кренуо је да створи инфраструктуру и тржиште за ове компоненте[4] измишљањем Objective-С програмског језика. (Он сажима овај став у својој књизи Објектно оријентисаног програмирања - еволутивни приступ 1986) Софтверске компоненте користе се у два различита контекста и две врсте: (1.) уз компоненте и делове да изграде једну извршну, или (2.) свако извршну третира као компоненту у дистрибуираном окружењу, где компоненте сарађују међусобно користећи интернет или интранет комуникациони протокол за ИПК (Интер процес комуникације). Наведени припада бившим врстама. IBM-је водио пут са својим системом објект моделом (СОМ) почетком 1990-их. Као реакција Microsoft отвара пут за стварно распоређивање компоненти софтвера са ОЛЕ и ЦОМ.[5] Од 2010. године постоји много успешних модела софтверских компоненати. Разлике из објектно оријентисаног програмирањаКритичари објектно оријентисаног програмирања (ООП) тврде да софтвер треба да буде написан у складу са менталним моделима стварних или измишљених објеката које заступа. ООП и сродних дисциплина објектно-оријентисана анализа и објектно-оријентисаног дизајна са фокусом на моделирању у стварном свету [уреди] интеракције и покушава да створи "именице" и "глаголе" који се могу користити на више читљив начин, идеално крајњим корисницима, као и од стране програмера који кодирају то крајњим корисницима. Компонентно оријентисано програмирање, с друге стране, не прави такве претпоставке, и уместо тога наводи да програмер треба да изгради софтвер лепљењем заједно монтажних елемената - слично као и у области електронике и механике. Поједини вршњаци [ко?] ће чак говорити о модуларизингу системимама као софтверске компоненте нове парадигме програмирања. Пример за могућу парадигме: многи стручњаци сматрају да еволуира потреба прилагодљив је важнија од поновне употребе, јер 80% софтверског инжењерства се бави одржавањем или отпуштањем нове верзије. Зато је пожељно да се изгради комплексан систем састављањем од високо кохезивних лабава спрегнутих великих компоненти где трошак редизајнирања сваке од таквих усвојивих компоненти (или замена бољим компонентом) се минимизира. Неки [ко?] тврде да су раније компјутерски научници направили ову разлику, са теоријом "писменог програмирања" Доналдa Кнутa оптимистички под претпоставком да је сличност између интуитивних и формалних модела, а Едсгер Дајкстра теорија у чланку окрутности Реалли наставе информатике, који је изјавио да је програмирање једноставно и само грана математике.[6][7] У оба облика, овај појам је довео до многих академских расправа [Веасел вордс] о предностима и манама ова два приступа и могућих стратегија за обједињавање оба. Неки [ko?] разматрају различите стратегије не као конкуренте, али као описе истих проблема са различитих тачака гледишта. Један приступ за стварање софтверских компонената заснован користећи објектно-оријентисано програмирање је расподељено израчунавање. Међутим, програмски интерфејс заснован не инхерентним подршкама дистрибуираних система, и многи рачунарски системи се инхерентно дистрибуирају у 21. веку. Программинг Интерфаце заснован на ООП смислу може се продужити до дистрибуираних система за дистрибуиране моделе компонент објекта; Међутим, многи су тврдили у последњих неколико година да ОДМОР АПИ или глумац модела су погоднији за приступ. АрхитектураРачунар који ради неколико софтверских компоненти се често назива апликативни сервер. Ова комбинација апликација сервера и софтверских компоненти се обично назива расподељено израчунавање. Типична реалном свету примењена је у, на пример, финансијским апликацијама или пословним софтверима. МоделиМодел компонента је дефинисање стандарда за компонентне имплементације, документацију и примену. Примери компонентних модела су: Ентерприсе ЈаваБеанс (ЕЈБ) модела, Цомпонент Објецт Модел (ЦОМ). НЕТ модел и уобичајен захтев објекта брокер Архитектура (Цорба) компонента модел. Компонента модел одређује како интерфејси треба да буду дефинисани и елементи који треба да буду укључени у дефиницији интерфејса. Технологије
Види још
Референце
Додатна литература
Спољашње везе
|
Portal di Ensiklopedia Dunia
