Computerstøttet software engineering - Computer-aided software engineering

Eksempel på et CASE-værktøj.

Computerstøttet software engineering ( CASE ) er domænet for softwareværktøjer, der bruges til at designe og implementere applikationer. CASE-værktøjer ligner og blev delvist inspireret af CAD-værktøjer ( computer-aided design ), der bruges til at designe hardwareprodukter. CASE-værktøjer bruges til at udvikle høj kvalitet, fejlfri og vedligeholdelig software. CASE-software er ofte forbundet med metoder til udvikling af informationssystemer sammen med automatiserede værktøjer, der kan bruges i softwareudviklingsprocessen .

Historie

Information System Design and Optimization System (ISDOS) -projektet, der startede i 1968 ved University of Michigan , initierede stor interesse for hele konceptet med at bruge computersystemer til at hjælpe analytikere i den meget vanskelige proces med at analysere krav og udvikle systemer. Flere papirer af Daniel Teichroew fyrede en hel generation af entusiaster med potentialet i automatiseret systemudvikling. Hans Problem Statement Language / Problem Statement Analyzer (PSL / PSA) værktøj var et CASE-værktøj, selvom det forud for udtrykket.

En anden væsentlig tråd dukket op som en logisk forlængelse af data ordbog af en database . Ved at udvide rækkevidden af metadata, der holdes, kan attributterne for en applikation holdes i en ordbog og bruges under kørsel. Denne "aktive ordbog" blev forløberen for den mere moderne model-drevne tekniske kapacitet. Den aktive ordbog tilvejebragte imidlertid ikke en grafisk gengivelse af nogen af metadataene. Det var sammenkædningen af begrebet en ordbog, der indeholdt analytikers metadata, som stammer fra brugen af et integreret sæt teknikker sammen med den grafiske gengivelse af sådanne data, der gav anledning til de tidligere versioner af CASE.

Den næste aktør på markedet var Excelerator fra Index Technology i Cambridge, Massachusetts. Mens DesignAid kørte på Convergent Technologies og senere Burroughs Ngen-netværksmikrocomputere, lancerede Index Excelerator på IBM PC / AT- platformen. Mens IBM-platformen på lanceringstidspunktet og i flere år ikke understøttede netværk eller en centraliseret database, ligesom Convergent Technologies eller Burroughs-maskinerne, var IBM's lokke stærk, og Excelerator kom til at blive fremtrædende. Hot på hælene i Excelerator var et udslæt af tilbud fra virksomheder som Knowledgeware (James Martin, Fran Tarkenton og Don Addington), Texas Instruments CA Gen og Andersen Consultings FOUNDATION-værktøjssæt (DESIGN / 1, INSTALL / 1, FCP).

CASE-værktøjer var på sit højdepunkt i begyndelsen af 1990'erne. Ifølge PC Magazine i januar 1990 tilbød over 100 virksomheder næsten 200 forskellige CASE-værktøjer. På det tidspunkt havde IBM foreslået AD / Cycle, som var en alliance af softwareleverandører centreret om IBMs softwarelager ved hjælp af IBM DB2 i mainframe og OS / 2 :

Applikationsudviklingsværktøjerne kan være fra flere kilder: fra IBM, fra leverandører og fra kunderne selv. IBM har indgået relationer med Bachman Information Systems, Index Technology Corporation og Knowledgeware, hvor udvalgte produkter fra disse leverandører vil blive markedsført gennem et supplerende IBM-markedsføringsprogram for at tilbyde tilbud, der hjælper med at opnå fuldstændig livscyklusdækning .

Med nedgangen i mainframe døde AD / Cycle og Big CASE-værktøjerne og åbnede markedet for nutidens mainstream CASE-værktøjer. Mange af lederne af CASE-markedet i begyndelsen af 1990'erne blev købt af Computer Associates , herunder IEW, IEF, ADW, Cayenne og Learmonth & Burchett Management Systems (LBMS). Den anden tendens, der førte til udviklingen af CASE-værktøjer, var stigningen i objektorienterede metoder og værktøjer. De fleste af de forskellige værktøjsleverandører tilføjede noget support til objektorienterede metoder og værktøjer. Derudover opstod der nye produkter, der blev designet nedenfra og op for at understøtte den objektorienterede tilgang. Andersen udviklede sit projekt Eagle som et alternativ til Foundation. Flere af tankelederne inden for objektorienteret udvikling udviklede hver deres metode og CASE-værktøjssæt: Jacobsen, Rumbaugh, Booch osv. Til sidst blev disse forskellige værktøjssæt og metoder konsolideret via standarder ledet af Object Management Group (OMG). OMG's Unified Modeling Language (UML) er i øjeblikket bredt accepteret som industristandarden for objektorienteret modellering.

CASE-software

A. Fuggetta klassificeret CASE-software forskellig i 3 kategorier:

Værktøjer understøtter specifikke opgaver i softwarens livscyklus .
Arbejdsbænke kombinerer to eller flere værktøjer, der er fokuseret på en bestemt del af softwarelevecyklussen.
Miljøer kombinerer to eller flere værktøjer eller arbejdsbænke og understøtter den komplette softwarelevecyklus.

Værktøjer

CASE-værktøjer understøtter specifikke opgaver i softwareudviklingens livscyklus. De kan opdeles i følgende kategorier:

Forretnings- og analysemodellering. Grafiske modelleringsværktøjer. F.eks. E / R-modellering, objektmodellering osv.
Udvikling. Design- og konstruktionsfaser i livscyklussen. Fejlfindingsmiljøer. F.eks. IISE LKO .
Verifikation og validering . Analysér kode og specifikationer for korrekthed , ydeevne osv.
Konfigurationsstyring. Kontroller ind- og udtjekning af arkivobjekter og filer. F.eks. SCCS , IISE.
Metrics og måling. Analyser kode for kompleksitet, modularitet (f.eks. Ingen "go to's"), ydeevne osv.
Projektledelse. Administrer projektplaner, opgaveopgaver, planlægning.

En anden almindelig måde at skelne mellem CASE-værktøjer er sondringen mellem Upper CASE og Lower CASE. Upper CASE Tools understøtter forretnings- og analysemodellering. De understøtter traditionelle diagrammatiske sprog såsom ER-diagrammer , Dataflowdiagram , Strukturdiagrammer , Beslutningstræer , Beslutningstabeller osv. Lavere CASE-værktøjer understøtter udviklingsaktiviteter, såsom fysisk design, fejlretning, konstruktion, testning, komponentintegration, vedligeholdelse og omvendt ingeniørarbejde. Alle andre aktiviteter spænder over hele livscyklussen og gælder ens for øvre og nedre CASE.

Arbejdsbænke

Arbejdsbænke integrerer to eller flere CASE-værktøjer og understøtter specifikke softwareprocesaktiviteter. Derfor opnår de:

en homogen og konsistent grænseflade (præsentation integration).
Problemfri integration af værktøjer og værktøjskæder (kontrol og dataintegration).

Et eksempel på en arbejdsbord er Microsofts Visual Basic- programmeringsmiljø. Den indeholder flere udviklingsværktøjer: en GUI-builder, en smart-kodeditor, debugger osv. De fleste kommercielle CASE-produkter havde tendens til at være sådanne arbejdsbænke, der problemfrit integrerede to eller flere værktøjer. Arbejdsbænke kan også klassificeres på samme måde som værktøjer; som at fokusere på analyse, udvikling, verifikation osv. såvel som at være fokuseret på store og små bogstaver eller processer såsom konfigurationsstyring, der spænder over hele livscyklussen.

Miljøer

Et miljø er en samling af CASE-værktøjer eller arbejdsbænke, der forsøger at understøtte den komplette softwareproces. Dette står i kontrast til værktøjer, der fokuserer på en bestemt opgave eller en bestemt del af livscyklussen. CASE-miljøer klassificeres af Fuggetta som følger:

Værktøjssæt. Løst koblede samlinger af værktøjer. Disse bygger typisk på operativsystems arbejdsbænke såsom Unix programmørens Workbench eller VMS VAX-sættet. De udfører typisk integration via rør eller anden grundlæggende mekanisme til at dele data og videregive kontrol. Styrken ved nem integration er også en af ulemperne. Enkel overføring af parametre via teknologier som shell-scripting kan ikke give den slags sofistikeret integration, som en fælles lagerdatabase kan.
Fjerde generation. Disse miljøer er også kendt som 4GL, der står for fjerde generation sprogmiljøer på grund af det faktum, at de tidlige miljøer blev designet omkring bestemte sprog såsom Visual Basic. De var de første miljøer, der leverede dyb integration af flere værktøjer. Disse miljøer var typisk fokuseret på specifikke typer applikationer. For eksempel brugergrænsefladedrevne applikationer, der udførte standard atomtransaktioner til en relationsdatabase. Eksempler er Informix 4GL og Focus.
Sprogcentreret. Miljøer baseret på et enkelt ofte objektorienteret sprog såsom Symbolics Lisp Genera-miljøet eller VisualWorks Smalltalk fra Parcplace. I disse miljøer var alle operativsystemets ressourcer objekter i det objektorienterede sprog. Dette giver kraftige fejlretning og grafiske muligheder, men den udviklede kode er for det meste begrænset til det specifikke sprog. Af denne grund var disse miljøer for det meste en niche inden for CASE. Deres brug var hovedsagelig til prototyping og F & U-projekter. En fælles kerneide for disse miljøer var brugergrænsefladen model – view – controller , der gjorde det muligt at holde flere præsentationer af det samme design i overensstemmelse med den underliggende model. MVC-arkitekturen blev vedtaget af de andre typer CASE-miljøer såvel som mange af de applikationer, der blev bygget sammen med dem.
Integreret. Disse miljøer er et eksempel på, hvad de fleste it-folk ofte tænker på, når de tænker på CASE. Miljøer som IBMs AD / Cycle, Andersen Consultings FOUNDATION, ICL CADES- systemet og DEC-samhørighed. Disse miljøer forsøger at dække hele livscyklussen fra analyse til vedligeholdelse og tilvejebringe et integreret databaselager til lagring af alle artefakter i softwareprocessen. Det integrerede softwarelager var den definerende funktion for denne slags værktøjer. De leverede flere forskellige designmodeller samt støtte til kode på heterogene sprog. Et af hovedmålene for disse typer miljøer var "rundtursteknik": at kunne foretage ændringer på designniveau og få dem til automatisk at blive afspejlet i koden og omvendt. Disse miljøer var typisk også forbundet med en bestemt metode til softwareudvikling. F.eks. Var FOUNDATION CASE-pakken fra Andersen tæt knyttet til Andersen Method / 1-metoden.
Procescentreret. Dette er den mest ambitiøse type integration. Disse miljøer forsøger ikke blot formelt at specificere analyse- og designobjekterne i softwareprocessen, men selve selve processen og at bruge den formelle proces til at kontrollere og styre softwareprojekter. Eksempler er East, Enterprise II, Process Wise, Process Weaver og Arcadia. Disse miljøer var pr. Definition bundet til en vis metode, da selve softwareprocessen er en del af miljøet og kan kontrollere mange aspekter af værktøjsindkaldelse.

I praksis var sondringen mellem arbejdsbænke og miljøer fleksibel. Visual Basic var for eksempel en programmeringsbænk, men blev også betragtet som et 4GL-miljø af mange. Funktionerne, der adskiller arbejdsbænke fra miljøer, var dyb integration via et delt lager eller fælles sprog og en eller anden form for metode (integrerede og procescentrerede miljøer) eller domæne (4GL) specificitet.

Større CASE-risikofaktorer

Nogle af de mest betydningsfulde risikofaktorer for organisationer, der anvender CASE-teknologi, inkluderer:

Utilstrækkelig standardisering. Organisationer skal normalt skræddersy og vedtage metoder og værktøjer til deres specifikke krav. Det kan kræve en betydelig indsats for at integrere både divergerende teknologier såvel som divergerende metoder. For eksempel, inden vedtagelsen af UML-standarden, var diagramkonventionerne og metoderne til at designe objektorienterede modeller meget forskellige blandt tilhængere af Jacobsen, Booch og Rumbaugh.
Urealistiske forventninger. Tilhængerne af CASE-teknologi - især leverandører, der markedsfører dyre værktøjssæt - hype ofte forventningerne om, at den nye tilgang vil være en sølvkugle, der løser alle problemer. I virkeligheden kan ingen sådan teknologi gøre det, og hvis organisationer nærmer sig CASE med urealistiske forventninger, vil de uundgåeligt blive skuffede.
Utilstrækkelig træning. Som med enhver ny teknologi kræver CASE tid til at træne folk i, hvordan de bruger værktøjerne og får fart på dem. CASE-projekter kan mislykkes, hvis praktikere ikke får tilstrækkelig tid til træning, eller hvis det første projekt, der er forsøgt med den nye teknologi, i sig selv er yderst missionskritisk og fyldt med risiko.
Utilstrækkelig proceskontrol. CASE giver betydelige nye muligheder for at udnytte nye typer værktøjer på innovative måder. Uden den korrekte procesvejledning og kontrol kan disse nye funktioner også medføre betydelige nye problemer.

Languages

In other projects