2013.TE.7766
‘Ontwikkeling van een iPad app voor
digitale DSA systemen’
Sebastiaan Koppenaal
s.m.m.koppenaal@student.tudelft.nl
1236423
2013.TE.7766
‘Ontwikkeling van een iPad app
voor digitale DSA systemen’
Sebastiaan Koppenaal
Samenvatting
Binnen de delftse systeemkunde hebben tekeningen een belangrijke rol. Ze helpen de
„systeemkundige‟ met een beeld vormen van het systeem en met de communicatie over
het systeem. Door een app op een tablet te ontwikkelen kunnen deze tekeningen sneller
worden gemaakt en nieuwe inzichten worden verwerkt. Doordat de ontwikkelde app
specifiek ontwikkeld is voor de Delftse systeemkunde kunnen tekenafspraken en
conventies gemakkelijker gehandhaafd worden.
Als basis voor de app zijn alle elementen uit Bron 1: Veeke H.P.M., Ottjes J.A, Lodewijks
G. (2008) ; “The Delft Systems Approach, Analysis and Design of Industrial Systems”;
Springer, London. behalve de iteratieve pijlen toegevoegd aan de app. Verder zal de app
automatisch de in- en output pijlen koppelen en deze een vergelijkbare stijl geven. De
functie en pijlen kunnen gemakkelijk worden aangemaakt en worden gesleept naar de
juiste plek in het systeem. Voor de pijlen is het mogelijk om de losse delen te slepen over
het scherm, zo kan een gebruiker de pijlen om nieuw aangemaakte elementen laten
lopen. Voor alle elementen is het mogelijk om een korte tekstbeschrijving toe te voegen.
De functie elementen hebben verder de ruimte voor een uitgebreidere beschrijving, deze
beschrijving wordt afgedrukt in rapport export van het systeem. De app geeft ook de
mogelijkheid om door het systeem te navigeren en zorgt voor de consistie van de
verschillende aggregatie niveaus.
Het opslaan van wijzigingen gebeurt automatisch in een SQLite database. Per project
bestaat een apparte database die uitwisselbaar is met andere mensen die ook de app
hebben. Verder bestaat er de mogelijkheid om een pdf document te exporteren waarin het
systeem getekent is. Hiervoor zijn een aantal verschillende stijlen beschikbaar. Dit pdf
document bevat interne linkjes waardoor er door het afgedrukte systeem kan worden
genavigeerd door op de verschillende functies in de afbeelding te drukken.
De app is geprogrammeerd voor de iPad in xCode, de ontwikkelomgeving van Apple. Er
zijn verschillende „communicatiemiddelen‟ in objective-C gebruikt en er is gebruik gemaakt
van „Model, View, Controller‟ principes zoals gebruikelijk in objective-C. Pijlen en functies
hebben hun eigen model en controller die zelfstandig het aanpassen van hun modellen
regelen. Om de consistentie en de samenwerking van die verschillende elementen te
waarborgen is een „systeem controller‟ gebruikt. Verder zijn er een aantal „table view
controllers‟ ontwikkelt om: nieuwe elementen toe te voegen, projecten te kiezen,
systemen als lijsten weer te geven en om details van functies te veranderen. Om een
goede grafische weergave van de elementen te maken is gebruik gemaakt van „custom
views‟. Voor functies zijn deze redelijk zelfstandig en kunnen ze zichzelf tekenen op basis
van hun beschikbare „frame‟. Voor pijlen geeft de „arrow controller‟ zichzelf als
gedelegeerde op zodat deze op basis van het „model‟ en de juiste stijl de pijl kan worden
getekent.
Inleiding
Binnen de systeemkunde hebben tekeningen een belangrijke positie. Tekeningen helpen
de systeemkundige met het in kaart brengen van het volledige systeem en met de
communicatie over dat systeem. De huidige software pakketten om deze tekeningen mee
te maken zijn echter niet gebruiksvriendelijk.
Deze problemen kunnen worden opgelost door een programma te schrijven dat specifiek
is toegespitst op het maken van systeemkundige tekeningen. Doordat conventies direct
worden toegepast en de interface gericht is op het doel van de gebruiker kan er sneller en
beter getekend worden. Verder kan een specifiek programma ook invulling geven aan het
„Nurse‟-effect.
Door de huidige beperkingen van gebruikelijke software wordt in de praktijk veel gebruik
gemaakt van papier gevuld met schetsen. Dit kost veel werk, en bij nieuwe inzichten
moeten deze opnieuw gemaakt worden. Om ook hier ondersteuning te bieden moet een
toegepast tekenprogramma dus ook mobiel zijn.
Uiteindelijk heb ik gekozen voor een iPad app die een oplossing moet bieden voor de
eerder genoemde problemen. De iPad is marktleider van de tablet markt en daarom een
voor de hand liggende keuze. In dit document wordt uiteengezet wat deze iPad app moet
kunnen, welke principes uit de systeemkunde worden gevolgd en welke
programmeerprincipes worden gebruikt. Vervolgens worden de verschillende object
„classes‟ kort samengevat en wordt de interactie verder beschreven.
Inhoud
Samenvatting... 3
Inleiding ... 4
Inhoud ... 5
H1. Systeemkundige mogelijkheden van de app. ... 7
§ 1.1 Basiselementen ... 7
Product pijl ... 7
Informatie pijl ... 7
Functie of Proces ... 7
§ 1.2 Steady-state elementen ... 8
Invullingen door basiselementen. ... 8
Metingen en ingrepen. ... 8 De filter ... 8 De buffer ... 9 Afvoer pijlen ... 9
§1.3 PROPER element ... 9
§1.4 Flow-elementen ... 10
Splitsen of samenvoegen ... 10 Reguleren ... 10§1.5 Discussie ... 11
H.2 Interface mogelijkheden ... 12
§ 2.1 Elementen aanmaken ... 12
§ 2.2 Pijlen bewerken ... 12
§ 2.3 Functies bewerken ... 13
§ 2.4 Navigatie door het systeem. ... 14
§ 2.5 Opslaan van het systeem. ... 14
H3. Programmeer principes ... 15
H4. Object ‘Classes’ ... 16
§ 4.1 inleiding objective-C ... 16
Classes ... 16 Methods ... 16 Protocols ... 16 ARC ... 17Value, Objecten en Pointers. ... 17
§4.2 ‘Model Classes’ ... 18
§4.2.1 ‘Functie model Class’ ... 18
§4.2.2 ‘Arrow model Class’ ... 18
§4.2.3 ‘ArrowStyle model Class’ ... 19
§4.2.4 ‘PointObject model Class’ ... 19
§4.2.5 ‘DSADataLoader model Class’ ... 19
§4.3 ‘Controller Classes’ ... 20
§4.3.1 ‘DSASystemViewController’ ... 20
§4.3.3 ‘DSAArrowViewController’ ... 21 §4.3.4 ‘DSAProjectTableViewController’... 21 §4.3.5 ‘DSASystemPrinter’ ... 22 §4.3.6 ‘DSASystemNavigationViewController’ ... 23 §4.3.7 ‘DSAFunctionDetailViewController’ ... 23
§4.4 ‘View Classes’ ... 24
§4.4.1 ‘Function View’s’ ... 24 §4.4.2 ‘Arrow View’s’ ... 24 §4.4.3 ‘DSATableViewCell’ ... 25 §4.4.4 ‘Storyboard View’s’ ... 25Literatuurlijst ... 26
Bijlagen... 27
Header files ... 28
Models... 28 Controllers ... 34 View’s ... 41Implementation files ... 46
Models... 46 Controllers ... 111 View’s ... 222Storyboard afbeeldingen ... 246
H1. Systeemkundige mogelijkheden van de app.
Het mogelijk maken om gemakkelijk digitale systeemtekeningen te produceren is het doel
van de ontwikkeling van de app. Om te toetsen of de app daadwerkelijk dit doel bereikt
heeft moet het in principe mogelijk zijn om alle systeemelementen uit de afbeeldingen
“the Delft Systems Approach” (Bron 1: Veeke H.P.M., Ottjes J.A, Lodewijks G. (2008) ;
“The Delft Systems Approach, Analysis and Design of Industrial Systems”; Springer,
London.) in te reproduceren. Het enige element dat hiervan is uitgezonderd is de
iteratieve (gekromde) pijl uit het innovatie model. Om extra voordeel van een digitale
tekening te beleven en de verschillende tekeningen van een systeem geordend te houden
moet het ook mogelijk zijn om een blackbox van binnen te bekijken en zo invulling te
geven aan „Nurse effect‟.
§ 1.1 Basiselementen
Product pijl
De dubbele pijl geeft een „product‟ van een functie weer, in proper modellen worden voor
verschillende aspecten ook verschillende grijstinten gebruikt. De productpijl verandert in
de app van kleur voor verschillende aspecten. Als alle standaard kleuren zijn gebruikt
krijgt deze een extra lijn om zo te zorgen dat er geen limiet is aan het aantal aspecten.
Informatie pijl
De informatie pijl wordt weergegeven met een enkele zwarte pijl, deze verandert verder
niet van dikte of kleur.
Functie of Proces
Een functie of een proces wordt altijd weergegeven met een rechthoek en een
beschrijving in tekst
§ 1.2 Steady-state elementen
In Figuur 2 is een compleet steady-state model weergegeven. Een aantal elementen uit
deze tekening kunnen niet met de drie basiselementen worden weergegeven.
Figuur 2 Volledig steady-state model uit 'the DSA'
Invullingen door basiselementen.
In Figuur 2 worden Initialiseren, evalueren, vergelijken en aansturen weergegeven met
blokjes en een werkwoord. Dit is niet anders dan het basiselement voor een functie, de
enige extra eis is dat het blokje van formaat kan veranderen. Hiermee is het ook direct
mogelijk om de codering functies te tekenen.
Metingen en ingrepen.
Metingen en ingrepen worden in Figuur 2 weergegeven met ovalen en informatiepeilen.
Deze worden hier specifiek en globaal gebruikt, door of een informatie pijl in en uit de
functie te laten gaan, of door vier pijlen diagonaal te plaatsen en verder of alleen
inkomende of alleen uitkomende informatie te hebben. Hiervoor moet aan de app dus een
ovaal element worden toegevoegd. De tekst die de gebruiker invoert kan verder
specificeren wat het element voor functie heeft.
De filter
De filter wordt weergegeven met een gearceerd rechthoek, deze moet worden
toegevoegd aan de app. Hierbij is nog de mogelijkheid om het teken voor “add the
missing” toe te voegen. Dit teken dat lijkt op „Pacman‟ maar zijn oorsprong vind in een
cirkel met een ontbrekend stukje geeft aan dat voor bepaalde onvolkomenheden de
mogelijkheid bestaat deze te verbeteren. Dit teken moet ook in de app beschikbaar zijn.
De buffer
De buffer wordt weergegeven met een gelijkzijdige driehoek waarvan de punt naar
beneden staat. Deze zal ook in de app beschikbaar zijn.
Afvoer pijlen
De verticale stromen uit de buffers en filters in Figuur 2 geven de afvoer van de filters en
de buffers weer. Binnen de app kan voor dit soort stromen een normale dubbele pijl
worden gebruikt. Een apart soort pijl is niet nodig omdat het tekenen van het
afvoerstromen doorgaans alleen gebeurt als dit „afval‟ nog ergens gebruikt wordt.
§1.3 PROPER element
Binnen de systeemkunde heeft de
compleetheid van een analyse een
belangrijke plek. Het uitgangspunt is niet
het bestrijden van de symptomen die
worden aangegeven door gebruikers van
het systeem, maar het vinden en oplossen
van de oorzaken. Hierbij komt het vaak
voor dat problemen ontstaan door de
manier waarop processen van elkaar
afhankelijk zijn.
Deze afhankelijkheid tussen de
verschillende aspecten wordt vaak
weergegeven met een PROPER model zoals
weergegeven in Figuur 3. Het afwijkende
van deze manier van weergeven is dat er
één coördinerende-(„Control‟) functie is voor
drie aspectfuncties die je op bijna hetzelfde
aggregatie niveau wil weergeven. Binnen
de app zal dit ook mogelijk zijn, maar moet
er een keuze worden gemaakt m.b.t. de
invulling van het „Nurse‟-effect. Hierbij kan
gekozen worden om nadruk te leggen op
het feit dat bijna raak hetzelfde is als missen en de omvattende functie van de drie
aspectfuncties een speciale functie is waar een bepaalde mate van doorzichtigheid
mogelijk is. De andere optie is dat de aspectfuncties worden gezien als functies op het
zelfde aggregatie niveau als de coördinerende functie. De omsluitende functie geeft dan
alleen aan dat de normen en resultaten overkoepelend zijn. De eerste optie laat de
tekenaar inzoomen op de omsluitende functie en met de tweede optie kan direct op één
van aspectfuncties worden ingezoomd. Omdat met de eerste opties niet eenduidig kan
worden afgeleidt welke functies wel en niet weergegeven moeten worden na het
uitzoomen is gekozen voor de tweede optie. De omsluitende de functie geeft dan de
mogelijkheid om informatiepijlen niet te laten weergeven maar na inzoomen bij één van
de aspectfuncties deze toch te laten binnenkomen.
§1.4 Flow-elementen
De laatste twee benodigde elementen zijn elementen die gebruikt worden om aan te
geven hoe de producten zich door het systeem heen bewegen.
Splitsen of samenvoegen
In Figuur 4 wordt de stroom van vliegtuigen gesplitst en samengevoegd door gebruik te
maken van een parallellogram. Doordat de app zelf in de gaten houdt of een
productstroom doorloopt en daarmee de kleur van de pijl gelijk houdt zal in het geval van
een splitsing dit expliciet gedaan moeten worden. Door deze restrictie op te leggen hoeft
de tekenaar zich geen zorgen te maken over het kiezen van kleuren. Het expliciet splitsen
en samenvoegen geeft in een tekening wel extra informatie en zorgt daardoor tot een
betere tekening.
Figuur 4 Gebruik van het 'wybertje'
Reguleren
Binnen een aantal bedrijfskundige trends krijgen de begrippen „push‟ en „pull‟ een
belangrijke plaats. Binnen de tekeningen in “Bron 1:wordt dit ingevuld door een kraan die
wordt aangestuurd met een informatiepijl. De oorsprong van deze informatie pijl geeft aan
hoe bepaald wordt of er producten stromen. Deze kraan (of in
het engels „tap‟) wordt weergegeven met een doorbroken cirkel
zoals te zien in Figuur 5 afbeelding van een 'tap'.
Figuur 5 afbeelding van een 'tap'
§1.5 Discussie
Het voorgestelde principe om het aantal mogelijke verschillende pijlen uit te bereiden door
na het opgebruiken van de standaard kleuren meer lijnen per pijl toe te voegen geeft een
conflict met de tekenafspraken uit Analyse van organisatie problemen van in ‟t Veld (Bron
2). Hierin wordt gesteld dat als een productstroom veel van karakter verandert er een
extra lijn in de pijl kan worden getekend. In zowel Bron 1 en Bron 2 is deze afspraak
echter nooit gebruikt, wel wordt een derde streep gebruikt om onderscheid te maken
tussen twee verschillende invoer pijlen. De keuze is dus genomen om prioriteit te geven
aan het onderscheiden van elementenstromen t.o.v. de mogelijkheid om kenmerkende
transformaties van elementen verduidelijken.
Verder wordt in veel tekeningen in Bron 1 gebruik gemaakt van gebiedsarcering om
aspecten of subsystemen aan te geven. Dit wordt vaak gedaan om in de uitgebreidere
modellen die in stukken worden afgeleid die eerder gevormde stukken te kunnen
identificeren. In de app is dit in principe niet nodig, doordat er snel en gemakkelijk
genavigeerd kan worden door de gebruiker.
Het ontbreken van de iteratieve (gekromde) pijl heeft verschillende redenen die
gezamenlijk genoeg zijn om dit te verdedigen. De andere pijlen bestaan altijd uit verticale
en horizontale stukken, dit geeft een overzichtelijk en gestructureerd beeld. De
mogelijkheden om deze pijlen te veranderen op een scherm vergen een fundamenteel
andere besturing dan eventueel gekromde pijlen. Het programmeren van een extra
besturing kost veel tijd die ook aan andere (nuttigere) features besteed kan worden. Ook
zijn er andere mogelijkheden om aan te geven dat iets een iteratief proces is. Door deze
simpelweg te vervangen van de kromme pijlen met rechte pijlen zal een gebruiker niet
heel veel anders vertellen. Verder is één van de redenen voor het maken van DSA
tekeningen dat ze ondersteunend zijn in de communicatie. Hoe meer verschillende soorten
symbolen en pijlen er zijn, hoe meer kennis wordt gevraagd van de lezer.
H.2 Interface mogelijkheden
In de app moeten de in “
H1. Systeemkundige mogelijkheden van de app.” beschreven elementen makkelijk te
plaatsen zijn. Hoe de besturing daarvan moet werken zal in dit hoofdstuk beschreven
worden. In de basis zijn de elementen onder te verdelen in functies en pijlen, daarnaast
moet de app de mogelijkheid bieden gemakkelijk te navigeren door het systeem. Verder
zal de app zich zo goed mogelijk moeten conformeren aan de iOS Human Interface
Guidelines van Apple (Bron 3).
§ 2.1 Elementen aanmaken
De drie basiselementen beschreven in § 1.1 Basiselementen kunnen worden toegevoegd
doormiddel van een eigen toevoeg knop in de balk aan de bovenkant van het scherm.
Deze worden dan onder de knop in het scherm geplaatst en de app zorgt zelf dat de data
voor deze elementen worden opgeslagen. De overige elementen zullen samen worden
gevoegd onder een vierde knop waarmee een extra keuzescherm kan worden geopend.
Voor de pijlen moet het mogelijk zijn om later te bedenken dat deze toch de andere soort
moeten hebben. Voor de andere elementen moet dit ook kunnen, maar doordat er
meerdere mogelijkheden zijn moeten hier dezelfde keuzes worden weergegeven als bij het
maken van een nieuw overig element.
§ 2.2 Pijlen bewerken
Na het aanmaken van een standaard pijl zorgt de app dat deze wordt opgeslagen en krijgt
de gebruiker op het scherm een bewerkbare pijl. Voor een product pijl is dit een
horizontale pijl in een kleur die nog niet gebruikt wordt. Voor een informatie pijl is deze
vertikaal, zwart en naar beneden gericht.
Het bewerken van een pijl kan op drie manieren:
Het verplaatsen van het begin- of eindpunt.
Het verplaatsen van een deel.
Het verplaatsen van de hele pijl.
Het verplaatsen van het begin- of eindpunt kan met een vinger gedaan worden. Ondanks
de eventuele kleinere afbeelding van dat punt is het aanraak gevoelige oppervlak
overeenkomstig met het gewenste oppervlak beschreven in Bron 3. Door een begin- of
eindpunt te verplaatsen kunnen extra hoeken in de pijl worden gemaakt. Per keer dat het
punt „gepakt‟ wordt kan één extra hoek worden gemaakt, zo kan het punt altijd naar de
gewenste plek worden verplaatst. Het limiteren van het aantal hoeken per keer „pakken‟
zorgt dat er niet te zorgvuldig verplaatst hoeft te worden om een „traplopende pijl‟ te
voorkomen.
Het verplaatsen van een deel kan geen extra hoeken maken, maar als de gebruiker het
deel zo verplaats dat er (bijna) een rechte lijn ontstaat zal er wel een hoek worden
weggehaald. Als een deel wordt verplaats staan de twee punten en de lengte van dat deel
vast. Eventuele andere delen veranderen zodanig dat de pijl nog steeds één geheel blijft,
maar begin- en eindpunt van de pijl veranderen alleen als deze behoren tot het
Het verplaatsen van de hele pijl is mogelijk als de pijl nog niet verbonden is met een
ander element op het scherm. Als de gebruiker een pijl bewerkt zal deze „omlijst‟ worden
met een rechthoek. Deze hele rechthoek kan gebruikt worden om de pijl mee beet te
pakken en te verplaatsen. De pijl zal dan niet van vorm veranderen en alle delen blijven
dus even groot.
Aan de bovenkant van omlijsting zal een zwarte balk zijn waarin gewisseld kan worden
tussen een productpijl of informatie pijl. Ook zal hier een knop zijn om de pijl te
verwijderen van het scherm en bestaat er de mogelijkheid om de vorm van de pijl te
bewaren maar deze wel 90 graden te draaien.
Aangezien een pijl ook een beperkte omschrijving in tekst moet bevatten zal de interface
daar ook ruimte voor bieden. Ook mag de gebruiker de locatie van deze beschrijving
verplaatsen.
§ 2.3 Functies bewerken
Om consistentie in de interface te waarborgen zullen alle overige elementen worden
gezien als een functie. De gebruiker moet deze op twee manieren kunnen bewerken:
Het aanpassen van de grote.
Het aanpassen van de locatie.
Net als de pijlen zullen de functies ook „omlijst‟ worden, al zal dit in het geval van de
standaard functie en de PROPER omvattende functie niet een extra rechthoek opleveren.
Deze rechthoek zal in de bovenrand voorzien zijn van een zwarte balk waar net als bij de
pijlen het type functie kan worden veranderd en waar deze kan worden verwijderd.
Rechtsonder in deze rechthoek zal een markering worden aangebracht die de gebruiker
laat weten dat de grote kan worden aangepast. Door deze markering te verslepen over
het scherm zal de app direct de dimensies van de functie aanpassen zodat de gebruiker
weet hoe de veranderingen er uit zien. Na het loslaten van deze markering zal de app
eventuele aanpassingen aan gerelateerde elementen toepassen.
Het verplaatsen van het element zal hetzelfde werken als het verplaatsen van een
volledige pijl. Wel is het de bedoeling dat de pijlen die verbonden zijn met de functie
verbonden blijven. De app zal zonodig de pijlen aanpassen.
Een functiebeschrijving in tekst zal voor sommige functies ook mogelijk zijn. Voor een
functie blok of „control acties‟ zal deze tekst altijd gecentreerd in de functie leesbaar zijn.
De andere functies hebben door de specifieke afbeelding geen extra omschrijving nodig.
Als de tekst niet past kan de gebruiker kiezen om de functie groter te maken of de
beschrijving in te korten.
§ 2.4 Navigatie door het systeem.
De gebruiker moet zonder problemen en intuïtief door het getekende systeem kunnen
navigeren. De app moet daarom (enigszins) in staat zijn om de consistentie van het
systeem te waarborgen. Dit houdt in dat de app zorg draagt dat het openmaken van een
functie resulteert in binnenkomende en uitgaande pijlen die overeenkomen met de
opengemaakte versie van die functie. Vervolgens moeten wijzigingen aan de binnenkant
van de functie ook aan de buitenkant toegepast worden.
§ 2.5 Opslaan van het systeem.
Hoog in het vaandel van de principes uit Bron 3 staat dat de gebruiker zich geen zorgen
hoeft te maken over het opslaan van wijzigingen. In de app zal dit betekenen dat alle
wijzigingen altijd direct worden opgeslagen door de app. Het enige wat de gebruiker kan
doen is het maken van een nieuw systeem. Hierbij moet het in ieder geval mogelijk zijn
om bestaand project te kopiëren om zo gemakkelijk IST, SOLL en andere varianten te
kunnen maken.
H3. Programmeer principes
Binnen de faculteit 3mE is er beperkt aandacht voor het ontwerpen en programmeren van
applicaties. Het programmeren van applicaties voor de iOS omgeving wordt vanuit Apple
en andere websites goed ondersteund. Om toch een onderbouwde systematiek te
gebruikten voor het programmeren zal de app gebruik maken van het “Model, view,
controller structuur” (MVC).
Hoewel MVC breed geaccepteerd is zijn er toch veel verschillende vormen. De app zal in
grote lijnen de principes gebruiken zoals onderwezen in het open vak “CS 193P: iPhone
Application Development” van Stanford University (Bron 4). Hierbij wordt MVC toegepast
i.c.m. object georiënteerd programmeren specifiek voor het iOS platform. Binnen dit vak
worden voor MVC de volgende normen gehandhaafd:
Voor een model geldt dat het inhoud wat je applicatie is en niet hoe het wordt
weergegeven. Een model kan wel berekeningen en acties uitvoeren, als het maar
onafhankelijk blijft van de interface.
De controller is verantwoordelijk voor de vertaling van het model naar het scherm,
hiervoor geeft hij de view instructies.
De view voert de opdrachten van de controller uit en heeft nooit direct contact met
het model.
De controller specificeert bij de view hoe deze mag communiceren met de
controller.
De programeer omgeving is Xcode, deze omgeving wordt gratis aangeboden door Apple.
De gebruikte programmeer taal is „Objective-C‟, dit is een strikte superset van „C‟. Verder
wordt het gebruik van een „storyboard‟ aanbevolen omdat dit ook als een soort van
documentatie kan worden gezien. De mogelijkheden om dit te doen zijn gering doordat de
gebruiker zijn eigen systeem gaat maken en er dus niet een vast patroon is.
De opslag van de gemaakte systemen zal worden gedaan met behulp van het SQLite
framework. SQLite wordt door bijna alle besturingsystemen ondersteunt en dit houdt de
mogelijkheid open voor DSA applicaties op andere besturingsystemen.
H4. Object ‘Classes’
Voor de app zijn een aantal classes ontworpen. Zoals in H3. Programmeer principes is
beschreven wordt in de app gebruik gemaakt van het „model, view, controller‟ principe. De
ontworpen classes kunnen dus worden ingedeeld in modellen, controllers, views en utility
classes. In de eerste paragraaf worden eerst een aantal begrippen die gebruikelijk zijn bij
het programmeren in objective-C toegelicht.
§ 4.1 inleiding objective-C
Classes
Bij object georiënteerd programmeren in obj-C wordt gebruik gemaakt van „classes‟. Een
class wordt in objective-C beschreven met een „header file‟ (.h) en een „implementation
file‟ (.m). Hierbij is het gebruikelijk dat andere classes alleen gebruik maken van de
functies en mogelijkheden die in de „header file‟ van die „class‟ beschreven zijn. In de
praktijk betekend dit dat de implementatie en eventuele niet beschreven functies in die
implementatie alleen gebruikt worden om de publieke mogelijkheden beschreven in de
„header‟ mogelijk te maken.
Methods
Verder wordt er expliciet onderscheid gemaakt tussen „instance methods‟ en „class
methods‟. Dit onderscheid wordt aangegeven met een „-„ voor in „instance method‟ en een
„+‟ voor een „class method‟. Over het algemeen zal het meest gebruik gemaakt worden
van „instance methods„ omdat hiermee de voordelen van object georiënteerd
programmeren volledig gebruikt worden. „Class methods‟ worden in de praktijk bijna
alleen gebruikt bij het maken van een nieuw object van een „class‟. Het verschil tussen de
twee soorten „methods‟ is dat een „instance method‟ een opdracht is voor een
geïnitialiseerd object en een „class method‟ een opdracht is voor de „class‟. Een class
method heeft daardoor ook geen actuele gegevens anders dan een eventuele input
parameter van de opdracht.
Protocols
Verder geeft objective-C de mogelijkheid om een protocol te declareren. Dit houdt vaak in
dat een bepaald object A van een „class‟ een verwijzing krijgt naar een object B. Object B
is dan in staat is om de opdrachten uit het protocol van object A te verwerken en
beantwoorden. Het protocol wordt dan gebruikt om in dit geval object A geen kennis van
zijn omgeving te hoeven geven. Hierdoor kan de „class‟ waar object A toe behoort veel
breder inzetbaar zijn en kan een gebruiker van die „class‟ (object B) het gedrag van object
A finetunen.
ARC
Om memory management makkelijker te maken maakt objective-C gebruik van „Automatic
Reference Counting‟ (ARC). ARC houdt in dat bijgehouden wordt welke objecten
verwijzingen hebben naar een object. Als ARC geen verwijzing naar een object vind dan
wordt dit object uit het geheugen gehaald. Om hier extra flexibiliteit in te bouwen wordt
er onderscheid gemaakt tussen verschillende soorten verwijzingen. Alleen een verwijzing
van het type „strong‟ wordt meegeteld door ARC. Dit maakt het mogelijk voor objecten om
naar elkaar te verwijzen zonder een object te creëren dat nooit verdwijnt. Door
bijvoorbeeld object A een „strong‟ verwijzing te geven naar object B en object B een ander
type verwijzing (bijv. „weak‟) naar A te geven blijft object B bestaan zolang object A
bestaat. Op het moment at object A niet meer gebruikt wordt worden beide objecten uit
het geheugen verwijderd. Hierdoor is het gebruikelijk om alleen een hoofdgebruiker van
een object een sterke verwijzing te geven naar een object.
Value, Objecten en Pointers.
Binnen objective-C bestaat onderscheid tussen value‟s en objecten . In de syntax wordt dit
onderscheid duidelijk gemaakt door het gebruik van een „
‟ voor pointers naar een object,
de enige uitzondering hierbij is „id‟. „Id‟ wordt gebruikt als indicatie dat het om een pointer
naar een object gaat waarbij geen restricties zijn voor het type object. Een „Value‟ of in
het Nederlands een waarde is wat de naam suggereert, een variabele die bijvoorbeeld een
de waarde van een getal onthoud.
In de praktijk worden deze subtiele verschillen vooral merkbaar bij het vergelijken van
waardes en objecten. In het geval van waardes worden de waardes direct vergeleken dus
integer A met waarde 5 en integer B met waarde 4 geven in een vergelijking aan
verschillend te zijn. Bij het vergelijken van (pointers naar) objecten wordt vergeleken of ze
naar het zelfde object wijzen. Een vergelijking van bijvoorbeeld NSNumber C met waarde
5 en NSNumber D met waarde 5 zal dus aangeven dat ze niet gelijk zijn. Om de waardes
van C en D te vergelijken kunnen instance methods van C en/of D worden gebruikt.
§4.2 ‘Model Classes’
§4.2.1 ‘Functie model Class’
De „DSAFunction class‟ is de klasse die invulling geeft aan het model gedeelte behorende
bij een DSA functie of systeem. In de app heeft het functiemodel de taak om bij te
houden welke pijlen horen bij deze functie. Het functiemodel maakt dus gebruik van het
model voor pijlen beschreven in §4.2.2 „Arrow model Class‟. Het functie model heeft een
aantal mogelijke types die overeenkomen met de verschillende functie elementen
beschreven in H1. Systeemkundige mogelijkheden van de app. Extra is toegevoegd dat de
functie ook een systeem kan zijn, dit houdt in dat dit de functie is die is opengemaakt.
De belangrijkste taken van een object van de DSAFunction klasse zijn:
Pijlen controleren en op de juiste manier aanpassen om aan te sluiten.
Het onthouden van de beschrijving van de functie.
Het onthouden van de aggregatie niveau van de functie in het systeem.
Het aanpassen van de plaats en groote in het huidige aggregatie niveau en daarbij
aanpassingen ook toepassen op verbonden pijlen.
Consistentie garanderen tussen verwante functies op andere aggregatie niveau‟s
tijdens in- en uitzoomen.
Het onthouden en verstrekken van gegevens om weergave en manipulatie door een
controller mogelijk te maken.
Zichzelf omschrijven als een regel tekst en zich vanuit die tekst herstellen.
De volledige code voor de DSAFunction klasse is gegeven in Bijlage 1 DSAFunction.h en
Bijlage 26 DSAFunction.m
§4.2.2 ‘Arrow model Class’
De „DSAArrow class‟ is de klasse die invulling geeft aan het model gedeelte behorende bij
een pijl. Hiervoor maakt de pijl gebruikt van een stijl object beschreven in §4.2.3
„ArrowStyle model Class‟ en van punt objecten beschreven in §4.2.4 „PointObject model
Class‟. In principe is een pijl object niet meer dan rij met punt objecten en een
bijbehorende omschrijving.
De belangrijkste taken van een object van de DSAArrow klasse zijn:
Het onthouden van de punten die loop van de pijl beschrijven.
Het onthouden van de beschrijving van de pijl en de locatie van de beschrijving.
Het mogelijk maken om de pijl te bewerken met een zeer beperkte kennis van de
omgeving.
Het kloppend houden van de pijl.
Het aanpassen van zijn stijl object om te matchen met andere pijlen.
Het onthouden van welke pijlen opvolgend zijn.
Het onthouden en verstrekken van gegevens om weergave en manipulatie door een
controller mogelijk te maken.
Zichzelf omschrijven als een regel tekst en zich vanuit die tekst herstellen.
De volledige code voor de DSAArrow klasse is gegeven in Bijlage 2 DSAArrow.h en Bijlage
27 DSAArrow.m
§4.2.3 ‘ArrowStyle model Class’
De „DSAArrowStyle class‟ is de klasse die wordt gebruikt om de stijl van pijlen te
omschrijven. Een stijl bestaat uit een aantal lijnen en een kleur per lijn. Daarbij is
vastgelegd hoe dik een lijn moet zijn, welke kleur die heeft en hoe dik de totale pijl is. De
standaart informatie stijl bijvoorbeeld, bestaat uit 2 lijnen van elk 2 punten dik, alle lijnen
zijn zwart en de totale dikte van de pijl is 4.
De belangrijkste taken van een object van de DSAArrowStyle klasse zijn:
Het onthouden en verstrekken van gegevens om weergave door een controller
mogelijk te maken.
Het uitvoeren van aanpassingen om een vergelijkbare stijl te krijgen aan een
andere stijl
Het veranderen van stijl.
Het uitvoeren van aanpassingen aan de totale grote om te passen bij een andere
stijl.
Bepalen of de stijl vergelijkbaar is met een andere stijl.
Zichzelf omschrijven als een regel tekst en zich vanuit die tekst herstellen.
Hierbij wordt een vergelijkbare stijl gezien als een stijl met dezelfde hoeveelheid lijnen
met dezelfde kleur per lijn. De totale hoogte is hierbij niet meegenomen.
De volledige code voor de DSAArrowStyle klasse is gegeven in Bijlage 3 DSAArrowStyle.h
en Bijlage 28 DSAArrowStyle.m
§4.2.4 ‘PointObject model Class’
De „PointObject class‟ geeft een object dat een x- en een y-coördinaat onthoud. Daarbij
kan het zichzelf „verplaatsen‟, omschrijven met tekst en met die tekst kan de klasse een
nieuw object maken met de juiste coördinaten.
De noodzaak voor deze klasse is niet direct duidelijk aangezien een CGPoint veel
vergelijkbare mogelijkheden biedt. Het probleem van het CGPoint is dat het geen object is
en daarom niet in een NSArray geplaatst kan worden. In combinatie met de voordelen van
de mogelijkheid om het verplaatsen en omvormen naar tekst toe te voegen is toch
gekozen deze klasse te ontwerpen.
De volledige code voor de pointObject klasse is gegeven in Bijlage 4 PointObject.h en
Bijlage 29 PointObject.m
§4.2.5 ‘DSADataLoader model Class’
De „DSADataLoader class‟ zorgt voor de opslag en het laden van de functie en pijl
modellen in een SQLite database van een project. In principe wordt een DataLoader
object gebruikt voor één project, dit project wordt geopend of aangemaakt bij het
initialiseren van een DataLoader object.
De belangrijkste taken van een object van de DSADataLoader klasse zijn:
Het laden en opslaan van pijlen en functie modellen in een SQLite database.
Het kopiëren, wijzigen, verwijderen en aanmaken van nieuwe projectbestanden.
Vragen van gebruikers beantwoorden m.b.t. het gehele project, bijvoorbeeld of een
bepaalde stijl voor pijlen al in gebruik is.
Vragen van gebruikers beantwoorde m.b.t. andere projecten.
De volledige code voor de DSADataLoader klasse is gegeven in Bijlage 5 DSADataLoader.h
en Bijlage 30 DSADataLoader.m
§4.3 ‘Controller Classes’
§4.3.1 ‘DSASystemViewController’
De DSASystemViewController klasse is de top level controller en maakt gebruik van de
andere view controllers beschreven in de rest van §4.3 „Controller Classes‟. Om berichten
te ontvangen wordt een groot aantal protocollen geïmplementeerd. Het model van deze
controller is een functie model beschreven in §4.2.1 „Functie model Class‟ van het type
„systeem model‟. Om dit model te bemachtigen en wijzigingen in het model op te slaan
wordt gebruik gemaakt van een §4.2.5 „DSADataLoader model Class‟ object. Bij het laden
van de app wordt het laatst gebruikte project geopend op het laatst gebruikte
aggregatieniveau. Deze gegevens worden opgeslagen in en opgevraagd uit de standaard
„user defaults‟.
De belangrijkste taken van een object van de DSASystemViewController klasse zijn:
Het laden van het model.
Het laden en reageren op acties in de menubalk.
Wijzigingen in onderdelen van het model doorgeven aan de gerelateerde controllers
en opslaan in het project bestand.
Het reageren op het roteren van de iPad.
Navigeren door het project mogelijk maken.
Het beheren van de „stapel‟ views die op het scherm staan. De
systemViewController zorgt dat een pijl of een functie die wordt aangepast naar
boven wordt geplaatst.
Het toevoegen van nieuwe pijlen of functies.
Het herstellen van de laatste situatie op het scherm na een onderbreking in het
gebruik van de app.
De volledige code voor de DSASystemViewController klasse is gegeven in Bijlage 6
DSASystemViewController.h en Bijlage 31 DSASystemViewController.m
§4.3.2 ‘DSAFunctionViewController’
De DSAFunctionViewController klasse is de klasse die een grafische weergave van een
functie verzorgt en een groot deel van de aanpassingen doorvoert. Doormiddel van een
aantal gedelegeerde methodes kan deze view controller bepaalde berichten doorgeven
aan de „system view controller‟. Hierdoor kan deze „system view controller‟ controleren of
er nu pijlen verbonden moeten worden en de reeds verbonden pijlen krijgen dan bericht
om de aanpassingen op het scherm weer te geven. De belangrijkste taken van een object
van de DSAFunctionViewController klasse zijn:
Het grafisch weergeven van een functie op het scherm.
Het reageren op acties in de menubalk.
Wijzigingen of andere gebeurtenissen doorgeven aan de „systemViewController‟.
Het bijhouden en verwerken van „touch‟ input via het scherm.
Het juiste type functieView gebruiken.
De volledige code voor de DSAFunctionViewController klasse is gegeven in Bijlage 7
DSAFunctionViewContoller.h en Bijlage 32 DSAFunctionViewContoller.m
§4.3.3 ‘DSAArrowViewController’
De DSAArrowViewController klasse is de klasse die een grafische weergave van een pijl
verzorgt en een groot deel van de aanpassingen doorvoert naar het model. Doormiddel
van een aantal gedelegeerde methodes kan deze view controller bepaalde berichten
doorgeven aan de „system view controller‟. Hierdoor kan deze „system view controller‟
controleren of de pijl verbonden moeten worden met een functie. De belangrijkste taken
van een object van de DSAArrowViewController klasse zijn:
Het grafisch weergeven van een pijl op het scherm.
Het reageren op acties in de menubalk.
Wijzigingen of andere gebeurtenissen doorgeven aan de „systemViewController‟.
Het bijhouden en verwerken van „touch‟ input via het scherm.
Het vergroten en verkleinen van het aanraak gevoelige oppervlak van de pijl. Bij
inzoomen blijft die oppervlakte in absolute zin gelijk waardoor het gemakkelijker
wordt het gewenste deel te raken.
Het tekenen van de verschillende delen van de pijl in de verschillende segmenten.
De volledige code voor de DSAArrowViewController klasse is gegeven in Bijlage 8
DSAArrowViewController.h en Bijlage 33 DSAArrowViewController.m
§4.3.4 ‘DSAProjectTableViewController’
De DSAProjectTableViewController klasse is de klasse die een lijst met beschikbare
projecten weergeeft. Vervolgens kan de gebruiker kiezen of hij een project grafisch wil
openen of in een lijst wil weergeven. Verder kunnen regels in deze lijst gekopieerd worden
om zo een kopie te maken van het project. In de app wordt deze aangestuurd door de
system view controller. De communicatie terug houdt staat vast in het bijbehorende
protocol. De belangrijkste taken van een object van de DSAProjectTableViewController
klasse zijn:
Een gekozen project doorgeven aan de „systemViewController‟.
Het aanmaken van nieuwe projecten.
Het kopiëren van bestaande projecten.
Het initiëren van een „system navigator‟.
Gekopieerde systemen, dus niet bestanden maar een DSAFunction instance
doorgeven tussen verschillende „systeem navigator‟s‟
De volledige code voor de DSAProjectTableViewController klasse is gegeven in Bijlage 9
DSAProjectTableViewController.h en Bijlage 34 DSAProjectTableViewController.m
§4.3.5 ‘DSASystemPrinter’
De DSASystemPrinter klasse behoort wel tot de controllers, maar de view‟s zijn vervangen
met een PDF context. Het model van deze controller is een volledig systeem model dat
wordt geladen met een DSADataLoader. Deze DSASystemPrinter werkt bijna volledig op
een achtergrond thread waardoor de gebruiker gewoon kan blijven werken. Gebruikers
van deze klasse kunnen gebruik maken van het protocol en zichzelf als „delegate‟
aangeven om bericht te krijgen wanneer de pdf klaar is. Om geen conflicten te krijgen
met andere DataLoaders die in hetzelfde project werken wordt een kopie aangemaakt en
na het printen weer verwijderd. Om de weergave van deze kopie in de projectenlijst te
voorkomen kunnen gebruikers de naam van de kopie opvragen.
De belangrijkste taken van een object van de DSASystemPrinter klasse zijn:
Het volledig laden van het systeem in een project bestand
Het creëren van een PDF bestand
Het systeem tekenen in het PDF bestand
PDF-links in het bestand maken zodat een gebruiker in het PDF bestand kan
navigeren.
Het bieden van verschillende instellingen voor de gemaakte PDF bestanden
In de rapport stijl PDF worden de uitgebreide beschrijvingen van functies ook in het
PDF bestand geplaatst.
De „delegate‟ bericht geven.
De volledige code voor de DSASystemPrinter klasse is gegeven in Bijlage 10
DSASystemPrinter.h en Bijlage 35 DSASystemPrinter.m
§4.3.6 ‘DSASystemNavigationViewController’
De DSASystemNavigatonViewController klasse is een subclass van een standaard
UITableViewController. Het „model‟ is weer een DSAFunction instance maar nu wordt deze
weergegeven in een lijst. Om functies in die lijst weer te geven wordt gebruik gemaakt
van een DSATableViewCell. Het wijzigen van de locatie van pijlen en functies is niet
mogelijk, maar de beschrijvingen kunnen wel worden gewijzigd. Ook kunnen onderdelen
gekopieerd en geplakt worden. Om dit mogelijk te maken zorgt een „system navigator‟ dat
het volledige systeem wordt geladen. Het op deze manier mogelijk maken van kopiëren en
plakken maakt het mogelijk om met gemak bijvoorbeeld een volledig steady-state model
te plakken.
De „system navigator‟ maakt gebruik van de DSAFunctionDetailViewController klasse om
wijzigingen aan functies te maken en de DSASystemPrinter klasse om de gebruiker PDF
bestanden te laten exporteren.
De belangrijkste taken van een object van de DSASystemNavigationController klasse zijn:
Het kopieren en plakken van delen van het systeem
De gebruiker verschillende manieren geven om het systeem met andere te delen.
Er is een mogelijkheid om de database bestanden met andere te delen of het
systeem te exporteren als PDF bestand. Daarbij bestaat de optie om de bestanden
naar iemand te mailen of het bestand in een andere app te openen.
De gebruiker de mogelijkheid bieden om sneller te navigeren in een systeem en op
de gewenste locatie te openen.
Het weergeven van verschillende instellingen voor de gemaakte PDF bestanden.
De „delegate‟ bericht geven over de geselecteerde locatie in een bepaald project. In
de app worden deze berichten via de „ProjectController‟ doorgegeven aan de
„System View Controller‟.
De volledige code voor de DSASystemNavigationController klasse is gegeven in Bijlage 11
DSASystemNavigationViewController.h en Bijlage 36
DSASystemNavigationViewController.m
§4.3.7 ‘DSAFunctionDetailViewController’
De DSAFunctionDetailViewController klasse is waarmee de details van een functie in een
tabel worden weergegeven en aangepast. Deze klasse is een subclass van een
UITableViewController en maakt gebruik van een „delegate‟ die verantwoordelijk is voor
het opslaan van eventuele wijzigingen. In de app wordt deze klasse gebruikt door de
„system controller‟ „system navigator‟ en „function controller‟.
De belangrijkste taken van een object van de DSAFunctionDetailViewController klasse zijn:
Het weergeven van de functie en de verschillende eigenschappen.
Het mogelijk maken het type van de functie aan te passen.
De beschrijving en uitgebreide beschrijving laten aanpassen door de gebruiker.
De gebruiker laten instellen of de uitgebreide beschrijving moet worden toegevoegd
aan het rapport.
De „delegate‟ bericht geven over wijzigingen, de „delegate‟ is datn verantwoordelijk
voor het opslaan van die wijzigingen.
De volledige code voor de DSAFunctionDetailViewController klasse is gegeven in Bijlage 12
DSAFunctionDetailViewController.h en Bijlage 37 DSAFunctionDetailViewController.m
§4.4 ‘View Classes’
§4.4.1 ‘Function View’s’
De function views zijn de verschillende view‟s die samen allemaal subclasses zijn van de
DSAFunctionView. Het zijn view‟s die op basis van hun eigen grootte de weergave voor
hun type functie tekenen. Ze worden gebruikt door de „function controller‟, de „function
detail controller‟ en de DSATableViewCell. Deze gebruikers zorgen zelf dat ze het geschikte
type kiezen voor de verschillende soorten type functies.
Hoe de verschillende types de view tekenen is te lezen in de volledige code beschikbaar in
de implementation (.m) bestanden. Deze zijn gegeven in de bijlages.
Subclasses en bijlages:
Bijlage 13 DSAFunctionView.h en Bijlage 38 DSAFunctionView.m
Bijlage 14 DSARectangleView.h en Bijlage 39 DSARectangleView.m
Bijlage 15 DSASplitterView.h en Bijlage 40 DSASplitterView.m
Bijlage 16 DSATapView.h en Bijlage 41 DSATapView.m
Bijlage 17 DSAFilterView.h en Bijlage 42 DSAFilterView.m
Bijlage 18 DSAaddTheMissingFilterView.h en Bijlage 43 DSAaddTheMissingFilterView.m
Bijlage 19 DSABufferView.h en Bijlage 44 DSABufferView.m
Bijlage 20 DSAGlobalInterventionView.h en Bijlage 45 DSAGlobalInterventionView.m
Bijlage 21 DSAGlobalMeasurementView.h en Bijlage 46 DSAGlobalMeasurementView.m
Bijlage 22 DSASpecificTaskView.h en Bijlage 47 DSASpecificTaskView.m
§4.4.2 ‘Arrow View’s’
De arrow views zijn de views die gebruikt worden om de pijlen mee weer te geven. Het
zijn custom views die een „delegate‟ vragen om zich te tekenen. Ze worden gebruikt door
„arrow controllers‟ en de „systeem controller‟. Voor de app zijn ze vooral nodig omdat het
registreren van bewegingen op het scherm wordt uitgevoerd op een view. Hierdoor
kunnen de verschillende delen van de pijlen per deel worden bewogen. De „arrow
controller‟ kan vervolgens achterhalen welk deel dat was en zo het juiste deel van het
„arrow model‟ aanpassen.
Een alternatief voor deze constructie zou kunnen zijn dat de „arrow controller‟ bij elke
aanraking afhankelijk van de locatie van aanraking bepaald welk deel aangepast moet
worden. Het nadeel hiervan is dat het waarschijnlijk minder leesbare code oplevert en bij
wijzigingen de volledige pijl steeds opnieuw moet worden getekend. Nu moeten bij het
verplaatsen van een deel van de pijl alleen de aangrenzende delen opnieuw worden
getekend.
Bijlages:
Bijlage 23 DSAPointView.h en Bijlage 48 DSAPointView.m
§4.4.3 ‘DSATableViewCell’
De DSATableViewCell klasse is een subclass van een UITableViewCell en kan worden
gebruikt in een UITableView of een subclass daarvan. De klasse is gemaakt om met een
DSAFunction instance een specifieke cell te maken. Een instance van een
DSATableViewCell kan zichzelf aanpassen maar doordat de verschillende onderdelen in de
header staan vermeld kan een gebruiker deze ook zelf aanpassen. In de app wordt deze
cell gebruikt door de „system navigator‟ om niet alleen het type functie te kunnen
weergeven maak ook de beschrijving.
De volledige code voor de DSATableViewCell is gegeven in Bijlage 25 DSATableViewCell.h
en Bijlage 50 DSATableViewCell.m
§4.4.4 ‘Storyboard View’s’
Binnen xCode bestaat de mogelijkheden om grafische verschillende view‟s in te richten.
Deze grafische omgeving wordt onderdeel van de app en is opgeslagen in een storyboard
bestand. Verschillende view(controller)‟s kunnen dan via bepaalde overgangen of via een
naam geïnitieerd worden. De meeste beschreven viewcontrollers in de app maken gebruik
van grafisch opgebouwde view‟s. Ook zijn voor een aantal tableView‟s weer specifieke
cellen aangemaakt die worden geïnitieerd via hun „reuse identifier‟.
De verschillende afbeeldingen zijn gegeven in de bijlages:
Bijlage 51 view voor „System controller‟
Bijlage 52 view voor „Nieuwe functie keuze‟
Bijlage 53 view voor 'Function Details'
Bijlage 54 view voor 'Nieuwe pijl keuze'
Bijlage 55 view voor 'Project tabel'
Bijlage 56 view voor 'Systeem navigator'
Bijlage 57 view voor 'Export keuze'
Literatuurlijst
Bron 1: Veeke H.P.M., Ottjes J.A, Lodewijks G. (2008) ; “The Delft Systems Approach,
Analysis and Design of Industrial Systems”; Springer, London.
Bron 2: Veld in 't J. (2002); “Analyse van organisatieproblemen, een toepassing van
denken in systemen en processen”; Wolters-Noordhof, Groningen, 8
stedruk.
Bron 3: iOS Human Interface Guidelines, Apple Inc.,
http://developer.apple.com/library/ios/ -
documentation/UserExperience/Conceptual/MobileHIG/Introduction/Introduction.html
Bron 4: CS 193P iPhone Application Development, Stanford University, Prof. P. Hegarty,
Fall 2011.
Bijlagen
Bijlage 1 DSAFunction.h ... 28 Bijlage 2 DSAArrow.h ... 30 Bijlage 3 DSAArrowStyle.h ... 31 Bijlage 4 PointObject.h ... 32 Bijlage 5 DSADataLoader.h ... 33 Bijlage 6 DSASystemViewController.h ... 34 Bijlage 7 DSAFunctionViewContoller.h ... 35 Bijlage 8 DSAArrowViewController.h ... 36 Bijlage 9 DSAProjectTableViewController.h ... 37 Bijlage 10 DSASystemPrinter.h ... 38 Bijlage 11 DSASystemNavigationViewController.h ... 39 Bijlage 12 DSAFunctionDetailViewController.h ... 40 Bijlage 13 DSAFunctionView.h ... 41 Bijlage 14 DSARectangleView.h ... 41 Bijlage 15 DSASplitterView.h ... 41 Bijlage 16 DSATapView.h ... 42 Bijlage 17 DSAFilterView.h ... 42 Bijlage 18 DSAaddTheMissingFilterView.h ... 42 Bijlage 19 DSABufferView.h ... 42 Bijlage 20 DSAGlobalInterventionView.h ... 42 Bijlage 21 DSAGlobalMeasurementView.h ... 43 Bijlage 22 DSASpecificTaskView.h ... 43 Bijlage 23 DSAPointView.h ... 44 Bijlage 24 DSAArrowSegmentView.h ... 44 Bijlage 25 DSATableViewCell.h ... 45 Bijlage 26 DSAFunction.m ... 46 Bijlage 27 DSAArrow.m ... 78 Bijlage 28 DSAArrowStyle.m ... 89 Bijlage 29 PointObject.m ... 95 Bijlage 30 DSADataLoader.m ... 96 Bijlage 31 DSASystemViewController.m ... 111 Bijlage 32 DSAFunctionViewContoller.m ... 141 Bijlage 33 DSAArrowViewController.m ... 156 Bijlage 34 DSAProjectTableViewController.m ... 177 Bijlage 35 DSASystemPrinter.m ... 183 Bijlage 36 DSASystemNavigationViewController.m ... 203 Bijlage 37 DSAFunctionDetailViewController.m ... 217 Bijlage 38 DSAFunctionView.m ... 222 Bijlage 39 DSARectangleView.m ... 223 Bijlage 40 DSASplitterView.m ... 224 Bijlage 41 DSATapView.m ... 225 Bijlage 42 DSAFilterView.m ... 225 Bijlage 43 DSAaddTheMissingFilterView.m ... 228 Bijlage 44 DSABufferView.m ... 230 Bijlage 45 DSAGlobalInterventionView.m ... 231 Bijlage 46 DSAGlobalMeasurementView.m ... 235 Bijlage 47 DSASpecificTaskView.m ... 238 Bijlage 48 DSAPointView.m ... 238 Bijlage 49 DSAArrowSegmentView.m ... 239 Bijlage 50 DSATableViewCell.m ... 241 Bijlage 51 view voor ‘System controller’ ... 246 Bijlage 52 view voor ‘Nieuwe functie keuze’ ... 247 Bijlage 53 view voor 'Function Details' ... 248 Bijlage 54 view voor 'Nieuwe pijl keuze' ... 249 Bijlage 55 view voor 'Project tabel' ... 250 Bijlage 56 view voor 'Systeem navigator' ... 251 Bijlage 57 view voor 'Export keuze' ... 252Header files
Models
Bijlage 1 DSAFunction.h
// DSAFunction.h // DSAeditor //// Created by Sebastiaan Koppenaal on 25/10/12.
// Copyright (c) 2012 Sebastiaan Koppenaal. All rights reserved. //
#import <Foundation/Foundation.h>
#import "DSAArrow.h"
typedef NS_ENUM(int, DSA_Function_Type) { DSA_System_Function = 0, DSA_Standart_Function = 1, DSA_Filter = 2, DSA_Buffer = 3, DSA_Tap= 4, DSA_Task = 5, DSA_Add_The_Missing_Filter = 6, DSA_PROPER_function = 7, DSA_Splitter_function = 8 };
typedef NS_ENUM(int, DSA_Function_Edge) { DSA_Function_LeftEdge = 0, DSA_Function_TopEdge = 1, DSA_Function_RightEdge = 2, DSA_Function_BottomEdge = 3, DSA_Function_NoEdge = 4 };
@interface DSAFunction : NSObject
@property (strong, nonatomic) NSString *systemLocation; @property (weak, nonatomic) DSAFunction *parentFunction; @property (strong, nonatomic) NSString *description; @property (strong, nonatomic) NSString *fullDescription; @property (nonatomic) BOOL addFullDescriptionToPDFReport; -(DSA_Function_Edge)calculateEdgeForArrow:(DSAArrow *)arrow; -(int)subfunctionNumber;
-(DSA_Function_Type)functionType;
-(void)setFunctionType:(DSA_Function_Type)functionType; -(NSArray *)subFunctions;
-(void)addSubFunction:(DSAFunction *)subFunction; -(NSArray *)inputArrows; -(NSArray *)outputArrows; -(NSArray *)requirementArrows; -(NSArray *)resultArrows; -(NSArray *)unconnectedArrows; -(NSArray *)connectedArrows;
-(void)removeArrow:(DSAArrow *)arrow;
-(void)removeSubFunction:(DSAFunction *)function; -(void)moveArrowToConnectedArrows:(DSAArrow *)arrow; -(void)moveArrowToUnconnectedArrows:(DSAArrow *)arrow;
-(NSArray *)allArrows;
-(NSArray *)allArrowsExluding:(NSArray *)arrowArray; -(NSArray *)allInternalArrows;
-(NSArray *)allInternalArrowsExluding:(NSArray *)arrowArray; -(CGRect)blackbox;
-(void)setBlackbox:(CGRect)blackbox;
-(void)moveFunctionWith:(CGPoint)translation; -(NSString *)stringForFunction;
-(NSString *)stringForParentSystemLocation;
-(void)addArrow:(DSAArrow *)arrow; // if the arrow is connected it will added, but it will not be modified.
-(BOOL)checkArrowForConnection:(DSAArrow *)arrow; //returns YES if there is a connection and apply adjustments to style and form.
-(BOOL)isFunctionInsideYourBlackbox:(DSAFunction *)potentialInsideFunction; -(DSAFunction *)newSubfunction;
-(NSArray *)conformToFunction:(DSAFunction *)function withMaxArrowID:(int)maxArrowID; // the reciever returns its existing arrows that were not matching to any arrows in the argument function. The function did not remove these! maxArrowID needs to be provided to properly setup newly created arrows.
+(DSAFunction *)createFunctionFromString:(NSString *)functionString; +(DSAFunction *)newStandartFunction;
+(DSAFunction *)newSystemFunction; @end
Bijlage 2 DSAArrow.h
// DSAArrow.h// DSAeditor
// Created by Sebastiaan Koppenaal on 5/10/12.
// Copyright (c) 2012 Sebastiaan Koppenaal. All rights reserved.
#import <Foundation/Foundation.h> #import "DSAArrowStyle.h"
#import "PointObject.h"
@interface DSAArrow : NSObject
@property (strong, nonatomic) NSArray *path; //array of pointobjects ordered to create the path for the arrow.
@property (strong, nonatomic) DSAArrowStyle* style; @property (strong, nonatomic) NSString *description; @property (nonatomic) int uniqueIndentifier;
@property (nonatomic) int nextArrowInSystemID;
@property (nonatomic) int nextArrowForOtherAggregationLevelID;
-(int)snapDistance; // the length for a segment at wich it will be removed to create a straight arrow. -(void)addPointToPath:(CGPoint)newPoint at:(int)index;
-(void)movePoint:(int)index with:(CGPoint)translation; -(void)moveSegment:(int)index with:(CGPoint)translation; -(void)moveArrowWith:(CGPoint)translation;
-(void)rotateArrowClockwise;
-(BOOL)isSegmentWithIndexHorizontal:(int)index; -(BOOL)isSegmentWithIndexForward:(int)index; -(CGPoint)arrowTail;
-(BOOL)isTailConnected;
-(void)tailIsConnected:(BOOL)isTailConnected; -(CGPoint)arrowHead;
-(BOOL)isHeadConnected;
-(void)headIsConnected:(BOOL)isHeadConnected; -(CGPoint)pointAt:(int)index;
-(BOOL)isArrowProduct;
-(CGPoint)descriptionOriginPoint;
-(void)updateDescriptionOriginWith:(CGPoint)translation; -(BOOL)cleanUp; //returns wheter or not points where removed -(NSString *)stringForArrow;
-(BOOL)makeArrowFit:(DSAArrow *)arrowToFit; //returns YES if receiver has been modified -(void)increaseArrowHeigthToFit:(DSAArrow *)arrowToFit;
+(DSAArrow *)createNewArrow;
+(DSAArrow *)createArrowWithString:(NSString *)arrowString; +(DSAArrow *)createNewInformationArrow;
Bijlage 3 DSAArrowStyle.h
//// DSAArrowStyle.h // DSAeditor //
// Created by Sebastiaan Koppenaal on 10/10/12.
// Copyright (c) 2012 Sebastiaan Koppenaal. All rights reserved. //
#import <Foundation/Foundation.h> @interface DSAArrowStyle : NSObject
-(UIColor *)colorForLine:(int)lineNumber;
-(void)setColor:(UIColor *)color forLine:(int)lineNumber; -(int)numberOfLines;
-(void)setNumberOfLines:(int)numberOfLines; -(int)totalHeight;
-(void)setTotalHeight:(int)totalHeight; -(int)widthPerLine;
-(void)setWidthPerLine:(int)widthPerLine;
-(void)becomeNextStyle; //multiple color arrows will become monocolor -(BOOL)isEqualToStyle:(DSAArrowStyle *)arrowStyle;
-(void)conformToStyle:(DSAArrowStyle *)arrowStyle; -(BOOL)isArrowProductStyle;
-(NSString *)stringForStyle;
-(NSString *)stringForStyleComparison;
-(BOOL)changeStylesToFit:(DSAArrowStyle *)insideArrow; -(void)increaseStyleHeightToFit:(DSAArrowStyle *)insideArrow; +(DSAArrowStyle *)createNewArrowStyle;
+(DSAArrowStyle *)createNewInformationArrowStyle;
+(DSAArrowStyle *)createArrowStyleWithString:(NSString*)styleString; @end
Bijlage 4 PointObject.h
//// PointObject.h // DSAeditor //
// Created by Sebastiaan Koppenaal on 5/10/12.
// Copyright (c) 2012 Sebastiaan Koppenaal. All rights reserved. //
#import <Foundation/Foundation.h> @interface pointObject : NSObject
+(pointObject *)createPointObjectWith:(CGPoint)point;
+(pointObject *)createPointObjectWithString:(NSString *)string; -(CGPoint)getPoint;
-(void)setPoint:(CGPoint)point;
-(void)updatePointWith:(CGPoint)translation; -(NSString *)stringForPoint; //(x:y)
Bijlage 5 DSADataLoader.h
//// DSADataLoader.h // DSAeditor
//
// Created by Sebastiaan Koppenaal on 10/12/12.
// Copyright (c) 2012 Sebastiaan Koppenaal. All rights reserved. //
#import <Foundation/Foundation.h> #import "DSAArrow.h"
#import "DSAFunction.h" #import "sqlite3.h"
@interface DSADataLoader : NSObject
@property (nonatomic, strong) NSString *projectName; // changing the projectName will edit the name of the associated file.
//loading API
-(DSAFunction *)loadDSAFunctionWithLocation:(NSString *)functionLocation;
-(NSArray *)arrayWithSubFunctionsForFunctionWithIndentifier:(NSString *)functionLocation; //array with DSAFunctions
-(NSArray *)arrayWithArrowsForFunctionWithIndentifier:(NSString *)functionLocation; //array with DSAArrows
//saving API
-(void)saveFunction:(DSAFunction *)function;
-(void)saveArrow:(DSAArrow *)arrow inLocation:(NSString *)arrowLocation; //removing API
-(void)removeFunctionWithIndentifier:(NSString *)functionLocation; -(void)removeArrowWithIndentifier:(int)arrowID;
-(void)deleteProjectWithName:(NSString *)projectName; //File managing API
-(void)copyProjectWithName:(NSString *)projectName; -(NSURL *)url;
+(BOOL)isFileWithURLaDSAProject:(NSURL *)fileURL;
//information API
-(BOOL)isArrowStyleUsed:(DSAArrowStyle *)arrowStyle; -(NSArray *)possibleProjectNames;
-(int)maxArrowID;
//initialiser
-(DSADataLoader *)initWithProjectName:(NSString *)projectName;
-(DSADataLoader *)initWithFileURL:(NSURL *)fileUrl; //will move the file from the URL to the document folder. The resulting projectname will be changed if it was a duplicate project.
