Πρότυπο καταγραφής αποφάσεων του arc42

https://arc42.org/overview

1. Εισαγωγή και στόχοι

Σύντομη περιγραφή των απαιτήσεων, των κινητήριων δυνάμεων, απόσπασμα (ή περίληψη) των απαιτήσεων. Οι τρεις κορυφαίοι (το πολύ πέντε) στόχοι ποιότητας για την αρχιτεκτονική που έχουν την υψηλότερη προτεραιότητα για τα βασικά ενδιαφερόμενα μέρη. Ένας πίνακας με τα σημαντικά ενδιαφερόμενα μέρη και τις προσδοκίες τους σχετικά με την αρχιτεκτονική.

1.1 Επισκόπηση απαιτήσεων

Περιεχόμενα

Σύντομη περιγραφή των λειτουργικών απαιτήσεων, των κινητήριων δυνάμεων, απόσπασμα (ή περίληψη) των απαιτήσεων. Σύνδεσμοι προς τα (ελπίζουμε υπάρχοντα) έγγραφα απαιτήσεων, με πληροφορίες για το πού μπορούν να βρεθούν.

Κίνητρο

Από την πλευρά των τελικών χρηστών, ένα σύστημα δημιουργείται ή τροποποιείται για να υποστηρίξει καλύτερα μια επιχειρηματική δραστηριότητα και/ή να βελτιώσει την ποιότητα.

Μορφή

Σύντομη περιγραφή σε κείμενο, πιθανώς σε μορφή πίνακα περιπτώσεων χρήσης. Αν υπάρχουν έγγραφα απαιτήσεων, αυτή η επισκόπηση πρέπει να παραπέμπει σε αυτά.

Διατηρήστε αυτά τα αποσπάσματα όσο πιο σύντομα γίνεται. Ισορροπήστε την αναγνωσιμότητα αυτού του εγγράφου με την πιθανή πλεονασμό σε σχέση με τα έγγραφα απαιτήσεων.

1.2 Στόχοι ποιότητας

Περιεχόμενο

Οι τρεις κορυφαίοι (το πολύ πέντε) στόχοι ποιότητας για την αρχιτεκτονική, των οποίων η εκπλήρωση έχει τη μεγαλύτερη σημασία για τα βασικά ενδιαφερόμενα μέρη. Εννοούμε πραγματικά στόχους ποιότητας για την αρχιτεκτονική. Μην τους συγχέετε με τους στόχους του έργου. Δεν είναι απαραίτητα ταυτόσημοι. Το πρότυπο ISO 25010 παρέχει μια ωραία επισκόπηση πιθανών θεμάτων ενδιαφέροντος.

Κίνητρο

Πρέπει να γνωρίζετε τους στόχους ποιότητας των σημαντικότερων ενδιαφερόμενων μερών σας, καθώς θα επηρεάσουν θεμελιώδεις αρχιτεκτονικές αποφάσεις. Να είστε πολύ συγκεκριμένοι για αυτές τις ποιότητες, αποφύγετε τα φραστικά κλισέ. Αν ως αρχιτέκτονας δεν γνωρίζετε πώς θα κριθεί η ποιότητα της δουλειάς σας …

Μορφή

Ένας πίνακας με τους σημαντικότερους στόχους ποιότητας και συγκεκριμένα σενάρια, ταξινομημένους κατά προτεραιότητα.

1.3 Ενδιαφερόμενα μέρη

Περιεχόμενο

Ρητή επισκόπηση των ενδιαφερόμενων μερών του συστήματος, δηλαδή όλων των προσώπων, ρόλων ή οργανισμών που

• πρέπει να γνωρίζουν την αρχιτεκτονική

• πρέπει να πεισθούν για την αρχιτεκτονική

• πρέπει να εργάζονται με την αρχιτεκτονική ή με τον κώδικα

• χρειάζονται την τεκμηρίωση της αρχιτεκτονικής για τη δουλειά τους

• πρέπει να λάβουν αποφάσεις σχετικά με το σύστημα ή την ανάπτυξή του

Κίνητρο

Πρέπει να γνωρίζετε όλα τα μέρη που εμπλέκονται στην ανάπτυξη του συστήματος ή επηρεάζονται από αυτό. Διαφορετικά, μπορεί να έχετε δυσάρεστες εκπλήξεις αργότερα στη διαδικασία ανάπτυξης. Αυτά τα ενδιαφερόμενα μέρη καθορίζουν την έκταση και το επίπεδο λεπτομέρειας της δουλειάς σας και των αποτελεσμάτων της.

Μορφή

Πίνακας με ονόματα ρόλων, ονόματα προσώπων και τις προσδοκίες τους σε σχέση με την αρχιτεκτονική και την τεκμηρίωσή της.

2. Περιορισμοί

Οτιδήποτε περιορίζει τις ομάδες στις αποφάσεις σχεδίασης και υλοποίησης ή στις αποφάσεις για σχετικές διαδικασίες. Μπορεί μερικές φορές να υπερβαίνουν μεμονωμένα συστήματα και να ισχύουν για ολόκληρους οργανισμούς και εταιρείες.

Περιεχόμενο

Κάθε απαίτηση που περιορίζει τους αρχιτέκτονες λογισμικού στην ελευθερία σχεδίασης και στις αποφάσεις υλοποίησης ή στην απόφαση για τη διαδικασία ανάπτυξης. Αυτοί οι περιορισμοί μερικές φορές υπερβαίνουν μεμονωμένα συστήματα και ισχύουν για ολόκληρους οργανισμούς και εταιρείες.

Κίνητρο

Οι αρχιτέκτονες πρέπει να γνωρίζουν ακριβώς πού είναι ελεύθεροι στις αποφάσεις σχεδίασής τους και πού πρέπει να τηρούν περιορισμούς. Οι περιορισμοί πρέπει πάντα να αντιμετωπίζονται· ωστόσο, μπορεί να είναι διαπραγματεύσιμοι.

Μορφή

Απλοί πίνακες περιορισμών με εξηγήσεις. Αν χρειάζεται, μπορείτε να τους υποδιαιρέσετε σε τεχνικούς περιορισμούς, οργανωτικούς και πολιτικούς περιορισμούς και συμβάσεις (π.χ. οδηγίες προγραμματισμού ή εκδόσεων, συμβάσεις τεκμηρίωσης ή ονομασίας)

3. Πλαίσιο και εύρος

Οριοθετεί το σύστημά σας από τους (εξωτερικούς) συνεργάτες επικοινωνίας του (γειτονικά συστήματα και χρήστες). Προσδιορίζει τις εξωτερικές διεπαφές. Παρουσιάζεται από επιχειρηματική/πεδιακή οπτική (πάντα) ή τεχνική οπτική (προαιρετικά)

Περιεχόμενο

Το εύρος και το πλαίσιο του συστήματος — όπως υποδηλώνει το όνομα — οριοθετεί το σύστημά σας (δηλαδή το εύρος σας) από όλους τους συνεργάτες επικοινωνίας του (γειτονικά συστήματα και χρήστες, δηλαδή το πλαίσιο του συστήματός σας). Έτσι προσδιορίζει τις εξωτερικές διεπαφές.

Αν χρειάζεται, διακρίνετε το επιχειρηματικό πλαίσιο (είσοδοι και έξοδοι ειδικές για τον τομέα) από το τεχνικό πλαίσιο (κανάλια, πρωτόκολλα, υλικό).

Κίνητρο

Οι διεπαφές τομέα και οι τεχνικές διεπαφές προς τους συνεργάτες επικοινωνίας είναι από τις πιο κρίσιμες πτυχές του συστήματός σας. Βεβαιωθείτε ότι τις κατανοείτε πλήρως.

Μορφή

• Διάφορα διαγράμματα πλαισίου

• Κατάλογοι συνεργατών επικοινωνίας και των διεπαφών τους.

3.1 Επιχειρηματικό πλαίσιο

Περιεχόμενο

Προδιαγραφή όλων των συνεργατών επικοινωνίας (χρήστες, συστήματα IT, …) με εξηγήσεις των εισόδων και εξόδων ή των διεπαφών ειδικών για τον τομέα. Προαιρετικά μπορείτε να προσθέσετε μορφές ειδικές για τον τομέα ή πρωτόκολλα επικοινωνίας.

Κίνητρο

Όλα τα ενδιαφερόμενα μέρη πρέπει να κατανοούν ποια δεδομένα ανταλλάσσονται με το περιβάλλον του συστήματος.

Μορφή

Κάθε είδους διαγράμματα που δείχνουν το σύστημα ως μαύρο κουτί και προσδιορίζουν τις διεπαφές τομέα προς τους συνεργάτες επικοινωνίας.

Εναλλακτικά (ή επιπλέον) μπορείτε να χρησιμοποιήσετε έναν πίνακα. Ο τίτλος του πίνακα είναι το όνομα του συστήματός σας, οι τρεις στήλες περιέχουν το όνομα του συνεργάτη επικοινωνίας, τις εισόδους και τις εξόδους.

3.2 Τεχνικό πλαίσιο

Περιεχόμενα

Οι τεχνικές διεπαφές (κανάλια και μέσα μετάδοσης) που συνδέουν το σύστημά σας με το περιβάλλον του. Επιπλέον, μια αντιστοίχιση των εισόδων/εξόδων ειδικών για τον τομέα στα κανάλια, δηλαδή μια εξήγηση του ποιο κανάλι χρησιμοποιεί ποια είσοδος/έξοδος.

Κίνητρο

Πολλά ενδιαφερόμενα μέρη λαμβάνουν αρχιτεκτονικές αποφάσεις βάσει των τεχνικών διεπαφών μεταξύ του συστήματος και του πλαισίου του. Ιδιαίτερα οι σχεδιαστές υποδομής ή υλικού αποφασίζουν αυτές τις τεχνικές διεπαφές.

Μορφή

Π.χ. διάγραμμα ανάπτυξης UML που περιγράφει τα κανάλια προς γειτονικά συστήματα, μαζί με έναν πίνακα αντιστοίχισης που δείχνει τις σχέσεις μεταξύ καναλιών και εισόδων/εξόδων.

4. Στρατηγική λύσης

Περίληψη των θεμελιωδών αποφάσεων και στρατηγικών λύσης που διαμορφώνουν την αρχιτεκτονική. Μπορεί να περιλαμβάνει τεχνολογία, αποσύνθεση ανώτατου επιπέδου, προσεγγίσεις για την επίτευξη των κορυφαίων στόχων ποιότητας και σχετικές οργανωτικές αποφάσεις.

Περιεχόμενα

Μια σύντομη περίληψη και εξήγηση των θεμελιωδών αποφάσεων και στρατηγικών λύσης που διαμορφώνουν την αρχιτεκτονική του συστήματος. Αυτές περιλαμβάνουν

• τεχνολογικές αποφάσεις

• αποφάσεις για την αποσύνθεση ανώτατου επιπέδου του συστήματος, π.χ. χρήση αρχιτεκτονικού μοτίβου ή μοτίβου σχεδίασης

• αποφάσεις για το πώς θα επιτευχθούν βασικοί στόχοι ποιότητας

• σχετικές οργανωτικές αποφάσεις, π.χ. επιλογή διαδικασίας ανάπτυξης ή ανάθεση ορισμένων εργασιών σε τρίτους.

Κίνητρο

Αυτές οι αποφάσεις αποτελούν τους θεμέλιους λίθους της αρχιτεκτονικής σας. Είναι η βάση για πολλές άλλες αναλυτικές αποφάσεις ή κανόνες υλοποίησης.

Μορφή

Διατηρήστε την εξήγηση αυτών των βασικών αποφάσεων σύντομη.

Αιτιολογήστε τι αποφασίσατε και γιατί αποφασίσατε έτσι, με βάση τη διατύπωση του προβλήματος, τους στόχους ποιότητας και τους βασικούς περιορισμούς. Παραπέμψτε σε λεπτομέρειες στις επόμενες ενότητες (ενότητα 5 για δομικές λεπτομέρειες, ενότητα 8 για διαπλέκουσες έννοιες).

Μπορείτε να χρησιμοποιήσετε έναν κατάλογο προσεγγίσεων λύσης ή έναν πίνακα.

5. Όψη δομικών στοιχείων

Στατική αποσύνθεση του συστήματος, αφαιρέσεις του πηγαίου κώδικα, που παρουσιάζονται ως ιεραρχία λευκών κουτιών (που περιέχουν μαύρα κουτιά), μέχρι το κατάλληλο επίπεδο λεπτομέρειας.

Περιεχόμενο

Η όψη δομικών στοιχείων δείχνει τη στατική αποσύνθεση του συστήματος σε δομικά στοιχεία (μονάδες, συστατικά, υποσυστήματα, κλάσεις, διεπαφές, πακέτα, βιβλιοθήκες, πλαίσια, επίπεδα, διαμερίσματα, βαθμίδες, συναρτήσεις, μακροεντολές, λειτουργίες, δομές δεδομένων, …) καθώς και τις εξαρτήσεις τους (σχέσεις, συσχετίσεις, …)

Αυτή η όψη είναι υποχρεωτική για κάθε τεκμηρίωση αρχιτεκτονικής. Κατ' αναλογία με ένα σπίτι, είναι η κάτοψη.

Κίνητρο

Διατηρήστε μια επισκόπηση του πηγαίου κώδικά σας κάνοντας τη δομή του κατανοητή μέσω αφαίρεσης.

Αυτό σας επιτρέπει να επικοινωνείτε με τα ενδιαφερόμενα μέρη σε αφηρημένο επίπεδο χωρίς να αποκαλύπτετε λεπτομέρειες υλοποίησης.

Μορφή

Η όψη δομικών στοιχείων είναι μια ιεραρχική συλλογή μαύρων και λευκών κουτιών (βλ. το σχήμα παρακάτω) και των περιγραφών τους.

5.1 Λευκό κουτί — ολόκληρο το σύστημα

Εδώ περιγράφετε την αποσύνθεση ολόκληρου του συστήματος χρησιμοποιώντας το παρακάτω πρότυπο λευκού κουτιού. Περιέχει

• ένα διάγραμμα επισκόπησης

• ένα κίνητρο για την αποσύνθεση

• περιγραφές μαύρου κουτιού των περιεχόμενων δομικών στοιχείων. Για αυτά σας προσφέρουμε εναλλακτικές:

  • χρησιμοποιήστε έναν πίνακα για μια σύντομη και πραγματιστική επισκόπηση όλων των περιεχόμενων δομικών στοιχείων και των διεπαφών τους

  • χρησιμοποιήστε έναν κατάλογο περιγραφών μαύρου κουτιού των δομικών στοιχείων σύμφωνα με το πρότυπο μαύρου κουτιού (βλ. παρακάτω). Ανάλογα με την επιλογή εργαλείου, αυτός ο κατάλογος μπορεί να είναι υποκεφάλαια (σε αρχεία κειμένου), υποσελίδες (σε Wiki) ή ένθετα στοιχεία (σε εργαλείο μοντελοποίησης).

  • (προαιρετικά:) σημαντικές διεπαφές, που δεν εξηγούνται στα πρότυπα μαύρου κουτιού ενός δομικού στοιχείου, αλλά είναι πολύ σημαντικές για την κατανόηση του λευκού κουτιού.

Επειδή υπάρχουν τόσοι πολλοί τρόποι προσδιορισμού διεπαφών, δεν παρέχουμε συγκεκριμένο πρότυπο γι' αυτές.

Στην καλύτερη περίπτωση θα τα βγάλετε πέρα με παραδείγματα ή απλές υπογραφές.

5.2 Επίπεδο 2

Εδώ μπορείτε να προσδιορίσετε την εσωτερική δομή (ορισμένων) δομικών στοιχείων του επιπέδου 1 ως λευκά κουτιά.

Πρέπει να αποφασίσετε ποια δομικά στοιχεία του συστήματός σας είναι αρκετά σημαντικά ώστε να δικαιολογούν μια τόσο αναλυτική περιγραφή. Προτιμήστε τη συνάφεια έναντι της πληρότητας. Προσδιορίστε δομικά στοιχεία σημαντικά, εκπληκτικά, επικίνδυνα, σύνθετα ή ασταθή. Παραλείψτε τα κανονικά, απλά, βαρετά ή τυποποιημένα μέρη του συστήματός σας

5.2.1 Λευκό κουτί για το δομικό στοιχείο 1

Προσδιορίζει την εσωτερική δομή του δομικού στοιχείου 1.

Χρησιμοποιήστε το πρότυπο λευκού κουτιού (βλ. παραπάνω).

6. Όψη χρόνου εκτέλεσης

Συμπεριφορά των δομικών στοιχείων ως σενάρια, που καλύπτουν σημαντικές περιπτώσεις χρήσης ή λειτουργίες, αλληλεπιδράσεις σε κρίσιμες εξωτερικές διεπαφές, λειτουργία και διαχείριση, καθώς και συμπεριφορά σε σφάλματα και εξαιρέσεις.

Περιεχόμενο

Η όψη χρόνου εκτέλεσης περιγράφει τη συγκεκριμένη συμπεριφορά και τις αλληλεπιδράσεις των δομικών στοιχείων του συστήματος με τη μορφή σεναρίων από τους ακόλουθους τομείς:

• σημαντικές περιπτώσεις χρήσης ή λειτουργίες: πώς τις εκτελούν τα δομικά στοιχεία;

• αλληλεπιδράσεις σε κρίσιμες εξωτερικές διεπαφές: πώς συνεργάζονται τα δομικά στοιχεία με τους χρήστες και τα γειτονικά συστήματα;

• λειτουργία και διαχείριση: εκκίνηση, ενεργοποίηση, διακοπή

• σενάρια σφαλμάτων και εξαιρέσεων

Παρατήρηση: Το κύριο κριτήριο για την επιλογή πιθανών σεναρίων (ακολουθίες, ροές εργασιών) είναι η αρχιτεκτονική τους συνάφεια. Δεν είναι σημαντικό να περιγράψετε μεγάλο αριθμό σεναρίων. Καλύτερα να τεκμηριώσετε μια αντιπροσωπευτική επιλογή.

Κίνητρο

Πρέπει να κατανοείτε πώς (τα στιγμιότυπα των) δομικών στοιχείων του συστήματός σας εκτελούν τη δουλειά τους και επικοινωνούν κατά τον χρόνο εκτέλεσης. Θα καταγράφετε κυρίως σενάρια στην τεκμηρίωσή σας για να κοινοποιήσετε την αρχιτεκτονική σας σε ενδιαφερόμενα μέρη που είναι λιγότερο πρόθυμα ή ικανά να διαβάσουν και να κατανοήσουν τα στατικά μοντέλα (όψη δομικών στοιχείων, όψη ανάπτυξης).

Μορφή

Υπάρχουν πολλές σημειογραφίες για την περιγραφή σεναρίων, π.χ.

• αριθμημένος κατάλογος βημάτων (σε φυσική γλώσσα)

• διαγράμματα δραστηριότητας ή διαγράμματα ροής

• διαγράμματα ακολουθίας

• BPMN ή EPC (αλυσίδες διαδικασιών γεγονότων)

• μηχανές καταστάσεων

• κ.λπ.

6.n Σενάριο χρόνου εκτέλεσης n (1, 2, 3 κ.λπ.)

Εισαγάγετε διάγραμμα χρόνου εκτέλεσης ή περιγραφή του σεναρίου σε κείμενο.

Εισαγάγετε περιγραφή των αξιοσημείωτων πτυχών των αλληλεπιδράσεων μεταξύ των στιγμιοτύπων δομικών στοιχείων που απεικονίζονται σε αυτό το διάγραμμα.

7. Όψη ανάπτυξης

Τεχνική υποδομή με περιβάλλοντα, υπολογιστές, επεξεργαστές, τοπολογίες. Αντιστοίχιση των (λογισμικών) δομικών στοιχείων σε στοιχεία υποδομής.

Περιεχόμενο

Η όψη ανάπτυξης περιγράφει:

• την τεχνική υποδομή που χρησιμοποιείται για την εκτέλεση του συστήματός σας, με στοιχεία υποδομής όπως γεωγραφικές τοποθεσίες, περιβάλλοντα, υπολογιστές, επεξεργαστές, κανάλια και τοπολογίες δικτύου καθώς και άλλα στοιχεία υποδομής και

• την αντιστοίχιση των (λογισμικών) δομικών στοιχείων σε αυτά τα στοιχεία υποδομής.

Συχνά τα συστήματα εκτελούνται σε διαφορετικά περιβάλλοντα, π.χ. περιβάλλον ανάπτυξης, περιβάλλον δοκιμών, περιβάλλον παραγωγής. Σε τέτοιες περιπτώσεις πρέπει να τεκμηριώσετε όλα τα σχετικά περιβάλλοντα.

Τεκμηριώστε ιδιαίτερα την όψη ανάπτυξης όταν το λογισμικό σας εκτελείται ως κατανεμημένο σύστημα με περισσότερους από έναν υπολογιστές, επεξεργαστές, διακομιστές ή κοντέινερ ή όταν σχεδιάζετε και κατασκευάζετε δικούς σας επεξεργαστές υλικού και τσιπ.

Από την οπτική του λογισμικού αρκεί να καταγράψετε εκείνα τα στοιχεία της υποδομής που χρειάζονται για να δειχθεί η ανάπτυξη των δομικών στοιχείων σας. Οι αρχιτέκτονες υλικού μπορούν να πάνε πέρα από αυτό και να περιγράψουν την υποδομή σε οποιοδήποτε επίπεδο λεπτομέρειας χρειάζονται.

Κίνητρο

Το λογισμικό δεν τρέχει χωρίς υλικό. Αυτή η υποκείμενη υποδομή μπορεί και θα επηρεάσει το σύστημά σας ή/και ορισμένες διαπλέκουσες έννοιες. Επομένως, πρέπει να γνωρίζετε την υποδομή.

Μορφή

Ίσως το διάγραμμα ανάπτυξης ανώτατου επιπέδου περιέχεται ήδη στην ενότητα 3.2 ως τεχνικό πλαίσιο με τη δική σας υποδομή ως ΕΝΑ μαύρο κουτί. Σε αυτή την ενότητα θα μεγεθύνετε αυτό το μαύρο κουτί χρησιμοποιώντας πρόσθετα διαγράμματα ανάπτυξης.

• Η UML προσφέρει διαγράμματα ανάπτυξης για να εκφράσει αυτή την όψη. Χρησιμοποιήστε την, πιθανώς με ένθετα διαγράμματα, όταν η υποδομή σας είναι πιο σύνθετη.

• Όταν τα (υλικού) ενδιαφερόμενα μέρη σας προτιμούν άλλα είδη διαγραμμάτων αντί για το διάγραμμα ανάπτυξης UML, αφήστε τα να χρησιμοποιήσουν οποιοδήποτε είδος μπορεί να δείξει κόμβους και κανάλια της υποδομής.

7.1 Υποδομή επίπεδο 1

Περιγράψτε (συνήθως με συνδυασμό διαγραμμάτων, πινάκων και κειμένου):

• τη διανομή του συστήματός σας σε πολλαπλές τοποθεσίες, περιβάλλοντα, υπολογιστές, επεξεργαστές, .. καθώς και τις φυσικές συνδέσεις μεταξύ τους

• σημαντική αιτιολόγηση ή κίνητρο για αυτή τη δομή ανάπτυξης

• χαρακτηριστικά ποιότητας ή/και απόδοσης της υποδομής

• την αντιστοίχιση των τεχνουργημάτων λογισμικού (δομικά στοιχεία) σε στοιχεία της υποδομής

Για πολλαπλά περιβάλλοντα ή εναλλακτικές αναπτύξεις αντιγράψτε αυτή την ενότητα του arc42 για όλα τα σχετικά περιβάλλοντα. **

7.2 Υποδομή επίπεδο 2

Εδώ μπορείτε να συμπεριλάβετε την εσωτερική δομή (ορισμένων) στοιχείων υποδομής από το επίπεδο 1 της υποδομής.

Αντιγράψτε τη δομή από το επίπεδο 1 για κάθε επιλεγμένο στοιχείο.

8. Διαπλέκουσες έννοιες

Γενικές, βασικές ρυθμίσεις και προσεγγίσεις λύσης που σχετίζονται με πολλά μέρη (→ διαπλέκουσες) του συστήματος. Οι έννοιες συχνά σχετίζονται με πολλά δομικά στοιχεία. Περιλαμβάνουν διάφορα θέματα όπως μοντέλα τομέα, αρχιτεκτονικά μοτίβα και στυλ, κανόνες χρήσης συγκεκριμένης τεχνολογίας και κανόνες υλοποίησης.

Περιεχόμενο

Αυτή η ενότητα περιγράφει διαπλέκουσες έννοιες (πρακτικές, μοτίβα, ρυθμίσεις ή ιδέες λύσεων). Τέτοιες έννοιες συχνά σχετίζονται με πολλά δομικά στοιχεία. Μπορεί να περιλαμβάνουν πολλά διαφορετικά θέματα.

Κίνητρο

Οι έννοιες αποτελούν τη βάση για την εννοιολογική ακεραιότητα (συνέπεια, ομοιογένεια) της αρχιτεκτονικής. Επομένως, είναι σημαντική συμβολή στην επίτευξη των εσωτερικών ποιοτήτων του συστήματός σας.

Αυτό είναι το σημείο του προτύπου που παρέχουμε για τη συνεκτική προδιαγραφή τέτοιων εννοιών.

Πολλές από αυτές τις έννοιες σχετίζονται με ή επηρεάζουν πολλά από τα δομικά σας στοιχεία.

Μορφή

Η μορφή μπορεί να ποικίλλει:

• εννοιολογικά κείμενα με οποιαδήποτε δομή

• παραδείγματα υλοποιήσεων, ιδίως για τεχνικές έννοιες

• διαπλέκοντα αποσπάσματα μοντέλων ή σενάρια με σημειογραφίες των αρχιτεκτονικών όψεων

Δομή αυτής της ενότητας

Επιλέξτε μόνο τα πιο αναγκαία θέματα για το σύστημά σας και αντιστοιχίστε σε καθένα έναν τίτλο επιπέδου 2 σε αυτή την ενότητα (π.χ. 8.1, 8.2 κ.λπ.).

• ΜΗΝ ΠΡΟΣΠΑΘΗΣΕΤΕ να καλύψετε όλα τα θέματα του προαναφερθέντος διαγράμματος.

Υπόβαθρο

Ορισμένα θέματα στα συστήματα αφορούν συχνά πολλά δομικά στοιχεία, στοιχεία υλικού ή διαδικασίες ανάπτυξης. Μπορεί να είναι ευκολότερο να κοινοποιηθούν ή να τεκμηριωθούν τέτοια διαπλέκοντα θέματα σε μια κεντρική θέση, αντί να επαναλαμβάνονται στην περιγραφή των εμπλεκόμενων δομικών στοιχείων, στοιχείων υλικού ή διαδικασιών ανάπτυξης.

Ορισμένες έννοιες μπορεί να αφορούν όλα τα στοιχεία ενός συστήματος, άλλες μπορεί να είναι σχετικές μόνο με λίγα.

9. Αρχιτεκτονικές αποφάσεις

Σημαντικές, δαπανηρές, κρίσιμες, μεγάλης κλίμακας ή επικίνδυνες αρχιτεκτονικές αποφάσεις μαζί με τις αιτιολογήσεις τους.

Περιεχόμενο

Σημαντικές, δαπανηρές, μεγάλης κλίμακας ή επικίνδυνες αρχιτεκτονικές αποφάσεις μαζί με τις αιτιολογήσεις τους. Με τον όρο «αποφάσεις» εννοούμε την επιλογή μιας εναλλακτικής βάσει δεδομένων κριτηρίων.

Χρησιμοποιήστε την κρίση σας για να αποφασίσετε αν μια αρχιτεκτονική απόφαση πρέπει να τεκμηριωθεί εδώ, σε αυτή την κεντρική ενότητα, ή αν είναι καλύτερα να τεκμηριωθεί τοπικά (π.χ. μέσα στο πρότυπο λευκού κουτιού ενός δομικού στοιχείου). Αποφύγετε τα πλεονάζοντα κείμενα. Παραπέμψτε στην ενότητα 4, όπου έχετε ήδη καταγράψει τις σημαντικότερες αποφάσεις της αρχιτεκτονικής σας.

Κίνητρο

Τα ενδιαφερόμενα μέρη του συστήματός σας πρέπει να μπορούν να κατανοούν και να ανασυνθέτουν τις αποφάσεις σας.

Μορφή

• ADR (καταγραφή αρχιτεκτονικής απόφασης) για κάθε σημαντική απόφαση

• κατάλογος ή πίνακας, ταξινομημένος κατά σημασία και συνέπειες ή

• πιο αναλυτικά με τη μορφή ξεχωριστών ενοτήτων ανά απόφαση

Υπόβαθρο (για τα ADR)

Τα μικρότερα κομμάτια τεκμηρίωσης είναι ευκολότερο να διαβαστούν, να δημιουργηθούν και να συντηρηθούν. Όσον αφορά τις αρχιτεκτονικές αποφάσεις, οι ομάδες ανάπτυξης συχνά:

• γνωρίζουν την απόφαση, καθώς είναι ορατή π.χ. στον πηγαίο κώδικα, αλλά

• δεν γνωρίζουν το κίνητρο πίσω από αυτή την απόφαση (βλ. Nygard 2011)

Επομένως, πρέπει να τεκμηριώσετε μερικές σημαντικές αποφάσεις μαζί με το κίνητρο και το σκεπτικό τους

Η πρότασή μας σχετικά με τις αποφάσεις

Διατηρήστε μια συλλογή αρχιτεκτονικά σημαντικών αποφάσεων, δηλαδή αποφάσεων που επηρεάζουν τη δομή, τα χαρακτηριστικά ποιότητας, σημαντικές (ιδίως εξωτερικές) εξαρτήσεις και διεπαφές ή τεχνικές κατασκευής (χάρη στον Michael Nygard για αυτή την πρόταση).

10. Απαιτήσεις ποιότητας

Απαιτήσεις ποιότητας ως σενάρια, με δέντρο ποιότητας που παρέχει επισκόπηση υψηλού επιπέδου. Οι σημαντικότεροι στόχοι ποιότητας θα έπρεπε να έχουν περιγραφεί στην ενότητα 1.2. (στόχοι ποιότητας).

Περιεχόμενο

Αυτή η ενότητα περιέχει όλες τις σχετικές απαιτήσεις ποιότητας.

Οι σημαντικότερες από αυτές τις απαιτήσεις έχουν ήδη περιγραφεί στην ενότητα 1.2. (στόχοι ποιότητας), επομένως εδώ πρέπει μόνο να αναφέρονται. Σε αυτή την ενότητα 10 πρέπει επίσης να καταγράψετε απαιτήσεις ποιότητας μικρότερης σημασίας, που δεν θα δημιουργήσουν μεγάλους κινδύνους αν δεν επιτευχθούν πλήρως (αλλά μπορεί να είναι επιθυμητές).

Κίνητρο

Επειδή οι απαιτήσεις ποιότητας θα έχουν μεγάλη επιρροή στις αρχιτεκτονικές αποφάσεις, πρέπει να γνωρίζετε ποιες ποιότητες είναι πραγματικά σημαντικές για τα ενδιαφερόμενα μέρη σας, με συγκεκριμένο και μετρήσιμο τρόπο.

Περαιτέρω πληροφορίες

Δείτε το εκτενές μοντέλο ποιότητας Q42 στο https://quality.arc42.org.

10.1 Επισκόπηση απαιτήσεων ποιότητας

Περιεχόμενο

Μια επισκόπηση ή περίληψη των απαιτήσεων ποιότητας.

Κίνητρο

Συχνά συναντούμε δεκάδες (ή και εκατοντάδες) αναλυτικές απαιτήσεις ποιότητας. Σε αυτή την ενότητα επισκόπησης πρέπει να προσπαθήσετε να συνοψίσετε, π.χ. περιγράφοντας κατηγορίες ή θέματα (όπως προτείνουν τα ISO 25010:2023 ή Q42

Αν αυτές οι συνοπτικές περιγραφές είναι ήδη ακριβείς, αρκετά συγκεκριμένες και μετρήσιμες, μπορείτε να παραλείψετε την ενότητα 10.2.

Μορφή

Χρησιμοποιήστε έναν απλό πίνακα όπου κάθε γραμμή περιέχει μια κατηγορία ή θέμα και μια σύντομη περιγραφή της απαίτησης ποιότητας. Εναλλακτικά, μπορείτε να χρησιμοποιήσετε έναν νοητικό χάρτη για να δομήσετε αυτές τις απαιτήσεις ποιότητας.

Στη βιβλιογραφία έχει περιγραφεί επίσης η ιδέα ενός δέντρου ποιοτικών χαρακτηριστικών, που θέτει τον γενικό όρο «ποιότητα» ως ρίζα και χρησιμοποιεί μια δενδροειδή εξειδίκευση του όρου «ποιότητα». Το [Bass+21] εισήγαγε για αυτόν τον σκοπό τον όρο «Quality Attribute Utility Tree».

10.2 Σενάρια ποιότητας

Περιεχόμενο

Τα σενάρια ποιότητας συγκεκριμενοποιούν τις απαιτήσεις ποιότητας και επιτρέπουν να αποφασιστεί αν ικανοποιούνται (υπό την έννοια των κριτηρίων αποδοχής). Βεβαιωθείτε ότι τα σενάριά σας είναι συγκεκριμένα και μετρήσιμα.

Δύο είδη σεναρίων είναι ιδιαίτερα χρήσιμα:

• Τα σενάρια χρήσης (που λέγονται και σενάρια εφαρμογής ή σενάρια περιπτώσεων χρήσης) περιγράφουν την αντίδραση του συστήματος κατά τον χρόνο εκτέλεσης σε ένα συγκεκριμένο ερέθισμα. Αυτό περιλαμβάνει και σενάρια που περιγράφουν την αποδοτικότητα ή την απόδοση του συστήματος. Παράδειγμα: Το σύστημα αντιδρά στο αίτημα ενός χρήστη εντός ενός δευτερολέπτου.

• Τα σενάρια αλλαγής περιγράφουν το επιθυμητό αποτέλεσμα μιας τροποποίησης ή επέκτασης του συστήματος ή του άμεσου περιβάλλοντός του. Παράδειγμα: Υλοποιείται πρόσθετη λειτουργικότητα ή αλλάζουν οι απαιτήσεις για ένα ποιοτικό χαρακτηριστικό και μετράται η προσπάθεια ή η διάρκεια της αλλαγής.

Μορφή

Τυπικές πληροφορίες για αναλυτικά σενάρια περιλαμβάνουν τα εξής:

Σε σύντομη μορφή (προτιμάται στο μοντέλο Q42):

• Πλαίσιο/Υπόβαθρο: Τι είδους σύστημα ή συστατικό, ποιο είναι το περιβάλλον ή η κατάσταση;

• Πηγή/Ερέθισμα: Ποιος ή τι ξεκινά ή πυροδοτεί μια συμπεριφορά, αντίδραση ή ενέργεια.

• Μέτρο/Κριτήρια αποδοχής: Μια απόκριση που περιλαμβάνει ένα μέτρο ή μετρική

Η εκτεταμένη μορφή των σεναρίων (προτιμάται από το SEI και το [Bass+21]) είναι πιο αναλυτική και περιλαμβάνει τις ακόλουθες πληροφορίες:

• Αναγνωριστικό σεναρίου: Ένα μοναδικό αναγνωριστικό για το σενάριο.

• Όνομα σεναρίου: Ένα σύντομο, περιγραφικό όνομα για το σενάριο.

• Πηγή: Η οντότητα (χρήστης, σύστημα ή γεγονός) που ξεκινά το σενάριο.

• Ερέθισμα: Το γεγονός ή η συνθήκη που πυροδοτεί και την οποία το σύστημα πρέπει να αντιμετωπίσει.

• Περιβάλλον: Το λειτουργικό πλαίσιο ή η συνθήκη υπό την οποία το σύστημα βιώνει το ερέθισμα.

• Τεχνούργημα: Τα δομικά στοιχεία ή άλλα στοιχεία του συστήματος που επηρεάζονται από το ερέθισμα.

• Απόκριση: Το αποτέλεσμα ή η συμπεριφορά που εμφανίζει το σύστημα ως αντίδραση στο ερέθισμα.

• Μέτρο απόκρισης: Τα κριτήρια ή η μετρική βάσει των οποίων αξιολογείται η απόκριση του συστήματος.

Δείτε επίσης

Από τον Ιανουάριο του 2023, το arc42 παρέχει ένα πραγματιστικό μοντέλο ποιότητας, που προτείνει την επισήμανση των απαιτήσεων ποιότητας με hashtags ή ετικέτες όπως #flexible, #efficient, #usable, #operable, #testable, #secure, #safe, #reliable.

11. Κίνδυνοι και τεχνικό χρέος

Γνωστοί τεχνικοί κίνδυνοι ή τεχνικό χρέος. Ποια πιθανά προβλήματα υπάρχουν μέσα ή γύρω από το σύστημα; Για τι αισθάνεται άσχημα η ομάδα ανάπτυξης;

Περιεχόμενο

Ένας κατάλογος εντοπισμένων τεχνικών κινδύνων ή τεχνικών χρεών, ταξινομημένος κατά προτεραιότητα

Κίνητρο

«Η διαχείριση κινδύνου είναι διαχείριση έργου για ενήλικες» (Tim Lister, Atlantic Systems Guild.)

Αυτό πρέπει να είναι το σύνθημά σας για τη συστηματική ανίχνευση και αξιολόγηση κινδύνων και τεχνικών χρεών στην αρχιτεκτονική, που θα χρειαστούν τα ενδιαφερόμενα μέρη της διοίκησης (π.χ. διευθυντές έργου, ιδιοκτήτες προϊόντος) ως μέρος της συνολικής ανάλυσης κινδύνου και του σχεδιασμού μέτρων.

Μορφή

Κατάλογος κινδύνων ή/και τεχνικών χρεών, πιθανώς με προτεινόμενα μέτρα για την ελαχιστοποίηση, μετριασμό ή αποφυγή κινδύνων ή τη μείωση τεχνικών χρεών.