Algoritmisk Trading System Architecture. Tidligere på denne bloggen har jeg skrevet om den konseptuelle arkitekturen til et intelligent algoritmisk handelssystem, samt de funksjonelle og ikke-funksjonelle kravene til et produksjonsalgoritmisk handelssystem. Siden da har jeg designet en systemarkitektur som jeg tror kunne tilfredsstille disse arkitektoniske kravene I dette innlegget vil jeg beskrive arkitekturen i henhold til retningslinjene i ISO IEC IEEE 42010-systemene og programvare engineering arkitektur beskrivelse standard Ifølge denne standarden en arkitektur beskrivelse må. Opprettholde flere standardiserte arkitektoniske visninger f. eks i UML og. Maintain sporbarhet mellom designbeslutninger og arkitektoniske krav. Programvarearkitekturdefinisjon. Det er fortsatt ingen konsensus om hva en systemets arkitektur er. I sammenheng med denne artikkelen er det definert som den infrastrukturen der applikasjonskomponenter som tilfredsstiller funksjonelle krav kan spesifiseres, distribuert og utført Funksjonskrav er systemets forventede funksjoner og dens komponenter Ikke-funksjonelle krav er tiltak der kvaliteten på systemet kan måles. Et system som fullt ut tilfredsstiller funksjonskravene, kan fortsatt ikke oppfylle forventningene dersom ikke-funksjonelle krav For å illustrere dette konseptet, vurder følgende scenario et algoritmisk handelssystem som du nettopp har kjøpt bygget gjør gode handelsbeslutninger, men er helt ubrukelig med organisasjonene risikostyring og regnskapssystemer. Dette systemet vil oppfylle dine forventninger. Konceptuell arkitektur. En konseptuell visning beskriver høyt nivå konsepter og mekanismer som eksisterer i systemet på høyeste nivå av granularitet På dette nivået følger det algoritmiske handelssystemet en eventdrevet arkitektur EDA brutt opp over fire lag og to arkitektoniske aspekter For hvert lag og aspekt referanse arkitekturer og mønstre ar e brukt Arkitektoniske mønstre er bevist, generiske strukturer for å oppnå spesifikke krav Arkitektoniske aspekter er tverrgående bekymringer som spenner over flere komponenter. Eventyrd arkitektur - en arkitektur som produserer, oppdager, forbruker og reagerer på hendelser Hendelser inkluderer realtidsbevegelser, komplisert hendelser eller trender, og handelshendelser, for eksempel å sende inn en bestilling. Dette diagrammet illustrerer den konseptuelle arkitekturen til det algoritmiske handelssystemet. Referansearkitekturer. For å bruke en analogi, er en referansearkitektur ligner tegningene for en bærende vegg. Denne blåutskriften kan brukes til flere byggedesigner uavhengig av hvilken bygning som bygges ettersom den tilfredsstiller et sett av vanlige krav. Tilsvarende definerer en referansearkitektur en mal som inneholder generiske strukturer og mekanismer som kan brukes til å konstruere en konkret programvarearkitektur som tilfredsstiller spesifikke krav Arkitekturen for algoritmisk tr addering system bruker en plassbasert arkitektur SBA og en modellvisningskontroll MVC som referanser God praksis som operativ datalager ODS, ekstrakttransformatoren og last ETL-mønster og et datalager DW benyttes også. Modelleringsvisningskontrollen - et mønster som separerer representasjonen av informasjon fra brukerens interaksjon med det. Mellombasert arkitektur - spesifiserer en infrastruktur hvor løst koblede behandlingsenheter samhandler med hverandre gjennom et felles associativt minne som kalles mellomrom vist nedenfor. Spaces-based arkitektonisk konseptbilde Modellvisning Controller original image. Strukturell visning. Strukturvisningen av en arkitektur viser komponentene og delkomponentene i det algoritmiske handelssystemet. Det viser også hvordan disse komponentene distribueres på fysisk infrastruktur. UML-diagrammene som brukes i denne visningen, inkluderer komponentdiagrammer og distribusjonsdiagrammer. distribusjonsdiagrammer for det generelle algoritmiske handelssystemet og p prosesseringsenheter i SBA-referansearkitekturen, samt relaterte komponentdiagrammer for hver enkelt lag. Algoritmisk handelssystem høyt distribusjonsdiagram SBA-behandlingsenheter distribusjonsdiagram Bestil bearbeidingskomponentdiagram Automatisert handlerbegivenhetsbehandlingskomponentdiagram Datakilde og forbehandlingslag komponent diagram MVC basert brukergrensesnitt komponent diagram. Architectural Tactics. According til programvare engineering instituttet en arkitektonisk taktikk er et middel til å tilfredsstille et kvalitetskrav ved å manipulere noe aspekt av en kvalitet attributt modell gjennom arkitektoniske design beslutninger Et enkelt eksempel brukt i den algoritmiske trading systemarkitektur manipulerer en operativ datalager ODS med en kontinuerlig spørringskomponent Denne komponenten vil kontinuerlig analysere ODS for å identifisere og trekke ut komplekse hendelser Følgende taktikker brukes i arkitekturen. Disruptor-mønsteret i hendelses - og ordrekøene. Delet minne for hendelses - og ordrekøene. Kontinuerlig spørringssprog CQL på ODS. Data filtrerer med filterdesignmønsteret på innkommende data. Konkurransebegreperingsalgoritmer på alle innkommende og utgående tilkoblinger. Aktivkøsstyring AQM og eksplisitte overbelastningsvarslingsmoditets databehandlingsressurser med kapasitet til oppgradering skalerbar. Aktiv redundans for alle enkle punkter av feil. Indexasjon og optimaliserte utholdenhet strukturer i ODS. Schedule regelmessige data backup og opprydding skript for ODS. Transaction historier på alle databaser. Checksums for alle ordrer for å oppdage feil. Annotere hendelser med tidsstempler til hopp over stale hendelser. Order validering regler, f. eks maksimal handel quantities. Automated trader komponenter bruker en in-memory database for analysis. Two stadium autentisering for brukergrensesnitt kobler til ATs. Encryption på brukergrensesnitt og tilkoblinger til ATs. Observer design mønster for MVC for å administrere visninger. Ovenstående liste er bare noen få designbeslutninger jeg identifiserte under design av arkitekturen Det er ikke en komplett liste over taktikk Når systemet utvikles, bør flere taktikker brukes på flere nivåer av granularitet for å møte funksjonelle og ikke-funksjonelle krav. Nedenfor er tre diagrammer som beskriver disruptor design mønster, filter design mønster, og den kontinuerlige spørrekomponenten. Kontinuerlig Querying-komponentdiagram Disruptor designmønster klassediagramkilde Filterdesignmønster klassediagram. Opphavsrettvisning. Dette syn på en arkitektur viser hvordan komponentene og lagene skal samhandle med hverandre Dette er nyttig når du lager scenarier for testing av arkitektur design og for å forstå systemet fra ende til slutt Denne visningen består av sekvensdiagrammer og aktivitetsdiagrammer Aktivitetsdiagrammer som viser den interne prosessen for det algoritmiske handelssystemet s og hvordan handelsmenn skal interagere med det algoritmiske handelssystemet, vises nedenfor. Algoritmisk handelsvirksomhet End-to-end algoritmisk handel prosess. Technologies og rammer. Det siste trinnet i å designe en programvarearkitektur er å identifisere potensielle teknologier og rammer som kan brukes til å realisere arkitekturen. Som et generelt prinsipp er det bedre å utnytte eksisterende teknologier, forutsatt at de tilfredsstillende tilfredsstiller både funksjonelle og ikke-funksjonelle krav Et rammeverk er en realisert referansearkitektur, for eksempel JBoss er et rammeverk som realiserer JEE-referansearkitekturen. Følgende teknologier og rammer er interessante og bør vurderes ved implementering av et algoritmisk handelssystem. CUDA - NVidia har en rekke produkter som støtter høy ytelse beregningsmessig finansiering modellering En kan oppnå opptil 50x ytelse forbedringer i å kjøre Monte Carlo simuleringer på GPU i stedet for CPU. Apache River - River er et verktøy-sett som brukes til å utvikle distribuerte systemer. Det har blitt brukt som et rammeverk for å bygge applikasjonsbaserte på SBA-mønsteret. Apache Hadoop - i e vent at den gjennomgripende logging er et krav, da har bruken av Hadoop en interessant løsning på det store dataproblemet Hadoop kan distribueres i et klynget miljø som støtter CUDA technologies. AlgoTrader - en algoritmisk handelsplatform med åpen kildekode AlgoTrader kan potensielt bli distribuert i stedet for de automatiserte handelsdeler. FIX Engine - en frittstående applikasjon som støtter Financial Information Exchange FIX-protokollene, inkludert FIX, FAST og FIXatdl. Selv om det ikke er en teknologi eller et rammeverk, bør komponenter bygges med et programmeringsgrensesnitt API for å forbedre interoperabiliteten av systemet og dets komponenter. Den foreslåtte arkitekturen er utformet for å tilfredsstille meget generiske krav som er identifisert for algoritmiske handelssystemer. Generelt sett er algoritmiske handelssystemer komplisert av tre faktorer som varierer med hver implementering. Forhold på eksterne virksomhets - og utvekslingssystemer. Utløpende ikke-funksjonelle krav and. Ev olving arkitektoniske begrensninger. Den foreslåtte programvarearkitekturen vil derfor måtte tilpasses fra tilfelle til sak for å tilfredsstille spesifikke organisatoriske og regulatoriske krav, samt å overvinne regionale begrensninger. Den algoritmiske handelssystemarkitekturen bør ses som bare en referansepunkt for enkeltpersoner og organisasjoner som ønsker å designe sine egne algoritmiske handelssystemer. For en fullstendig kopi og kilder som brukes, vennligst last ned en kopi av rapporten min. Takk. Oppgraderingssystemer som utformer systemet ditt - Del 1.Den foregående delen av denne opplæringen så på elementene som utgjør et handelssystem og diskuterte fordelene og ulempene ved å bruke et slikt system i et levende handelsmiljø. I denne delen bygger vi på den kunnskapen ved å undersøke hvilke markeder som er spesielt velegnet til systemhandel. Vi vil da ta en mer dyptgående, se på de ulike sjangrene av handelssystemer. Rangering i ulike markeder. Kvartalsmarkedet Aksjemarkedet er trolig det vanligste markedet for å handle, særlig blant nybegynnere. I denne arena dominerer store spillere som Warren Buffett og Merrill Lynch, og tradisjonelle verdier og vekststrategier er langt den vanligste. Likevel har mange institusjoner investert betydelig i design, utvikling og implementering av handelssystemer Individuelle investorer er med i denne trenden, men sakte. Her er noen viktige faktorer å huske på når du bruker handelssystemer i aksjemarkedene. Det store antall tilgjengelige aksjer gir forhandlere mulighet til å teste systemer på mange forskjellige typer av aksjer - alt fra ekstremt volatile over-the-counter OTC-aksjer til ikke-flyktige blue chips. Effektiviteten av handelssystemer kan begrenses av lav likviditet i enkelte aksjer, spesielt OTC og rosa ark issuesmissions kan spise i fortjeneste generert av vellykket handler, og kan øke tapene OTC og rosa ark aksjer ofte pådrar ytterligere provisjon avgifter. Den viktigste trading sy Stengler som brukes er de som ser etter verdi - det vil si systemer som bruker forskjellige parametere for å avgjøre om en sikkerhet er undervurdert i forhold til tidligere prestasjoner, sine jevnaldrende eller markedet generelt. Forex Exchange Markets Valutamarkedet eller forex er verdens største og mest likvide marked Verdens regjeringer, banker og andre store institusjoner handler trillioner dollar på valutamarkedet hver dag De fleste institusjonelle handelsmenn på forexen stole på handelssystemer Det samme gjelder for enkeltpersoner på forexen, men noen handel basert på økonomiske rapporter eller rentebetalinger. Her er noen viktige faktorer å huske på når du bruker handelssystemer i forexmarkedet. Likviditeten i dette markedet, på grunn av det store volumet, gjør handelssystemene mer nøyaktige og effektive. Der er ingen provisjoner i dette markedet, bare sprer seg Derfor er det mye lettere å foreta mange transaksjoner uten å øke kostnadsbesparende til mengden aksjer eller råvarer tilgjengelig e, antall valutaer til handel er begrenset Men på grunn av tilgjengeligheten av eksotiske valutapar - det vil si valutaer fra mindre land - er volatilitetsintervallet ikke nødvendigvis begrenset. De viktigste handelssystemene som brukes i forex er de som følger trender et populært ordtak i markedet er trenden er din venn eller systemer som kjøper eller selger på breakouts Dette skyldes at økonomiske indikatorer ofte forårsaker store prisbevegelser på en gang. Futures Equity, forex og råvaremarkeder tilbyr alle futures trading Dette er et populært kjøretøy for systemhandel på grunn av økt utnyttbar utnyttelse og økt likviditet og volatilitet. Disse faktorene kan imidlertid kutte begge måtene de kan enten forstørre gevinstene dine eller forsterke tapene. Av denne grunn er bruken av futures vanligvis reservert for avanserte individuelle og institusjonelle systemhandlere Dette skyldes at handelssystemer som er i stand til å kapitalisere på futures markedet krever mye større tilpasning, bruk mer avanserte indikatorer og ta mye lenger tid å utvikle. Så det er best Det er opp til den enkelte investor å bestemme hvilket marked som passer best til systemhandel - hver har sine egne fordeler og ulemper. De fleste er mer kjent med aksjemarkedene, og denne kjennskapen gjør det enklere å utvikle et handelssystem. Forex anses imidlertid å være den overlegne plattformen for å drive handelssystemer - spesielt blant mer erfarne handelsmenn. Hvis en næringsdrivende bestemmer seg for å kapitalisere på økt innflytelse og volatilitet, er futuresalternativet alltid åpent I siste instans ligger valget i hendene til systemutvikleren. Typer av handelssystemer. Trinn-Følgende systemer Den vanligste metoden for systemhandel er trend-følgende system I sin mest grunnleggende form venter dette systemet bare en betydelig prisbevegelse , så kjøper eller selger i den retningen Denne typen systembanker på håp om at disse prisbevegelsene vil opprettholde trenden. Gjennomgang Averag e Systemer Ofte brukt i teknisk analyse er et glidende gjennomsnitt en indikator som bare viser gjennomsnittsprisen på en aksje over en tidsperiode. Essensen av trender er avledet fra denne måling. Den vanligste måten å bestemme inngang og utgang er en crossover. Den logiske bak det er enkelt En ny trend er etablert når prisen faller over eller under sin historiske prisgods trend. Her er et diagram som viser både prisblå linjen og den 20-dagers MA-røde linjen i IBM. Breakout Systems. Det grunnleggende konseptet bak denne typen av systemet ligner på et glidende gjennomsnittssystem Ideen er at når en ny høy eller lav er etablert, er prisbevegelsen mest sannsynlig å fortsette i retning av breakout. En indikator som kan brukes til å bestemme breakouts, er en enkel Bollinger Band Overlay Bollinger Bands viser gjennomsnitt av høye og lave priser, og breakouts oppstår når prisen møter kantene på bandene. Her er et diagram som plots pris blå linje og Bollinger Bands gra y-linjer av Microsoft. Ulemper med Trend-Følgende systemer. Ved å bestemme trender, er det alltid et empirisk element for å vurdere varigheten av den historiske trenden. For eksempel kan det bevegelige gjennomsnittet være de siste 20 dagene eller for de siste fem årene, så utvikleren må avgjøre hvilken som er best for systemet. Andre faktorer som skal fastslås er de gjennomsnittlige høyder og nedturer i breakout-systemer. Lagring av natur - Flytte gjennomsnitt og breakout systemer vil alltid ligge. Med andre ord, de kan aldri treffe den eksakte toppen eller bunnen av en trend Dette resulterer uunngåelig i en fortabelse av potensiell fortjeneste, noe som noen ganger kan være signifikant. Alternativ effekt - Blant markedskreftene som er skadelige for suksessen til trend-følgende systemer, er dette en av Den vanligste Whipsaw-effekten oppstår når det bevegelige gjennomsnittet genererer et falsk signal - det vil si når gjennomsnittet faller like i rekkevidde, så reverserer det plutselig retning Dette kan føre til mas sive tap, med mindre effektive stoppstopp og risikostyringsteknikker er ansatt. Slike markeder - Trend-følgende systemer er av naturen i stand til kun å tjene penger på markeder som faktisk gjør trend. Men markeder flytter også sideveis innenfor et visst område for en Utvidet tidsperiode. Ekstrem volatilitet kan forekomme. Noen ganger kan trend-følgende systemer oppleve ekstrem volatilitet, men næringsdrivende må holde seg til hans eller hennes system. Manglende evne til å gjøre det, vil resultere i sikret feil. Motvirkningssystemer I utgangspunktet er målet med motstridssystemet skal kjøpes til lavest og selge på høyeste høyde. Hovedforskjellen mellom dette og trend-etter-systemet er at mottrengsystemet ikke er selvkorrigerende. Med andre ord er det ikke satt tid for å gå ut av stillinger, og dette resulterer i et ubegrenset ulemper potensielle Typer av motstrømsystemer Mange forskjellige typer systemer betraktes som motstrømsystemer Ideen her er å kjøpe når mo mentum i en retning begynner å falme Dette beregnes oftest ved hjelp av oscillatorer For eksempel kan et signal genereres når stokastikk eller andre relative styrkeindikatorer faller under bestemte punkter. Det finnes andre typer mottrendshandelssystemer, men alle deler det samme grunnleggende målet - å kjøpe lavt og selge høyt. Ulemper ved å motvirke følgende systemer. Ønsket beslutningsprosess er nødvendig. For eksempel er en av faktorene som systemutvikleren må bestemme seg for, hvilke punkter relativstyrkeindikatorene fade. Extreme Volatilitet kan forekomme - Disse systemene kan også oppleve ekstrem volatilitet, og en manglende evne til å holde fast i systemet til tross for denne volatiliteten vil resultere i sikret feil. Ubegrenset Ulempe - Som tidligere nevnt er det ubegrenset ulemper, fordi systemet ikke er selvkorrigerende. Det er ikke satt Tid for å gå ut av posisjoner. Konklusjon Hovedmarkedene som handelssystemer egner seg for, er egenkapitalen, forex og futu resmarkeder Hvert av disse markedene har sine fordeler og ulemper De to viktigste sjangrene av handelssystemer er trend-følge og countertrend-systemer Til tross for deres forskjeller krever begge typer systemer i deres utviklingsstadier empirisk beslutningsprosesser fra den delen av utvikler Også disse systemene er utsatt for ekstrem volatilitet, og dette kan kreve noe utholdenhet - det er viktig at systemhandleren holder fast med systemet hans i disse tider. I den følgende avdelingen vil vi se nærmere på hvordan du designer en handel system og diskutere noe av programvaren som systemhandlere bruker for å gjøre livet enklere. Diagrammeringssystemer er fortsatt en stort sett uforskudt aktivitet, til tross for de mange fremskrittene i notasjon og metodologi som er gjort de siste 10-15 årene. Den typiske systemarkitekturdiagramprofilen av en stor organisasjon går noe som dette. Formale standarder eller anbefalinger ikke eksisterer, som fører til ad hoc-diagrammer med et begrenset konsistensnivå på lagnivå og ingen konsistens på bedriftsnivå. Diagramformatene spenner fra bokser og linjer til flammende vegger, miniatyrstasjoner og et ubegrenset sett med Microsoft Visio-ikoner. De fleste diagrammer er overbelastet med uansett informasjon som passer , og deretter litt mer. Flere leverandører involverer prosjekter, bringer egne diagramformater, eller enda mer sannsynlig, flere personer fra forskjellige leverandører, hver med sine egne diagrammer. System Systems Flow har vært en langsiktig advokat for UML for diagrammer systemarkitekturer Alle våre konsulenter er opplært i grunnlaget for notasjonen og i våre unike stilistiske og formelle utvidelser. Vi mener at en streng, men enkel tilnærming til diagrammer er den mest kritiske ingrediensen til formell kommunikasjon i et blandet IT-miljø. Her er en få eksempler på vår tilnærming, sammen med litt forklaring. Logisk distribusjonsdiagram. Notat UML-distribusjonsdiagram. Konvensjoner M odler logiske systemer som noder, inkluderer arkitektonisk viktige komponenter, viser grensesnittleverandører med lollipops og grensesnittkunder med en tilkoblingslinje Se Investigative Architecture Logical Diagram for flere detaljer. Utvikling For teknisk publikum primært. Data Kontekst Diagram. Notat UML Kommunikasjonsdiagram. Konvensjoner Vis ekte tid og batch feeds mellom systemer, samt arten av dataene som blir overført Se Investigative Architecture Data Context Diagram for flere detaljer. Utvikling Godt for forretnings - og tekniske interessenter. Konceptuell oversikt Diagram. Notasjon Ikke-standard. Konvensjoner Handelsnøyaktighet og fullstendighet for enkelhet og markedsførbarhet Bruk begrenset sett med gjenkjennelige ikoner Se Investigative Architecture Conceptual Diagram for mer info. Utvikling Først og fremst for forretningsinteressenter, men også et godt samlet veikartskjema for et helt system. Les mer om diagrammer og UML for Enterprise og Solution Architecture her på vår blogg eller sjekk ut noen av våre publikasjoner Leveraging UML som en standardnotasjon for Enterprise Architecture er et godt sted å starte, da det gir en litt mer detaljert oversikt over dette emnet. Vi inviterer deg til å bli med i kampen for verdien av et klart sett med diagrammer for din organisasjon Ta kontakt med oss, vi vil gjerne hjelpe. Ben Sommer er en hovedkonsulent med Systems Flow, Inc. Han konsulterer for øyeblikket i enterprise solutions arkitektur for store kunder. Han leder også treningsprogrammer for Systems Flow. Hans karriere har spannet nettverk, systemer , og open source software engineering med fokus på identitetsadministrasjon Ben er en utdannet musiker og komponist.
No comments:
Post a Comment