Softwarový rámec - Software framework

„Rámec (počítačová věda)“ přeadresuje tady. Pro další použití viz Rámec (disambiguation).

v programování, a softwarový rámec je abstrakce ve kterém software poskytování obecných funkcí lze selektivně měnit dodatečným uživatelem napsaným kódem, čímž se poskytuje software specifický pro aplikaci. Poskytuje standardní způsob vytváření a nasazování aplikací a je univerzální, opakovaně použitelný softwarové prostředí který poskytuje zvláštní funkce jako součást většího softwarová platforma usnadnit rozvoj softwarové aplikace, produkty a řešení. Softwarové rámce mohou zahrnovat podpůrné programy, kompilátory, knihovny kódů, sady nástrojů a aplikační programovací rozhraní (API) které spojují všechny různé komponenty umožnit vývoj a projekt nebo Systém.

Rámečky mají klíčové rozlišovací vlastnosti, které je oddělují od normálních knihovny:

  • inverze kontroly: V rámci, na rozdíl od knihoven nebo standardních uživatelských aplikací, celkový program tok kontroly není diktováno volajícím, ale rámcem.[1] Toho je obvykle dosaženo pomocí Šablona metoda vzor.
  • výchozí chování: To lze zajistit invariantními metodami Metoda šablony v abstraktní třídě, kterou poskytuje framework.
  • rozšiřitelnost: Uživatel může rozšířit rámec - obvykle selektivním přepsáním - nebo mohou programátoři přidat specializovaný uživatelský kód, aby poskytli konkrétní funkce. Toho je obvykle dosaženo metodou zavěšení v podtřídě, která přepíše metodu šablony v nadtřídě.
  • neměnný kód rámce: Kód rámce by obecně neměl být upravován při přijímání uživatelem implementovaných rozšíření. Jinými slovy, uživatelé mohou rámec rozšířit, ale nemohou upravovat jeho kód.

Odůvodnění

Návrháři softwarových rámců mají za cíl usnadnit vývoj softwaru tím, že umožní návrhářům a programátorům věnovat svůj čas splnění softwarových požadavků, místo aby se zabývali standardnějšími podrobnostmi poskytování pracovního systému na nízké úrovni, čímž se zkracuje celková doba vývoje.[2] Například tým využívající a webový rámec vývoj bankovního webu se může soustředit spíše na psaní kódu konkrétního bankovnictví než na mechaniku vyřizování požadavků a řízení státu.

Rámece často zvětšují rozsah programů, což je jev nazývaný „kód nafouknout ". Kvůli potřebám aplikací založených na požadavcích zákazníků někdy v produktu končí jak konkurenční, tak doplňkové rámce. Dále kvůli složitosti jejich API nemusí být dosaženo zamýšleného zkrácení celkové doby vývoje kvůli potřebě věnujte další čas učení se používání rámce; tato kritika je jasně platná, když se vývojový personál poprvé setká se speciálním nebo novým rámcem.[Citace je zapotřebí ] Pokud se takový rámec nepoužívá v následných pracovních úkolech, může čas investovaný do učení se tohoto rámce stát více než účelově napsaný kód známý zaměstnancům projektu; mnoho programátorů uchovává kopie užitečných standardních štítků pro běžné potřeby.

Jakmile se však rámec naučí, budoucí projekty mohou být rychlejší a snadněji dokončitelné; konceptem rámce je vytvořit univerzální sadu řešení pro všechny a se známostí by měla logicky vzrůst produkce kódu. Neexistují žádná taková tvrzení o velikosti kódu, který je nakonec svázán s výstupním produktem, ani o jeho relativní účinnosti a stručnosti. Použití libovolného řešení knihovny nutně přitáhne doplňky a nepoužívané cizí prostředky, pokud software není linker kompilátoru a objektu, který vytváří těsný (malý, plně kontrolovaný a specifikovaný) spustitelný modul.

Problém pokračuje, ale má desetiletou zkušenost s průmyslem[Citace je zapotřebí ] prokázal, že nejúčinnějšími rámci se ukázaly být ty, které se vyvíjejí z re-factoringu společného kódu podniku, namísto použití obecného „univerzálního“ rámce vyvinutého třetími stranami pro obecné účely. Příkladem toho by bylo, jak se uživatelské rozhraní v takovém aplikačním balíčku, jako je kancelářská sada, rozroste, aby měl společný vzhled, chování a atributy a metody sdílení dat, protože jakmile se různorodé aplikace v balíku stanou jednotnými, v sadu, která je přísnější a menší; novější / vyvinutou sadou může být produkt, který sdílí integrované obslužné knihovny a uživatelská rozhraní.

Tento trend kontroverze vyvolává důležitou otázku týkající se rámců. Vytváření elegantního rámce ve srovnání s rámcem, který pouze řeší problém, je stále spíše řemeslem než vědou. "Software elegance „znamená jasnost, stručnost a malé množství odpadu (nadbytečné nebo cizí funkce, z nichž většina je definována uživatelem). Pro ty rámce, které generují kód, by například„ elegance “znamenala vytvoření kódu, který je čistý a srozumitelný pro rozumně znalý programátor (a který je proto snadno upravitelný) ve srovnání s programem, který pouze generuje správný kód. Problém elegance je důvod, proč relativně málo softwarových rámců obstálo ve zkoušce času: nejlepší rámce se dokázaly elegantně vyvinout jako základní technologie, na které byly postaveny pokročilé. I tam, po vývoji, si mnoho takových balíčků zachová starší schopnosti nadouvající finální software, protože jinak nahrazené metody byly zachovány paralelně s novějšími metodami.

Příklady

Softwarové rámce obvykle obsahují značný úklid a obslužný kód, aby pomohly zavést uživatelské aplikace, ale obecně se zaměřují na konkrétní problémové domény, například:

Architektura

Podle Pree,[8] softwarové rámce se skládají z zmrzlé skvrny a horká místa. Zmrazené skvrny definovat celkovou architekturu softwarového systému, to znamená jeho základní komponenty a vztahy mezi nimi. Ty zůstanou nezměněny (zmrazeny) v jakékoli instanci aplikačního rámce. Žhavá místa představují ty části, kde programátoři využívající framework přidávají vlastní kód pro přidání funkcí specifických pro jejich vlastní projekt.

V objektově orientovaný prostředí, rámec se skládá z abstraktní a beton třídy. Instance takového rámce se skládá z skládání a podtřídy stávající třídy.[9]

Potřebnou funkčnost lze implementovat pomocí Metoda šablony ve kterém zmrzlé skvrny jsou známé jako invariantní metody a horká místa jsou známé jako varianty nebo hákové metody. Inariantní metody v nadtřídě poskytují výchozí chování, zatímco metody zavěšení v každé podtřídě poskytují vlastní chování.

Při vývoji konkrétního softwarového systému se softwarovým rámcem využívají vývojáři horká místa podle konkrétních potřeb a požadavků systému. Softwarové rámce se spoléhají na Hollywoodský princip: "Nevolajte nám, zavoláme vám."[10] [11] To znamená, že uživatelem definované třídy (například nové podtřídy) přijímají zprávy z předdefinovaných tříd rámce. Vývojáři to obvykle řeší implementací nadtřída abstraktní metody.

Viz také

Reference

  1. ^ Riehle, Dirk (2000), Návrh rámce: přístup modelování rolí (PDF), Švýcarský federální technologický institut
  2. ^ "Rámec". DocForge. Citováno 15. prosince 2008.[mrtvý odkaz ]
  3. ^ Vlissides, J. M.; Linton, MA (1990), „Unidraw: framework for building domain-specific graphical editors“, Transakce ACM v informačních systémech, 8 (3): 237–268, doi:10.1145/98188.98197, S2CID  11248368
  4. ^ Johnson, RE (1992), „Dokumentace rámců pomocí vzorů“, Sborník z konference o jazycích a aplikacích objektově orientovaných programovacích systémů, ACM Press: 63–76
  5. ^ Birrer, A; Eggenschwiler, T (1993), „Sborník z evropské konference o objektově orientovaném programování“, Rámečky v oblasti finančního inženýrství: zpráva o zkušenostech, Springer-Verlag, str. 21–35
  6. ^ Hill, C; DeLuca, C; Balaji, V; Suarez, M; da Silva, A (2004), „Architecture of the Earth System Modeling Framework (ESMF)“, Výpočetní technika ve vědě a inženýrství, 6: 18–28, doi:10.1109 / MCISE.2004.1255817, S2CID  9311752
  7. ^ Gachet, A (2003), „Softwarové rámce pro vývoj systémů na podporu rozhodování - nová součást klasifikace vývojových nástrojů DSS“, Journal of Decision Systems, 12 (3): 271–281, doi:10.3166 / jds.12.271-280, S2CID  29690836
  8. ^ Pree, W (1994), „Meta vzory: prostředek k zachycení základů opakovaně použitelného objektově orientovaného designu“, Sborník příspěvků z 8. evropské konference o objektově orientovaném programování, Přednášky v informatice, Springer-Verlag, 821: 150–162, CiteSeerX  10.1.1.74.7935, doi:10.1007 / BFb0052181, ISBN  978-3-540-58202-1
  9. ^ Buschmann, F (1996), Softwarová architektura orientovaná na vzory, svazek 1: Systém vzorů. Chichester, Wiley, ISBN  978-0-471-95869-7
  10. ^ Larman, C (2001), Aplikování UML a vzorů: Úvod do objektově orientované analýzy a designu a jednotného procesu (2. vyd.), Prentice Hall, ISBN  978-0-13-092569-5
  11. ^ Gamma, Erichu; Kormidlo, Richarde; Johnson, Ralph; Vlissides, Johne (1994). Designové vzory. Addison-Wesley. ISBN  0-201-63361-2.

externí odkazy