SASD

Structured Analysis and Structured Design (SASD) is een software ontwikkelmethode die met name gebruikt wordt voor grote en complexe systemen. De hoofdgedachte van de SASD-methode is om het (conceptuele) systeem te verdelen in componenten, om zo ieder component beter te begrijpen alsmede de onderlinge relaties tussen de verschillende componenten. Deze aanpak moet vooral leiden tot een kortere ontwikkeltijd voor projecten.

Geschiedenis

SASD is eind jaren 70 ontwikkeld door Edward Yourdon en Tom DeMarco, nadat ze de veel formelere methode Structured Analysis Design Technique (SADT) vereenvoudigd hadden. Hiermee werd SASD toegankelijker voor een groter publiek. Al snel werd de methode populair in de software-industrie en ging IBM het ook in hun ontwikkeltraject gebruiken.

Helaas was er bij het originele SASD (ook wel “Classic SASD” genoemd) geen verband tussen de gestructureerde analyse en het ontwerp, waardoor de methode soms lastig bij te houden was. Ook Yourdon zag deze nare eigenschap en begon te schaven aan zijn concept. Uiteindelijk is er in 1989 een boek van Yourdon op de markt gekomen die later de standaard vormde voor SASD (ook wel “modern SASD” genoemd). Daarnaast werd de ontwikkeling van software steeds beter ondersteund door zogeheten CASE-tools (Computer Aided Software Engineering), doordat deze vaak al gegevens konden genereren uit diagrammen die voor de analyse waren gemaakt.

Het fundamentele model

De methode bestaat eigenlijk uit twee hoofdmodellen: het fundamentele model en het implementatiemodel. “Het fundamentele model is een model van wat het systeem moet doen om de gebruiker tevreden te stellen, waarbij er zo min mogelijk gezegd wordt over de implementatie van het systeem”, zo stelde Yourdon. Het fundamentele model bestaat op zijn beurt weer uit twee submodellen: het omgevingsmodel(domeinmodel) en het functioneel model.

Het omgevingsmodel

Het omgevingsmodel geeft in feite de grens aan tussen het systeem en de externe wereld. De volgende stappen zijn hiermee gemoeid:

• Het opstellen van een doelstelling (“Statement of Purpose”).

Deze doelstelling is in feite het antwoord op de vraag: “Wat moet het systeem (gaan) doen?”. Het is belangrijk dat deze vraag goed beantwoord wordt, omdat het de basis vormt voor het verdere ontwerp. Bovendien is het erg gewenst om het antwoord zo beknopt mogelijk op te schrijven (niet meer dan 1 alinea) om zo niet te veel in detail te treden.

• Het maken van een Context Diagram.

Het Context Diagram geeft een beeld van de objecten buiten het systeem en de manier waarmee het systeem hiermee te maken heeft. Daarnaast vormt het diagram het nulniveau van een Data Flow Diagram (DFD).

• Het opstellen van een lijst van gebeurtenissen (Event List).

Deze lijst bevat alle gebeurtenissen (events) van buitenaf waarop het systeem moet reageren. Na het maken van deze lijst kan er teruggekoppeld worden op het Context Diagram om te kijken of deze met elkaar overeenkomen.

Het functioneel model

Het functioneel model beschrijft het interne gedrag van het systeem en brengt hiermee de functionele eisen in kaart. De technieken om de functionele eigenschappen te omschrijven zijn:

• Het maken van Data Flow Diagrams (DFD).

Een DFD beschrijft de processen van een systeem met hun taken en de datastromen tussen verschillende taken en processen. Hierdoor worden de functies van een systeem duidelijk, alsmede de verbanden tussen verschillende functies.

• Het maken van proces specificaties.

Bij sommige (ingewikkelde) processen uit het DFD is het handig om een proces beschrijving te maken. Deze bestaat uit pseudo-code die de input, het algoritme en de output van het proces beschrijft.

• Het maken van data beschrijvingen (Data Dictionary).

Alle data(stromen) uit het DFD worden in de data beschrijvingen uitgebreid beschreven, zodat ze ook daadwerkelijk betekenis krijgen. Er is echter geen standaard manier om een data beschrijving te maken.

• Het maken van een Entity Relation Diagram (ERD).

In het ERD worden de relaties tussen de data-objecten (entiteiten) van het systeem in kaart gebracht. Het geeft verdere informatie over de manier van dataopslag.

• Het maken van State-Transition Diagrams (STD).

Een STD modelleert het tijdsafhankelijke gedrag van het systeem. Met andere woorden brengt het de verschillende statussen en de overgangen hiertussen in kaart.

Het implementatiemodel

Het implementatiemodel neemt binnen SASD het Designgedeelte voor z’n rekening. In dit model maakt men gebruik van de zogeheten Structure Chart. Met een Structure Chart deelt men het systeem in in modules, waarvan de input en output nauwkeurig beschreven wordt. Ook worden de relaties tussen de verschillende modules met behulp van pijlen en gegevensstromen duidelijk gemaakt. De interne functies van de modules worden echter niet genoemd. Het zogenaamde “black-box” principe wordt hier toegepast. Het doel van deze opdeling in modules is het in kaart brengen van de interactie van de gebruiker met het systeem. Daarnaast wordt hier exact vastgesteld wat er geautomatiseerd wordt en wat niet. Er wordt als het ware een duidelijke grens getrokken tussen de gebruiker en het systeem.

Kritiek

SASD wordt nu al meer dan 30 jaar gebruikt en is daarmee een ‘volwassen’ software ontwikkelmethode geworden. Veel ontwikkelaars vinden SASD een prettige methode omdat het uit gaat van de (natuurlijke) procesgerichte denkwijze. De kritiek richting SASD gaat vooral uit naar het feit dat SASD niet veel aandacht heeft voor de gebruiker gedurende het ontwikkeltraject. Iets wat juist een kritieke succesfactor is voor een geslaagd softwareproject. Zodoende verliest SASD zijn populariteit en gaat de voorkeur vandaag de dag vaak uit naar ‘Agile’-ontwikkelmethoden als DSDM en RAD.