Softwareudvikling og dokumentationsværktøjer. Softwareudviklingsværktøjer

1. Softwareudviklingsværktøjer. I processen med softwareudvikling bruges computerstøtte til softwareudviklingsprocesser i en eller anden grad. Dette opnås ved at præsentere i det mindste nogle softwaredokumenter fra PS'en (primært programmer) på computerlagringsmedier (f.eks. diske) og stille speciel software eller specielle enheder inkluderet i computeren til rådighed for softwareudvikleren, skabt til enhver behandling af sådanne. Dokumenter. Som sådan en speciel software kan du angive en compiler fra et hvilket som helst programmeringssprog.

Compileren fritager softwareudvikleren for behovet for at skrive programmer på det computersprog, der er beregnet til udvikleren. En PS ville være ekstremt ubelejlig - i stedet kompilerer den programmer i et programmeringssprog, der passer til den, som den tilsvarende compiler automatisk oversætter til computersprog. En emulator af et sprog kan tjene som en speciel enhed, der understøtter softwareudviklingsprocessen. En emulator giver dig mulighed for at udføre (fortolke) programmer på et andet sprog end computerens sprog, der understøtter udviklingen af ​​softwaren, for eksempel på sproget på den computer, som dette program er beregnet til. En software, der er designet til at understøtte udviklingen af ​​anden software, vil blive kaldt et softwareværktøj til softwareudvikling, og en computerenhed, der er specielt designet til at understøtte udviklingen af ​​software, vil blive kaldt et hardwareværktøj til softwareudvikling.

Softwareudviklingsværktøjer kan bruges gennem hele softwarens livscyklus til at arbejde med forskellige programdokumenter. Så en teksteditor kan bruges til at udvikle næsten ethvert softwaredokument. Ud fra de funktioner, som værktøjer udfører under softwareudvikling, kan de opdeles i følgende fire grupper: · redaktører, · analysatorer, · konvertere, · værktøjer, der understøtter programafviklingsprocessen.

Redaktører understøtter designet (dannelsen) af visse programdokumenter på forskellige stadier af livscyklussen. Som allerede nævnt kan du bruge en universel teksteditor til dette. Men specialiserede redaktører kan give stærkere støtte: hver type dokument har sin egen editor. Især i de tidlige udviklingsstadier kan grafiske beskrivelsesmidler (diagrammer, diagrammer osv.) bruges i vid udstrækning i dokumenter. I sådanne tilfælde kan grafiske editorer være meget nyttige. På programmerings- (kodnings)stadiet, i stedet for en teksteditor, kan en syntaktisk styret editor orienteret til det anvendte programmeringssprog være mere praktisk. Analysatorer udfører enten statisk behandling af dokumenter, udfører forskellige typer kontrol, identificerer visse af deres egenskaber og akkumulerer statistiske data (f.eks. kontrollerer dokumenternes overensstemmelse med specificerede standarder) eller dynamisk analyse af programmer (f.eks. for at identificere fordeling af programdriftstid på tværs af softwaremoduler). Konverteringsprogrammer giver dig mulighed for automatisk at konvertere dokumenter til en anden form for repræsentation (for eksempel formatere) eller oversætte et dokument af en type til et dokument af en anden type (for eksempel konvertere eller kompilatorer), syntetisere et dokument fra separate dele osv.

Værktøjer, der understøtter programafviklingsprocessen, giver dig mulighed for på en computer at udføre beskrivelser af processer eller individuelle dele deraf, præsenteret i en anden form end maskinkode eller maskinkode med yderligere muligheder for fortolkning. Et eksempel på et sådant værktøj er en emulator af en anden computers kode. Denne gruppe af værktøjer omfatter også forskellige debuggere. I det væsentlige indeholder hvert programmeringssystem et run-time software-undersystem, der udfører de mest typiske programfragmenter for et programmeringssprog og giver et standardsvar på ekstraordinære situationer, der opstår under programafvikling (vi vil kalde et sådant undersystem for executive support) - kan også være betragtes som et værktøj for denne gruppe.

2. Værktøjsmiljøer til udvikling og vedligeholdelse af software. I øjeblikket er hvert programmeringssystem ikke forbundet med individuelle værktøjer (for eksempel en compiler), men med et vist logisk forbundet sæt af software- og hardwareværktøjer, der understøtter udvikling og vedligeholdelse af software i et givet programmeringssprog eller er fokuseret på et specifikt emneområde. Vi vil kalde et sådant sæt det instrumentelle miljø for softwareudvikling og vedligeholdelse. Sådanne værktøjsmiljøer er for det første kendetegnet ved brugen af ​​både software- og hardwareværktøjer, og for det andet ved en vis orientering mod enten et bestemt programmeringssprog eller et specifikt fagområde. Værktøjsmiljøet behøver ikke nødvendigvis at fungere på den computer, hvor softwaren, der er udviklet med dens hjælp, skal bruges. Ofte er en sådan kombination ret praktisk (hvis kun den anvendte computers kraft tillader det): der er ingen grund til at beskæftige sig med computere af forskellige typer; komponenter i selve værktøjsmiljøet kan inkluderes i den udviklede software.

Der er tre hovedklasser af værktøjsmiljøer til udvikling og vedligeholdelse af PS-programmeringsmiljøer, · computerteknologiske arbejdspladser, · værktøjssystemer til programmeringsteknologi. Programmeringsmiljøet er primært beregnet til at understøtte processerne for programmering (kodning), test og fejlretning af softwaren. Den computerteknologiske arbejdsplads er fokuseret på at understøtte de tidlige stadier af softwareudvikling (specifikationer) og automatisk generering af programmer i henhold til specifikationer. Det programmeringsteknologiske værktøjssystem er designet til at understøtte alle udviklings- og vedligeholdelsesprocesser gennem hele softwarens livscyklus og er fokuseret på den kollektive udvikling af store softwaresystemer med en lang livscyklus.

3. Værktøjsprogrammeringsmiljøer indeholder først og fremmest en teksteditor, der giver dig mulighed for at konstruere programmer i et givet programmeringssprog, værktøjer, der giver dig mulighed for at kompilere eller fortolke programmer på dette sprog, samt teste og fejlsøge de resulterende programmer. Derudover kan der være andre værktøjer, for eksempel til statisk eller dynamisk programanalyse. Disse værktøjer interagerer med hinanden gennem almindelige filer ved hjælp af standard filsystemfunktioner. Der skelnes mellem følgende klasser af programmeringsværktøjer: miljøer til generelle formål, sprogorienterede miljøer.

Programmeringsmiljøer til generelle formål indeholder et sæt softwareværktøjer, der understøtter udviklingen af ​​programmer på forskellige programmeringssprog (for eksempel en teksteditor, en linkeditor eller en fortolker til sproget på målcomputeren) og repræsenterer normalt nogle udvidelse af det anvendte operativsystems muligheder. For at programmere i et sådant miljø i et hvilket som helst programmeringssprog vil der være behov for yderligere værktøjer målrettet mod dette sprog (for eksempel en compiler). . . Klassificering af programmeringsværktøjer

4. Begrebet computerteknologi til softwareudvikling og dets job. Der er nogle vanskeligheder ved at udvikle en streng definition af CASE-teknologi (computerteknologi til softwareudvikling). CASE er et akronym for Computer-Aided Software Engineering. Men uden hjælp (support) fra en computer er softwaresystemer ikke blevet udviklet i lang tid (i det mindste bruges en compiler). Faktisk får dette begreb en snævrere (særlig) betydning, som gradvist udviskes (som det altid sker, når et begreb ikke har en stram definition). Oprindeligt blev CASE forstået som konstruktionen af ​​de tidlige stadier af softwareudvikling (definering af krav, udvikling af en ekstern beskrivelse og arkitektur af softwaren) ved hjælp af softwaresupport (softwareværktøjer). Nu kan CASE også forstås som konstruktion af hele livscyklussen af ​​et softwaresystem (inklusive dets vedligeholdelse), men kun i tilfældet, hvor programmer er delvist eller fuldstændigt genereret ud fra dokumenter, der er opnået på disse tidlige udviklingsstadier. I dette tilfælde begyndte CASE-teknologien at adskille sig fundamentalt fra den manuelle (traditionelle) teknologi til softwareudvikling: ikke kun indholdet af teknologiske processer har ændret sig, men også deres helhed.

I øjeblikket kan comkarakteriseres ved: - Brugen af ​​softwareunderstøttelse til udvikling af grafiske krav og grafiske specifikationer for softwaren, - automatisk generering af programmer i ethvert programmeringssprog eller i maskinkode (delvist eller fuldstændigt) , - software support til prototyping.

Et programmeringsteknologiværktøjssystem er et integreret sæt software- og hardwareværktøjer, der understøtter alle processer med udvikling og vedligeholdelse af store softwaresystemer gennem hele livscyklussen inden for en bestemt teknologi. Fra denne definition følger følgende hovedtræk ved denne klasse af computerstøtte: · kompleksitet, · fokus på kollektiv udvikling, · teknologisk sikkerhed, · integration.

Under hensyntagen til de diskuterede egenskaber ved instrumentelle programmeringsteknologiske systemer kan der skelnes mellem tre af deres hovedkomponenter: · udviklingsdatabase (repository), · værktøjer, · grænseflader.

Et repository er en central computerlagring af information relateret til projektet (udviklingen) af et softwaresystem gennem hele dets livscyklus. Værktøjssæt - et sæt værktøjer, der definerer de muligheder, som systemet leverer til udviklingsteamet. Typisk er dette sæt åbent: Ud over det minimale sæt (indbyggede værktøjer) indeholder det midler til dets forlængelse (importerede værktøjer) og struktureret, bestående af en fælles del af alle værktøjer (kernen) og strukturelle (nogle gange hierarkisk relaterede) klasser af værktøjer. Interfaces er opdelt i 1) bruger 2) system. Brugergrænsefladen giver udviklere adgang til værktøjer (kommandosprog osv.) og implementeres af systemskallen. Systemgrænseflader giver interaktion mellem værktøjer og deres fælles dele. Systemgrænseflader fremhæves som arkitektoniske komponenter på grund af systemets åbenhed – de skal bruges af nye (importerede) værktøjer, der indgår i systemet.

Der er to klasser af programmeringsteknologiske værktøjssystemer: 1) projektstøtteværktøjssystemer og 2) sprogafhængige værktøjssystemer. Det instrumentelle projektstøttesystem er et åbent system, der er i stand til at understøtte udviklingen af ​​software på forskellige programmeringssprog efter passende udvidelse med softwareværktøjer fokuseret på det valgte sprog. Et sådant system indeholder en kerne (som især giver adgang til lageret), et sæt værktøjer, der understøtter styring af softwareudvikling, programmeringssprogsuafhængige værktøjer, der understøtter softwareudvikling (tekst- og grafiske editorer, rapportgeneratorer osv.) , samt systemudvidelsesværktøjer. Et sprogafhængigt instrumentsystem er et system til at understøtte udviklingen af ​​software i et hvilket som helst programmeringssprog, som i det væsentlige bruger dette sprogs specifikationer til at organisere sit arbejde. Denne specificitet kan påvirke både kernens muligheder (inklusive strukturen af ​​depotet) og kravene til shell og værktøjer.

Unified Modeling Language UML De fleste eksisterende objektorienterede analyse- og designmetoder (OOAP) omfatter både et modelleringssprog og en beskrivelse af modelleringsprocessen. Et modelleringssprog er en notation (for det meste grafisk), der bruges af en metode til at beskrive projekter. Notation er en samling af grafiske objekter, der bruges i modeller; det er syntaksen for modelleringssproget. For eksempel definerer klassediagramnotation, hvordan elementer og begreber som klasse, association og multiplicitet er repræsenteret. En proces er en beskrivelse af de trin, der skal følges i udviklingen af ​​et projekt. Unified Modeling Language (UML) er efterfølgeren til den generation af OOAP-metoder, der dukkede op i slutningen af ​​80'erne og begyndelsen af ​​90'erne.

UML er et generel visuelt modelleringssprog, der er designet til at specificere, visualisere, designe og dokumentere softwarekomponenter, forretningsprocesser og andre systemer. UML-sproget er på samme tid et enkelt og kraftfuldt modelleringsværktøj, der effektivt kan bruges til at bygge konceptuelle, logiske og grafiske modeller af komplekse systemer til en lang række forskellige formål. Konstruktiv brug af UML-sproget er baseret på en forståelse af de generelle principper for modellering af komplekse systemer og især funktionerne i den objektorienterede designproces (OOP). Valget af ekspressive midler til at konstruere modeller af komplekse systemer forudbestemmer de opgaver, der kan løses ved hjælp af disse modeller. Samtidig er et af de grundlæggende principper for at konstruere modeller af komplekse systemer abstraktionsprincippet, som foreskriver, at man i modellen kun inkluderer de aspekter af det designede system, der er direkte relateret til systemets udførelse af dets funktioner eller dets tilsigtede formål. . I dette tilfælde er alle mindre detaljer udeladt for ikke at komplicere processen med analyse og forskning af den resulterende model.

UML indeholder et standardsæt af diagrammer og notationer af en lang række forskellige typer. Et diagram i UML er en grafisk repræsentation af et sæt elementer, oftest afbildet som en forbundet graf med hjørner (entiteter) og kanter (relationer). Diagrammer er tegnet for at visualisere et system fra forskellige perspektiver. Et diagram er på en måde en af ​​systemets projektioner. Som regel, undtagen i de mest trivielle tilfælde, giver diagrammer et fortættet billede af de elementer, der udgør systemet. Det samme element kan være til stede i alle diagrammer, eller kun i nogle få (den mest almindelige mulighed), eller ikke til stede i nogen (meget sjælden). I teorien kan diagrammer indeholde enhver kombination af entiteter og relationer. I praksis anvendes der dog et relativt lille antal standardkombinationer, svarende til de fem mest almindelige typer, der udgør arkitekturen i et softwaresystem.

UML skelner mellem følgende typer diagrammer: – use case diagrams – til modellering af organisationens forretningsprocesser (systemkrav); – klassediagrammer – til modellering af den statiske struktur af systemklasser og forbindelserne mellem dem. Disse diagrammer viser klasser, grænseflader, objekter og samarbejder samt deres relationer. Ved modellering af objektorienterede systemer bruges denne type diagram oftest. Klassediagrammer svarer til den statiske visning af systemet fra et designsynspunkt; – systemadfærdsdiagrammer (adfærdsdiagrammer); interaktionsdiagrammer – til modellering af processen med at udveksle meddelelser mellem objekter. – statechart-diagrammer – til modellering af systemobjekters adfærd under overgangen fra en tilstand til en anden.

– aktivitetsdiagrammer – til modellering af systemets adfærd inden for forskellige use cases eller modelleringsaktiviteter. – implementeringsdiagrammer: komponentdiagrammer – til modellering af hierarkiet af komponenter (undersystemer) i systemet; implementeringsdiagrammer – til modellering af systemets fysiske arkitektur.

Instrumentel software er software beregnet til brug ved design, udvikling og vedligeholdelse af programmer.

I processen med at studere fagområdet blev værktøjer til at skabe virtuelle udflugter udforsket. Følgende blev undersøgt som midler til at skabe en virtuel udflugt:

KPresenter er et gratis præsentationsprogram, der er en del af KOffice- og KDE-projekterne. Programgrænsefladen er vist i figur 6.

Figur 6- Kpresenter.

Adobe Photoshop blev valgt frem for en række andre programmer (Paint, Paint.net, Photoshop online osv.) på grund af, at det er ret nemt at lære og bruge. Der er lavet en lang række videolektioner på den, og desuden indgår den i studieprogrammet. Med dens hjælp vil forvrængninger, der konstant opstår, blive fjernet. Programgrænsefladen er vist i figur 7.

Figur 7 - Adobe Photoshop.

Microsoft Paint er en multifunktionel, men samtidig ret brugervenlig rastergrafikeditor fra Microsoft, inkluderet i alle Windows-operativsystemer fra de første versioner. Programgrænsefladen er vist i figur 8.

Figur 8- Maling.

Paint.NET er en gratis rastergrafikeditor til Windows NT baseret på .NET Framework. Applikationen startede som et projekt udviklet af en gruppe studerende fra Washington State University til Microsoft Windows under ledelse af Microsoft. Paint.NET er skrevet i C#, med nogle C++ brugt under installation og shell integration.

Photoshop online er en gratis internetressource placeret på http://photoshop.domfailov.ru. En grafisk editor, der er udstyret med en masse funktioner. Et program, der giver dig mulighed for at udføre forskellige handlinger for at forbedre og behandle billedet. Sådanne handlinger omfatter: farvebehandling, installation og meget mere. Programgrænsefladen er vist i figur 9.

Figur 9 - Photoshop online.

Microsoft Office Word 2003 er et tekstbehandlingsprogram designet til at oprette, se og redigere tekstdokumenter med lokal anvendelse af de enkleste former for tabelmatrix-algoritmer. Produceret af Microsoft Corporation som en del af Microsoft Office-pakken. Programgrænsefladen er vist i figur 10.

Figur 10 - Microsoft Office Word 2003.

Microsoft Power Point er et program til at lave og afvikle præsentationer, som er en del af Microsoft Office og findes i udgaver til styresystemer.Programgrænsefladen er vist i figur 11.

Figur 11 - Microsoft Power Point.

Microsoft ICE Autopano Giga, Ulead Cool 360, The Panorama Factory, PTGui Pro på grund af dens brugervenlighed og det faktum, at den er gratis. For at kombinere billeder til et panorama skal du blot flytte dem til programmets arbejdsområde, hvorefter programmet fungerer automatisk. Programgrænsefladen er vist i figur 12.

Figur 12 - Microsoft ICE.

Autopano Giga - Hele oprettelsesprocessen er fuldt automatiseret: den vil korrigere og afbalancere lysstyrke og farve, justere fragmenter og automatisk finde fotos, der er egnede til limning i den mappe, som brugeren har angivet. Et betydeligt antal formater understøttes (inklusive RAW-format). Programgrænsefladen er vist i figur 13.

Figur 13 - Autopano Giga.

PTGui Pro er et kommercielt (shareware) computerprogram til at skabe panoramabilleder, udviklet og vedligeholdt af det hollandske firma New House Internet Services med base i Rotterdam, grundlagt i 1996. PTGui var oprindeligt en grafisk grænseflade til et sæt gratis Panorama Tools (deraf navnet på programmet), men senere versioner af programmet arbejder på sin egen fotostingalgoritme. Programgrænsefladen er vist i figur 14.

Figur 14 - PTGui Pro.

Microsoft Office SharePoint Designer 2007 - Programmet er nemt at bruge og distribueres gratis. Programmet har en bred vifte af muligheder, især kan det automatisk sende ændringer foretaget af webstedsudvikleren til kildeteksterne i realtid. Programgrænsefladen er vist i figur 15.

Figur 15 - Microsoft Office SharePoint Designer.

Pano2VR er den enkleste af de andre muligheder (Photo Warp, Tourweaver, Panorama2Flash, Pano2QTVR free, JATC, Easypano Studio Pro); der er meget få velkendte programmer med sådanne muligheder, og den ubestridte leder på dette område er det amerikanske firma IPIX Corporation (http://www.ipix.com), som er forfatteren til virtual tour-teknologi. Derfor bruges dets softwareprodukter oftest i udviklingen af ​​ture, herunder i Rusland. Der er dog meget interessante alternative muligheder fra andre virksomheder, der også giver fremragende resultater, men koster meget mindre.

Easypano Studio Pakken indeholder to softwaremoduler: Panoweaver og Tourweaver. Den første af dem er en stitcher af 360 × 360 sfæriske panoramaer, som er mulig både i fuldautomatisk og manuel tilstand, og den anden giver dig mulighed for at kombinere panoramaer såvel som andre oplysninger i virtuelle ture. Tourweaver-applikationen kan bruges ikke kun i forbindelse med Panoweaver, men også selvstændig, da den understøtter import af panoramaer, der er oprettet i andre stitchers. For eksempel kan du importere cylindriske panoramaer produceret i Panorama Factory, eller panoramaer genereret i 3D-pakker, især 3D Studio Max. Derudover er det muligt at importere panoramaer fra digitale panoramakameraer Kaidans 360 One VR, Panoscan, RoundShot osv. Programgrænsefladen er vist i figur 16.

Figur 16 - 360 Degrees Of Freedom Developer Suite.

SP_VTB, SP_STITCHER - Virksomheden Spherical Panorama har specialiseret sig i at udvikle software til at skabe forskellige typer panoramaer og kombinere dem til virtuelle ture, men i vores tilfælde er SP_STITCHER billedsammenføjningen til panoramaer og SP_VTB virtuelle turbyggeren af ​​størst interesse. De leveres som separate applikationer, men når de udvikler virtuelle ture, supplerer de hinanden, da SP_VTB giver dig mulighed for kun at oprette ture baseret på panoramaer i spf-format opnået i SP_STITCHER-miljøet. Begge applikationer er ret nemme at bruge, og den medfølgende detaljerede dokumentation, adskillige fiskeøje-syning-testsæt og en virtuel prøvetur vil hjælpe dig med hurtigt at forstå værkets forviklinger. Programgrænsefladen er vist i figur 17.

Figur 17 - SP_VTB, SP_STITCHER.

IPIX Interactive Studio, IPIX Real Estate Wizard, IPIX i-Linker - Som applikationer til at skabe virtuelle ture tilbyder IPIX softwarepakkerne IPIX i-Linker 3.1 og IPIX Multimedia Toolkit, som giver mening kun at bruge i forbindelse med IPIX stitcher, da begge applikationer er konfigureret til at bruge IPIX-panoramaer. IPIX Interactive Studio og IPIX Real Estate Wizard-pakker kan bruges som programmer til sammensætning af panoramaer. Programgrænsefladen er vist i figur 18.

Figur 18 - SP_VTB, SP_STITCHER.

Nå, faktisk er Pano2VR et program for dem, der er involveret i produktionen af ​​virtuelle 3D-panoramaer, det nye produkt vil give alle de nødvendige moderne muligheder for at præsentere indhold baseret på Flash-teknologi. Udover efterproduktion kan du også udføre teksturtransformationer (der er et stort udvalg) og lave forhåndsvisningsbilleder (thumbnail). Det nye koncept er blevet omskrevet fra bunden og har tilføjet et stort antal forbedringer og funktioner. Selvom programmet som tidligere understøtter konvertering til QTVR-formatet, blev hovedvægten i denne udgave lagt på Flash-teknologi. Et program til konvertering af sfæriske eller cylindriske panoramabilleder til formaterne QuickTime VR (QTVR) eller Adobe Flash 8 og Flash 9/10 (SWF). Med muligheden for at oprette dine egne skabeloner til panoramaer, knapper, tilføje animation og lyd og automatisk rotation. Programgrænsefladen er vist i figur 19.

Figur 19 - Pano2VR.

Pano2VR værktøjer:

Patch-værktøj. Tillader dynamisk korrektion af det originale billede. Du kan vælge et panoramaområde og eksportere det til billedredigeringssoftware. Understøtter muligheden for kun at redigere de udvalgte områder, der skal rettes, og resten af ​​billedet påvirkes ikke.

Skin Editor. Mulighed for at oprette din egen panoramaskabelon. Du kan tilføje dine egne knapper og grafik, design. Du kan også tilføje animationer og lydeffekter til din skabelon.

Lydeditor. Mulighed for at tilføje forskellige lyde til panoramaer.

Flash eksport. Eksporter panoramaer, inklusive alle grafiske elementer, som en enkelt SWF-fil. Dette forenkler i høj grad processen med at sende et panorama til et indholdsstyringssystem eller placere det på en blog. Cylindriske såvel som kubiske panoramaer kan roteres automatisk med valg af bevægelsesretning, hastighed og forsinkelse. Panoramaer kan indeholde hot spots såvel som foruddefinerede eller fuldt tilpassede skabeloner. Den indbyggede skabeloneditor giver dig også mulighed for at tilføje kort, links, logoer og anden information til panoramaet i en brugervenlig form.

QuickTime VR-eksport. Mulighed for at eksportere cylindriske og kubiske panoramaer til QuickTime VR-format.

Adobe Flash Player er programmet, hvorigennem udflugten vil blive demonstreret; andre muligheder er mulige (Java-applets optaget på cd'er ses ved hjælp af specielle udflugtsbrowsere), men takket være Adobe-mærkets popularitet og den udbredte brug af Flash Player, er dette er hvad der vil blive brugt

Share Point Designer 2007 -WYSIWYG HTML er et gratis editor- og webdesignprogram fra Microsoft, en erstatning for Microsoft Office FrontPage og en del af SharePoint-familien. Det er en af ​​komponenterne i Microsoft Office 2007-pakken, men er ikke inkluderet i nogen af ​​kontorpakkerne (installeret separat). Navneændringen fra FrontPage til SharePoint Designer skyldes dets formål: at skabe og designe Microsoft SharePoint-websteder. SharePoint Designer har den samme HTML-gengivelsesmotor som Microsoft Expression Web og er ikke afhængig af Internet Explorers Trident-motor, som er mindre kompatibel med almindelige standarder.

Yandex Internet er den mest moderne og derfor hurtigere og mere lovende browser. Turen vil blive testet på den; valget blev truffet blandt en række muligheder: Google Chrome (Figur 2), Chromium (Figur 22), Chrome fra Yandex (Figur 23), Microsoft Internet Explorer (Figur 24), Mozilla Firefox ( Figur 25), Opera (Figur 26), Yandex (Figur 20) osv.

Figur 20 - Yandex browser.

Figur 21 - Google Chrome.

Figur 22 - Opera.

Figur 23 - Chrom.

Figur 24 - Chrome fra Yandex.

Figur 25 - Internet Explorer.

Figur 26 - Mozilla Firefox.

Programmerne nedenfor er valgt fra listen over værktøjer af de årsager, der er angivet nedenfor.

Begrundelse for valg af udviklingsværktøjer og software

Baseret på en undersøgelse af softwareudviklingsværktøjer vil følgende blive brugt som værktøjer til at udvikle en virtuel rundvisning på skole nr. 2:

Adobe Photoshop CS3 - er i stand til at arbejde med en lang række formater, oprette, gemme, redigere og ændre billeder på forskellige måder. En multifunktionel grafisk editor, som er perfekt til et mere præcist resultat af at kombinere billeder til et panorama.

Microsoft ICE version 1.4.4.0 - programmet er nødvendigt for at kombinere mange individuelle fotografier af et objekt med den korrekte rækkefølge til ét panoramabillede.

Pano2VR version 4.1.0 pro - et program til at kombinere panoramaer til udflugter.

Adobe flash player 13 plugin er et gratis program til at se udflugten.

Yandex Internet 14.4.1750.13414 er den nyeste, mest bekvemme og hurtigste browser.

Share Point Designer 2007 er et gratis websideredigeringsprogram, HTML-editor og webdesignprogram fra Microsoft, en erstatning for Microsoft Office FrontPage og en del af SharePoint-familien.

Microsoft Word er en teksteditor og dokumenteditor. Den imponerer med sin funktionalitet og anvendelighed, den er i stand til at arbejde med forskellige formater.

Microsoft Office PowerPoint er en del af Microsoft Office. Dette gjorde det muligt for PowerPoint at blive det mest udbredte præsentationsprogram på verdensplan. PowerPoint-præsentationsfiler sendes ofte af programbrugere til andre computere, hvilket betyder, at konkurrenternes programmer skal være kompatible med dem.

De udvalgte udviklingsværktøjer blev undersøgt og installeret på computeren. Softwareudvikling vil blive udført med deres hjælp.

Emne: Softwareudviklingsteknologi.

Emne: Samarbejdsværktøjer til softwareudvikling.

Pædagogisk

Kendskab til værktøjer til kollektiv softwareudvikling.

Udviklingsmæssigt:

Udvikle evnen til at lytte til andre, drage konklusioner og generalisere erhvervet viden

Uddannelsesmæssigt:

At dyrke en følelse af vigtigheden af ​​emnet i professionelle aktiviteter, nøjagtighed i arbejdet

Tværfaglige forbindelser:

engelsk sprog

OS

Informationsteknologi

Grundlæggende om algoritmisering og programmering

Udstyr: tavle, kridt, skriveredskaber, projektor, pc

Lektionstype: kombineret

Undervisningsform: Forklarende og illustrativt

Under undervisningen:

1.Organisatorisk øjeblik

Kontrol af kontorets beredskab

Annoncering af emnet

2. Indstilling af lektionsmålet

3.Gentagelse af det dækkede materiale

Softwareudviklingsværktøjer.

Værktøjsmiljøer til udvikling og vedligeholdelse af software og principper for deres klassificering

Hovedklasser af værktøjsmiljøer til softwareudvikling og vedligeholdelse

Programmeringsmiljøer

4.Formidling af ny viden

Begrebet comog dets job

Instrumental systemer programmering teknologi

Softwareudviklingsværktøjer

5. Elevernes opfattelse og bevidsthed om nyt materiale

6. Forståelse, generalisering og systematisering af viden

7. Opsummering af lektionen og tildeling af lektier

Lær emneindhold

Gagarina L.G. s. 257-259.

Svar på spørgsmålene:

16.4. Begrebet comog dets job

Der er nogle vanskeligheder ved at udvikle en streng definition af CASE-teknologi (computerteknologi til softwareudvikling). CASE er et akronym for Computer-Aided Software Engineering. Men uden hjælp (support) fra en computer er softwaresystemer ikke blevet udviklet i lang tid (i det mindste bruges en compiler). Faktisk får dette begreb en snævrere (særlig) betydning, som gradvist udviskes (som det altid sker, når et begreb ikke har en stram definition). Oprindeligt blev CASE forstået som konstruktionen af ​​de tidlige stadier af softwareudvikling (definition af krav, udvikling af ekstern beskrivelse og arkitektur af softwaren) ved hjælp af softwaresupport (softwareværktøjer). Nu kan CASE også forstås som konstruktion af hele livscyklussen af ​​et softwaresystem (inklusive dets vedligeholdelse), men kun i tilfældet, hvor programmer er delvist eller fuldstændigt genereret ud fra dokumenter, der er opnået på disse tidlige udviklingsstadier. I dette tilfælde begyndte CASE-teknologien at adskille sig fundamentalt fra den manuelle (traditionelle) teknologi til softwareudvikling: ikke kun indholdet af teknologiske processer har ændret sig, men også deres helhed.

I øjeblikket computerteknologi softwareudvikling kan karakteriseres ved brugen

• softwaresupport til udvikling af grafiske krav og grafiske specifikationer for softwaren,
• automatisk generering af programmer i ethvert programmeringssprog eller maskinkode (delvist eller fuldstændigt),
• softwareunderstøttelse til prototyping.

De siger også, at computerteknologi til udvikling af software er "papirløs", dvs. designet til computerrepræsentation af programdokumenter. Det er dog ret vanskeligt at skelne manuel softwareudviklingsteknologi fra computerteknologi baseret på disse egenskaber. Det betyder, at de vigtigste ting inden for computerteknologi ikke er blevet fremhævet.

Efter vores mening er hovedforskellen mellem manuel softwareudviklingsteknologi og computerteknologi følgende. Manuel teknologi er fokuseret på at udvikle dokumenter, der er ligeligt forstået af forskellige softwareudviklere, mens computerteknologi er fokuseret på at give semantisk forståelse (fortolkning) af dokumenter ved hjælp af softwareunderstøttelse til computerteknologi. Semantisk forståelse af dokumenter giver softwaresupport mulighed for automatisk at generere programmer. I denne henseende bliver brugen af ​​formelle sprog i de tidlige stadier af softwareudvikling en væsentlig del af computerteknologien: både til specifikation af programmer og til specifikation af andre dokumenter. Især formelle grafiske specifikationssprog er meget udbredt. Det er det, der gør det muligt rationelt at ændre selve sættet af teknologiske processer til udvikling og vedligeholdelse af software.

Ud fra diskussionen ovenfor kan det fastslås computerteknologi til softwareudvikling som en programmeringsteknologi, der bruger softwareværktøjer til at udvikle formaliserede specifikationer af programmer og andre dokumenter (herunder grafiske specifikationer) med efterfølgende automatisk generering af programmer og dokumenter (eller i det mindste en væsentlig del af dem) i henhold til disse specifikationer.

Nu er de vigtigste ændringer i softwarens livscyklus til computerteknologi ved at blive tydelige. Hvis hovedbestræbelserne på at udvikle softwaren ved brug af manuel teknologi blev gjort på stadierne af programmering (kodning) og debugging (test), så ved brug af computerteknologi - i de tidlige stadier af softwareudvikling (definering af krav og funktionelle specifikationer, arkitekturudvikling). Samtidig har dokumentationens karakter ændret sig markant. I stedet for en hel kæde af uformelle dokumenter, der sigter mod at overføre information fra kunden (brugeren) til forskellige kategorier af udviklere, dannes en softwareprototype, der understøtter den valgte brugergrænseflade, og formelle funktionelle specifikationer (nogle gange formelle specifikationer af softwarearkitekturen) er tilstrækkelige. til automatisk syntese (generering) af programmer PS (eller i det mindste en betydelig del af dem). Samtidig blev det muligt automatisk at generere en del af den dokumentation, der er nødvendig for udviklere og brugere. I stedet for manuel programmering (kodning) er der automatisk generering af programmer, hvilket gør autonom fejlfinding og test af programmer unødvendig: I stedet tilføjes en dyb automatisk semantisk kontrol af dokumentation. Det bliver muligt automatisk at generere test baseret på formelle specifikationer for komplekse ( systemisk) fejlretning af PS. Arten af ​​softwareunderstøttelse ændrer sig også væsentligt: ​​alle ændringer af vedligeholderudvikleren foretages kun til specifikationerne (inklusive prototypen), andre ændringer af softwaren udføres automatisk.

Med det sagt livscyklus af software til computerteknologi kan repræsenteres af følgende diagram (fig. 16.3).

Ris. 16.3. Livscyklus af software til computerteknologi.

Prototyping PS er en valgfri fase af softwarens livscyklus med computerteknologi, som vist i fig. 16.3 er vist med en stiplet pil. Imidlertid er brugen af ​​dette trin i mange tilfælde og den tilsvarende computerstøtte til dette trin karakteristisk for computerteknologi. I nogle tilfælde udføres prototyping efter (eller under) specifikationsudvikling PS, for eksempel i tilfælde af prototyping af brugergrænseflader. Dette er vist i fig. 16,3 prikket returpil. Selvom vi tillader en tilbagevenden til tidligere stadier på ethvert trin, vises dette eksplicit her, da prototyping er en særlig tilgang til softwareudvikling (se foredrag 3). Brugergrænsefladeprototyping giver dig mulighed for at erstatte den indirekte beskrivelse af interaktionen mellem brugeren og softwaren ved hjælp af manuel teknologi (når du udvikler en ekstern beskrivelse af softwaren) med brugerens direkte valg af metoden og stilen for denne interaktion med optagelse af alle nødvendige detaljer. I det væsentlige producerer dette trin en nøjagtig beskrivelse af brugergrænsefladen, som er forståelig for computerteknologiens softwaresupport, med ansvarlig brugerdeltagelse. Alt dette er baseret på tilstedeværelsen i softwareunderstøttelse af computerteknologi af en brugerdefineret shell med et omfattende bibliotek af blanks af forskellige fragmenter og skærmdele. Denne type prototyping ser ud til at være den bedste måde at bygge bro over barrieren mellem bruger og udvikler.

Udvikling af PS specifikationer opdeles i flere forskellige processer. Hvis vi udelukker den indledende fase af specifikationsudvikling (kravdefinition), bruger disse processer metoder, der fører til oprettelse af formaliserede dokumenter, dvs. formaliserede specifikationssprog bruges. I dette tilfælde er grafiske specifikationsmetoder udbredt, hvilket fører til oprettelsen af ​​forskellige diagrammer og diagrammer, der bestemmer strukturen af ​​informationsmiljøet og strukturen af ​​softwarestyringen. Fragmenter af data og programbeskrivelser præsenteret i algebraiske specifikationssprog (for eksempel ved brug af operationel eller aksiomatisk semantik) eller logiske specifikationssprog (baseret på en logisk tilgang til programspecifikation) er knyttet til sådanne strukturer. Sådanne specifikationer gør det muligt at generere programmer stort set eller helt automatisk. En væsentlig del af udviklingen af ​​specifikationer er at skabe et ordforråd af navngivne enheder, der bruges i specifikationerne.

Automatiseret specifikationskontrol PS udnytter, at en væsentlig del af specifikationerne præsenteres på formelle sprog. Dette giver dig mulighed for automatisk at udføre forskellige typer kontrol: syntaktisk og delvis semantisk kontrol af specifikationer, kontrol af fuldstændigheden og konsistensen af ​​diagrammer og diagrammer (især skal alle deres elementer identificeres og afspejles i ordbogen over navngivne enheder), end-to-end kontrol af balancen mellem specifikationsniveauer og andre typer kontrol i afhængigt af specifikationssprogenes muligheder.

Generation programmer PS. På dette stadium genererer den automatisk skeletter af softwareprogramkoder eller komplette koder for disse programmer i henhold til formelle softwarespecifikationer.

Automatiseret dokumentation af software. Det forudsætter muligheden for at generere forskellige former for dokumenter med deres delvise udfyldning i henhold til oplysninger, der er lagret i depotet. Samtidig reduceres antallet af dokumenttyper i forhold til traditionel teknologi.

Omfattende test og fejlretning af PS. På dette stadium testes alle softwarespecifikationer, og eventuelle fejl, der opdages, rettes. Test kan oprettes enten manuelt eller automatisk (hvis de anvendte specifikationssprog tillader dette) og sendes gennem de genererede softwareprogrammer.

PS certificeringhar samme indhold.

PS support er væsentligt forenklet, da de vigtigste ændringer kun foretages i specifikationerne.

Computerteknologisk arbejdsstation til softwareudvikling er et instrumentelt miljø, der understøtter alle stadier af denne teknologis livscyklus. Dette miljø gør betydelig brug af et depot. Depotet gemmer al information, der er oprettet under softwareudviklingsprocessen (især ordbogen over navngivne enheder og alle specifikationer). Grundlæggende er den computerteknologiske arbejdsplads integreret, i det mindste med hensyn til brugergrænseflade og data. De vigtigste værktøjer på en sådan arbejdsplads er:

• designere af brugergrænseflader;
• et værktøj til at arbejde med en ordbog over navngivne enheder;
• grafiske og testspecifikationseditorer;
• specifikationsanalysatorer;
• program generator;
• Dokumentører.

14.5. Instrumental systemer programmering teknologi

Programmeringsteknologi værktøjssystem er et integreret sæt af software- og hardwareværktøjer, der understøtter alle processer med udvikling og vedligeholdelse af stor software gennem hele dets livscyklus inden for rammerne af en specifik teknologi. Det blev allerede bemærket ovenfor (se afsnit 14.3), at det udover at være integreret også har egenskaberne kompleksitet og fokus på kollektiv udvikling. Det betyder, at det er baseret på konsistensen af ​​produkterne fra de teknologiske processer. Således er det instrumentelle system i stand til i det mindste at give kontrol over fuldstændigheden (fuldstændigheden) af den oprettede dokumentation (inklusive et sæt programmer) og konsistensen af ​​dens ændringer (versionering). Understøttelse af softwaresupportfasen af ​​det instrumentelle system betyder, at det skal yde PS konfigurationsstyring. Derudover understøtter det instrumentelle system ledelsen af ​​et teams arbejde og giver for forskellige medlemmer af dette team forskellige adgangsrettigheder til forskellige fragmenter af teknologiske procesprodukter og understøtter arbejdet ledere om at lede et team af udviklere. Instrumentelle programmeringsteknologiske systemer er store nok og dyre nok til, at deres instrumentelle overbelastning på en eller anden måde er berettiget. Derfor er det sæt værktøjer, der er inkluderet i dem, omhyggeligt udvalgt under hensyntagen til fagområdets behov, de anvendte sprog og den valgte programmeringsteknologi.

Under hensyntagen til de diskuterede egenskaber ved instrumentelle systemer til programmeringsteknologi kan der skelnes mellem tre hovedkomponenter:

• depot,
• værktøjer,
• grænseflader.

Værktøjer- et sæt værktøjer, der definerer de muligheder, som systemet leverer til udviklingsteamet. Typisk er dette sæt åbent og struktureret. Ud over minimumssættet ( indbyggede værktøjer), den indeholder midler til sin forlængelse ( importerede værktøjer). Derudover består det på grund af dets integrerede handlinger af en vis fælles del af alle værktøjer ( kerner) og strukturelle (nogle gange hierarkisk relaterede) klasser af værktøjer.

Grænsefladerer opdelt i bruger og system. Brugerdefinerede Grænsefladen giver udviklere adgang til værktøjerne. Det er ved at blive implementeret skal systemer. System Grænseflader giver interaktion mellem værktøjer og deres fælles dele. Systemgrænseflader identificeres som arkitektoniske komponenter på grund af systemets åbenhed - der kræves nye for at bruge dem ( importeret) værktøjer inkluderet i systemet.

Den mest generelle arkitektur af programmeringsteknologiske instrumentelle systemer er præsenteret i fig. 16.4.

Ris. 16.4. Generel arkitektur af instrumentelle systemer til programmeringsteknologi.

Der er to klasser af programmeringsteknologiske værktøjssystemer: projektstøtteværktøjssystemer og sprogafhængige værktøjssystemer.

Instrumentelt projektstøttesystem er et åbent system, der er i stand til at understøtte udviklingen af ​​software på forskellige programmeringssprog efter passende udvidelse med softwareværktøjer fokuseret på det valgte sprog. Sættet af værktøjer i et sådant system understøtter softwareudvikling og indeholder også programmeringssprog-uafhængige værktøjer, der understøtter softwareudvikling (tekst- og grafiske editorer, rapportgeneratorer osv.). Derudover indeholder den systemudvidelsesværktøjer. Kernen i et sådant system giver især adgang til depotet.

Sprogfølsomt værktøjssystem er et system til at understøtte udviklingen af ​​software i et hvilket som helst programmeringssprog, som i det væsentlige bruger dette sprogs specifikationer til at organisere sit arbejde. Denne specificitet kan påvirke både kernens muligheder (inklusive strukturen af ​​depotet) og kravene til shell og værktøjer. Et eksempel på et sådant system er Ada Programming Support Environment (APSE).

7.1. Softwareudviklingsværktøjer

Softwareværktøjer - software brugt til udvikling, justering eller udvikling af andre programmer:

redaktører, compilere, debuggere, hjælpesystemprogrammer, grafikpakker osv.

Dette omfatter programmeringssprog, integrerede programudviklingsmiljøer, CASE-systemer osv.

7.1.2. Valg af programmeringssprog

De programmeringssprog, der findes i dag, kan opdeles i følgende grupper:

Universal sprog på højt niveau;

Specialiserede softwareudviklersprog;

Specialiserede brugersprog;

Sprog på lavt niveau.

I gruppen af ​​universelle sprog på højt niveau er den ubestridte leder i dag C++ sproget. Faktisk har det en række fordele:

Skalerbarhed. Programmer er udviklet i C++ til en bred vifte af platforme og systemer;

Evnen til at arbejde på et lavt niveau med hukommelse, adresser, porte, som, hvis de bruges skødesløst, nemt kan blive til en ulempe;

C++ har en kraftig præprocessor, der er arvet fra C, men som ethvert andet kraftfuldt værktøj kræver det omhyggelig brug;

Evnen til at skabe generaliserede algoritmer til forskellige typer data, deres specialisering og beregninger på kompileringsstadiet ved hjælp af skabeloner.

Samtidig har C++ sproget en række væsentlige ulemper:

Tilslutning af grænsefladen til et eksternt modul gennem præprocessor-indsættelse af en header-fil (#include) forsinker kompileringen alvorligt, når der forbindes et stort antal moduler;

Mangel på information om datatyper på kompileringstidspunktet;

Svært at lære og kompilere;

Nogle typekonverteringer er uintuitive. Især giver en operation på usignerede og signerede numre et usigneret resultat.

For C++ er der et stort antal klassebiblioteker, der understøtter oprettelsen af ​​brugergrænseflader, klient-server-applikationer, arbejde med databaser osv.

Derfor er der endnu ikke noget alternativ til C++. Visual Basic bruges nogle gange til mindre projekter. Java-sproget blev betragtet som et alternativ til Basic, men på grund af manglen på visuelt

Det kan stadig ikke bruges som et formudviklingsværktøj.

Modern Object Pascal er, ligesom Pascal, foreslået af N. Wirth i midten af ​​70'erne af det 20. århundrede, fortsat den mest attraktive til at undervise i det grundlæggende i programmering på grund af dets

enkelhed, struktur og detektion af compileren af ​​et stort antal ikke kun syntaktiske, men også semantiske fejl.

På nuværende tidspunkt, i modsætning til 60'erne i det XX århundrede. Programmeringssprog skabes ekstremt sjældent. I løbet af de sidste 15 år kan der kun bemærkes to nye produkter, der er blevet udbredt - Java (Sun Microsystems, 1995), som blev populært hovedsageligt på grund af teknologien til dets brug på internettet og fremkomsten af ​​noget som Java virtuel maskine og C# (Microsoft, 2000), skabt baseret på C++.

Sprogets skaber er Microsoft-medarbejder Andreas Hejlsberg. Han blev berømt i programmørernes verden længe før han kom til Microsoft. Heilsberg var blandt de førende

udviklere af et af de mest populære udviklingsmiljøer - Delphi. Hos Microsoft deltog han i skabelsen af ​​versionen af ​​Java - J++, så han har masser af erfaring med at skrive sprog og programmeringsmiljøer. Som Andreas Heilsberg selv bemærkede, blev C# skabt som et komponentprogrammeringssprog, og dette er en af ​​sprogets vigtigste fordele, rettet mod muligheden for at genbruge oprettede komponenter.

Andre fordele ved C#-sproget:

Bevarer de bedste funktioner fra de populære C/C++ programmeringssprog, som den er baseret på. I denne henseende lettes overgangen af ​​programmører fra C++ til C#;

Det er enklere og mere pålideligt end C++. Enkelhed og pålidelighed skyldes hovedsageligt, at i C#, selvom sådanne farlige egenskaber ved C++ tolereres, opmuntres de ikke.

som pointer, adressering, dereferencing, adressearitmetik;

Det er et helt objektorienteret sprog, hvor selv de typer, der er indbygget i sproget, er repræsenteret af klasser;

Implementerer mulighederne for arv og universalisering;

Tager højde for alle funktionerne i .Net Framework, da C# blev skabt parallelt med dette miljø;

Med .Net Framework bygget oven på operativsystemet får C#-programmører de samme fordele ved at arbejde med en virtuel maskine som

Java programmører. Kodeeffektiviteten er endda forbedret, fordi CLR er en mellemsprogskompiler, mens

den virtuelle Java-maskine er en bytekodefortolker;

Et kraftfuldt rammebibliotek understøtter letheden ved at bygge forskellige typer C#-applikationer, så du nemt kan bygge webtjenester, andre typer komponenter,

Det er ret nemt at gemme og hente information fra en database og andre datalagringsfaciliteter;

Er en kilde til pålidelig og effektiv kode.

Ud over de sprog, der er beskrevet ovenfor, inkluderer gruppen af ​​universelle sprog også Modula, Ada, COBOL, FORTRAN og nogle andre. Hvert af sprogene beskrevet ovenfor har sine egne karakteristika og følgelig sit eget anvendelsesområde. I øjeblikket bruges universelle programmeringssprog i en lang række områder af menneskelig aktivitet, såsom:

Videnskabelig databehandling (sprogene C++, FORTRAN, Java);

Systemprogrammering (sprogene C++, Java);

Informationsbehandling (sprogene C++, COBOL, Java);

Kunstig intelligens (LISP, Prolog);

Publiseringsaktiviteter (Postscript, TeX);

Fjerninformationsbehandling (Perl, PHP, Java, C++);

Beskrivelse af dokumenter (HTML, XML).

Med tiden udviklede nogle sprog sig, fik nye funktioner og forblev efterspurgte, andre mistede deres relevans og er i dag i bedste fald af rent teoretisk interesse (Focal, PL/1 osv.). Dette skyldes i høj grad følgende faktorer:

Tilgængelighed af et programmeringsmiljø, der understøtter udviklingen af ​​applikationer i et specifikt programmeringssprog;

Nem vedligeholdelse og afprøvning af programmer;

Udgifter til udvikling ved brug af et specifikt programmeringssprog;

Klarhed og ortogonalitet af sprogstrukturer;

Anvendelse af en objektorienteret tilgang.

Specialiserede udviklersprog bruges til at skabe specifikke typer software. Disse omfatter:

Database sprog;

Sprog til oprettelse af netværksapplikationer;

Sprog til at skabe kunstige intelligenssystemer mv.

Specialiserede brugersprog er normalt en del af professionelle brugermiljøer, har et snævert fokus og bruges ikke af softwareudviklere.

Sprog på lavt niveau tillader programmering næsten på niveau med maskininstruktioner. I dette tilfælde opnås de mest optimale både med hensyn til tid

udførelse, og med hensyn til mængden af ​​påkrævet programhukommelse. Deres ulempe er, at de ikke understøtter principperne for struktureret programmering.

I øjeblikket bruger assemblersprog typisk:

Når du skriver relativt simple programmer for at få adgang til tekniske midler, såsom drivere;

I form af indsættelser i programmer på højniveausprog, for eksempel for at fremskynde datakonvertering i loops med et stort antal gentagelser.

I højere grad bestemmes valget af programmeringssprog af udviklerens erfaring, kravene fra den organisation, der leder udviklingen, eller blot etableret mening.

7.7.3. Valg af programmeringsmiljø

Et integreret softwareudviklingsmiljø er et softwaresystem, der bruges af programmører til at udvikle software.

Typisk omfatter udviklingsmiljøet en teksteditor, en compiler og/eller fortolker, en linker, en debugger og et hjælpesystem. Nogle gange indeholder den også versionskontrol og forskellige værktøjer til at forenkle designet af en grafisk brugergrænseflade.

Mange moderne udviklingsmiljøer inkluderer også en objektinspektør, en klassebrowser og et klassehierarkidiagram, som bruges til objektorienteret softwareudvikling.

Et udviklingsmiljø er typisk designet til et specifikt programmeringssprog, såsom Visual Basic eller Deiphi, men der er udviklingsmiljøer designet til flere sprog, såsom Eclipse eller Microsoft Visual Studio.

Eksempler på udviklingsmiljøer er Turbo Pascal, Borland C++, GNU toolchain, DrPython.

På det seneste, med udviklingen af ​​objektorienteret programmering, er de tidligere nævnte visuelle programmeringsmiljøer blevet udbredt, bl.

hvor de mest almindelige blokke af programkode præsenteres i form af grafiske objekter.

De mest brugte visuelle miljøer er Delphi, C++ Builder fra Borland (Inprise Corporation), Visual C++, Visual Basic fra Microsoft, Visual Ada fra IBM osv.

.NET Framework-teknologien, foreslået af Microsoft som en platform til at skabe både almindelige programmer og webapplikationer, er blevet meget populær i disse dage. Den største fordel ved .NET er kompatibiliteten af ​​forskellige tjenester skrevet på forskellige sprog.

For eksempel kan en tjeneste skrevet i C++ til .NET kalde en klassemetode fra et bibliotek skrevet i Delphi; i C# kan du skrive en klasse, der arver fra en klasse skrevet i Visual Basic .NET, og en undtagelse smidt af en metode skrevet i C# kan fanges og håndteres i Delphi.

Ligesom i tilfældet med at vælge et programmeringssprog, er valget af et programmeringsmiljø bestemt af projektets art, udviklerens vaner og færdigheder, tidens tendenser, kundernes krav og simpelthen den offentlige mening: "Alt sådan Udviklingen skal udføres i et miljø...

Generelle karakteristika for softwareudviklingsværktøjer

Generelle karakteristika for softwareudviklingsværktøjer

Instrumental systemer programmering teknologi

CASE værktøjer. Karakteristika for moderne CASE-værktøjer

Oversigt over objektorienterede værktøjer

Objektorienteret programmering opstod før objektorienteret analyse og design, så i dag er der et ret stort antal sprog, der understøtter denne teknologi. Den første af dem, ifølge oprindelsesdatoen, anses for at være sprog Småsnak, selvom mange elementer af den objektorienterede tilgang blev brugt i sproget Simula i 1967 Det mest kraftfulde værktøj til at skabe objektorienterede programmer i dag er sproget C++, skabt på basis af et struktureret programmeringssprog C. Sproget udvikler sig med succes Java, som oprindeligt var designet til at være objektorienteret.

Udviklingen af ​​store softwaresystemer under moderne forhold er umulig uden brug afsværktøjer (CASE-værktøjer). Der er ikke mange CASEs, der understøtter den objektorienterede tilgang. Det mest kendte værktøj i denne retning er systemet Rationel Rose , som blandt andet understøtter faserne af objektorienteret analyse og design.

Rational Rose objektorienteret CASE-værktøj

Udvikler Rationel Rose- Rational Software Corp., kendt for sin udvikling inden for objektorienterede teknologier, hvoraf den vigtigste er UML-sproget. Det er netop for at understøtte UML, som det vigtigste softwaredesignsprog, at dette CASE-system er orienteret.

Som ethvert moderne CASE-værktøj understøtter dette system alle stadier af softwarens livscyklus og giver brugeren en bred vifte af funktioner til at analysere, designe, bygge og vedligeholde software. I dette tilfælde bruges objektorienterede teknologier, og grafiske modeller er meget brugt.

Rationel Rose består af følgende hovedkomponenter: et lager, en grafisk brugergrænseflade, projektinspektionsværktøjer (browser), projektstyringsværktøjer, statistikindsamlingsværktøjer og en dokumentgenerator samt udvidelser til at understøtte forskellige programmeringssprog.

De vigtigste funktioner omfatter følgende:

Et kraftfuldt grafisk domænemodelleringssprog, der har et højt formaliseringsniveau og understøtter objektorienteret metodologi.

Praktisk navigation mellem modelelementer ved hjælp af "projektinspektøren".

Lagring af designresultater i form af en enkelt model.

Støtte udviklingsteamets arbejde med projektet.

Kraftfuldt system til udarbejdelse af rapporter og projektdokumentation.

Mulighed for programsyntese i næsten alle moderne objektorienterede sprog, herunder Java-sproget på tværs af platforme.

Support til komponentteknologier til opbygning af softwaresystemer.

Brede muligheder for at designe software med forskellige arkitekturer, fra simple programmer til store "klient-server"-systemer og internetapplikationer.

Mulighed for omstrukturering af modellen baseret på programmets kildekode. Dette sikrer, at integriteten af ​​designinformation og implementering opretholdes.

Konfiguration og udvidelse af funktionaliteten af ​​CASE-miljøet ved at installere udvidelsesmoduler, primært for at understøtte forskellige programmeringssprog.

Principper for udvikling af softwaresystemer i Rational Rose

Konstruktionen af ​​objektorienterede systemer har sine egne specifikationer. For at opnå maksimal effektivitet bør der naturligvis anvendes en enkelt teknologi på alle stadier af livscyklussen. Denne mulighed leveres af det universelle modelleringssprog UML. Rationel Rose understøtter alle systemdesignfaser, der er defineret i UML-specifikationen.

Den primære designmetode er at skabe forskellige slags diagrammer og specifikationer, der definerer den logiske og fysiske struktur af systemmodellen, dens statiske og dynamiske aspekter. Disse inkluderer klasse-, tilstands-, script-, modul- og procesdiagrammer.

På alle stadier er det muligt at bruge specialiserede grafiske editorer til modelelementer og bruge modelinspektøren til at navigere mellem dens komponenter. Alle designoplysninger gemmes i en enkelt modelfil (*.mdl).

Arbejdet begynder med opbygningen af ​​et Use Case Diagram, som karakteriserer hovedopgaverne og miljøet i det designede system. Dernæst udvikles sekvensdiagrammer for hver Use Case præsenteret i brugsdiagrammet, der identificerer objekter i systemet og beskriver rækkefølgen af ​​hændelser, der opstår i kommunikationsprocessen mellem objekter. Rationel Rose giver dig mulighed for automatisk at knytte sekvensdiagrammer til brugsblokke.

Objekterne i sekvensdiagrammer er defineret i systemet ved hjælp af klasser. Klasser og deres relationer defineres ved hjælp af klassediagrammer, hvis udvikling også understøttes Rationel Rose. Klasser er grupperet i pakker. Rationel Rose giver dig mulighed for at definere et sæt pakker, relationerne mellem dem og repræsentere deres bestanddele i indlejrede klassediagrammer.

Sammensætningen af ​​kompilerede og udførte systemmoduler er specificeret i Rationel Rose ved hjælp af et komponentdiagram. Diagrammet identificerer afhængighederne mellem komponenter. Komponenter kan have grænseflader, hvorigennem afhængigheder implementeres. Implementeringsdiagrammer i Rationel Rose afspejler konfigurationen af ​​det eksekverende softwaresystem og består af noder og interaktionsrelationer mellem noder. Noderne inkluderer komponenterne repræsenteret i systemkomponentdiagrammet.

For en fuldt defineret model er det muligt at generere kildeprogramtekster i forskellige understøttede objektorienterede programmeringssprog Rationel Rose, såsom Java eller C++.

De resulterende programtekster kan ændres udenfor Rationel Rose, og for at tage højde for de ændringer, der er foretaget, giver systemet dig mulighed for at omdanne tekster til en model.

Software design

Domænemodellering . Oprettelsen af ​​et projekt begynder med dannelsen af ​​principper for brug af systemet. Inden for Rationel Rose Denne fase kaldes "Use Case View". Implementeringen af ​​denne fase giver dig mulighed for at identificere eksterne brugere, brugsblokke, systemobjekter og forbindelser mellem dem.

Der udarbejdes et forbrugsdiagram, der afspejler den eksterne funktion af det system, der oprettes. Denne model ligner på mange måder dataflowdiagrammet i strukturanalyse. Dens hovedkomponenter er eksterne brugere (aktører), brugsblokke (use cases) og forbindelser mellem komponenter. For at oprette et diagram i Rationel Rose der anvendes en specialiseret grafisk editor.

Alle elementer i brugsdiagrammet identificeres af systemet som uafhængige komponenter i modellen inden for denne fase og er underlagt yderligere specifikation. Først og fremmest drejer det sig om brugsblokke, som afspejler grupper af systemfunktioner præsenteret som en enkelt helhed for en ekstern bruger.

For hver brugsblok er der konstrueret et sekvensdiagram, som viser interaktionen over tid af objekter, der udfører opgaven. Sådanne diagrammer identificerer systemobjekter og definerer de meddelelser, hvorigennem disse objekter interagerer. Diagrammer er konstrueret i en specialiseret editor.

Hvert objekt i et sekvensdiagram er ledsaget af navnet på den klasse, som det tilhører. Et specifikt objekt er en forekomst af en eller anden klasse. Klasser danner den logiske struktur i systemet.

Udvikling af en logisk struktur. Efter at have afsluttet dannelsen af ​​principperne for brug af systemet, begynder stadiet med at udvikle dets logiske struktur. I Rationel Rose det hedder "Logisk visning". Resultatet af denne fase bør være et hoveddiagram og detaljerede diagrammer for dets elementer.

På dette stadium bør du bestemme de klasser, der er nødvendige i systemet. Forekomster af disse klasser er allerede specificeret i sekvensdiagrammer. Klasser og deres sammenhænge afspejles i modellen i form af et klassediagram. Grupper af klasser i disse diagrammer kan grupperes i pakker.

At designe en logisk struktur bør begynde med at definere kernepakkerne. En pakke er et universelt værktøj til at gruppere modelelementer. Brugen af ​​pakker giver dig mulighed for at gøre modellen mere synlig. Pakker kan placeres inde i hinanden. Klasserne, der udgør hver pakke, er beskrevet i det medfølgende diagram.

Indbygget Rationel Rose Class Diagram Editor giver praktiske værktøjer til sådanne operationer, og Model Inspector gør det nemt at navigere i diagramhierarkiet.

For hver klasse er der specificeret en specifikation, der beskriver sammensætningen af ​​attributter og metoder, forbindelser, skabelonen, som klassen er oprettet på, og implementeringsfunktioner.

Tilstedeværelsen af ​​skabeloner gør det nemt at oprette klasser af forskellige strukturer.

Klasser kan importeres til systemet udefra. Rationel Rose understøtter softwarens komponentstruktur og tillader brug af binære komponenter såsom COM og ActiveX i modellen. Deres repræsentation i modellen udføres ved hjælp af klasser baseret på disse komponenters grænseflader.

Ud over klassediagrammer bruges tilstandsdiagrammer, scenariediagrammer og andre elementer i UML-sproget til at beskrive systemlogikken på dette trin.

Design applikationens fysiske struktur. Klasserne beskrevet i det foregående trin er forbundet med de fysiske komponenter i programmet ved hjælp af komponentdiagrammer.

En komponent er et eksekverbart modul i systemet og er forbundet med en kildefil, en binær biblioteksfil, et objektmodul eller en eksekverbar fil. Komponenter kan omfatte andre komponenter.

For at visualisere komponenterne i det designede system, anvendes komponentdiagrammer. Stadium for konstruktion af komponentdiagrammer i Rose kaldet "Komponentvisning". Det består i at konstruere et overordnet diagram og om nødvendigt detaljere enkelte komponenter i underdiagrammer.

Disse diagrammer afspejler forholdet mellem komponenterne i softwaren. Relationen implementeres gennem grænseflader, som også vises på diagrammet.

Diagrammer oprettes i en specialiseret editor. For en komponent er dens bestanddele angivet.

Komponenten kan generere kildetekst på forskellige understøttede programmeringssprog Rationel Rose, eller tildele programfragmenter udviklet uden for miljøet Rose. I sidstnævnte tilfælde skal deres grænseflade matche den, der er deklareret i modellen.

Det sidste trin i softwaredesign er at udarbejde et implementeringsdiagram. I Rose dette trin kaldes "Deployment View". Implementeringsdiagrammer viser konfigurationen af ​​et eksekverbart softwaresystem. Den består af noder og interaktionsforhold mellem noder og komponenter. Noder kan omfatte komponenter og objekter. Noder er fysiske runtime-elementer.

Konstruktion og vedligeholdelse af systemet

Generering af kildetekster . Når de specifikke komponenter i systemet, der udvikles, er blevet identificeret, er det tid til at generere programkode for hver komponent.

Rent faktisk, Rose genererer et programskelet, som efterfølgende sendes til programmører til revision. Definitioner af klasser og metoder syntetiseres automatisk, hvis specifikke implementering skal udføres manuelt.

Den indledende information for denne operation er information om de klasser, der udgør denne komponent, og det valgte sprog til implementering af denne komponent.

Før du udfører operationen, skal du bestemme sammensætningen og parametrene for at gemme den modtagne kode. Udfør derefter genereringen ved at vælge det ønskede sprog. Hvis der opstår fejl, vil systemet informere dig om dette.

Det er muligt selektivt at generere programkode for individuelle modelkomponenter og tilpasse information placeret i programfiler. Dette giver høj fleksibilitet ved opgradering og ændring af modellen.

Rational Rose 98 Enterprise Edition giver dig mulighed for at generere kildetekst i Visual Basic, C++, Java, samt få en beskrivelse af komponentgrænseflader i IDL og oprette projekter til Oracle 8-systemet.

Omstrukturering af en model baseret på kildekoder . Evnen til at omkonstruere, eller, som det også kaldes, "reverse engineering", en model fra kildeprogramtekster synes at være en af ​​de vigtige og selvfølgelig nyttige funktioner Rose. Behovet for en sådan operation opstår ofte ved ændring og opgradering af et projekt. De programskabeloner, som modellen genererer, efter at de er overført til programmører, kan ændres, og disse ændringer skal tages i betragtning i modellen. Desuden siden Rationel Rose understøtter import af binære komponenter (COM-objekter i Win32-miljøet), så er understøttelse af opbygning af klasser baseret på beskrivelsen af ​​grænseflader til en binær komponent simpelthen nødvendig.

Du kan reverse engineering-klasser ved at vælge det programmeringssprog, som klasserne er implementeret i, og angive den mappe, hvor kildefilerne er placeret. Derefter kan du vælge de nødvendige filer eller omvendt manipulere dem alle. Når du udfører disse handlinger, skal du være forsigtig og kun vælge de elementer, der faktisk kan konverteres til en model. Under drift vil systemet informere dig om tilstedeværelsen af ​​fejl.

Efter vellykket afslutning af operationen vil et nyt element vises på komponentdiagrammet ("Komponentvisning"-stadiet), der har et navn, der matcher kildefilernes bibliotek. At gå til logisk visningsstadiet vil vise, at alle klasser og pakker, der udgør den nye komponent, også er dukket op i klassediagrammerne.

Det er nu muligt at foretage ændringer i modellen, bestemt af de tilføjede komponenter, og genskabe kildeteksterne.

Understøttelse af udviklingsstadiet

Komponenter og skabeloner. En af mulighederne Rose er modellering af binære komponenter, der understøtter COM-specifikationen. I modellen er sådanne komponenter repræsenteret af grænsefladeklasser oprettet på basis af IDL-filer, der ledsager COM-objektet. Dette giver dig mulighed for at inkludere forskellige hyldekomponenter i din model.

Understøttelse af modelelementskabeloner forenkler designprocessen. I Rose Du kan oprette og bruge skabeloner til de fleste elementer i modellen, herunder: brugsblokke, pakker, klasser, komponenter samt til operationer på modellen. Når du opretter et nyt element, skal du angive, hvilken skabelon der bruges, og elementet vil indeholde alle skabelonens egenskaber. Denne tilgang giver dig mulighed for at slippe af med rutinearbejde og koncentrere dig om selve projektet.

Arbejdsmiljøer. En logisk udvikling af ideen om at bruge skabeloner og eksterne binære komponenter i Rationel Rose var fremkomsten af ​​arbejdsmiljøet (Framework).

Et arbejdsområde er en type skabelon, der sætter miljøet for den model, der oprettes. Dette gøres ved at indlæse de basiselementer, der indgår i arbejdsbordet, som bliver en integreret del af modellen.

Rose giver en bred vifte af standard arbejdsmiljøer, og du kan også skabe dine egne. Sættet af standard arbejdsmiljøer er som følger:

Application Performance Explorer

Standard miljø. Fokuseret på at skabe applikationer i Visual Basic. Indeholder erklæring af mange standard VB-objekter.

Applikationsdesignmiljø til internettet. Indeholder definition af forskellige ActiveX-komponenter og VB-biblioteker.

Applikationsdesignmiljø til at arbejde med lokale databaser (Local Database). Indeholder erklæringen om DAO-systemobjekter

Applikationsdesignmiljø ved hjælp af RDO (Remote Data Object). Giver dig mulighed for at bruge RDO-objekter til at oprette klient-server-applikationer.

Et applikationsdesignmiljø til adgang til SQL-servere (SQL Server Distributed Management Object (SQL-DMO)), der understøtter adgang til SQL gennem OLE-Automation-objekter.

Microsoft Transaction Server Support-miljø

Microsoft Outlook Supportmiljø

Java-applikationsudviklingsmiljøer (Java JDK 114 Full og Java JDK 114 Quick). Indeholder modeller af Java-klasser og grænseflader opnået gennem reverse engineering.

Oracle8 supportmiljø

Udviklingsmiljøet tildeles ved oprettelse af modellen. Udviklingsmiljøer gemmes i form af modelfiler (*.mdl) beregnet til skrivebeskyttet. Under processen med at skabe en ny model indlæses de nødvendige elementer fra det valgte udviklingsmiljø, hvorefter en ny model oprettes.

Udviklingsmiljøer giver en fantastisk mekanisme til tilpasning Rose til et konkret projekt. Du kan oprette dit eget udviklingsmiljø, som vil indeholde de elementer, du skal bruge fra forskellige standardmiljøer. En del Rationel Rose omfatter en "mester" til at skabe arbejdsmiljøer.

Support til udviklingsteam. Ethvert stort projekt udføres normalt af en gruppe udviklere, som omfatter analytikere, designere og programmører. Udviklingsprocessen består af successive iterationer med cyklussen "analyse" - "design" - "implementering". På hvert trin arbejder flere udviklere med modellen, og trinene gentages cyklisk. Under sådanne forhold er det nødvendigt at bevare projektets integritet, tage højde for ændringer foretaget på forskellige stadier og koordinere faserne. Alt dette kræver brug af et fælles depot og en særlig designideologi.

Sammen med et praktisk modelinspektionsværktøj, der gør det nemmere at skifte mellem stadier, Rationel Rose Mekanismer til at støtte udviklingsteamet er blevet identificeret.

Opretter forskellige arbejdsrum til udviklere og et arbejdsrum til hele projektet. Hver udvikler foretager ændringer i sin del (undermodel), og disse ændringer bliver globale (overført til den generelle model), først efter at de er godkendt af projektstyringssystemet. Som projektcontrollere i Rose eksterne systemer kan anvendes, som f.eks ClearCase Og Microsoft SourceSafe.

Brug af udvidelsesmoduler . I Rationel Rose En fleksibel mekanisme til konfiguration og tilpasning af systemkapaciteter er blevet introduceret. Der er forskellige udvidelsesmoduler, der kan installeres i Rose og løse forskellige problemer. Der er to hovedtyper af udvidelsesmoduler: udvidelser, der understøtter programmeringssprog, og udvidelser af miljøets funktionalitet.

Når du tilføjer en ny udvidelse, integreres den med systemet ved at tilføje elementer til systemmenuerne og installere de nødvendige biblioteker og eksekverbare filer. Derudover kan hver udvidelse tilføje sine egne typer og skabeloner til systemet.

De nødvendige udvidelser tilføjes normalt under den indledende installation af systemet, men de kan installeres senere. Distribution af udvidelser via internettet er understøttet

For at administrere udvidelser i Rose Der er en udvidelsesmanager. Med dens hjælp kan du aktivere og deaktivere forskellige udvidelsesmoduler.

Fordele og ulemper ved Rational Rose

Dette CASE-værktøj kan bruges til at skabe en række objektorienteret software, primært til Windows-platformen såvel som i Java-sproget på tværs af platforme.

UML-sproget bruges på alle udviklingsstadier, og softwareprojektet er en enkelt model.

Vigtige fordele er tilpasning til forskellige programmeringssprog og softwaresystemarkitekturer, samt muligheden for "reverse engineering" baseret på kildetekster på forskellige programmeringssprog. Der er understøttelse af forskellige metoder til fysisk implementering af komponenterne i det designede system.

Muligheden for at konfigurere systemet ved hjælp af udvidelsesmoduler er meget nyttig. Faktisk er den eneste måde at skrive et program til et ikke-Windows-operativsystem på at bruge Java-sproget.

Trin 1: til midten af ​​50'erne.

De vigtigste omkostninger er relateret til kodning (i maskinkoder). Autokoder (sprog, der bruger mnemoniske kommandonotationer) og oversættere fra dem (samlere) vises.

Mulighederne for særskilt opstilling og flytning af programmer implementeres. Loadere og programlinkere vises.

Trin 2: midten af ​​50'erne til midten af ​​60'erne.

Størrelsen af ​​programmer er stigende, og der opstår en kløft mellem begreberne problemdomæner og maskinorienterede sprog. Forskellige sprog på højt niveau (algoritmiske, universelle) vises:

Fortran (1954-1957);

Algol-60 (1958-1960);

Cobol (1959-1961);

og oversættere fra dem (kompilatorer). Næsten alle grundlæggende datatyper, operationer på dem, kontrolstrukturer og metoder til at repræsentere dem i programmer og forskellige muligheder for at parametrere underrutiner er opfundet og testet.

Trin 3: midten af ​​60'erne - begyndelsen af ​​70'erne.

Softwarens størrelse er stærkt stigende, og der sker en overgang til arbejdets kollektive karakter. Softwarekravene er stigende på grund af overgangen til kommerciel produktion.

Forholdet mellem softwareudviklingsomkostninger ændrer sig (40% eller mere bruges på fejlretning, design og dokumentation), kodning er en af ​​de enkleste typer arbejde. "Store" programmeringssprog bruges og oprettes - PL/1, ALGOL-68, SIMULA-67, der generaliserer og integrerer tidligere fundne løsninger.

Udviklede programmeringssystemer vises med optimerings- og fejlfindingsoversættere, makrobiblioteker, biblioteker af standardprogrammer, specialiserede teksteditorer, analyseværktøjer og interaktiv debugging med hensyn til inputsproget. Udviklede operativsystemer, det første DBMS, adskilligetemer, softwa(sporing af ændringer og samling af softwareversioner) er under udvikling.

Fase 4 ("stadium af krise i softwareudvikling"): begyndelsen af ​​70'erne - midten af ​​70'erne.

På trods af udviklingen af ​​værktøjer vokser programmørernes produktivitet ikke. Desuden falder arbejdsproduktiviteten på grund af stigende krav til software og en ikke-lineær stigning i dens kompleksitet. Deadlines for softwareudvikling er overset, omkostningerne stiger, kvaliteten er uforudsigelig, traditionelle metoder (som giver yderligere menneskelige og materielle ressourcer) virker ikke, hvilket karakteriseres som en "softwarekrise."

Metodikken for struktureret programmering vinder anerkendelse (Dijkstra, 1968), og grundlaget for programmeringsteknologi er ved at blive dannet (Pascal-sprog (N. Wirth), 1971).

Etape 5: 1976 – vor tid. Stadie af post-krise udvikling af værktøjer.

1976 – udgivelse af Boehms arbejde, som introducerer konceptet om softwarens livscyklus og indikerer, at hovedomkostningerne ikke er i udvikling, men i vedligeholdelse af programmer.

Programmeringssprog:

C (begyndelsen af ​​1970'erne, første gang beskrevet ganske fuldt ud i 1978);

Modula-2 (1978, udvikling - Oberon-sprog (1988));

Prolog (1972, udbredt siden 1980);

Smalltalk (1970'erne, introduceret i 1980 som Smalltalk-80);

C++ (begyndelsen af ​​1980'erne, navn – 1983, eksisterer i sin sædvanlige form siden 1990);

Java (version Java 1.0 – 1996, Java 2.0 – 1998, Java 5 – 2004...);

C# (1998–2001, version 1.0 – 2000–2002, version 2.0 – 2003-2005, version 3.0 – 2004–2008, version 4.0 – 2008–2010).

Integrerede softwareudviklingsværktøjsmiljøer er ved at blive udviklet. Den objektorienterede tilgang til design og programmering vinder anerkendelse. Programmer udvikles til at understøtte softwareoprettelse på alle stadier.

Kontrolspørgsmål:

1. Hvilke aktiviteter omfatter udviklingen af ​​et softwareprodukt?

2. Hvilke stadier i softwareudvikling er identificeret inden for Rational Unified Process (RUP)?

3. Hvad sikrer brugen af ​​værktøjer?

4. Hvilke komponenter er inkluderet i programmet? Formålet med hver del.

5. Definitioner af program og software.

6. Hvilke egenskaber skal softwaren have?

7. Hvilke programmeringssprog bruges ved udvikling af programmer?

8. Definition af softwareværktøjer.

9. Hvilke fire grupper kan software inddeles i? Eksempler på software til hver gruppe.

10. Efter hvilke kriterier kan programmer fra samme klasse sammenlignes?

11. Hvad er stadierne i udviklingen af ​​softwareudviklingsværktøjer?

12. Formål og hovedkarakteristika for compilere (assemblere) og link-editorer.

13. Formål og hovedkarakteristika for teksteditorer.

14. Formål og hovedkarakteristika for debuggere.

15. Formål og hovedkarakteristika for programmer til oprettelse af installatører.

16. Formål og hovedkarakteristika for ressourceredaktører.

17. Profilers formål og hovedkarakteristika.

18. Formål og hovedkarakteristika for versionsstøtteprogrammer.

19. Formål og hovedkarakteristika for programmer til oprettelse af hjælpefiler (dokumentation).

20. Dokumentationsgeneratorers formål og hovedkarakteristika.

21. Formål og hovedkarakteristika for disassemblere og decompilere.

22. Formål og hovedkarakteristika for programmer til overvågning af systemaktivitet og ændringer i systemet.

23. Formål og hovedkarakteristika for verifikatorprogrammer og containere.

24. Formål og hovedkarakteristika for programmer til beskyttelse af udviklet software (beskyttere).

25. Formål og hovedkarakteristika for SDK.

26. Formål og hovedkarakteristika for parsere.

27. Formål med teknologiske standarder.

EMNE: Softwareudviklingsmetoder.

Litteratur: 1. Zelkowitz M., Shaw A., Gannon J. Principper for softwareudvikling.

2. Ghezzi C., Jazayeri M., Mandrioli D. Fundamentals of software engineering.

3. Kamaev V. A., Kosterin V. V. Programmeringsteknologier.

Lad os overveje begreberne metode, metode og midler.

Definition 1: Metode(fra den græske methodos - en måde at forskning eller viden, teori eller undervisning på) - en teknik eller system af teknikker til den praktiske implementering af noget inden for ethvert fagområde, et sæt teknikker eller operationer til praktisk eller teoretisk udvikling af virkeligheden, underordnet løsningen af ​​specifikke problemer.

Metoden omfatter faciliteter- hvordan handlingen udføres og måder- hvordan handlingen udføres.

Definition 2: Metodik er et system af principper, såvel som et sæt ideer, koncepter, metoder, metoder og midler, der bestemmer stilen for softwareudvikling.

En metode er en implementering af en standard. Standarderne i sig selv taler kun om, hvad der burde være, hvilket efterlader valgfrihed og tilpasning.

Specifikke ting implementeres gennem den valgte metode. Det er hende, der bestemmer, hvordan udviklingen skal gennemføres. Der er mange succesfulde softwareudviklingsmetoder. Valget af en specifik metode afhænger af teamets størrelse, projektets detaljer og kompleksitet, stabiliteten og modenheden af ​​virksomhedens processer og medarbejdernes personlige egenskaber.

Metoder repræsenterer kernen i softwareudviklingsteorien.

Afhængigt af den anvendte livscyklusmodel er metoderne opdelt i:

Vandfald (kaskade);

Iterativ (spiral).

Der er også en mere generel klassificering i:

Forudsigelig;

Fleksibel.

Forudsagte metoder fokus på detaljeret planlægning for fremtiden. De planlagte opgaver og ressourcer for hele projektets varighed er kendt. Holdet har svært ved at reagere på mulige ændringer. Planen er optimeret ud fra arbejdets omfang og eksisterende krav. Ændrede krav kan medføre væsentlige ændringer i planen samt udformningen af ​​projektet. Ofte oprettes et dedikeret "forandringsledelse"-udvalg for at sikre, at kun de vigtigste krav bliver behandlet i projektet.

Adaptive metoder er rettet mod at overvinde den forventede ufuldstændige krav og deres konstante ændring. Når kravene ændres, ændres udviklingsteamet også. Et team involveret i adaptiv udvikling har svært ved at forudsige projektets fremtid. Der er kun en nøjagtig plan for den nærmeste fremtid. Fjernere planer eksisterer kun som erklæringer om projektets mål, forventede omkostninger og resultater.

Kaskade udvikling eller vandfaldsmodel - en model af softwareudviklingsprocessen, hvor udviklingsprocessen ser ud som et flow, der successivt passerer gennem faserne med kravanalyse, design, implementering, test, integration og support.

Det grundlæggende træk ved kaskadetilgangen er: overgangen til næste fase udføres først, efter at arbejdet på den nuværende fase er fuldstændigt afsluttet, og der ikke gives tilbagevenden til afsluttede faser . Hver fase afsluttes med nogle resultater, der tjener som input til næste fase (fig. 1).

Ris. 1. Cascade livscyklusmodel.

Hvert trin slutter med frigivelsen af ​​et sæt dokumentation, der er tilstrækkeligt til, at udviklingen kan fortsættes af et andet udviklingsteam. Kriteriet for kvaliteten af ​​udviklingen med denne tilgang er nøjagtigheden af ​​opfyldelsen af ​​de tekniske specifikationer.

Fordele ved at bruge kaskademetoden:

På hvert trin genereres et komplet sæt designdokumentation, der opfylder kravene til fuldstændighed og konsistens;

Stadierne af arbejdet udført i en logisk rækkefølge gør det muligt at planlægge færdiggørelsestiden for alt arbejde og de tilsvarende omkostninger.

Kaskadetilgangen har vist sig godt i konstruktionen af ​​elektroniske informationssystemer, hvortil alle krav i begyndelsen af ​​udviklingen kan formuleres ret præcist og fuldstændigt for at give udviklere frihed til at implementere dem teknisk bedst muligt.

Samtidig har denne tilgang en række ulemper, primært forårsaget af det faktum, at selve processen med at skabe software aldrig helt passer ind i et så rigidt skema. Processen med at skabe software er som regel iterativ af natur: resultaterne af den næste fase forårsager ofte ændringer i designløsninger udviklet på tidligere stadier. Der er således et konstant behov for at vende tilbage til tidligere stadier og afklare eller revidere tidligere truffet beslutninger (fig. 2). Det afbildede diagram kan henføres til en separat model - en model med mellemstyring, hvor mellemtrinsjusteringer giver større pålidelighed sammenlignet med kaskademodellen, selvom de øger hele udviklingsperioden.

Den største ulempe ved kaskademodellen er en betydelig forsinkelse i opnåelse af resultater og som følge heraf en høj risiko for at skabe et system, der ikke opfylder brugernes skiftende behov. Dette skyldes to årsager:

Brugere kan ikke angive alle deres krav på én gang og kan ikke forudse, hvordan de vil ændre sig under udviklingen;

Under udviklingen kan der forekomme ændringer i det ydre miljø, som vil påvirke kravene til systemet.

Ris. 2. Kaskade livscyklusmodel i praksis.

Som en del af kaskadetilgangen er kravene til det produkt, der udvikles, fastlagt i form af tekniske specifikationer for hele oprettelsestiden, og de opnåede resultater aftales kun med brugerne på punkter, der er planlagt efter afslutningen af ​​hver fase ( det er muligt at justere resultaterne baseret på brugerkommentarer, hvis de ikke påvirker kravene, der er angivet i de tekniske specifikationer). Således kan brugere først komme med væsentlige kommentarer, efter at arbejdet med systemet er fuldstændigt afsluttet. Brugere kan modtage et system, der ikke opfylder deres behov. Som et resultat er du nødt til at starte et nyt projekt, som kan lide samme skæbne.

For at overvinde disse problemer blev en spiral livscyklusmodel foreslået i midten af ​​80'erne (fig. 3).

Ris. 3. Spiral (iterativ) livscyklusmodel.

Dens grundlæggende egenskab er følgende: applikationssoftware oprettes ikke umiddelbart, som i tilfældet med vandfaldstilgangen, men i dele ved hjælp af prototypemetoden .

Under prototype forstås som en driftssoftwarekomponent, der implementerer individuelle funktioner og eksterne grænseflader for den software, der udvikles. Prototyping udføres i flere iterationer eller spiraldrejninger. Hver iteration svarer til oprettelsen af ​​et fragment eller en version af softwaren, hvor projektets mål og karakteristika afklares, kvaliteten af ​​de opnåede resultater vurderes, og arbejdet med den næste iteration planlægges. Ved hver iteration foretages en grundig vurdering af projektets tidsplanrisiko og omkostninger for at afgøre, om endnu en iteration er nødvendig, om systemkravene er fuldt ud og præcist forstået, og om projektet skal afsluttes.

Spiralmodellen fritager brugere og udviklere for behovet for præcist og fuldstændigt at formulere systemkrav i den indledende fase, da de forfines ved hver iteration. Således er detaljerne i projektet uddybet og konsekvent specificeret, og som følge heraf vælges en rimelig mulighed, som bringes til implementering.

Spiralmodellen er et klassisk eksempel på anvendelsen af ​​en evolutionær designstrategi. Spiralmodellen (af Barry Boehm, 1988) er baseret på de bedste egenskaber ved klassisk livscyklus og prototyping, hvortil der er tilføjet et nyt element - risikoanalyse, som tidligere manglede.

Spiralmodellen definerer fire handlinger, repræsenteret af individuelle sektorer af spiralen:

1. Planlægning - definere mål, muligheder og begrænsninger.

2. Risikoanalyse - analyse af muligheder og risikogenkendelse/udvælgelse.

3. Design - udvikling af et næste niveau produkt.

4. Evaluering - kundens vurdering af de aktuelle designresultater.

Det integrerende aspekt af spiralmodellen er indlysende, når den radiale dimension af spiralen tages i betragtning. Med hver iteration i en spiral (bevæger sig fra centrum til periferien), bygges flere og flere komplette versioner af softwaren.

I den første drejning af spiralen fastlægges indledende mål, muligheder og begrænsninger, risiko erkendes og analyseres. Hvis risikoanalysen viser usikkerhed i kravene, kommer prototyping (brugt i designkvadranten) udvikler og kunde til hjælp. Simulering kan bruges til yderligere at identificere problematiske og raffinerede krav. Kunden evaluerer det tekniske (design)arbejde og fremsætter forslag til ændring. Den næste fase af planlægning og risikoanalyse er baseret på kundens forslag. I hver spiralcyklus dannes resultaterne af risikoanalysen i form af "fortsæt, fortsæt ikke." Hvis risikoen er for stor, kan projektet blive stoppet.

I de fleste tilfælde fortsætter spiralen, hvor hvert trin bevæger udviklere mod en mere generel model af systemet.

Med den iterative metode kan den manglende del af arbejdet udføres i næste iteration. Hovedopgaven er at vise systembrugere et brugbart produkt så hurtigt som muligt, og derved aktivere processen med at afklare og supplere krav.

Spiralmodellen udelukker ikke kaskadetilgangen i projektets afsluttende faser i tilfælde, hvor kravene til systemet er fuldt definerede.

Hovedproblemet i spiralcyklussen er at bestemme tidspunktet for overgangen til næste fase. For at løse det er det nødvendigt at indføre tidsbegrænsninger for hvert af livscyklusstadierne. Overgangen forløber som planlagt, selvom ikke alt planlagt arbejde er afsluttet. Planen er udarbejdet på baggrund af statistiske data indhentet fra tidligere projekter og udviklernes personlige erfaringer.

Fordele ved spiralmodellen:

Mest realistisk (i form af evolution) afspejler det softwareudvikling;

Giver dig mulighed for eksplicit at tage risiko i betragtning på hvert trin i udviklingen;

Indeholder et systematisk tilgangstrin i den iterative udviklingsstruktur;

Bruger simulering til at reducere risikoen og forbedre softwareproduktet.

Ulemper ved spiralmodellen:

Nyhed (der er ikke tilstrækkelig statistik over modellens effektivitet);

Øgede krav til kunden;

Vanskeligheder med at overvåge og administrere udviklingstid.

I dag kan der skelnes mellem følgende iterative softwareudviklingsmetoder:

Rational Unified Process (RUP)

Agile udviklingsmetoder (SCRUM, KANBAN, DSDM, MSF, ALM, XP)

Agile udviklingsmetodik(Engelsk: Agile softwareudvikling).

De fleste agile metoder sigter mod at minimere risikoen ved at reducere udviklingen til en række korte cyklusser kaldet iterationer, som normalt varer en til to uger. Hver iteration i sig selv ligner et miniaturesoftwareprojekt og inkluderer alle de opgaver, der er nødvendige for at levere et mini-tilvækst i funktionalitet: planlægning, kravanalyse, design, kodning, test og dokumentation. Selvom en enkelt iteration generelt ikke er tilstrækkelig til at frigive en ny version af et produkt, er antagelsen, at et agilt softwareprojekt er klar til udgivelse ved afslutningen af ​​hver iteration. I slutningen af ​​hver iteration revurderer teamet udviklingsprioriteter.

Agile metoder lægger vægt på direkte kommunikation ansigt til ansigt. De fleste agile teams er placeret på samme kontor. Det omfatter som minimum "kunder" (kunder, der definerer produktet; disse kan også være produktchefer, forretningsanalytikere eller kunder). Kontoret kan også omfatte testere, grænsefladedesignere, tekniske skribenter og ledere.

En af de mest berømte og avancerede agile metoder er SCRUM-metoden.

SCRUM- en metode designet til små teams (op til 10 personer). Hele projektet er opdelt i iterationer (sprints), der hver varer 30 dage. En liste over systemfunktioner, der er planlagt implementeret i løbet af næste sprint, er valgt. De vigtigste betingelser er konstansen af ​​de valgte funktioner under én iteration og streng overholdelse af deadlines for den næste udgivelse, selvom det ikke er muligt at implementere al den planlagte funktionalitet ved udgivelsen. Udviklingschefen afholder daglige 20-minutters møder, som kaldes scrum, hvis resultat er at bestemme funktionerne i systemet, dem, der er implementeret den foregående dag, de opståede vanskeligheder og planen for den næste dag. Sådanne møder giver dig mulighed for konstant at overvåge projektets fremskridt, hurtigt identificere problemer og reagere hurtigt på dem.

KANBAN– fleksibel, opgaveorienteret softwareudviklingsmetodologi.

Grundlæggende regler:

Udviklingsvisualisering:

o opdeling af arbejdet i opgaver;

o brug af mærker om opgavens position i udviklingen;

Begrænsning af arbejde udført samtidigt på hvert udviklingstrin;

Cyklustidsmåling (gennemsnitlig tid til at fuldføre én opgave) og procesoptimering.

Fordele ved KANBAN:

Reduktion af antallet af parallelle opgaver reducerer udførelsestiden for hver enkelt opgave markant;

Hurtig identifikation af problematiske opgaver;

Beregning af tid til at udføre en gennemsnitsopgave.

METODE FOR DYNAMISK SYSTEMUDVIKLING(DSDM) var resultatet af arbejdet i et konsortium af 17 engelske virksomheder. En hel organisation er ved at udvikle manualer om denne metodik, organiserer træningskurser, akkrediteringsprogrammer osv. Derudover har DSDM en pengeværdi.

Det hele starter med at studere programmets gennemførlighed og dets omfang. I det første tilfælde forsøger du at forstå, om DSDM er egnet til et givet projekt. Anvendelsesområdet for programmet forventes at blive udforsket gennem en kort række seminarer, hvor programmører lærer om det forretningsområde, de vil arbejde for. De vigtigste bestemmelser vedrørende det fremtidige systems arkitektur og projektplanen er også omtalt her.

Processen opdeles derefter i tre indbyrdes forbundne cyklusser: den funktionelle modelcyklus er ansvarlig for at skabe analytisk dokumentation og prototyper, design- og konstruktionscyklussen er ansvarlig for at bringe systemet i drift, og endelig sikrer den sidste cyklus - implementeringscyklussen - udrulning af softwaresystemet.

De grundlæggende principper, som DSDM er bygget på:

Aktiv interaktion med brugere;

Hyppige versionsudgivelser;

Udvikleres uafhængighed i beslutningstagning;

Test gennem hele arbejdscyklussen.

Som de fleste andre agile metoder bruger DSDM korte iterationer, der hver varer to til seks uger. Der lægges særlig vægt på arbejde af høj kvalitet og tilpasning til ændringer i krav.

MICROSOFT SOLUTIONS RAMME(MSF) er en softwareudviklingsmetodologi foreslået af Microsoft Corporation. Læger uden Grænser trækker på Microsofts praktiske erfaring og beskriver, hvordan man administrerer mennesker og arbejdsprocesser under løsningsudviklingsprocessen.

Grundlæggende begreber og principper for MSF-procesmodellen:

En samlet vision for projektet - alle interesserede parter og blot projektdeltagere skal klart forestille sig det endelige resultat, alle skal forstå målet med projektet;

Håndtering af afvejninger - finde afvejninger mellem projektressourcer, tidsplan og gennemførlighed;

Fleksibilitet – parathed til at ændre designforhold;

Koncentration om forretningsprioriteter - med fokus på den effekt og fordel, som forbrugeren af ​​løsningen forventer at modtage;

Tilskyndelse til fri kommunikation inden for projektet;

Oprettelse af en grundlæggende version - registrering af status for enhver projektartefakt, inklusive programkode, projektplan, brugermanual, serverindstillinger og efterfølgende effektiv ændringsstyring, projektanalyse.

Læger uden Grænser leverer gennemprøvede metoder til planlægning, design, udvikling og implementering af succesrige it-løsninger. Takket være sin fleksibilitet, skalerbarhed og mangel på stive instruktioner kan Læger uden Grænser opfylde behovene hos en organisation eller et projekthold af enhver størrelse. Læger uden Grænsers metodologi består af principper, modeller og discipliner til styring af mennesker, processer, teknologiske elementer og relaterede problemstillinger, som er typiske for de fleste projekter.

Application Lifecycle Management(ALM) - udviklet og understøttet af Borland.

Ekstrem programmering(XP) - Ekstrem programmering, understøttet af et åbent fællesskab af uafhængige udviklere.