4. Methodik der Softwareentwicklung
4. Methodik der Softwareentwicklung
4. Methodik der Softwareentwicklung
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
<strong>4.</strong><strong>Methodik</strong><strong>der</strong><br />
<strong>Softwareentwicklung</strong><br />
• Einführung<br />
• Anfor<strong>der</strong>ungsanalyse<br />
• Entwurf<br />
• Implementierung<br />
• ValidierungundVerifikation<br />
• InstallationundKonfigurationsmanagement<br />
• Managementaspekte<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
367
DieEntwicklunggroßerundsicherheitskritischer<br />
SoftwaresystemeisteinkomplexeAufgabe.<br />
SieunterscheidetsichvondemSchreibeneines<br />
kleinenProgrammswiedieKonstruktioneines<br />
WolkenkratzersvondemBastelneinerHundehütte.<br />
DasKapitelbetrachtet<strong>Softwareentwicklung</strong>als<br />
einenProzess,<strong>der</strong><br />
- strukturiertundorganisiertwerdenmuss,<br />
- desseneinzelnenSchritteverstandenwerdenmüssen ,<br />
- <strong>der</strong>ineinemgegebenenZeit- undKostenrahmen<br />
ablaufensoll.<br />
<strong>4.</strong>1Einführung<br />
BisherstandenModelle,Sprachen,Techniken<br />
undWerkzeugezur<strong>Softwareentwicklung</strong>im<br />
Vor<strong>der</strong>grund( Softwaretechnik).<br />
<strong>Methodik</strong> <strong>der</strong><strong>Softwareentwicklung</strong>:<br />
LehrevondenVerfahren/Methodenzursystematischen<br />
EntwicklungvonSoftware-Systemen<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
368
Anfor<strong>der</strong>ung<br />
Entwurf<br />
Implementierung<br />
Installation<br />
Wartung<br />
Modelle<br />
<strong>Softwareentwicklung</strong>smethodik:<br />
• GeeignetesVorgehen?<br />
• KontrolledesProzesses?<br />
• Geeignete Mittel?<br />
Softwaretechnik:<br />
Programmgerüste<br />
Sprachen<br />
OO-<br />
ADL<br />
Modelle UML<br />
Software-Engineering=<br />
Java<br />
Techniken<br />
Werkzeuge<br />
Compiler<br />
Debugger<br />
make<br />
spezifisches<br />
Wissen<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
369<br />
Generierung<br />
Konfigurationsmanagement<br />
Algorithmen<br />
Softwarevisualisierung<br />
Softwaretechnik+SW-Entwicklungsmethodik+...
Begriffsklärung: (Entwicklungv.SW-Systemen)<br />
Die EntwicklungeinesSoftwaresystems umfasstdie<br />
SchritteundTätigkeitenvon<strong>der</strong>IdeebiszurInsta llation<br />
desSystemssowiedieWartung.<br />
BetrachtetmandenAblauf<strong>der</strong>SchritteundTätigkei ten<br />
in<strong>der</strong>Zeit,sprichtmanvom SW-Entwicklungsprozess.<br />
Phasen<strong>der</strong>SW-Entwicklung<br />
Anfor<strong>der</strong>ung<br />
Entwurf<br />
(vgl.ESSy 1,Folien25,26)<br />
Implementierung<br />
Installation<br />
Wartung<br />
Eine SW-Entwicklungsmethode beschreibtdie<br />
Modelle,Prozesse,SprachenundWerkzeugezur<br />
LösungeinerKlassevonSW-Entwicklungsaufgaben.<br />
Wieinan<strong>der</strong>enDisziplinen,hängtdieEignungeiner<br />
SW-EntwicklungsmethodevondenAnfor<strong>der</strong>ungenab.<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
370
ZentraleUnterscheidung:<br />
Produkt:<br />
- Dokumente<br />
- Programme<br />
- Daten<br />
- Testfälle<br />
- ...<br />
These:<br />
Prozess:<br />
- Schritte<br />
- Eingabe<br />
- Ausgabe<br />
- Abstimmung<br />
- ...<br />
DerProzesskontrolliertdasProduktbzgl.Qualität<br />
Skalierbarkeit,Produktivität.<br />
Folgerung:<br />
EingeeigneterProzessistvonzentralerBedeutung<br />
fürdieEntwicklungvonQualitätssoftware.<br />
Dokumentein<strong>der</strong><strong>Softwareentwicklung</strong><br />
ImFolgendenfassenwirunterdemBegriff<br />
„Dokument“alleszusammen,wasalsEin- und<br />
Ausgabevon<strong>Softwareentwicklung</strong>sprozessen<br />
relevantist.<br />
DerZusammenhangzwischendiesenDokumenten<br />
lässtsichwiefolgtdarstellen:<br />
d.Schritte<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
371
Anfor<strong>der</strong>ungen<br />
Dokumentenmodell<strong>der</strong>SW-Entwicklung:<br />
Problembeschreibung<br />
Benutzungsanfor<strong>der</strong>ungen<br />
Grobentwurf<br />
Entwicklungsanfor<strong>der</strong>ungen<br />
Feinentwurf<br />
Systementwurf<br />
Modulanfor<strong>der</strong>ungen<br />
Modulentwurf<br />
Modulimplementierung<br />
ausführbares<br />
System<br />
ausführbare<br />
Module<br />
benutztes<br />
System<br />
benutzbares<br />
System<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
372
Beachte:<br />
- ZieldesDokumentenmodellsisteine<br />
grundsätzliche Einordnung<strong>der</strong>Dokumente:<br />
nichtzu jedem imModellaufgeführtenDokumenttypwirdesbeijedemSW-Entwicklungsprozess<br />
expliziteDokumentegeben.<br />
- ZujedemDokumententypgibtesimAllg.bei<br />
einemProjekteineVielzahlvonDokumenten.<br />
Insbeson<strong>der</strong>egibtesaufdenunterenEbenen<br />
zujedemModulgeeigneteBeschreibungen.<br />
- ZieldesDokumentenmodellsistes nicht, eine<br />
zeitlicheAbfolgefürdieErstellung<strong>der</strong>Dokumente<br />
vorzugeben.<br />
<strong>Softwareentwicklung</strong>sprozesse<br />
Begriffsklärung: (SW-Entwicklungsprozess)<br />
Ein SW-Entwicklungsprozess istdiezeitliche<br />
Abfolge<strong>der</strong>Arbeitsschrittebei<strong>der</strong>Erstellungvon<br />
Softwareund<strong>der</strong>zugehörigenDokumente.<br />
Die Beschreibung einesSW-Entwicklungsprozesses<br />
legtfest,wiedieAbfolgeaussehensoll.<br />
Prozessmodelle, auch Vorgehensmodelle genannt,<br />
bietengrobeLeitlinienzurStrukturierungvon<br />
SW-Entwicklungsprozessen.<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
373
Wasserfallmodell:<br />
Zeit<br />
Problem<br />
beschreiben<br />
Anfor<strong>der</strong>ungen<br />
festlegen<br />
Grobentwurf<br />
entwickeln<br />
Feinentwurf<br />
entwickeln<br />
Implementieren<br />
Module<br />
testen<br />
Integrieren<br />
System<br />
testen<br />
Installation<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
374
Diskussion:<br />
- sehreinfach<br />
- sehrspäteValidation<strong>der</strong>Anfor<strong>der</strong>ungen:<br />
FehlerinfrühenPhasensindteuer<br />
- zeitlichschwerzuplanen,daeinePhaseerst<br />
vollständigerledigtseinmuss,bevordienächste<br />
beginnenkann<br />
- Risiken<strong>der</strong>letztenPhasenwerdenspäterkannt<br />
- schwerfälligbezüglichÄn<strong>der</strong>ungbeiden<br />
Anfor<strong>der</strong>ungen<br />
- nichtohneWeiteresaufProjektezurSoftware-<br />
Verän<strong>der</strong>ungbzw.Erweiterunganwendbar<br />
Lebenszyklusmodell(LifeCycle Model):<br />
DasLebenszyklusmodellbetontdenEinfluss<strong>der</strong><br />
ErfahrungenausdemBetriebeinesSoftware-<br />
SystemsaufdessenWeiterentwicklung.<br />
ImWesentlichenbesitzensolcheModelledie<br />
gleichenEigenschaftenwieWasserfallmodelle.<br />
ManbeachtejedochdasunterschiedlicheVersionen<br />
überlappendentwickeltwerdenkönnen.<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
375
Problem<br />
beschreiben<br />
Anfor<strong>der</strong>ungen<br />
festlegen<br />
Grobentwurf<br />
entwickeln<br />
Betriebund<br />
Bewertung<br />
Feinentwurf<br />
entwickeln<br />
Installation<br />
Implementieren<br />
System<br />
testen<br />
Module<br />
testen<br />
(dieRückwirkungenaufdieVorgängerphase<br />
sindhiernichtangegeben)<br />
Spiralmodell:<br />
Zeit<br />
ImGegensatzzumLebenszyklusmodellwird<strong>der</strong><br />
ZyklusimSpiralmodellmehrfachdurchlaufen,bis<br />
einevollständigeSystemversionentstandenist.<br />
Integrieren<br />
BeginnendmiteinemPrototypdesSystems,<strong>der</strong>nur<br />
dessenKernfunktionalitätrealisiert,werdeninjed em<br />
ZyklusleistungsfähigereApproximationenentwickelt .<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
376
BestimmungvonZielen,<br />
Alternativenund<br />
Restriktionen<br />
Planung<br />
desnächsten<br />
Zyklus‘<br />
Start<br />
Bewertungund<br />
Risikoanalyse<br />
- EntfernungvomMittelpunktgibtdieKostenan<br />
- LängedesWegsauf<strong>der</strong>SpiralegibtdieZeitan<br />
Prototypentwicklung<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
377<br />
P1<br />
P2<br />
P3<br />
Produktentwicklung
Diskussion:<br />
- Abgrenzung<strong>der</strong>Prozessschrittenichteinfach<br />
- früheValidation<strong>der</strong>Anfor<strong>der</strong>ungenmöglich<br />
- zeitlichbesserzuplanen,daZeitproblematik<br />
frühereinzuschätzenist;Reaktion:<br />
Reduktion<strong>der</strong>Anfor<strong>der</strong>ungen<br />
mehrPersonal<br />
- Risikenlassensichfrühererkennen<br />
¡ - Än<strong>der</strong>unglassensichleichterberücksichtigen<br />
alsbeidenerstenbeidenModellen<br />
InkrementellesModell:<br />
DasinkrementelleModellbetontevolutionäre<br />
EntwicklungeinesSystemsausgehendvom<br />
funktionalenKern.<br />
Ziele:<br />
- SystementwicklungbeiunklarenAnfor<strong>der</strong>ungen<br />
- schnelleVerfügbarkeitvonlauffähigenPrototypen<br />
zurfrühenValidation<br />
- parallelesArbeitenandenSW-Entwicklungsphasen<br />
- BewältigungdynamischerZeit- undKostenrahmen<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
378
Zeit<br />
Version0.5Version1.0Versio n1.1<br />
Analyse<br />
Entwurf<br />
Implementation<br />
undIntegration<br />
Installationund<br />
Bewertung<br />
Analytiker<br />
SW-Architekten<br />
Analyse<br />
Entwurf<br />
Implementation<br />
undIntegration<br />
Installationund<br />
Bewertung<br />
Analyse<br />
Entwurf<br />
Implementation<br />
undIntegration<br />
Installationund<br />
Bewertung<br />
Programmierer<br />
Kundenbetreuer<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
379
Diskussion:<br />
- erreichtdieobigenZielebesseralsan<strong>der</strong>e<br />
Prozessmodelle<br />
- lässtsichsehrfeingranulargestalten,z.B.:<br />
¢ jedenTagIntegration<br />
jedeWocheSystemtest<br />
- WartunglässtsichüberdieEntwicklungneuer<br />
VersionenindenProzessintegrieren<br />
¢<br />
- ersterEntwurfbasiertaufunvollständigerInforma tion;<br />
darauskönnenlangfristigNachteileentstehen.<br />
AbschließendeBemerkungen:<br />
1.DieModellegebengrobeRichtlinien,umdeutlic h<br />
zumachen,dassunterschiedlichesVorgehen<br />
möglichundsinnvollist.<br />
DabeientstehendieDokumenteinunterschiedlicher<br />
Reihenfolgeundggf.unterschiedlicherStruktur.<br />
2.AuswahldesProzesseshängtvondenEigenschaften<br />
deszuentwickelndenSystemsab:<br />
¢ sicherheitskritisch<br />
groß/klein,AnzahlbeteiligterPersonen<br />
Domänenwissen/Referenzmodelle<br />
¢<br />
DauerdesProjektes/LebensdauerdesProdukts<br />
¢<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
380
3.In<strong>der</strong>PraxiswirdmanhäufigKombinationen<br />
<strong>der</strong>vorgestelltenProzessefinden,z.B.:<br />
£ Spirallmodell beschränktaufdieAnalyse<br />
£ WasserfallmodellfürdieEntwurfsschritte<br />
InkrementellesModellfürdieImplementierung<br />
<strong>4.</strong>EsgibtvermehrtStandardisierungsanstrengungen<br />
£<br />
bzgl.SW-Entwicklungsprozessen.Dieallgemeine<br />
Begriffsbildungbzgl.feinererProzessschritteist<br />
abernochnichteinheitlich.<br />
Literatur:<br />
W.Zuser,S.Biffl,T.Grechenig,M.Köhle:<br />
SoftwareEngineeringmitUMLunddemUnified<br />
Process;PearsonStudium,2001.<br />
I.Sommerville:SoftwareEngineering.<br />
6.Auflage(DeutscheÜbersetzung);<br />
PearsonStudium,2001.<br />
G.Booch,J.Rumbaugh,I.Jacoson:The Unified<br />
ModelingLanguageUserGuide;Addison-Wesley,<br />
1999.<br />
(DieseLiteraturangabenbeziehensichaufdas<br />
ganzeKapitel<strong>4.</strong>)<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
381
<strong>Softwareentwicklung</strong>sprojekte<br />
<strong>Softwareentwicklung</strong>wirdoftinProjektenorganisie rt:<br />
Begriffsklärung: (Projekt)<br />
Ein Projekt unterscheidetsichvonkontinuierlicher<br />
ArbeitinUnternehmen/Gruppen/Organisationen<br />
durchfolgendecharakteristischeEigenschaften:<br />
1.EinProjektisteineinmaligesVorhaben.<br />
2.Esistzeitlichbegrenzt.<br />
3.EsverfolgtvorgegebeneZiele.<br />
<strong>4.</strong>PrinzipiellgehtesumdieLösungneuerAufgabe n.<br />
5.InProjektenwerdenjenachZielmehrere<br />
unterschiedlicheMethodenangewendet.<br />
6.Projekteerfor<strong>der</strong>nimAllg.dieZusammenarbeit<br />
vonPersonenmitunterschiedlichemfachlichen<br />
HintergrundundunterschiedlicherErfahrung.<br />
7.Wegen<strong>der</strong>einmaligenAufgabenstellung<br />
birgtjedesProjekteinspeziellesRisiko.<br />
8.ProjektehabeneineigenesBudget.<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
382
WichtigeAspekte:<br />
Projekttypen– charakteristischeMerkmale:<br />
- GrößebemessennachEntwicklungsaufwand(PJ)<br />
- DauerbemessennachZeit(Kalen<strong>der</strong>wochen)<br />
- Aufgabenstellung/Zielsetzung<br />
- fachlicheDomäne<br />
- Technologie<br />
Personen– ZusammenwirkenundRollen:<br />
- StrategischesDreieck<br />
- Entwicklerteam<br />
Auftraggeber/Kunde<br />
Benutzer<br />
Auftragnehmer/Management<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
383
nochzuPersonen<br />
- Entwicklerteam:<br />
¤ Projektleiter<br />
Gruppenleiter<br />
Analytiker<br />
¤<br />
Software-Architekt<br />
Programmierer<br />
¤ Qualitätssicherer/Tester<br />
ZeitundKosten:<br />
¤<br />
- zentraleFaktoren<br />
- durchEinsatzvonmehrPersonallässtsich<br />
ggf.Zeitsparen<br />
- durchStrecken<strong>der</strong>Projektdauerlassensich<br />
dieKostenproZeiteinheitsenken<br />
VorgehenimRestdesKapitels<br />
- Behandlung<strong>der</strong>zentralenProzessschritte<br />
- Erläuterung<strong>der</strong>beteiligtenDokumente/Diagramme<br />
- Illustration<strong>der</strong>Problematikund<strong>der</strong>Anwendung<br />
aneinemdurchgehendenBeispiel:<br />
EntwicklungeinesKursPlaners<br />
(aufbauendaufArbeitenvonProf.Gotzhein)<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
384
<strong>4.</strong>2Anfor<strong>der</strong>ungsanalyse<br />
Begriffsklärung: (Anfor<strong>der</strong>ungsanalyse)<br />
DerProzess<strong>der</strong>Feststellung<strong>der</strong>Anfor<strong>der</strong>ungen<br />
aneinSoftwareprojektwirdals Anfor<strong>der</strong>ungsanalyse<br />
bezeichnet.Sieumfasst:<br />
- die Ermittlung <strong>der</strong>Anfor<strong>der</strong>ungen,die<strong>der</strong><br />
AuftraggeberandieBenutzungdesSW-Systems<br />
stellt;<br />
- die AnalyseundSpezifikation <strong>der</strong>ermittelten<br />
Anfor<strong>der</strong>ungensowiedieErmittlungundSpezifikatio n<br />
darausableitbarerAnfor<strong>der</strong>ungenandietechnische<br />
Umsetzung;<br />
- das Validieren <strong>der</strong>spezifiziertenAnfor<strong>der</strong>ungen.<br />
Abhängigkeitenbei<strong>der</strong>Anfor<strong>der</strong>ungsanalyse:<br />
Ermittlung<br />
Spezifikation<br />
Validation<br />
DerAblauf<br />
dieserSchritte<br />
kannvariieren.<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
385
Anfor<strong>der</strong>ungsermittlung<br />
DieAnfor<strong>der</strong>ungsermittlunggeschiehtim<br />
ZusammenwirkenvonAuftraggeberundAnalytiker.<br />
IhrErgebnismussfürdenAuftraggeberverständlich<br />
sein,imAllg.alsoineinernichtsoftwaretechnisc hen<br />
Spracheverfasstsein.<br />
Ergebnisse<strong>der</strong>Anfor<strong>der</strong>ungsermittlung:<br />
DieAnfor<strong>der</strong>ungsermittlungsolltefolgende<br />
Informationendokumentieren/inDokumenten<br />
festhalten:<br />
1.Systembeschreibung:AllgemeineEinführungin<br />
dieFunktionalitätdesSystems<br />
2.Begriffsverzeichnis:InformelleErläuterung<strong>der</strong><br />
FachbegriffealsBasis<strong>der</strong>Analysegespräche.<br />
3.Aktorenliste:Beschreibung<strong>der</strong>ArtenvonAktor en,<br />
diemitdemSystemarbeitensollen,undihrer<br />
Rechte.<br />
<strong>4.</strong>Anwendungsfalldiagramm(engl.usecasediagram) :<br />
ÜbersichtlicheDarstellung<strong>der</strong>Aufgaben/Anwendungsfälle,dievomSystemerledigtwerden:<br />
WelcherAktoristfürwelcheAufgabezuständig?<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
386
5.Beschreibung<strong>der</strong>Anwendungsfälle:<br />
Je<strong>der</strong>AnwendungsfalldesAnwendungsfalldiagramms<br />
mussausführlichbzgl.Ablaufund<br />
Funktionalitätbeschriebenwerden:<br />
- NamedesAnwendungsfalls(ggf.eindeutigeNr.)<br />
- Kurzbeschreibung<br />
- VorbedingungfürdieAusführung<br />
- GenauerAblaufdesAnwendungsfallsund<strong>der</strong><br />
InteraktionmitdemBenutzer<br />
- AuswirkungdesAnwendungsfallsaufden<br />
Systemzustand<br />
- WeitereAnmerkungen<br />
6.Domänenmodell:Beschreibung<strong>der</strong>Domänenobjekte,diefürdasVerständnis<strong>der</strong>Funktionalität<br />
relevantsind.<br />
7.Benutzung:Angabenüberdiepotentiellen<br />
BenutzergruppenunddieBedienoberfläche.<br />
8.TechnischeRahmenbedingungen:Technische<br />
AspektesoweitsievomAuftraggeberbeurteilt<br />
o<strong>der</strong>vorgegebenwerdenkönnen.<br />
9.ZeitundKostenvorgaben.<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
387
Anfor<strong>der</strong>ungsermittlungfüreinenKursPlaner:<br />
Systembeschreibung:<br />
DerKursplanerhatdieAufgabe,einenStundenundRaumplanfürdieKurseamFachbereich<br />
Informatikzuerstellen.Ausgangspunkt<strong>der</strong><br />
PlanungsinddieAngabenüberHörsäle,<br />
belegbareZeitblöcke(Slots)undKurse.<br />
Begriffsverzeichnis:<br />
Kurse:Vorlesungen,Seminare,Übungen<br />
Kursveranstaltung:Kurs+Semester+Teilnehmerzahl<br />
Semester:Winter- undSommersemestermitJahr<br />
Räume<br />
Slot:Wochentag+Anfangs- undEndzeit<br />
Kursplan:legtfest,welcheKursveranstaltungzu<br />
welchemSlot inwelchemRaumstattfindet<br />
Studienabschnitte:GrundstudiumundHauptstudium<br />
Aktoren:<br />
Planer:verteiltKursveranstaltungenaufSlots+Rä ume<br />
Kurs- undRaumverwalter:legtfest,welcheRäume,<br />
welcheSlots,welcheKurseesgibt<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
388
Anwendungsfälle:<br />
KursPlaner:<br />
Kursveranstaltungen<br />
festlegen<br />
Kursveranstaltungen<br />
löschen<br />
Räume<br />
eintragen<br />
Kurse<br />
eintragen<br />
Planer<br />
Kursplan<br />
erstellen<br />
Verwalter<br />
Kursplan<br />
modifizieren<br />
Slots<br />
eintragen<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
389
ExemplarischwerdenzweiAnwendungsfälle<br />
beschrieben:<br />
Titel: Räumeeintragen<br />
Kurzbeschreibung: DerVerwalterkannneue<br />
RäumefürKursveranstaltungenzurVerfügung<br />
stellen.<br />
Vorbedingungen: keine<br />
BeschreibungdesAblaufs:<br />
E1)VerwalterwähltRaumeingabeaus<br />
A1)SystemantwortetmitEingabefenster<br />
E2)VerwaltergibtRaumnummerund<br />
Kapazitätein.<br />
A2)SystemliefertBestätigungo<strong>der</strong>Fehlermeldung.<br />
Auswirkungen: DerRaumbestandwirdverän<strong>der</strong>t.<br />
Anmerkungen: Während<strong>der</strong>Verwaltermit<br />
demSystemarbeitet,darfkeinPlanerdas<br />
Systembenutzen.<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
390
Titel: Kursplanmodifizieren<br />
Kurzbeschreibung: DerPlanerkannden<br />
Kursplanmodifizieren,indemerzusätzliche<br />
Kursveranstaltungeneinplanto<strong>der</strong>existierende<br />
Kursveranstaltungenlöscht.<br />
Vorbedingungen: Kursplanmussexistieren<br />
BeschreibungdesAblaufs:<br />
E1)PlanerhatKursveranstaltungengelöscht<br />
o<strong>der</strong>neueeingeplant(siehedort).<br />
A1)SystemhatListe<strong>der</strong>Kursveranstaltungen<br />
modifiziert.<br />
E2)PlanerlöstdieModifikationdesKursplans<br />
aus.<br />
A2)SystementferntgelöschteKursveranstaltungen<br />
ausdemKursplanundvergibtfür<br />
dieneueingeplantenVeranstaltungen<br />
RäumeundSlots(sieheKursplanerstellung).<br />
Dannwird<strong>der</strong>neueKursplanangezeigt.<br />
Auswirkungen: DerKursplanwirdverän<strong>der</strong>t.<br />
Anmerkungen: Während<strong>der</strong>Planermit<br />
demSystemarbeitet,darfkeinVerwaltero<strong>der</strong><br />
an<strong>der</strong>erPlanerdasSystembenutzen.<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
391
Domänenmodell<br />
Kurs<br />
Kursnr<br />
Kursveranstaltung<br />
Semester<br />
WSoSS<br />
Jahr<br />
Kurs<br />
maxTeilnehmerzahl<br />
Semester<br />
GSoHS<br />
Raum<br />
Raumnr<br />
Kapazität<br />
Slot<br />
Wochentag<br />
Anfangszeit<br />
Endzeit<br />
EingeplanteKursveranstaltung<br />
Kursveranstaltung<br />
Slot<br />
Raum<br />
Veranstaltungstabelle Kursplan<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
392
Benutzung:<br />
BenutzerhabennurgeringeErfahrungimUmgang<br />
mitRechnern.Systemsolltesehrrobustgegenüber<br />
beliebigerBenutzungsein.<br />
TechnischeRahmenbedingungen:<br />
DasSystemsollteaufPC‘smitunterschiedlichen<br />
Betriebssystemenlaufen(Linux,Windows,MacOS).<br />
Zeit- undKostenrahmen:<br />
- DasSystemsollinsechsMonateninstalliertund<br />
einsatzbereitsein.<br />
- DasbenutzendePersonalsollbisdahingeschult<br />
sein.<br />
Bemerkung:<br />
DasobigeBespieldemonstrierteinetypische<br />
StrukturierungvonAnfor<strong>der</strong>ungsdokumenten.<br />
ZurbesserenAustauschbarkeitzwischenProjekten,<br />
fürstandardisierteUntersuchungenund<br />
zumschnellerenEinarbeitengibtesmittlerweile<br />
auchStrukturierungsstandardsfürsolche<br />
Dokumente.<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
393
Beispiel: (Anfor<strong>der</strong>ungsdok.-Standard)<br />
InIEEESoftwareEngineeringStandardsCollection<br />
(1994Edition,IEEEPress,1994)werdenu.A.<br />
StrukturstandardsfürAnfor<strong>der</strong>ungsdokumentation<br />
festgelegt.WirzeigeneineVariante:<br />
Kurzfassung<br />
1.Einleitung<br />
1.1ZweckdesDokuments<br />
1.2Bereich(engl.scope)<br />
1.3Definitionen,Abkürzungen,Akronyme<br />
1.4Referenzen<br />
1.5Überblick<br />
2.Gesamtbeschreibung<br />
2.1Produktperspektive<br />
2.2Produktfunktion<br />
2.3Benutzercharakteristika<br />
2.4AllgemeineEinschränkungen<br />
2.5AnnahmenundAbhängigkeiten<br />
3.SpezifischeAnfor<strong>der</strong>ungen<br />
3.1Anfor<strong>der</strong>ungenandieexternenSystemschnittstellen:<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
394
3.1.1Benutzerschnittstellen<br />
3.1.2Hardwareschnittstellen<br />
3.1.3Softwareschnittstellen<br />
3.1.4Kommunikationsschnittstellen<br />
3.2FunktionaleAnfor<strong>der</strong>ungen<br />
3.3Performanzanfor<strong>der</strong>ungen<br />
3.4Entwurfsrestriktionen<br />
3.5SonstigeAnfor<strong>der</strong>ungen<br />
Anfor<strong>der</strong>ungsspezifikation<br />
DieermitteltenAnfor<strong>der</strong>ungenmüssenin<strong>der</strong><br />
Spezifikationsphaseanalysiertundpräziser<br />
spezifiziertwerden,um<br />
- offeneFragenmitdemAuftraggeberzuklären,<br />
- Wi<strong>der</strong>sprücheundUnklarheitenaufzudecken,<br />
- Entwicklungsaspektemiteinzubeziehen,<br />
- einemöglichstumfassendeSpezifikationfürdie<br />
EntwicklungundValidierung zurVerfügungzu<br />
haben.<br />
DieAnfor<strong>der</strong>ungsspezifikationwirdvonAnalytikern<br />
undSoftware-ArchitektenentwickeltundistTeilde s<br />
Anfor<strong>der</strong>ungsdokuments.<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
395
Ergebnisse<strong>der</strong>Anfor<strong>der</strong>ungsspezifikation:<br />
DieAnfor<strong>der</strong>ungsspezifikationsollteeina bstraktes<br />
Modell (konzeptionelleSicht)deszuentwickelnden<br />
Systemsbeschreiben.WichtigeAspekte:<br />
1.Datenmodell:DasDomänenmodellsolltezu<br />
einempräzisenDatenmodellerweitertwerden.<br />
2.Zustandsmodell:DieSpezifikationmussdeutlic h<br />
machen,welcheZuständedasSystemannehmen<br />
kann.<br />
3.Ablaufmodell/dynamischesModell:Diemöglichen<br />
SystemabläufeunddamitverbundenenZustandsübergänge<br />
solltenbeschriebenwerden.<br />
<strong>4.</strong>Bedienschnittstelle:DieSpezifikationsollte eine<br />
klareVorstellungvon<strong>der</strong>Bedienungundden<br />
Oberflächenbestandteilenvermitteln.<br />
5.DokumentationweitererAnalyseergebnisse<br />
DieSpezifikationsolltemitTestfällenangereicher t<br />
werden.<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
396
ZurSpezifikationkönnenSprachen<strong>der</strong>Softwaretechnikverwendetwerden,z.B.:<br />
- UML-Diagramme<br />
- ER-Diagramme<br />
- Zustandsübergangsdiagramme<br />
(Transistionssysteme)<br />
- formaleSpezifikationssprachen<br />
etc.<br />
Bemerkung:<br />
• DieAuswahl<strong>der</strong>Spezifikationstechnikund<strong>der</strong><br />
Detaillierungsgrad<strong>der</strong>Spezifikationhängenvom<br />
Projektab.<br />
• DieSpezifikationsolltenurdannEntwurfsaspekte<br />
(wiewirdetwasgemacht,stattwaswirdgemacht)<br />
enthalten,wenndiesvomAuftraggebervorgegeben<br />
o<strong>der</strong>gewünschtwird.<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
397
Anfor<strong>der</strong>ungsspezifikationfür KursPlaner:<br />
DaalsEntwurfs- undDokumentationssprachefür<br />
dieProgrammeEnglischbenutztwerdensoll,wird<br />
auchdieSpezifikationinEnglischverfasst.<br />
1.Datenmodell:<br />
DasDatenmodellerhaltenwirausdemDomänenmodelldurchPräzisierung<strong>der</strong>Datentypen;dabei<br />
bezeichne:<br />
SemKind={WS,SS}<br />
CurriculumPart={Grundstudium,Hauptstudium}<br />
Weekday={Mo,Tu,We,Th,Fr,Sa,Su}<br />
Invarianten:<br />
• Bereichsinvarianten:<br />
- WochentagistnichtamWochenende<br />
- Start- und Endezeite:volleStunde+0¼½¾<br />
- Kursnr., Raumnr.,KapazitätundTeilnehmerzahlen<br />
sindechtpositiveZahlen,Jahreszahlen ≥ 2000<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
398
Semester<br />
Course<br />
courseNo:int<br />
wsss:SemKind<br />
year:int<br />
1<br />
CourseTable<br />
1<br />
CourseToSchedule<br />
*<br />
maxNoOfParticipants:int<br />
gshs:CurriculumPart<br />
*<br />
*<br />
ScheduleTable<br />
RoomTable<br />
Room<br />
roomNo:int<br />
capacity:int<br />
1<br />
Slot<br />
day:Weekday<br />
startTime:float<br />
endTime:float<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
399<br />
*<br />
1<br />
SlotTable<br />
ScheduledCourse<br />
*<br />
*<br />
1<br />
CourseSchedule
• Objekt-übergreifendeInvarianten:<br />
- Slotsin<strong>der</strong>Slottabelledürfensichnichtüberschneiden(Analyseergebnis)<br />
- DieTeilnehmeranzahleinerKursveranstaltung<br />
musskleinerseinals<strong>der</strong>zugewieseneRaum<br />
- DerKursplandarfproRaumundSlotmaximal<br />
eineKursveranstaltungvorsehen.<br />
2.Zustandsmodell:<br />
DerSystemzustandumfasstzujedemZeitpunkt:<br />
- eineKurse-,Raum- undSlottabelle,<br />
- eineVeranstaltungstabelle.<br />
DieTabellenkönnenauchleersein.Darüberhinaus<br />
kannereinenaktuellenKursplanumfassen.<br />
DergesamteZustandist persistent zuverwalten.<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
400
3.Ablaufmodell:<br />
• DasSystemlässtkeineParallelitätzu.<br />
• ZujedemZeitpunktarbeitetmaximaleinPlanerode r<br />
VerwaltermitdemSystem.<br />
• FürdieAuthentifikation <strong>der</strong>Benutzerundum<br />
Planungs- vonVerwaltungssitzungenunterscheiden<br />
zukönnen,wirdeinLogIn-Mechanismus<br />
vorgeschlagen(Ergebnis<strong>der</strong>Analyse).<br />
• DieVerwaltung<strong>der</strong>Kurse-,Raum- und Slottabelle<br />
sollanalogablaufen,wobeidemVerwalterjeweils<br />
dieaktuellenDatenangezeigtwerden.<br />
• ZujedemZeitpunktarbeitetmaximaleinPlanerode r<br />
VerwaltermitdemSystem.<br />
OperationenfürZustandsübergänge:<br />
- modifyCTab,modifyRTab,modifySTab:modifizieren<br />
dieKurs-,Raum- undSlottabelle<br />
- updateCSchedule:modifiziertKursplansoferneiner<br />
einerexistiert;benutztdafürdenaktuellen<br />
KursplanunddieVeranstaltungstabelle<br />
- computeCSchedule:erstelltneuenKursplan;benutzt<br />
dafürdieVeranstaltungstabelle<br />
- saveState:sichertdenSystemzustand<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
401
AblaufmodellierungmitUMLStatechart Diagramm:<br />
course<br />
room<br />
loginRequest [admin]<br />
loginRequest<br />
[failed]<br />
LogIn<br />
loginRequest<br />
[planning]<br />
update<br />
[CourseSchedule<br />
isdefined]/<br />
updateCSchedule<br />
slot<br />
AddCourse<br />
AddRoom<br />
AddSlot<br />
Admin<br />
loginRequest<br />
[failed 3x|inuse]<br />
Planning<br />
schedule<br />
ScheduleCourse<br />
Dialog<br />
commit /<br />
modifyCTab<br />
exit /saveState<br />
exit /saveState<br />
new/<br />
computeCSchedule<br />
commit/<br />
updateScheduleTable<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
402
Bemerkung:<br />
• DieAblaufmodellierungistimWesentlicheneine<br />
Präzisierung<strong>der</strong>Anwendungsfälle.<br />
• UnterschiedlicheDiagrammartenundSpezifikationstechnikeneignensichzurAblaufmodellierung.<br />
Zustandsübergangsdiagramme eignensich<br />
beson<strong>der</strong>szurModellierungsequentielleAbläufe<br />
o<strong>der</strong>nebenläufigerAbläufe,diekaummiteinan<strong>der</strong><br />
kommunizieren.<br />
<strong>4.</strong>Bedienoberfläche:<br />
FolgendeFensterdienen<strong>der</strong>Interaktion:<br />
- Startfenster:AuswahlzwischenPlaner/Verwalter<br />
Einloggen<br />
Planersitzung:<br />
- PlanungsfensterzeigtdenaktuellenKursplan<br />
- FensterzurModifikation<strong>der</strong>Veranstaltungstabelle<br />
Verwaltersitzung:<br />
- FensterzurEingabevonKursen,Räumenu.Slots<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
403
5.DokumentationweitererAnalyseergebnisse<br />
BeimEntwickeln<strong>der</strong>Spezifikationwurdefolgenden<br />
Aspektediskutiert:<br />
- DiebeidenAnwendungsfällefestlegenundlöschen<br />
sollenzusammengelegtwerdenundwerdenals<br />
Aktualisieren<strong>der</strong>Veranstaltungstabellebetrachtet.<br />
- DieAnwendungsfälleKursplanerstellenund<br />
Kursplanmodifizierensollengetrenntbleiben<br />
(Alternative:FühreKursplanlöschenein).<br />
Anfor<strong>der</strong>ungsvalidation<br />
TätigkeitenzurValidierung solltendieAnfor<strong>der</strong>ungs -<br />
ermittlungund–spezifikationbegleiten,konzentrie ren<br />
sichabernaturgemäßamEnde<strong>der</strong>Analyse.<br />
Aufgaben:<br />
- EntsprechendieAnfor<strong>der</strong>ungendenVorstellungen<br />
desAuftraggebers?<br />
- SinddieAnfor<strong>der</strong>ungeninsichstimmigundklar<br />
spezifiziert?<br />
- IstdieAnfor<strong>der</strong>ungsdokumentationausreichend<br />
fürdieSystementwicklung?<br />
- IstdieAnfor<strong>der</strong>ungsdokumentationausreichend<br />
zurValidationundzumTestendesSystems?<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
404
Ergebnis<strong>der</strong>Anfor<strong>der</strong>ungsvalidationisteine<br />
verbesserteAnfor<strong>der</strong>ungsdokumentation.<br />
TechnikenzurValidation:<br />
- KonstruktioneinesPrototyps,insbeson<strong>der</strong>e<br />
zurIllustration<strong>der</strong>Interaktionund<strong>der</strong>Bedienoberfläche<br />
- Inspektion<strong>der</strong>Anfor<strong>der</strong>ungsdokumente<br />
- DurchspielenvonTestfällen<br />
- AbleitungvonEigenschaftenausden<br />
Anfor<strong>der</strong>ungen<br />
Bemerkung:<br />
Anfor<strong>der</strong>ungsvalidation wirdinihrerBedeutung<br />
häufigunterschätzt,obwohlgilt:<br />
JespäterimSWE-ProzesseinFehler<br />
erkanntwird,destoteureristes,ihn<br />
zubeheben.<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
405
Anfor<strong>der</strong>ungsvalidation für KursPlaner:<br />
- EntwerfedieDarstellungfürdieFensterund<br />
diskutieremöglicheAbläufe.<br />
- BetrachteTestdatenfürKurse,etc.undberechne<br />
KursplanvonHand.Ergebnismöglicherweise:<br />
¥ KursveranstaltungenmüssenmitPrioritäten<br />
versehenwerdenkönnen.<br />
AbschließendeBemerkungenzurAnalyse<br />
DieAnalysehatdieAufgabe,<br />
- dieAnfor<strong>der</strong>ungenanszuentwickelndeSystem<br />
möglichstvollständigundklarfestzustellenund<br />
zuanalysierenunddabei<br />
- Entwurfsentscheidungenoffenzulassen,wodies<br />
möglichist:<br />
¥ keineFestlegung<strong>der</strong>Architektur(Module,<br />
Schnittstellen,Verteilungsaspekte)<br />
¥ keineTechnikentscheidungen(Plattform,<br />
Implementierungssprachen,Werkzeuge)<br />
05.07.2004 ©A.Poetzsch-Heffter,TUKaiserslautern<br />
406
Change language