Modulær software
For at skabe fleksible, evolutionære og skalerbare systemer skal vi have modularitet, det vil sige den egenskab, der giver os mulighed for at skabe et bottom-up system (fra bund til top).
Først og fremmest skal du have modulerne, så du skal bruge et "arkiv" af moduler. De skal så være udskiftelige, det vil sige, at det skal være muligt at erstatte et modul med et andet tilsvarende modul, og det sker ved at tillade udveksling af information mellem moduler via definerede grænseflader: samspillet mellem komponenterne må ikke variere, da modulerne varierer.
Modulær software opdager et nyt paradigme for integration mellem komponenter med udvikling af mashups (hybride webapplikationer), det vil sige at skabe noget, der starter fra forskellige kilder, for eksempel ved hjælp af API'er, der oprindeligt blev oprettet til forskellige formål, men derefter kombineret for at producere et nyt produkt.
Hvor enkle skal modulerne være i et modulsystem?
Skemaerne skal laves så enkle som muligt. Hver virksomhed kan håndtere de mest komplicerede relationer på en meget forskellig måde (f.eks. personaleledelse), men de grundlæggende funktioner forbliver de samme (f.eks. løn). Små moduler giver mulighed for større genbrug, mindre udviklingstid og konstant udvikling (hvis du f.eks. adskiller brugergrænsefladen, skal du sikre dig, at den er sammenhængende, for eksempel skal du kunne bruge copy-paste uanset hvilket system den brugergrænseflade er til oprettet).
Il problema che si pone è, chiaramente, su come realizzare l’interazione tra moduli. Un sistema di grosse dimensioni permetteva di avere tante informazioni legate tra loro all’interno del sistema stesso, inoltre permetteva di gestire in modo univoco le informazioni relative
for at få adgang til tilladelser, mens med moduler i Dati de er spredte, og autentificeringsmekanismerne kan varieres.
Denne nedbrydning giver os på samme tid en masse frihed: i Dati vi kan placere dem, hvor vi vil, og distribuere dem, som vi ønsker.
Integration af alle komponenter, database, moduler og grænseflader, sker ikke i et vakuum, men sker på en platform: det er det, der giver os mulighed for at udføre integrationen, derfor er det nødvendigt at definere denne platform godt.
Det, der muliggør skabelsen af modulære systemer, er først og fremmest en standard for den type information, der udveksles af modulerne: Der skal være en overensstemmelse i de mulige kommunikationsstrømme mellem modulerne. Vi kan have flere udskiftelige skrivesystemer, hvis vi har en enkelt standard for dokumentet, men indtil nu er det stik modsatte sket: Et fremherskende skrivesystem med et stort antal dokumentformater. Denne situation har to negative aspekter:
- hvis standarden er forbundet med et system, har det en tendens til at blive universelt,
- questo tende a favorire la chiusura del mercato, perché c’è uno standard che nessun altro può generare, quindi il più diffuso diviene automaticamente il più forte.
Dagsordenen er et eksempel på en tværgående applikation i forhold til alle andre applikationer, fordi der skal være en dagsorden, derfor giver det mening at administrere den på systemniveau og ikke på applikationsniveau. Systemet er den platform, vi kører applikationerne på, hvorigennem vi får dem til at kommunikere. Dette giver os mulighed for at adskille Dati fra ansøgninger. Dette forenkler i høj grad oprettelsen af informationssystemet: vi kan kombinere Dati af to virksomheder lettere eller bruge forskellige applikationer til at få adgang til dem Dati.
Sammenlægning af informationssystemer er afgørende for virksomhedsfusionsprocessen. At have simple formularer gør udvekslingen af information lettere end at anvende komplekse formularer.
Modularitet er ofte allerede til stede fra et eksternt synspunkt: brugerens. Faktisk ser han systemet et stykke ad gangen, det vil sige, at han kun ser det stykke, han bruger, og opfatter det som et modul adskilt fra resten. Tilsyneladende modularitet er det første skridt til at fortsætte mod reel modularitet.
Dette giver os mulighed for at skabe nye inter-komponent interaktioner og tjenester. Systemgrænsefladen bliver afhængig af brugerens omgivende miljø: Systemet reagerer, når brugeren har brug for det, så ventetiden bliver afgørende for at måle systemets effektivitet.
Det er vigtigt, at grænsefladen er designet med udgangspunkt i brugeren, fra det han gør: brugeren vænner sig til procedurerne, selvom de er besværlige og blottet for logik.
Endelig skal platformen være bevidst om at være en platform: ikke kun skal den tillade udførelse af modulerne, men den skal også indeholde alle de funktioner, der kan være tværgående (f.eks. dagsorden, e-mail), som kan tilgås med systemet primitiver (ligesom med copy-paste). For systemet kunne disse ses som
- normale applikationer, men de er essentielle for at kunne forbinde komponenterne.
- Platform = system + tværgående tjenester.
Platformen er ikke systemet og erstatter det ikke, især hvis du har forskellige systemer (Windows, Linux, Mac...), hvor middlewaren tager over, og viser flere systemer, som om de var ét.
Derfor skal modulære systemer have mindst 4 egenskaber:
- formularerne skal være enkle;
- modulerne skal være udskiftelige;
- du har brug for en platform, der er fuld af tjenester, der er nødvendige for integration;
- grænsefladen skal være designet til at tilfredsstille dem, der bruger applikationen.
Alle disse karakteristika er knyttet til evolution: Modulerne tillader separate evolutioner og tillader evolutionen af systemet. Platformen og grænsefladen skal til gengæld kunne udvikle sig efter protokoller og procedurer.
Share:
Få mere at vide fra Online Web Agency
Abonner for at modtage de seneste artikler via e-mail.
