Funktioner i utvecklingen av mjukvaruagenter. Skäl för val av verktyg och mjukvaruutvecklingsmiljö

Vi tillhandahåller en omfattande övervägande av alla delar

Varför du behöver definiera krav

Utvecklingsmiljön bör innehålla allt du behöver för att skapa och distribuera mjukvaruintensiva system (d.v.s. system där mjukvara är det viktigaste och oumbärliga elementet). Varför är det viktigt att ha en konsekvent definition av utvecklingsmiljökrav? Kort sagt, många organisationer försöker minska tiden till marknaden, minska kostnaderna och förbättra kvaliteten, vilket alla är affärsmål som är direkt relaterade till kvaliteten på den miljö som används för att bygga sådana system. Att ha en konsekvent och heltäckande definition av utvecklingsmiljön till hands säkerställer att ingenting förbises när man planerar åtgärder för att förbättra den befintliga miljön, definierar miljökrav, definierar miljöns arkitektur, utvärderar miljön, säkerställer en lämplig nivå av avkastning på investeringen när förändra miljön och så vidare. Att definiera din utvecklingsmiljö är en avgörande input till alla dessa uppgifter.

Plats för utvecklingsmiljö i sammanhang

Innan du tittar på de specifika elementen som utgör en utvecklingsmiljö är det till stor hjälp att först förstå var utvecklingsmiljön passar in i helheten.

Figur 1 visar kvalitetssäkringscentrum(Center of Excellence), ansvarig för att skapa och underhålla utvecklingsmiljön. Denna miljö används i utvecklingsprojekt, som i sin tur skapar och underhåller mjukvaruintensiva system (eller någon annan mjukvarutillgång, såsom komponenter eller tjänster). Denna enkla visualisering låter dig klargöra skillnaderna mellan rollen som ett QA-center (inklusive rollerna för teammedlemmar, processer och en nyckelnod - utvecklingsmiljön) och projekt som använda sig av denna utvecklingsmiljö (och dem roller, processer och noder).

Utvecklingsmiljöelement

Enligt IBM Rationals mjukvaruexperter består utvecklingsmiljön av följande sex element, som var och en visas i figur 2 och beskrivs nedan:

• Metod
• Verktyg
• Förberedelse (aktivering)
• Organisation
• Implementering (antagande)

Du kanske är bekant med komponenterna i People-Process-Technology-modellen, som är viktiga byggstenar i ett framgångsrikt utvecklingsprojekt. Denna modell är dock alltför förenklad för denna artikels syften. Den här modellen är dock byggd på de element som visas i figur 2:

• Personal Det är organisation och förberedelser.
• Bearbetaär en metodik.
• Teknologi Det är medlen och infrastrukturen.

Implementering är ett nytt (och mycket viktigt) element som fokuserar på att distribuera utvecklingsmiljön över en organisation, affärsenhet eller projekt.

Metod

En nyckelkomponent i varje utvecklingsmiljö är den metodik som följs, formellt eller informellt, av praktiker. Här är nyckelkomponenterna relaterade till metoden:

• Nyckelelement i metodiken, såsom roller, arbetsprodukter, uppgifter och processer.
• Ytterligare delar av metoden, såsom standarder, riktlinjer, riktlinjer, mallar och exempel.
• Teknikens distributionstopologi, som kan beaktas till exempel när tekniken implementeras som en webbplats på ett företags intranät. I vårt exempel krävs en webbserver för att vara värd för innehållet, och arbetsstationerna måste ha en lämplig webbläsare installerad och ansluten till webbservern.

Verktyg

Utvecklingsverktyg automatiserar aspekter av den valda metoden. Du kan till exempel använda verktyg för att lagra och hantera krav för ett projekt under utveckling, för att visuellt modellera arkitektur och design, för att testa programvara etc.

Nyckelelement relaterade till verktyg:

• Utvecklingsverktyg och verktyg för deras integration.
• Scenarier för att installera och konfigurera utvecklingsverktyg.
• Topologi för distribution av utvecklingsverktyg, som tar hänsyn till nödvändig programvara och Hårdvara, både på klientsidan och på serversidan, tillsammans med alla målplattformar och emulatorer (till exempel vid utveckling av realtidsenheter eller inbäddade enheter).

Förberedelse (aktivering)

Utbildning av specialister för att använda utvecklingsmiljön (utbildning och mentorskap). viktigt tillstånd dess framgångsrika genomförande. Därför inkluderar aspekter av utvecklingsmiljön definitionen och skapandet av utbildnings- och instruktionsmaterial. Dessutom betalar ledande företag Särskild uppmärksamhetöka personalens professionalism och fokusera på externa professionella organisationer.

Nyckelelement relaterade till förberedelser:

• Studieprogram och kurser. De täcker en mängd olika behov, från att utbilda erfarna proffs i detaljerna i utvecklingsmiljön till ett omfattande omskolningsprogram för specialister.
• Instruktionsmaterial. De används av specialister när de ger råd till mindre erfarna kollegor.
• Provisioning distributionstopologi. Topologin för utplaceringen måste tas med i beräkningen, till exempel när utbildningen av specialister organiseras genom webbaserad utbildning. Återigen krävs en webbserver för att vara värd för innehåll och arbetsstationer måste vara utrustade med webbläsare. Distributionstopologin kan också specificera de rum och klassrum som krävs för klassrumsträning.

Organisation

En annan aspekt av utvecklingsmiljön är att säkerställa att lämpliga organisatoriska resurser finns tillgängliga för att definiera, distribuera och hantera den. Dessa kan inkludera specialister inom specifika aspekter av utvecklingsmiljön (till exempel facilitatorer, underspecialister, utbildare och mentorer), personal för att administrera och underhålla miljön, personal med lämpliga kvalifikationer i företagets helpdesk och relevanta praktikgemenskaper.

Nyckelelement relaterade till organisationen:

• Bestäm de organisatoriska roller och avdelningar som är en del av utvecklingsmiljön.
• En distributionstopologi för organisationsresurser som anger platsen för dessa organisationsenheter.

Infrastruktur

Ur utvecklingsmiljöns synvinkel betraktas infrastrukturen i termer av hårdvara och mjukvara. Detta har diskuterats tidigare i diskussionen om metodik, verktyg, utbildning och organisation. Det finns dock tre skäl att separat betrakta infrastruktur som ett nyckelelement:

1. Först, konsolidering. Till exempel, när man överväger infrastrukturbehoven för utvecklingsmiljön som helhet, kan det fastställas att endast en webbserver behövs för att stödja både webbinnehållsmetodik och webblärande.
2. För det andra, se till att all ytterligare hårdvara och mjukvara som stöder utvecklingsmiljön (t.ex. operativsystem, databashanteringssystem, hårdvaruhanteringssystem, testverktyg för utveckling av realtid och inbäddad enhet) tas i beaktande.
3. För det tredje kan kvalitetssäkringscentret kräva att infrastruktur distribueras för att stödja skapandet och testningen av utvecklingsmiljön innan den distribueras till någon produktionsinfrastruktur som stödjer affärsprojekt.

Nyckelelement relaterade till infrastruktur:

• Plats, noder och anslutning.
• Programvara (t.ex. operativsystem, databashanteringssystem, maskinvaruhanteringssystem, testverktyg).

Implementering (antagande)

Utöver de redan listade elementen är det viktigt att överväga att implementera miljön i en organisation, affärsenhet eller utvecklingsprojekt.

Nyckelelement relaterade till implementering:

• Implementationsplan. Den här planen definierar de uppgifter som vanligtvis utförs vid implementering av en miljö, såsom att skaffa hårdvara och mjukvara.
• Metoder för att genomföra organisatoriska förändringar. De kommer att behövas för att implementera och integrera utvecklingsmiljön i de relevanta organisationsstrukturernas dagliga aktiviteter.
• Definition av miljöindikatorer. Mätvärden används för att mäta en miljös prestanda.

Lösningskontext

Kontexten för lösningen (där lösningen i fråga är utvecklingsmiljön) är också viktig. Kontexten representerar kraven på utvecklingsmiljön och kan betraktas i termer av funktionalitet, egenskaper och restriktioner.

• Funktionalitet representerar schemat eller ordningen för programvaruutveckling som tillhandahålls av utvecklingsmiljön. Genomförandet av dessa krav gör det nödvändigt att ta hänsyn till alla de faktorer som nämnts tidigare. Till exempel stöds kravhanteringsordern (se figur 3) av följande aspekter:
  • Metodik för kravhantering.
  • Verktyg för kravhantering.
  • Krav chefsutbildning och mentorskap.
  • Ett supportteam som vet hur man hanterar kravhanteringsfrågor.
  • Hårdvara och mjukvara för att stödja element relaterade till kravhantering.
  • Lämplig implementering av kravhanteringsprocedurer i projekt.

Andra komponenter i utvecklingsmiljön, såsom arkitektur eller kvalitetsledning, kan betraktas på samma sätt. Denna teknik kan också tillämpas på specifika aktiviteter, såsom iterativ utveckling (vilket är grunden för ett agilt förhållningssätt till mjukvaruutveckling och leverans), vilket också kräver hänsyn till alla delar.

• Egenskaperär de parametrar som utvecklingsmiljön ska ha. De kräver också att alla delar av utvecklingsmiljön beaktas. Till exempel, för att implementera en skalbarhetsegenskap (till exempel möjligheten att stödja ett annat antal samtidiga användare), används följande tillvägagångssätt:
  • En metod som kan anpassas för att passa projektets storlek.
  • Verktyg som kan konfigureras för att stödja en konfigurerbar metod.
  • Lämpliga mekanismer och inlärningsnivåer för projekt av olika storlek.
  • Organisatoriska resurser för att säkerställa att personal med lämplig kompetensnivå finns tillgänglig för att stödja det förväntade antalet utvecklingsprojekt.
  • Infrastruktur som kan skalas för att stödja det förväntade antalet samtidiga användare.
  • Lämpliga miljöinjektionsmekanismer.
• Restriktioner, som utvecklingsmiljön måste följa, kräver också hänsyn till alla delar av utvecklingsmiljön. Om du till exempel behöver migrera från en befintlig miljö kan du behöva göra följande:
  • Ta reglerna från den befintliga metoden och införliva dem i den nya.
  • Migrera arbetsprodukter från den äldre verktygslådan till den nya verktygslådan (eller integrera med befintliga verktyg).
  • Tillhandahålla utbildning som är lämplig för det aktuella läget och korrekt organiserad.
  • Tillhandahålla personal för att säkerställa en smidig övergång från första anger i planerad.
  • Identifiera infrastruktur som utnyttjar befintlig infrastruktur maximalt (t.ex. återanvänd befintlig hård- och mjukvarulicenser där så är möjligt).
  • Tillhandahåll implementeringsmekanismer som bekräftar att migreringen har slutförts.

En annan viktig begränsning när man överväger att ändra en befintlig utvecklingsmiljö är naturligtvis Return On Investment (ROI). För att ett sådant initiativ ska bli framgångsrikt måste det verkligen ge positiva resultat i linje med affärsplanen. Varje aspekt av utvecklingsmiljön påverkar ROI både vad gäller kostnad och vinst.

Även om det inte visas i figur 2, är funktionaliteten, egenskaperna och begränsningarna vanligtvis associerade med en specifik affärskontext (t.ex. affärsmål). I denna mening omfattar beslutssammanhanget även affärsaspekter. Detta kan vara särskilt viktigt när man visar utvecklingsmiljöns direkta eller indirekta engagemang för att uppnå affärsmål.

Definiera, distribuera, hantera

När man definierar de olika delarna av utvecklingsmiljön är det användbart att beakta följande delar av miljöns livscykel (se figur 4) eftersom var och en av dem, förutom beslutssammanhanget, har sina egna aspekter som påverkar definitionen:

• Definition av miljö.
• Miljöutbyggnad.
• Miljöledning.

Innan man tittar på regionerna i figur 4 bör det förklaras varför de är sammankopplade cykel. Denna siffra bekräftar att en effektiv förändring (i det här fallet, en förbättring av utvecklingsmiljön) vanligtvis uppnås genom en serie inkrementella förändringar, snarare än en metod big bang(evolution, inte revolution), och varje inkrementell förändring representerar en passage genom cykeln. Men en förändring som genomförs i en cykel ändrar per definition sammanhanget för nästa (exempelvis har specialister nu de nödvändiga kvalifikationerna, ny utrustning har dykt upp, nya verktyg har införskaffats etc.), dvs. den cykliska karaktären förändringar visas.

Följande avsnitt täcker varje del av utvecklingsmiljön, tillsammans med att definiera en lösning, distribuera en lösning och hantera en lösning.

Definition

Appliceras på definition utvecklingsmiljöer påminner om den tidigare diskussionen om nyckelelement. Denna diskussion upprepas inte här, även om tabell 1 för fullständighetens skull listar de olika element som tidigare definierats.

Det bör också noteras att definitionen vanligtvis övervägs på organisationsnivå och kan kräva lokalt genomförande för att uppfylla kraven för en viss affärsenhet eller ett visst projekt när det distribueras. Detta återspeglas i följande avsnitt.

Tabell 1 Definitionsaspekter

Spridning

Att implementera en utvecklingsmiljö väcker specifika frågor om varje element (se tabell 2).

Tabell 2. Utbyggnadsöverväganden

Nyckelelement metoder:

• Fastställande av den lokala konfigurationen. När en metodik implementeras till en affärsenhet eller ett utvecklingsprojekt kan det krävas en lokal konfiguration för att återspegla de specifika egenskaperna hos affärsenheten, utvecklingsprojektet eller systemet (till exempel genom att tillhandahålla lämpliga nivå av formalitet).
• Utbyggnad av metodiken. Det garanterar tillgängligheten av tekniken för specialister.

Nyckelelement verktyg:

• Prestanda lokal miljö. All lokal anpassning av verktygen används för att automatisera anpassningen av den lokala metoden.
• Installation av verktyg. Gör installerade verktyg (och deras integration) tillgängliga för specialister.
• Migrering av lokal data. Det kan till exempel vara nödvändigt att migrera data från en befintlig verktygslåda till en ny.

Nyckelelement Träning:

• Utför lokala inställningar. lokal miljö. Vid behov – anpassning, förtydligande eller uppdatering läromedel. Du kan till exempel revidera utbildningsmaterialet för att anpassa det till den process som definieras för en given affärsenhet eller utvecklingsprojekt.
• Utplacering av utbildningsmaterial. Garanterar tillgång till dem för artister, inklusive tillgång till allt webbmaterial.
• Utövande utbildning. Under utbildningen samlas feedback från utförare in.

Nyckelelement organisationer:

• Fastställande av den lokala konfigurationen. Experter kan behövas för att stödja de specifika behoven hos en viss affärsenhet eller utvecklingsprojekt.
• Omorganisering. Organisering av personal och resurser för att stödja utvecklingsmiljön.

Nyckelelement infrastruktur:

• Fastställande av den lokala konfigurationen. Bestäm vilken infrastruktur som krävs för en viss affärsenhet eller utvecklingsprojekt.
• Tillhandahåller plats, noder och anslutningar. Gör all nödvändig hårdvara tillgänglig (inklusive alla målplattformar och emulatorer för realtids- och inbäddade enheter).
• Tillhandahåller stödjande programvara. Installera all nödvändig programvara som stöder utvecklingsmiljön (till exempel databashanteringssystem eller testverktyg).

Nyckelelement genomförande:

• Fastställande av en lokal genomförandeplan. Förfina implementeringsplanen för att möta affärsenhetens eller utvecklingsprojektets specifika behov.
• Kontrollera att miljön är korrekt. Testa den distribuerade miljön och verifiera att den uppfyller specifika krav vad gäller specificerad funktionalitet, egenskaper och begränsningar.

Kontrollera

Som visas i tabell 3 har hanteringen av utvecklingsmiljön efter att den har distribuerats också specifika aspekter för varje element.

Tabell 3. Ledningsaspekter

Nyckelelement metoder:

• Insamling av feedback om metodiken. En nyckelaspekt för att hantera en utvecklingsmiljö är dess ständiga förbättring. Därför gäller insamlingen av feedback för alla element. Feedback samlas vanligtvis in subjektivt med hjälp av till exempel frågeformulär.

Nyckelelement verktyg:

• Säkerhetskopiering, arkivering, dataåterställning. Verifiera att arbetsprodukter skapade av specialister hanteras på rätt sätt och att "god administration" tillämpas.
• Samla feedback om verktyg. Samla in feedback (både positiv och negativ) om verktygens tillgänglighet och prestanda.

Nyckelelement Träning:

• Utövande utbildning. Utse projektsponsorer så att genomförarna vet hur de ska använda miljön.
• Att samla in feedback om förberedelser, d.v.s. för utbildning eller mentorskap.

Nyckelelement organisationer:

• Samla in feedback om organisationen. Utförare ger sina kommentarer om det stöd som ges för användningen av utvecklingsmiljön (till exempel om kvaliteten på supporttjänsten).

Nyckelelement infrastruktur:

• Tillhandahållande eller borttagande av infrastrukturelement efter behov. Från början till slutet av projekt måste utvecklingsmiljön ändras på lämpligt sätt för att optimalt stödja antalet personer som använder miljön vid varje given tidpunkt.
• Samla in feedback om infrastrukturen, inklusive både hårdvara och stödjande mjukvara.

Nyckelelement genomförande:

• Mätning av miljöns effektivitet. Detta är en nyckelaspekt för framgångsrik implementering. Du kan till exempel förse artister med en checklista och be dem att utvärdera effektiviteten av införandet av nya arbetssätt.
• Insamling av feedback om implementering. Samla in feedback om implementeringsmetoder.

Ömsesidiga beroenden

Tänk slutligen på att utvecklingsmiljöns olika delar inte är oberoende. En alternativ representation av figur 2 visas i figur 5, som visar att varje element har relationer med alla andra element.

Här är några exempel på beroenden mellan element:

• Metodik (metodologi) avser tillgängliga utbildningar (utbildning).
• Verktyg (verktyg) automatiserar uppgifter (metodik).
• Administrativa roller (organisation) definieras för att stödja verktyg (verktyg).
• Servrar (infrastruktur) tillhandahålls för att vara värd för en uppsättning verktyg (verktyg).
• Implementering av arbetssätt (implementation) bedöms med hjälp av ett specifikt tillvägagångssätt (metodik).

Slutsats

Denna artikel kompletterar artikeln (EN) publicerad av samma författare i Den rationella kanten 2008. Den beskriver nyckelelementen i en utvecklingsmiljö och belyser de olika aspekterna av att definiera, distribuera och hantera den miljön. Den tillhandahåller ett enkelt ramverk för att säkerställa att alla dessa aspekter beaktas när man planerar åtgärder för att förbättra en befintlig miljö, definierar miljökrav, definierar en arkitektur, utvärderar en miljö och så vidare.

Alexey Fedorov, Natalia Elmanova

Den tidigare artikeln i denna serie ägnades åt övervägandet av den logiska och fysiska designen av data och de verktyg som används i denna process. Vi är övertygade om att datateknik spelar en nyckelroll i utvecklingen av informationssystem, eftersom kvaliteten på detta arbete avgör kostnaderna för att skapa applikationer för slutanvändare, såväl som med efterföljande underhåll och modernisering av den skapade produkten. Resultatet av detta steg är en "tom" databas (d.v.s. en databas vars tabeller i stort sett inte innehåller några poster, möjligen med undantag för tabeller av referenskaraktär såsom en lista över ämnen Ryska Federationen eller telefonriktnummer).

Nästa steg i livscykeln informationssystem- utveckling av klientapplikationer. Resultatet av detta steg är en färdig produkt, bestående av ett antal applikationer som låter användare lägga in data i tabeller eller redigera befintliga data, analysera inmatade data och presentera dem i en mer läsbar form - grafer, pivottabeller eller rapporter (inklusive " pappersdokument).

Processen att designa data för relationell DBMS är till viss del en logisk process och är föremål för en enda standardmetodik. Detta orsakar en låg grad av beroende av sekvensen av åtgärder som utförs under utformningen av dessa åtgärder, både av vilket särskilt datadesignverktyg som används, och av om det överhuvudtaget används. Egentligen är det därför som verktyg för datadesign är mer eller mindre lika i sitt gränssnitt, vilket i huvudsak återspeglar processen att rita datamodeller på papper.

Processen att skapa klientapplikationer som fungerar med databaser är ganska svår att beskriva i form av en sådan universell sekvens av åtgärder, eftersom logiken för en viss applikation nästan helt beror på logiken i den affärsprocess som modelleras. Applikationsutvecklingsverktyg som en kategori av mjukvaruprodukter har funnits mycket längre än datadesignverktyg, och de är mer olika - från en kompilator som körs från kommandorad, till verktyg, där den färdiga applikationen sätts ihop med "mus" från färdiga komponenter, och koden genereras automatiskt. Med en sådan mängd olika utvecklingsverktyg bör de klassificeras på något sätt, vilket vi kommer att försöka göra i den här artikeln, och berättar längs vägen vilka av dem som är bekväma att använda i ett visst fall.

Klassificering av applikationsutvecklingsverktyg

Utvecklingsverktyg kan klassificeras från olika positioner, till exempel baserat på det programmeringsspråk de stödjer, eller prestandan för de skapade applikationerna på en viss plattform, eller närvaron av vissa bibliotek och visuella verktyg i dem. Vi kommer att försöka klassificera applikationsutvecklingsverktyg baserat på bekvämligheten med deras användning för att skapa produkter som är ett användargränssnitt till databasen.

Nästan alla utvecklingsverktyg som påstår sig vara universella kan fås att fungera med vilken databas som helst - det räcker för att stödja användningen av tredjepartsbibliotek i detta utvecklingsverktyg och denna databas har en uppsättning klientgränssnitt (API) för plattformen på vilka de skapade applikationerna ska fungera. Men inte alla par av "utvecklingsverktyg plus DBMS"-produkter är attraktiva i termer av arbetskostnader förknippade med skapandet av sådana applikationer. Du kan skriva en komplett applikation som anropar klientens API-funktioner och implementerar ett bekvämt användargränssnitt med en C-kompilator och ett enkelt grafikbibliotek (till exempel så att du kan ändra färgen på pixlar på skärmen) för operativsystemet där detta applikationen kommer att köras. Men kostnaderna för att implementera ett sådant projekt kan vara helt omotiverade, eftersom utvecklare i det här fallet måste implementera funktioner som redan finns i klassbiblioteken och komponenter i utvecklingsverktyg som är djupare fokuserade på att skapa databasapplikationer eller inkluderar stöd för att skapa sådana applikationer.

Utvecklingsverktyg fokuserade på specifika DBMS

För tio eller tjugo år sedan, i många applikationer som använder databaser, anropades klient-API-funktioner från kod skriven på ett av programmeringsspråken, oftast i C. Se bara på beskrivningen av API:et för klientdelen av nästan vilken server-DBMS som helst - och du hittar många exempel på de mest typiska kodfragmenten, till exempel för att registrera en användare, köra frågor, etc. Det blev dock snabbt uppenbart för DBMS-utvecklare att arbetskostnaderna förknippade med att skriva sådan kod kan reduceras avsevärt genom att samla de mest typiska kodfragmenten och de vanligaste användargränssnittselementen (även för alfanumeriska terminaler) i biblioteken, ordna dessa bibliotek på ett sätt som en separat produkt och lägga till en utvecklingsmiljö och designverktyg för användarformulär för att visa och redigera data, samt rapporter. Så här dök de första DBMS-specifika utvecklingsverktygen ut, som Oracle * Forms (föregångaren till den nuvarande Oracle Forms-utvecklare).

Produkter av denna klass finns fortfarande tillgängliga på marknaden för utvecklingsverktyg idag. Nästan alla leverantörer av serverdatabas producerar också applikationsutvecklingsverktyg. I de allra flesta fall stöder moderna versioner av dessa utvecklingsverktyg åtkomst till DBMS från andra tillverkare som använder minst en av de universella dataåtkomstmekanismerna (ODBC, OLE DB, BDE). Åtkomst till "deras" DBMS utförs dock vanligtvis så mycket som möjligt effektivt sätt, det vill säga genom att använda klient-API:er, objekt som finns i biblioteken i klientdelen av serverns DBMS, speciella klasser för åtkomst till data i detta DBMS, eller genom att implementera drivrutiner för universella dataåtkomstmekanismer som kan ta hänsyn till de specifika egenskaperna hos denna DBMS.

Desktop DBMS-utvecklingsmiljöer kan särskiljas i en separat kategori. I artikeln i denna serie som ägnas åt skrivbords-DBMS, har vi redan noterat att den stora majoriteten av skrivbords-DBMS som har överlevt till denna dag, såsom Microsoft Visual FoxPro, Microsoft Access, Corel Paradox, Visual dBase, stöder åtkomst till server-DBMS, åtminstone genom att använda universella mekanismer för att komma åt data, vilket gör att vi villkorligt kan klassificera dem som utvecklingsverktyg. Observera dock att för närvarande är skapandet av applikationer i "klient-server"-arkitekturen med deras hjälp ett ovanligt fenomen. Undantaget är kanske paren Microsoft Access - MSDE, Microsoft Access - Microsoft SQL Server och Microsoft Visual FoxPro - Microsoft SQL Server. Detta är resultatet av en kompetent policy från Microsoft, som strävar efter maximal kompatibilitet för sina produkter och tillhandahåller det mest smärtfria för användare att byta ut sina stationära DBMS med sina egna databasservrar (Access->MSDE->Microsoft SQL Server, FoxPro->Visual FoxPro->Microsoft SQL Server) .

Utvecklingsverktyg som är universella i förhållande till DBMS

Utvecklingsverktyg som är universella i förhållande till DBMS (eller som påstår sig vara liknande universalitet), är som regel anhängare av konventionella applikationsutvecklingsverktyg som inte är direkt relaterade till databaser. Typiska exempel på sådana utvecklingsverktyg är Borland Pascal, Borland C++, Microsoft QuickC. Dessa verktyg kan använda tredjepartsbibliotek och gjorde det möjligt att komma åt funktionerna hos klient-API:er, och med utvecklingen av universella dataåtkomstmekanismer (som ODBC), även API-funktionerna för bibliotek som implementerar sådana mekanismer. Det bör noteras att stationära DBMS-miljöer (som dBase, FoxBase) eller pseudokompilatorer för språk i xBase-familjen (som Clipper) ofta skapades med hjälp av dessa utvecklingsverktyg.

Senare versioner av de tidigare nämnda utvecklingsverktygen förvärvade bibliotek med funktioner och klasser utformade för att komma åt data med hjälp av vissa universella mekanismer. Ytterligare utveckling av utvecklingsverktyg ledde till uppkomsten av två kategorier av produkter för detta ändamål.

Den första kategorin inkluderar utvecklingsverktyg som har omfattande klassbibliotek, ett stort antal "trollkarlar" och kodgeneratorer, men som är fokuserade på "manuell" kodskapande och som sällan används för att skapa "standardiserade" databasapplikationer (här under frasen " standardapplikation"vi menar en applikation som har direkt tillgång till databasen som användaren interagerar med, det vill säga det är en "klassisk" klient till serverns DBMS. En typisk (och den enda riktigt populära på mjukvarumarknaden) representant för detta klass av produkter är Microsoft Visual C ++. hjälp från Microsoft Visual C++ och MFC-bibliotek (Microsoft Foundation Classes) kan skapa vilken applikation som helst om du har skicklighet, kunskap, skicklighet och tid. Ändå utvecklas applikationer med ett komplext användargränssnitt (till exempel de som använder databaser) inte ofta med dess hjälp (även om exempel på dess användning finns även i rysk litteratur). I grund och botten används denna produkt för att skapa klientapplikationer i händelse av att de ställer speciella krav på dem, såsom hög prestanda, förmågan att utföra icke-standardiserade operationer, etc.

Den andra kategorin inkluderar utvecklingsverktyg med avancerade visuella verktyg som låter dig bokstavligen "rita" användargränssnittet, delvis radera skillnaderna mellan programmerarens och användarens arbete och minska kostnaderna för slutprodukten genom att locka utvecklare som inte är av den högsta kvalifikationen till utformningen av gränssnittet (om du noggrant studerar kursprogrammen utbildningscenter som specialiserat sig på att lära ut Microsoft, Borland och Sybase utvecklingsverktyg, kan du upptäcka att varaktigheten av utbildningen, efter att ha lyssnat på vilken den vanliga Windows-användare bör lära sig hur man skapar klientapplikationer för server DBMS, är från 5 till 10 arbetsdagar).

Det är denna kategori av utvecklingsverktyg som oftast används när man skapar klientapplikationer. De mest populära produkterna i denna klass inkluderar Microsoft Visual Basic, Borland Delphi , Sybase PowerBuilder och Borland C++Builder. Utvecklingsmiljöerna för sådana produkter är mycket lika till utseendet (upp till placeringen av fönstren på skärmen, som är inställd "som standard"): som regel innehåller utvecklingsmiljön för en sådan produkt en "tom" av den designade formulär (analogt med ett fönster), en separat panel med ikoner för användargränssnittselement och andra objekt som används i applikationen som kan väljas och placeras på formuläret, ett fönster där egenskaperna för ett av de valda elementen i formuläret är visas och redigeras (och ibland en lista över händelser som detta element reagerar på), ett kodredigeringsfönster där du kan ange kodavsnitt som är associerade med bearbetningen av vissa händelser, samt koden som implementerar arbetslogiken den här applikationen. Vanligtvis, moderna bekvämligheter utvecklingar av denna klass låter dig skapa de enklaste applikationerna för redigering av data med lite eller ingen kod.

På senare tid har det också blivit väldigt populärt att skapa applikationer som använder databasåtkomst, men som finns inuti vanliga dokument. Utvecklingsverktygen för sådana applikationer är baserade på makrospråken för motsvarande redaktörer. Den mest typiska och praktiskt taget enda populära representanten för utvecklingsverktygen i denna kategori är Visual. Grundläggande för Applikationer, som liknar de visuella utvecklingsverktygen som anges ovan och skiljer sig från dem genom att applikationer som skapats med dem finns i dokument Microsoft Office och är inte alienerade från dem.

Observera dock att ovanstående uppdelning av utvecklingsverktyg i dessa två klasser är ganska villkorad. Som vi sa ovan stöder nästan alla utvecklingsverktyg för databasapplikationer, inklusive de som fokuserar på specifika DBMS, minst en av de universella dataåtkomstmekanismerna. Och nästan alla "universella" applikationsutvecklingsverktyg, om de tillhör tillverkaren av någon server DBMS, stöder "deras" DBMS bättre än tredjeparts DBMS (detta kan uttryckas till exempel i specialklassbibliotek eller komponenter för åtkomst till detta server, och även i närvaro av gemensamma arkiv med objekt och datamodeller, och ibland redigerare av dataåtkomstparametrar eller datascheman som är gemensamma med klientdelen av serverns DBMS)

Klassificering av applikationer som använder databaser

Applikationer i klient-server-arkitektur

I de tidigare artiklarna i denna serie har vi redan pratat om vad som utgör en "klient-server"-arkitektur i traditionell mening. Därför kommer vi bara kort att minnas att informationssystem skapade i denna arkitektur är en databasserver som manipulerar data och en klientapplikation som får åtkomst till den och använder antingen klient-API:er (eller klasser och komponenter som kapslar in deras anrop), eller en från universell data åtkomstmekanismer. Vanligtvis, när en sådan applikationsarkitektur används, är databasservern också ansvarig för att upprätthålla affärsregler implementerade i form av lagrade procedurer, utlösare, serverbegränsningar och andra databasobjekt.

I det här fallet används oftast utvecklingsverktyg med avancerade visuella verktyg, som Microsoft Visual Basic, Borland Delphi, Sybase PowerBuilder, Borland C++Builder för att skapa klientapplikationer.

Observera dock att valet av moderna applikationsarkitekturer för närvarande är ganska brett och inte är begränsat till den "klassiska" klient-server-arkitekturen, vilket innebär att applikationen består av en databasserver och klientapplikationer som interagerar med denna server. Därför kommer vi nedan att diskutera vilka utvecklingsverktyg som är bekväma att använda när man skapar distribuerade applikationer.

Distribuerade applikationer

Distribuerade (eller flerskiktiga) applikationer består vanligtvis av presentationstjänster (eller "tunna" klienter som slutanvändare vanligtvis interagerar med), affärslogiktjänster implementerade som affärsobjekt (eller mellanskiktstjänster; ofta för att beskriva en samling av sådana tjänster benämns mellanprogram) och datatjänster (vanligtvis bestående av en databasserver och dataåtkomstmekanismer). Affärslogiktjänster är utformade för att ta emot användarinput från presentationstjänster, interagera med datatjänster för att utföra affärsoperationer (som orderhantering eller balansräkningsberäkning) och returnera resultaten av dessa operationer till presentationstjänster.

Till skillnad från konventionella klient-serverapplikationer, i system med flera nivåer, har tunna klienter vanligtvis inte direkt tillgång till data. Istället skickar kunder förfrågningar till affärsobjekt som är speciellt utformade för detta ändamål. Dessa kan i sin tur utföra affärsoperationer som kunden begär (som att bearbeta en order, slutföra banktransaktion etc.).

Vissa av affärsobjekten kan komma åt datatjänster med hjälp av någon form av dataåtkomstmekanism. Eftersom slutanvändaren inte interagerar direkt med affärsobjekt har de senare vanligtvis inget användargränssnitt i vanlig mening. Fysiskt kan affärsobjekt implementeras som operativsystemtjänster, konsolapplikationer eller Windows-applikationer, såväl som bibliotek som laddas in i adressutrymmet för en serverapplikation speciellt utformad för detta ändamål (webbserver, applikationsserver, transaktionsövervakare, etc.). ). Det är inte ovanligt att en enskild affärsenhet servar många kunder.

För att skapa affärsobjekt används både utvecklingsverktyg med avancerade visuella verktyg och utvecklingsverktyg fokuserade på "manuellt" skapande av applikationskod (som Visual C++). Observera att de senaste versionerna av nästan alla de mest populära Windows-(Microsoft Visual Basic, Visual FoxPro och Visual C++, Borland Delphi och C++Builder, Sybase PowerBuilder) stöder skapandet av olika typer av affärsobjekt (webbapplikationer, ASP-objekt, COM-servrar, etc.), med eventuellt undantag för Microsoft Access - denna produkt är designad mer för kvalificerade användare än för utvecklare av distribuerade system. Ofta används även verktyg för att skapa Java-applikationer (som Borland JBuilder) för detta ändamål.

Observera att, förutom de ovan nämnda "universella" verktygen för att skapa både applikationer i "klient-server"-arkitekturen och affärsobjekt för distribuerade system, finns det specialiserade verktyg på marknaden för utvecklingsverktyg som är utformade specifikt för att skapa affärsobjekt (vanligtvis webbapplikationer). Av utvecklingsverktygen i denna klass för Windows-plattformen är den mest populära Microsoft Visual InterDev, vars första version dök upp 1998. Vi kan också nämna en annan intressant produkt som tillhör samma kategori av utvecklingsverktyg - Borland IntraBuilder, som dök upp två år tidigare, men av någon anledning, trots det växande behovet av produkter av denna klass, fick den inte vidareutveckling. Utvecklingsverktyg av denna klass låter dig som regel skapa applikationer som dynamiskt genererar HTML-kod eller kod på ett av skriptspråken (VBScript eller JavaScript), som överförs av webbservern till användarens webbläsare som en del av en webbsida, och acceptera data som matats in av användaren i HTML-form och skickats av webbläsaren till webbservern.

Slutsats

I den här artikeln diskuterade vi processen för att skapa applikationer som använder databaser, såväl som de olika kategorierna av verktyg som används i deras utveckling. Vi har sett att utvecklingsverktyg kan villkorligt delas upp, å ena sidan, i verktyg fokuserade på användningen av specifika DBMS, verktyg som är universella i förhållande till DBMS, och desktop DBMS-miljöer som används för att utveckla applikationer. Å andra sidan kan de delas in i verktyg fokuserade på visuell design av användargränssnitt (denna kategori inkluderar Microsoft Visual Basic, Borland Delphi, Sybase PowerBuilder, Borland C++Builder) och verktyg fokuserade på att skriva applikationskod (Visual C++ ).

Efter att ha granskat några av de mest populära fann vi att de flesta av dessa produkter som regel stöder:

• åtminstone en av de universella dataåtkomstmekanismerna, som tillåter användning av data från olika DBMS i applikationerna som skapas;
• skapande av flera typer av distribuerade applikationer;
• automatisk generering av applikationskod baserad på modeller skapade med de mest populära verktygen för datadesign och affärsprocessmodellering.

Vi diskuterade också hur klient-serverapplikationer skiljer sig från distribuerade system och vilka utvecklingsverktyg som kan användas för att skapa båda typerna av applikationer.

Ett informationssystems livscykel slutar inte med utvecklingen av applikationer. När de väl har skapats ska de testas, implementeras, tränas för att använda dem och slutligen utnyttjas under ett antal år. Som ett resultat av sådan exploatering ackumuleras data, vilket i regel är mycket mer värdefullt än själva applikationerna. Dessa data utgör ofta det material som behövs för att fatta viktiga förvaltningsbeslut, så det är viktigt att kunna omvandla dem till en form som lämpar sig för ett sådant ändamål. För att göra detta finns det verktyg relaterade till kategorin Business Intelligence - rapportgeneratorer, verktyg analytisk bearbetning data och sök efter mönster. Vi kommer att prata om dem i nästa artikel i den här serien.

För optimal utveckling av mjukvaruverktygsmiljön är det nödvändigt att kombinera olika programmeringsspråk, eftersom vart och ett av dem syftar till att uppfylla vissa mål och mål. Precis som ett fåtal PHP-kommandon gör det möjligt att skapa en hel webbsida, men i praktiken används skriptet nästan alltid i kombination med HTML, och vanligtvis innehåller skriptets källkod ett stort antal rader. Men trots detta bör det noteras att PHP-kod kan finnas var som helst i HTML-dokumentet, men den behöver inte använda HTML. Det är bara nödvändigt att se till att PHP-koden genererar giltig HTML-kod, som sedan visas korrekt av webbläsaren.

HTML är ett hypertextmarkeringsspråk som används för att skapa dokument på Internet. Med den skapas den nödvändiga strukturen och rutnätet på sidan, vars utseende förbättras ytterligare av CSS och JavaScript. För närvarande är den senaste versionen HTML5, som föregicks av HTML4.01. De flesta webbresurser är byggda utifrån just detta språk.

Till skillnad från HTML 4, som har 3 validatorer, har HTML 5 en validator:. HTML 5 stöder MathML och SVG.

Nya taggar: avsnitt, artikel, åt sidan, hgroup, sidhuvud, sidfot, nav, dialog, figur, video, ljud, källa, bädda in för att bädda in innehåll med plugin(endast), markera, framsteg, mätare, tid, ruby, rt, rp , canvas, kommando, detaljer, datalista, keygen, output.

Nya inmatningstyper: tel, sökning, url, e-post, datumtid, datum, månad, vecka, tid, datumlokal, nummer, intervall, färg.

Nya attribut för taggar: pinga mediaattribut för a och område, etc.

Försvinnandet av vissa taggar, på grund av att de kan ersättas av CSS: basefont, big, center, font, s, strike, tt, u.

Ramar försvinner på grund av negativ påverkan på hela sidan

Försvinnandet av vissa taggar, ersatta i den uppdaterade specifikationen med mer relevanta: akronym (förkortning används), applet (objekt används), isindex, dir.

Vissa taggattribut stöds inte på grund av brist på nödvändighet: varv och teckenuppsättning för länk och a, form och koordinater för a, etc.

Vissa attribut för taggar stöds inte på grund av det faktum att när använder CSS uppnåtts bästa effekt: justera för alla taggar, alink, link, text, vlink for body, och så vidare.

Nya API:er: rita 2D-bilder i realtid; kontroll över uppspelningen av mediefiler; lagra data i webbläsaren; redigering; dra och släpp; nätverk; MIMA nya element i DOM.

CSS är ett formellt språk för att beskriva utseendet på ett dokument skrivet med ett märkningsspråk. CSS är en akronym för Cascading Style Sheets. CSS är ett stilspråk som definierar renderingen av HTML-dokument. Till exempel hanterar CSS typsnitt, färg, marginaler, linjer, höjd, bredd, bakgrundsbilder, elementpositionering och många andra saker. HTML kan användas för att utforma webbplatser, men CSS är kraftfullare och mer exakt och utarbetad. CSS stöds för närvarande av alla webbläsare.

HTML används för att strukturera innehållet på en sida. CSS används för att formatera detta strukturerade innehåll. Som webbutveckling designers började leta efter sätt att formatera onlinedokument. För att möta de ökande kraven från konsumenter uppfann webbläsartillverkarna (då Netscape och Microsoft) nya HTML-taggar som t.ex. , som skilde sig från de ursprungliga HTML-taggarna genom att de definierade utseende snarare än struktur. Detta resulterade också i ursprungliga struktureringstaggar som t.ex