- Definirajte jasnu svrhu i publiku za svaki dijagram i odaberite pravu notaciju (UML, dijagram toka, mrežu) koja odgovara pitanju na koje odgovarate.
- Koristite jednostavne, dosljedne vizualne konvencije za oblike, boje i odnose kako bi hijerarhija, ponašanje i struktura bili očigledni na prvi pogled.
- Primijenite specifična pravila crtanja i rasporeda za dijagrame klasa, dijagrame toka i mrežne dijagrame kako biste sačuvali topologiju i spriječili vizualnu gužvu.
- U automatiziranim mrežnim dijagramima, pažljivo dizajnirajte i poredajte pravila dijagrama (brisanje, proširenje, praćenje, smanjenje, iteracija) kako biste generirali pojednostavljene, ali tačne prikaze.
Dizajniranje sistemskih dijagrama koje ljudi zapravo razumiju mnogo je teže nego što izgleda – posebno u softverskim projektima gdje pokušavate komprimirati hiljade linija koda, više servisa i gomilu zainteresovanih strana u jednu sliku. Kada dijagrami postanu prenaduvani, nekonzistentni ili preopterećeni vizuelnom bukom, oni prestaju biti alat za komunikaciju i pretvaraju se u izvor konfuzije koji usporava timove i skriva stvarne probleme u dizajnu.
Dobra vijest je da postoje vrlo jasna, praktična pravila kojih se možete pridržavati kako biste dijagrame svojih sistema učinili jednostavnim, čitljivim i pouzdanim. kroz cijeli životni ciklus projekta. Kombiniranjem principa iz UML-a, dijagrama toka i pravila mrežnih dijagrama, možete kreirati vizualne prikaze koji funkcioniraju za programere, arhitekte, vlasnike proizvoda i netehničke dionike, a istovremeno biti dovoljno precizni da usmjeravaju implementaciju i rano uoče nedostatke.
Zašto su jasni sistemski dijagrami važni u softverskim projektima
U razvoju softvera, dijagrami su jedan od glavnih mostova između ideja i radnog koda.Oni pomažu programerima da razmišljaju o arhitekturi, omogućavaju netehničkim zainteresovanim stranama da vide kako se stvari uklapaju i otkrivaju skrivene pretpostavke prije nego što postanu skupe greške. Kada taj vizuelni sloj zakaže, timovi se vraćaju dugim sastancima, neusklađenim očekivanjima i „iznenađujućim“ ponašanjima u produkciji.
Zbunjujući dijagrami obično ne uspijevaju iz dva razloga: previše informacija i loša vizualna strukturaProblem nije samo u tome što postoji mnogo elemenata, već i u tome što odnosi, hijerarhije i tokovi nisu kodirani dosljedno. Kutije znače različite stvari na različitim mjestima, stilovi strelica se ponovo koriste s novim značenjima, a raspored ne odražava važnost ili grupiranje. Kao rezultat toga, različiti ljudi tumače isti crtež na različite načine.
Dobro osmišljen dijagram čini ključne elemente i odnose očiglednim na prvi pogledVažne komponente se vizualno ističu, informacije teku u predvidljivom smjeru i postoji jasna razlika između strukturnih odnosa (od čega je napravljeno), tokova ponašanja (šta se dešava prvo, a zatim šta) i detalja implementacije (tipovi podataka, metode, stanja). Ova jasnoća djeluje kao sigurnosna mreža za odluke o dizajnu.
Timovi koji ulažu u jasne dijagrame smanjuju preradu, brže usklađuju očekivanja i lakše uključuju nove članove.Za kompanije koje grade prilagođene aplikacije ili integriraju napredne tehnologije poput usluga u oblaku ili umjetne inteligencije, vizualna komunikacija postaje još važnija, jer broj pokretnih dijelova i zainteresiranih strana brzo raste, dok se tolerancija na nesporazume smanjuje.
Četiri osnovna pravila za lako čitljive sistemske dijagrame
Prvi korak ka boljim dijagramima je biti namjeran: znajte zašto crtate dijagram prije nego što počneteSvaki dijagram sistema treba imati jednu glavnu svrhu: opisivanje strukture, objašnjavanje ponašanja, dokumentiranje implementacije, razjašnjavanje odgovornosti ili slično. Miješanje previše svrha na jednom platnu jedan je od najbržih načina za stvaranje vizualnog haosa.
Pravilo 1: Definišite svrhu i publiku Prije dodavanja prvog oblika. Zapitajte se na koja ključna pitanja dijagram treba da odgovori, ko će ga koristiti i koje odluke treba da podrži. Dijagram koji objašnjava arhitekturu visokog nivoa poslovnim zainteresovanim stranama izgledaće veoma drugačije od onog koji koriste programeri za razmišljanje o odnosima klasa i životnim ciklusima objekata.
Pravilo 2: Održavajte vizuelni jezik jednostavnim i konzistentnimOdaberite mali skup oblika, boja i stilova linija i držite ih se. Koristite koherentnu paletu boja gdje svaka boja ima stabilno značenje (na primjer, komponente okrenute prema korisniku, domenske usluge, infrastruktura, vanjski sistemi). Izbjegavajte dekorativne elemente koji ne nose informacije; oni troše kognitivni propusni opseg bez dodavanja jasnoće.
Pravilo 3: Učinite hijerarhiju i važnost očiglednim kroz rasporedOrganizujte elemente tako da oko prirodno prati glavnu priču sistema: od vrha do dna i slijeva nadesno obično najbolje funkcioniše. Koristite grupisanje, prazan prostor i poravnanje da biste pokazali šta pripada zajedno. Važniji ili centralni koncepti trebaju biti veći, postavljeni na istaknutije pozicije ili vizuelno naglašeni.
Pravilo 4: Dodajte interaktivnost tamo gdje pomaže razumijevanju, a ne tamo gdje izgleda modernoDigitalni alati vam omogućavaju kreiranje slojevitih dijagrama, pa čak i izradu interaktivni grafikoni i dijagramiMožete sažeti detalje, povezati se s dubljim prikazima ili omogućiti klik na elemente kako biste otkrili atribute i kod. Pravilno korišteno, ovo transformira dijagrame iz statičnih postera u žive navigacijske mape vašeg sistema, omogućavajući svakom gledaocu da istražuje svojim tempom.
UML sistemski dijagrami: struktura i ponašanje prikazani vizuelno
Unified Modeling Language (UML) pruža standardni skup notacija za predstavljanje softverskih sistema, njihovu strukturu i njihovo ponašanje. UML dijagrami se široko koriste tokom analize, dizajna i dokumentacije jer komprimiraju složeni kod i odnose u oblik koji različite uloge mogu razumjeti bez ulaženja u implementaciju.
Na opštem nivou, UML dijagrami se dijele u dvije velike porodice: strukturne i bihevioralne.Strukturni dijagrami opisuju statičke gradivne blokove sistema – klase, komponente, pakete, čvorove implementacije i kako su oni povezani. Bihevioralni dijagrami se fokusiraju na ono što se dešava tokom vremena – aktivnosti, interakcije, stanja i slučajeve upotrebe.
Ova razlika je važna radi jasnoće jer miješanje strukturnih i bihevioralnih aspekata u jednom dijagramu brzo postaje zbunjujuće.Dijagram klase koji odgovara na pitanje „Koji su glavni objekti i kako su povezani?“ ne bi trebao pokušavati prikazati potpune tokove izvršavanja. Slično tome, dijagram aktivnosti ili sekvence koji se fokusira na „Šta se dešava i kojim redoslijedom?“ ne bi trebao preopteretiti svaki korak atributima klase i detaljima implementacije.
Selektivno korištenje UML-a – odabir pravog tipa dijagrama za pitanje na koje odgovarate – jedno je od najboljih pravila koje možete usvojiti.Umjesto jednog ogromnog dijagrama koji pokušava prikazati sve, ciljajte na nekoliko malih, fokusiranih dijagrama koji se mogu povezati pomoću alata ili dokumentacije.
Dijagrami klasa: pravila za jasnu objektno orijentisanu strukturu
Dijagrami klasa su vjerovatno najpoznatiji i najčešće korišteni UML dijagrami u objektno orijentisanom dizajnu.Oni opisuju statičku strukturu sistema u smislu klasa, njihovih atributa i operacija, te odnosa među njima (nasljeđivanje, asocijacije, agregacije, kompozicije, zavisnosti, interfejsi i drugo).
Standardni simbol UML klase je pravougaonik podijeljen na najviše tri horizontalna dijela.Gornji dio sadrži naziv klase i uvijek je prisutan. Srednji dio navodi atribute (svojstva, polja) i nije obavezan ako vam je potreban samo prikaz visokog nivoa. Donji dio navodi operacije ili metode, svaku u svom redu, opisujući kako se klasa ponaša ili interaguje s podacima.
Vidljivost članova se izražava malim simbolima ispred imena atributa i metodaZnak plus označava javne članove, znak minus privatne, hash označava zaštićene, tilda pokazuje vidljivost na nivou paketa, a kosa crta može označavati izvedene funkcije. Statički članovi se konvencionalno prikazuju podvučeni. Ovi mali znakovi nose važne informacije o kontroli pristupa, tako da ih treba koristiti dosljedno.
Članovi klase mogu postojati na nivou klasifikatora (statički) ili na nivou instance (po objektu)Razumijevanje te razlike je osnovno objektno orijentisano programiranje, ali dijagrami je čine vizualno eksplicitnom: statički članovi konceptualno pripadaju samoj klasi, dok članovi instance postoje zasebno za svaki kreirani objekt. Dijagrami ne bi trebali previše naglašavati ovu razliku, ali kada je statičko ponašanje važno (na primjer, tvorničke metode ili keš memorije), podvlačenje pojašnjava namjeru.
Osnovni elementi i dodaci u dijagramima klasa
U zavisnosti od konteksta, dijagram klasa može opisivati koncepte domena, softverske komponente koje treba kodirati ili objekte vremena izvršavanja.Kao minimum, svakoj klasi je potrebno ime; atributi i metode se mogu dodavati kako povećavate nivo detalja. Prekomjerna dokumentacija svakog gettera i settera rijetko poboljšava razumijevanje; fokusirajte se na ponašanje koje je važno za dizajn i saradnju.
Pored običnih klasa, UML dijagrami klasa mogu uključivati nekoliko drugih tipova elemenataInterfejsi predstavljaju skupove operacija koje definiraju mogućnosti bez specificiranja implementacije. Paketi grupiraju povezane klasifikatore u imenski prostor višeg nivoa i crtaju se kao pravokutnici s malom karticom. Nabrajanja predstavljaju korisnički definirane skupove imenovanih konstanti.
Signali i tipovi podataka se koriste kada je potrebno modelirati specifične vrste komunikacije ili primitivne vrijednosti.Signali bilježe asinhrone, jednosmjerne poruke koje se razmjenjuju između aktivnih objekata, dok tipovi podataka kodiraju primitivne ili strukturirane vrijednosti koje se pojavljuju u atributima ili potpisima operacija. Njihovo uključivanje samo tamo gdje su bitni pomaže da dijagram ostane čitljiv.
Objekti i artefakti se također mogu pojaviti na ovim dijagramima kada želite prikazati prototipove ili konkretne instance vremena izvođenja.Objekti su instance klasa i mogu se koristiti za ilustraciju primjera konfiguracija; artefakti predstavljaju fizičke elemente poput konfiguracijskih datoteka, izvršnih datoteka, baza podataka ili dokumenata. Korišteni štedljivo, oni povezuju apstraktni dizajn sa stvarnošću implementacije.
Odnosi, multiplicitet i kardinalnost
Moć dijagrama klasa proizilazi iz načina na koji prikazuju odnose između klasa.Generalizacija (nasljeđivanje) se crta kao puna linija sa zatvorenom, šupljom strelicom koja pokazuje od podklase do nadklase; to znači da podklasa nasljeđuje atribute i metode od roditelja, uz eventualno dodavanje ili specijalizaciju ponašanja.
Asocijacije predstavljaju strukturne veze gdje objekti jedne klase znaju o objektima druge klase.Osnovna asocijacija je puna linija, potencijalno s nazivima uloga i multiplicitetom na svakom kraju. Vrijednosti multipliciteta poput 1, 0..1, 0..*, 1..* ili određeni rasponi označavaju koliko se instanci može povezati, što je ključno za rasuđivanje o ograničenjima i kardinalnostima u domenu.
Neke asocijacije su usmjerene: kod jednosmjerne asocijacije, samo jedna klasa je svjesna drugeOvo se često prikazuje otvorenom strelicom koja pokazuje od klase znanja ka klasi znanja. U praksi, ovo bi mogla biti kamera za brzinu koja bilježi vozila, a da vozači nikada nisu svjesni svakog specifičnog primjera uređaja – zavisnost je jednosmjerna.
Agregacija i kompozicija su specijalizirane asocijacije za odnose cjeline i dijelaAgregacija (šuplji dijamant) sugerira labavo vlasništvo gdje dijelovi mogu postojati nezavisno, dok kompozicija (ispunjen dijamant) signalizira snažno vlasništvo i zajednički životni ciklus: kada se cjelina uništi, njeni dijelovi odlaze s njom. Ispravna upotreba ovih elemenata čini očekivanja životnog ciklusa eksplicitnim.
Dijagrami toka i dijagrami toka sistema: vizuelna pravila za procese
Nije svakom sistemskom dijagramu potrebna puna ekspresivnost UML-a; za mnoge procese klasični dijagram toka je najjasnija opcija.Dijagrami toka predstavljaju algoritme, tokove rada ili poslovne procese kao niz grafičkih simbola povezanih strelicama, ističući odluke, akcije i tokove podataka.
Dijagram toka treba da se čita kao priča od vrha do dna i slijeva nadesnoOrganiziranje simbola u tom smjeru pomaže gledaocu da prati logiku bez preskakanja stranice. Kada poštujete ovo pravilo rasporeda, smanjujete mentalni napor potreban za praćenje procesa, posebno za duge ili razgranate tokove.
Dijagrami toka se oslanjaju na mali vokabular standardnih simbola kao što su ovali ili zaobljeni pravougaonici za početak i kraj, pravougaonici za korake obrade, rombovi za odluke, paralelogrami za ulaze/izlaze i strelice za tok upravljanja. Pridržavanje ovih konvencija znači da svako ko je upoznat s osnovnim dijagramima može odmah pročitati vaš dijagram bez legende.
Jasnoća u dijagramima toka dolazi i od ujednačenih simbola i od konciznog tekstaUnutar svakog oblika koristite kratke, direktne fraze koje opisuju šta se dešava ili šta se odlučuje; duga objašnjenja prebacite u napomene ili zasebnu dokumentaciju. Složeni uslovi ili proračuni mogu se referencirati, a ne u potpunosti navesti, kako bi se vizualni prikaz održao čistim, a istovremeno sačuvala tačnost.
Nekoliko autora je predložilo različite taksonomije tipova dijagrama toka kako bi odgovarali različitim perspektivama.Neke klasifikacije razlikuju dijagrame toka sistema, dijagrame toka programa, dijagrame toka dokumenata, dijagrame toka podataka, dijagrame toka proizvoda i dijagrame toka procesa. Druge ih grupiraju po publici – menadžeri, analitičari, programeri – ili po nivou detalja, od pregleda sistema visokog nivoa do detaljne logike programa.
Standardi crtanja i najbolje prakse za dijagrame toka
Nekoliko pravila crtanja dramatično poboljšava čitljivost bilo kojeg dijagrama toka ili dijagrama toka sistemaUvijek počnite s jednim, jasno označenim početnim simbolom i završite s jednim ili više završnih simbola, od kojih svaki odgovara mogućem uvjetu prekida. Početni simbol treba se pojaviti samo jednom u cijelom grafikonu.
Trudite se da izbjegnete prelazak spojnih linijaKada se linije moraju ukrstiti, koristite standardizirane oznake skoka ili ukrštanja kako biste naznačili koja se putanja nastavlja. Međutim, preferirano rješenje je gotovo uvijek prilagođavanje rasporeda ili uvođenje simbola konektora koji vam omogućavaju da prekinete i nastavite tokove u drugom dijelu dijagrama.
Svaki korak obrade treba imati samo jedan ulazni i jedan izlazni tok, dok simboli odluka trebaju imati jedan ulazni i više izlaznih tokova (obično dva: da/ne ili tačno/netačno). Ovo jednostavno ograničenje održava logiku nedvosmislenom i prisiljava vas da složene uslove faktorizujete u odvojene odluke ako je potrebno.
Gdje god je to moguće, samo jedna strelica treba da izlazi iz bilo koje date strane oblika.Višestruko preklapanje strelica sa iste tačke ili strane otežava praćenje ispravne putanje, posebno u gustim dijagramima. Preraspoređivanje elemenata kako bi se svakoj strelici dao određeni prostor za disanje isplati se u lakšem održavanju i manje pogrešnih očitavanja.
Profesionalni alati za dijagrame toka dodaju dodatnu praktičnost, ali ne zamjenjuju disciplinuOnline urednici mogu ponuditi bogate biblioteke simbola, kolaborativno uređivanje, predloške i integracije s dokumentima ili wikijima. Međutim, najvažniji faktor ostaje vaša spremnost da dijagrami budu jednostavni, standardizirani i istinski usklađeni sa stvarnim procesom.
Kako razmisliti prije crtanja bilo kojeg sistemskog dijagrama
Pravilo s najvećim utjecajem za sistemske dijagrame je planiranje sadržaja prije nego što se dotakne alata.Počnite razjašnjavanjem cilja i obima: koji problem ovaj dijagram pomaže u rješavanju, koje će ga zainteresovane strane koristiti i koje će odluke ili diskusije podržati?
Kada je cilj jasan, navedite sve korake, odluke ili strukturne elemente koji su uključeniZa tok ili proces, razbijte složene zadatke na male, konkretne akcije i identificirajte tačke odlučivanja gdje se put odvaja. Za strukturni pogled, identificirajte ključne komponente, usluge, klase, skladišta podataka i vanjske aktere.
Zatim odaberite odgovarajući tip dijagrama i skup simbolaKoristite UML dijagrame klasa ili paketa za statičke strukture objekata, dijagrame aktivnosti ili sekvenci za ponašanje tokom vremena, dijagrame toka za proceduralnu logiku i dijagrame implementacije kada su hardver i čvorovi važni. Miješanje tipova dijagrama na ad-hoc način obično otežava stvari, a ne olakšava.
Prvo napravite grubu skicu, na papiru ili bijeloj tabli, bez brige o savršenom rasporedu pikselaU ovoj fazi testirate vlastito razumijevanje, provjeravate tok i odlučujete šta izostaviti. Mnogo je jeftinije preispitati strukturu dok još skicirate nego kada se usavršena digitalna verzija proširi po cijelom timu.
Tek nakon što je kostur stabilan, trebali biste preći na digitalni alat za sređivanje, dodavanje boja, grupiranja i hiperlinkova.Kritički procijenite da li svaki dodatni detalj zaista pomaže čitaocu. Ako ne možete objasniti zašto je simbol, boja ili napomena potreban, uklonite ih – vaše buduće ja će vam biti zahvalno kada se vratite dijagramu mjesecima kasnije.
Dijagrami mreža i komunalnih usluga: pravila, iteracija i pojednostavljenje
U domenima poput komunalnih mreža ili složene infrastrukture, dijagramima su često potrebna automatizirana pravila kako bi ostali upravljivi.Sistemi mogu generirati i ažurirati dijagrame iz osnovnih mrežnih podataka, a zatim primijeniti pravila transformacije kako bi uklonili šum, dodali izvedene elemente ili identificirali posebne tačke poput korijena i početnih lokacija za prelaske.
Jedna grupa pravila fokusira se na modifikaciju samog grafa dijagramaNa primjer, pravila za uklanjanje entiteta odbacuju određene mrežne karakteristike (kao što su određeni tipovi linija ili manji uređaji) koje nisu relevantne za trenutni prikaz. Druga pravila dodaju nedostajuće, ali važne elemente, kao što su povezanosti ili strukturni prilozi koji nisu podrazumevano nacrtani na osnovnoj mapi mreže.
Pravila za proširenje i sažimanje kontejnera pomažu u upravljanju ugniježđenim strukturamaProširenje prikazuje unutrašnji sadržaj kontejnera kada želite vidjeti detaljnu opremu unutar stanica, ormara ili kompozitnih čvorova. Sažimanje ponovo skriva te detalje, zamjenjujući ih jednim simbolom kontejnera, a istovremeno čuva topološke odnose s ostatkom mreže.
Pravila redukcije pojednostavljuju graf sažimanjem elemenata s niskim udjelom informacijaRedukcija spojeva može ukloniti međučvorove koji ne mijenjaju povezanost, dok redukcija ivica može spojiti jednostavne linearne segmente i njihove spojeve u apstraktnije elemente. Ključni zahtjev je da topologija – šta je s čime povezano – ostane netaknuta kako bi analize i zaključivanje i dalje bili tačni.
Pravila praćenja pokreću mrežne tragove direktno iz elemenata prisutnih u dijagramuU zavisnosti od tipa traga – povezani, podmrežni, uzvodni, nizvodni ili najkraći put – mehanizam koristi ili sve predstavljene elemente kao početne tačke ili specifične one koji su ranije označeni pravilima „postavljene početne tačke“. Ovo osigurava da dijagrami uvijek odražavaju trenutno stanje mreže prilikom regeneracije.
Markeri, mogućnosti i iterativni nizovi pravila
Neka pravila postoje isključivo za označavanje ili konfigurisanje elemenata dijagrama za kasniju obraduPostavljanje korijenskih spojeva, na primjer, definira gdje bi algoritmi za raspored stabla trebali početi prilikom reorganizacije crteža. Dodjeljivanje posebnih mogućnosti određenim čvorovima ili kontejnerima omogućava da se naredna pravila prema njima odnose drugačije – na primjer, štiteći kritičnu opremu od smanjenja ili kolapsa.
Redoslijed izvršavanja pravila ima ogroman utjecaj na konačni dijagramBudući da svako pravilo obrađuje trenutno stanje dijagrama i može kreirati ili uklanjati elemente, njihova primjena u jednom nizu može dati potpuno drugačiji rezultat u poređenju s drugim nizom, čak i ako su sama pravila ista. Ova nekomutativna priroda znači da morate namjerno dizajnirati i dokumentirati redoslijed pravila.
Svako pojedinačno pravilo se obično iterativno izvršava dok ne dostigne stabilno stanje.Pravilo redukcije spojeva, na primjer, će više puta sažimati spojeve koji ispunjavaju njegove kriterije sve dok više ne bude kandidata. Slično tome, pravilo proširenja će nastaviti otkrivati ugniježđene kontejnere sve dok ne pokrije sve relevantne nivoe ili ne može pronaći nove kontejnere koji odgovaraju njegovim filterima.
Međutim, nizovi pravila nisu automatski iterativni kao cjelinaPodrazumevano, sistem izvršava pravilo 1 do kraja, zatim pravilo 2 i tako dalje, bez vraćanja u petlju. U složenim scenarijima, posebno onima koji uključuju više pravila redukcije koja utiču jedno na drugo, možda ćete želeti da se ceo niz ponavlja u petlji sve dok se ne dese dalje promene.
Da bi se to podržalo, specijalizirana pravila kontrole iteracije mogu označiti gdje počinje i završava ponavljajući niz.Pravilo "početak iteracije" na početku bloka i odgovarajuće pravilo "zaustavljanje iteracije" na kraju upućuju generator dijagrama da nastavi ponovo pokretati taj blok sve dok se više ne mogu smanjiti spojevi ili ivice u skladu s konfiguriranim uvjetima. Ovo je posebno vrijedno prilikom smanjenja međusobno povezanih spojeva čija se povezanost mijenja nakon svakog prolaza redukcije.
Preporučeni redoslijed pravila dijagrama u automatizovanim sistemima
Kada konfigurirate predloške za automatski generirane dijagrame, redoslijed pravila je dio dizajnaRazuman redoslijed osigurava da svako pravilo ima potrebne informacije i da se pojednostavljenja događaju u pravo vrijeme, bez uništavanja podataka potrebnih za kasnije korake.
Uobičajena strategija je započeti uklanjanjem očigledno nebitnih entitetaRana pravila "brisanja po klasi, atributu ili kategoriji" uklanjaju "šumne" mrežne karakteristike ili cijele klase koje nikada ne želite vidjeti u ovom konkretnom prikazu. Budući da mehanizam za grafove logički čuva povezanost, eliminiranje određenih linijskih klasa i dalje može proizvesti konzistentne dijagrame, recimo, samo distribucijskog dijela mreže.
Pravila prostornih upita obično dolaze sljedeće, dodajući entitete na osnovu njihove lokacije u odnosu na postojeće elemente.Na primjer, sistem može uključiti obližnje strukture ili uređaje oko već odabranih linija, filtrirane prema atributima ili SQL izrazima. Rano pokretanje ovoga osigurava da su relevantni susjedi prisutni prije bilo kakvih pojednostavljenja višeg nivoa.
Pravila praćenja se obično postavljaju među prve operacije za predloške koji predstavljaju istraživanja mreže.Kada se kombinuju sa unaprijed definisanim pravilima početne tačke, tragovi mogu proširiti mali ulazni skup u koherentnu mrežnu regiju. Nizvodni koraci tada znaju da rade na konzistentnoj podmreži umjesto na proizvoljnim fragmentima.
Pravila za proširenje kontejnera treba primijeniti prije većine redukcija i kontrakcijaPrvo proširivanje vam omogućava da odlučite šta će ostati vidljivo, šta će se sažeti i kako će se tretirati sadržaj tokom kasnijih koraka. Nakon proširenja, pravila "dodavanja asocijacija povezivanja" mogu nacrtati nedostajuće veze između početnih i odredišnih spojeva, osiguravajući da konačni crtež odražava osnovne logičke asocijacije.
Pravila dodjeljivanja sposobnosti su korisna neposredno prije agresivnog pojednostavljenjaOznačavanjem određenih čvorova ili kontejnera kao "ne reducirati" ili davanjem im posebnih uloga, možete omogućiti izvršavanje globalnih pravila redukcije bez slučajnog urušavanja kritičnih tačaka interesa. Ova ciljana zaštita je preciznija od jednostavnog isključivanja cijelih klasa.
Pravila za kontrakciju kontejnera se pokreću nakon što ponovo odlučite koje unutrašnje detalje želite sakriti.Oni zamjenjuju prošireni sadržaj oblicima kontejnera višeg nivoa, a istovremeno održavaju povezanost i sve povezane markere. Ako je proširenje izvršeno ranije, kontrakcije i dalje mogu sačuvati pamćenje o tome koji se sadržaj konceptualno nalazi tamo.
Pravila za početak iteracije postavljaju se na početak blokova pravila za redukciju spojeva, a pravila za zaustavljanje iteracije na kraj.Unutar tog bloka možete povezati više pravila redukcije – po klasi, atributu ili kategoriji – i pustiti mehanizam da ih prelazi u petlji dok ne ostane više kandidata. Nakon što se niz stabilizira, izvršavanje se nastavlja sa svim sljedećim neiterativnim pravilima.
Pravila redukcije ivica, koja sažimaju linearne segmente u čvorove shematske redukcije, obično se izvršavaju pri krajuDo tada su pojednostavljenja kontejnera i spojeva završena, tako da smanjenje ivica neće sakriti važnu strukturu. Konačno, pravila strukturnog vezivanja se obično izvršavaju posljednja, bez obzira gdje se pojavljuju u konfiguraciji, kako bi se garantovalo da su fizička vezivanja ispravno nacrtana preko pojednostavljenog grafa.
Kada kombinujete jasne vizuelne principe, promišljenu upotrebu UML-a i notacija dijagrama toka i, gdje je to relevantno, dobro osmišljena automatizovana pravila za mrežne dijagrame, vaši sistemski dijagrami prestaju biti lijepe slike i postaju radni alati koji vode dizajn, rano otkrivaju probleme i održavaju sve u projektu usklađenim sa tim kako se sistem zaista ponaša i kako je strukturiran.
