Википедија

Компонентно оријентисано програмирање

Компонентно оријентисано програмирање (КОП) (такође познато као развојна компонента на бази (РКБ)) је огранак софтверског инжењерства која истиче одвајање проблема у погледу функционалности широко доступним током одређеног софтверског система. То је поновни приступ заснован на дефинисању, имплементацији и компоновања лабаво спрегнутих независних компоненти у системима. Ова пракса има за циљ да доведе до једнако широког степена користи и у кратком року и дугорочно за само софтвер и за организације које спонзоришу такав софтвер.

Софтверско инжењерски практиканти сматрају компоненте као део почетне платформе за сервис оријентацију. Компоненте играју ову улогу, на пример, у веб сервисима, а однедавно, у сервис оријентисаној архитектури (СОА), при чему компоненту конвертује веб сервис у сервис, а потом наследи даље карактеристике које превазилазе обичне компоненте.

Компоненте могу произвести или конзумирати догађаје и могу се користити и у догађај-покретној архитектури (ДПА).

Дефиниција и карактеристике компоненти

уреди

Појединачна софтверска компонента је софтверски пакет, веб сервис, извор на интернету, или модул који сажима скуп повезаних Функција (или података).

Сви процеси система су постављени у одвојене компоненте, тако да сви подаци и функције унутар сваке компоненте су семантички повезане (као са садржајем наставе). Због овог принципа, за компоненте се често каже да су модуларне и кохезивне.

Што се тиче системске координације, компоненте комуницирају једне са другима преко интерфејса. Када компонента пружа услуге остатку система, она их усваја под условом да интерфејс наводи услуге које друге компоненте могу да се користе, и како оне могу да раде. Овај интерфејс се може посматрати као потпис компоненте - клијент не треба да зна о унутрасњим пословима компоненте (имплементација) како би користио то. Овај принцип резултата у компоненти називају енкапсулирани. УМЛ илустрације у оквиру овог члана представљају обезбеђен интерфејсе од стране lollipop-симбола прикљученог на спољашње ивице компоненте.

Међутим, када компонента треба да користити неку другу компоненту у циљу функције, она усваја да се користи интерфејс који наводи услуге које су му потребне. У УМЛ илустрацијама у овом чланку, користе се интерфејси у представљању отворене утичнице пикључене на спољашње ивице компоненте.

 
Једноставан пример неколико софтверских компоненти - на слици у оквиру хипотетички одмор-резервационог система представљеног у УМЛ 2.0.

Још једна важна особина компоненти је да су заменљиве, тако да компонента може да замени другу (на дизајн времена или компоненти), ако је компонента наследник и испуњава захтеве почетне компоненте (изражена преко интерфејса). Према томе, компоненте се могу заменити било са ажурираном верзијом или алтернативом без нарушавања система у којој компонента дјелује.

Као опште правило за инжењере заменом компоненте, компонента Б може одмах да замени компоненту А, ако компонента Б обезбеђује барем оно што компонента А, и не користи више од онога што компонента А користи.

Софтверске компоненте су често у облику објеката (не класе) или колекције предмета (из Објектно-оријентисаног програмирања), у неком бинарном или текстуалном облику, придржавајући се неки опис интерфејс језика (ОИЈ), тако да компонента може постојати самостално од других компоненти у компјутеру. Другим речима, компонента делује без промене свог изворног кода. Иако понашање изворног кода компоненте може да се мења на основу проширења апликације, под условом свог писца.

Када се компоненти приступи или дели у извршењу контекста или мрежним везама, технике, као што су серијализације у Макишу се често користе да доставе компоненту свог одредишта.

Употребљивост је важна карактеристика за квалитетну софтверску компоненту. Програмери треба да осмисле и спроведу софтверске компоненте на такав начин да многи различити програми могу да их поново користите. Осим тога, компонента базирана на тестирању употребљивости треба узети у обзир када софтверске компоненте директно комуницирају са корисницима.

Потребно је уложити значајне напоре да се напише софтверска компонента која је ефикасна за вишекратну употребу. Компонента треба да буде:

  • у потпуности документована
  • испитана
    • робусна - са свеобухватним проверама улазног-важења
    • може да врати одговарајуће поруке о грешкама или враћа кодове
  • дизајнирана са свешћу да ће бити стављена за непредвиђене намене

Године 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. веку. Программинг Интерфаце заснован на ООП смислу може се продужити до дистрибуираних система за дистрибуиране моделе компонент објекта; Међутим, многи су тврдили у последњих неколико година да ОДМОР АПИ или глумац модела су погоднији за приступ.

Архитектура

уреди

Рачунар који ради неколико софтверских компоненти се често назива апликативни сервер. Ова комбинација апликација сервера и софтверских компоненти се обично назива расподељено израчунавање. Типична реалном свету примењена је у, на пример, финансијским апликацијама или пословним софтверима.

Модели

уреди

Модел компонента је дефинисање стандарда за компонентне имплементације, документацију и примену. Примери компонентних модела су: Ентерприсе ЈаваБеанс (ЕЈБ) модела, Цомпонент Објецт Модел (ЦОМ). НЕТ модел и уобичајен захтев објекта брокер Архитектура (Цорба) компонента модел. Компонента модел одређује како интерфејси треба да буду дефинисани и елементи који треба да буду укључени у дефиницији интерфејса.

Технологије

уреди

Види још

уреди

Референце

уреди
  1. ^ Foukalas, Fotis; Ntarladimas, Yiorgos; Glentis, Aristotelis; Boufidis, Zachos (2005). „Protocol Reconfiguration Using Component-Based Design”. Distributed Applications and Interoperable Systems. Lecture Notes in Computer Science. 3543. стр. 148—156. ISBN 978-3-540-26262-6. doi:10.1007/11498094_14. 
  2. ^ Wallace, Bruce (May 19, 2010). "A hole for every component, and every component in its hole". Existential Programming. There is no such thing as a Component
  3. ^ McIlroy, Malcolm Douglas (January 1969). "Mass produced software components" (PDF). Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7-11 Oct. 1968. Scientific Affairs Division, NATO. стр. 79.
  4. ^ Rainer Niekamp. "Software Component Architecture" Архивирано на сајту Wayback Machine (28. март 2012) (PDF). Gestión de Congresos - CIMNE/Institute for Scientific Computing, TU Braunschweig. стр. 4. Приступљено 2011-07-29. The modern concept of a software component largely defined by Brad Cox of Stepstone, => Objective-C programming language
  5. ^ Raphael Gfeller (December 9, 2008). "Upgrading of component-based application"[мртва веза]. HSR - Hochschule für Technik Rapperswill. стр. 4. Приступљено 2011-07-29. 1990, IBM invents their System Object Model. 1990, as a reaction, Microsoft released OLE 1.0 OLE custom controls (OCX)
  6. ^ "Dijkstra, Wybe Edsger". Encyclopedia.com. Приступљено 2011-07-29. In his view, the key to a good computing science program was to consider it as a branch of mathematics.
  7. ^ Donald E. Knuth (September 1983). "Literate Programming" (PDF). Literate Programming/The Computer Journal. стр. 15. Приступљено 2011-07-29. Thus, WEB may be only for the subset of computer scientists who like to write and to explain what they are doing. My hope is that the ability to make explanations more natural will cause more programmers to discover the joys of literate programming, because I believe it’s quite a pleasure to combine verbal and mathematical skills; but perhaps I’m hoping for too much. The fact that at least one paper has been written that is a syntactically correct ALGOL 68 program22 encourages me to persevere in my hopes for the future. Perhaps we will even one day find Pulitzer prizes awarded to computer programs.
  8. ^ MASH defines assets as people, property and information and management as monitoring, control and configuration. Presented at the 2013 IEEE IoT conference in Mountain View MASH includes a full IDE, Android client and runtime. "MASH YouTube channel"
  9. ^ A component-oriented approach is an ideal way to handle the diversity of software in consumer electronics. The Koala model, used for embedded software in TV sets, allows late binding of reusable components with no additional overhead. [1]
  10. ^ Component model for embedded devices like TV developed by Philips based on paper by van Ommering, R.: Koala, a Component Model for Consumer Electronics Product Software [2] Архивирано на сајту Wayback Machine (9. август 2014)
  11. ^ Arad, Cosmin (April 2013). "Programming Model and Protocols for Reconfigurable Distributed Systems" (PDF). Doctoral Dissertation. Stockholm, Sweden: KTH Royal Institute of Technology. ISBN 978-91-7501-694-8.
  12. ^ Remedy IT - AXCIOMA

Додатна литература

уреди


Спољашње везе

уреди
Преузето из „https://sr.wiki.x.io/w/index.php?title=Компонентно_оријентисано_програмирање&oldid=27754487”