03 Ανάλυση Απαιτήσεων καιΣχεδιασμός Λογισμικού

Τεχνολογία Λογισμικού

Σχολή Hλεκτρολόγων Mηχανικών & Mηχανικών YπολογιστώνΕθνικό Μετσόβιο Πολυτεχνείο

Χειμερινό εξάμηνο 2017‐18

Δρ. Κώστας Σαΐδης ﴾saiko@di.uoa.gr﴿

Περιεχόμενα1. Οι απαιτήσεις λογισμικού και τα είδη τους

2. Από την ανάλυση απαιτήσεων στη σύνταξη τωνπροδιαγραφών και ο ρόλος του επικεφαλής μηχανικού﴾Software Architect﴿

3. Μοντελοποίηση απαιτήσεων / προδιαγραφών & σχεδιασμού4. Σχεδιαστικές αρχές λογισμικού5. Η έννοια του τεχνικού χρέους ﴾technical/design/code debt﴿

2

1. Ανάλυση απαιτήσεων

3

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

Απαίτηση: Τι θέλουμε να κάνει το λογισμικόΙκανοποίηση απαίτησης: Πώς το λογισμικό καλύπτει τηναπαίτηση ﴾σχεδιαστική απόφαση και υλοποίηση﴿.

Εκτός, βέβαια, αν η υποστήριξη κάποιας τεχνολογίας είναι ρητήαπαίτηση

4

Είδη απαιτήσεωνΛειτουργικές απαιτήσειςΜη λειτουργικές απαιτήσειςΑπαιτήσεις συστήματοςΑναδυόμενες απαιτήσεις

5

Λειτουργικές απαιτήσειςΟι απαιτήσεις της λειτουργίας του λογισμικού ﴾συνήθως ηνέα λειτουργικότητα που πρέπει να αναπτυχθεί στο πλαίσιοτου έργου﴿Παραδείγματα: διαπίστευση και δικαιοδοσία χρηστών,επιχειρησιακή λογική, περιπτώσεις και σενάρια χρήσης,διαχειριστικές λειτουργίες

6

Διαπίστευση χρηστών ﴾userauthentication﴿

Σημεία εισόδου στο σύστημα ﴾entry‐points﴿ ‐ μηχανισμοίδιαπίστευσης χρηστώνΕπιβεβαίωση ότι ο χρήστης είναι:

"υπαρκτός" ﴾π.χ. ο λογαριασμός του είναι εγγεγραμμένοςστον "πίνακα" των χρηστών της ΒΔ﴿"έγκυρος" ﴾π.χ. γνωρίζει το προσωπικό του "μυστικό"που έχει συνδεθεί με το λογαριασμό του﴿"ενεργός" ﴾π.χ. δεν έχει απενεργοποιηθεί από τοδιαχειριστή﴿

7

Δικαιοδοσία χρηστών ﴾userauthorization﴿

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

Στατική ή δυναμική ανάθεση/ανάκληση δικαιωμάτων;ΡόλοιAccess Control Lists ﴾ACLs﴿Guards

8

Επιχειρησιακή λογική ﴾business logic﴿Οι επιχειρησιακές διαδικασίες ﴾business processes﴿Οι επιχειρησιακοί κανόνες ﴾business rules﴿

Μερική ή πλήρης "ηλεκτρονικοποίηση" των λειτουργιών τουοργανισμού

9

Πιο απλάΤα υποστηριζόμενα σενάρια και περιπτώσεις χρήσης ﴾usecases﴿ του λογισμικούΟι ενέργειες, λειτουργίες και διαδικασίες που εκτελούν οιχρήστες μέσω του συστήματος

10

Διαχειριστικές λειτουργίες﴾administrative functions﴿

Ποιες είναι οι διαχειριστικές λειτουργίες;Πώς εκτελούνται;

Θα παραμετροποιούνται από το χρήστη και πόσο;

11

Λειτουργίες αναφορών ﴾reportingrequirements﴿

Τι αναφορές απαιτούνται ;Πόσο παραμετροποιήσιμες πρέπει να είναι;

Ποιος έχει δικαίωμα να τις προσπελαύνει;

12

Μη λειτουργικές απαιτήσειςΑπαιτήσεις για ποιοτικά χαρακτηριστικά του λογισμικού

Διαθεσιμότητα ‐ Ανάνηψη από καταστροφέςΑσφάλεια ‐ ΑκεραιότηταΕυελιξία ‐ Επεκτασιμότητα

Απόδοση ‐ ΑπροκρισιμότηταΥποστήριξη διεθνών προτύπων

Καθορίζουν σε μεγάλο βαθμό την επιτυχία του έργου

13

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

14

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

15

Στην πράξηΣτην πράξη, κάποιες απαιτήσεις μπορεί να βρίσκονται"κάπου ανάμεσα" στα παραπάνω είδηΑλλά αυτό ποικίλει ανάλογα με το υπό ανάπτυξη λογισμικό,το περιβάλλον λειτουργίας του και τους εμπλεκόμενουςφορείς ‐ χρήστες του

Ας δούμε μερικά παραδείγματα

16

Τήρηση ημερολογίων ﴾audit tracking﴿Ποιες ενέργεις καταγράφονται σε ημερολόγια;Σε ποιο βαθμό λεπτομέρειας;Για ποιο σκοπό και με ποια τελική χρήση;

17

Μαζική εισαγωγή / εξαγωγή δεδομένων﴾Data import / export﴿

Απατείται η μαζική εισαγωγή / εξαγωγή δεδομένων;Θα παραμετροποιείται από το χρήστη και πόσο;Ποιοι μορφότυποι αρχείων / δεδομένων θα πρέπει ναυποστηρίζονται;

18

Υποστήριξη διεθνούς προτύπουΑνάλογα με την περίπτωση, μπορεί να επηρεάζει:

Ένα συγκεκριμένο συστατικόΈνα υποσύνολο των συστατικών

Το σχεδιασμό συνολικά

19

Διαλειτουργικότητα ﴾interoperability﴿Το υπό ανάπτυξη σύστημα θα διαλειτουργεί με τρίτασυστήματα;Τι είδους δεδομένα θα ανταλλάσονται;

Με ποιους μηχανισμούς, μορφότυπους και πρωτόκολλα;

20

Νομικές ή κανονιστικές απαιτήσειςΤο υπό ανάπτυξη σύστημα θα πρέπει να είναι σύννομο﴾προσωπικά δεδομένα, πνευματικά δικαιώματα, κτλ.﴿

Το υπό ανάπτυξη σύστημα μπορεί να διέπεται απόσυγκεκριμένο νομικό ή κανονιστικό πλαίσιο ﴾για παράδειγμα,πληροφοριακά συστήματα δημοσίου τομέα﴿.

21

Ορισμός των απαιτήσεωνΣαφήνεια ﴾η απαίτηση είναι σαφώς διατυπωμένη﴿Συνέπεια ﴾η μία απαίτηση δεν αντιβαίνει με την άλλη﴿

Πληρότητα ﴾η απαίτηση καλύπτει όλες τις περιπτώσεις﴿Επαληθευσιμότητα ﴾η απαίτηση μπορεί να ελεγχθεί σε σχέσημε την υλοποίηση﴿

22

ΕπίσηςΣε μεγάλα έργα

Καταγωγή/γενεαλογία απαίτησηςΠοιος τη ζήτησεΠοιον επιχειρησιακό στόχο εξυπηρετεί

Για παράδειγμα, θα πρέπει να γνωρίζει η ομάδα του έργου αν "τοζητάει ο διευθυντής"

23

Έγγραφο ανάλυσης απαιτήσεωνΠεριγραφή σε φυσική γλώσσα:

Σκοπός του συστήματοςΚατηγορίες χρηστών ﴾users & stakeholders﴿Εμβέλεια του συστήματος

ΠεριορισμοίΠαραδοχέςΑπαιτήσεις ﴾λειτουργικές ή μη﴿

24

2. Από την ανάλυση απαιτήσεων στησύνταξη των προδιαγραφών και ορόλος του επικεφαλής μηχανικού﴾Software Architect﴿

25

Ζητούμενα από το κείμενο τωντεχνικών προδιαγραφών

Να προσδιορίσουν τον τρόπο με τον οποίο το λογισμικό θαικανοποιήσει τις απαιτήσεις

26

ΣυγκεκριμέναΑρχιτεκτονικός σχεδιασμός και συστατικά του λογισμικού

Σαφής περιγραφή της αλληλεπίδρασης του λογισμικού με τοπαραγωγικό του περιβάλλον ﴾production environment﴿Λεπτομερής προδιαγραφή των λειτουργιών και τωνδιαδικασιών που υποστηρίζονται από το λογισμικόΣύνδεση των προδιαγραφών με τις απαιτήσεις ﴾πηγή/προέλευση προδιαγραφής﴿Καθορισμός κριτηρίων αποδοχής / απόρριψης ﴾τμημάτων ήόλου﴿ του συστήματος

27

Έλεγχοι αποδοχής ﴾acceptance tests﴿Έλεγχοι που καθορίζουν την αποδοχή ή την απόρριψησυστατικών ή λειτουργιών ή "οθονών" του λογισμικούΕίναι καλή πρακτική να έχουν προβλεφθεί ﴾μερικώς ήπλήρως﴿ στις προδιαγραφέςΈνας από τους κύριους στόχους ένταξης ελέγχων στον κύκλοτου λογισμικού είναι η ελαχιστοποίηση των σφαλμάτων πουθα προκύψουν κατά τους ελέγχους αποδοχής

28

Σχεδιαστικές αποφάσειςΓια να μετατραπούν οι υψηλού επιπέδου απαιτήσεις τουλογισμικούΣε χαμηλού επιπέδου τεχνικές προδιαγραφές αυτούΘα πρέπει να παρθούν συγκεκριμένες σχεδιαστικέςαποφάσεις

29

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

Από την άλλη δεν είναι αποδεκτό να προκύψει στην πορείαυλοποίησης μιας προδιαγραφής ένα ζήτημα που θα"ακυρώσει" το σχεδιασμόΤο ότι θα τον αλλάξει είναι ﴾σχεδόν﴿ βέβαιο!

30

Θυμηθείτε

31

Κοινός τόποςΗ ανάλυση των απαιτήσεων πρέπει να καταλήξει σε ένακοινά αποδεκτό ζητούμενο

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

32

Θυμηθείτε από την εισαγωγήΣτα μεγάλα έργα λογισμικού εμπλέκονται πολλοί συμμετέχοντες:

Χρήστες

ΠελάτεςΔιοίκηση ﴾ακόμα και Μέτοχοι ή Επενδυτές﴿ΑναλυτέςΠρογραμματιστές

ΔοκιμαστέςΣχεδιαστές διεπαφώνΥπεύθυνοι έργουκτλ.

33

Ο ρόλος του Software Architect

Διαχείριση της πολυπλοκότητας

50% αρχιτεκτονική ﴾ουσιώδης πολυπλοκότητα﴿50% επικοινωνία ﴾τεχνητή πολυπλοκότητα﴿

με τους stakeholdersμε την επιχειρησιακή ομάδα έργου ﴾Project Manager,Business Analyst, κ.ά﴿με την ομάδα ανάπτυξης ﴾engineers﴿

34

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

Ο Architect θα πρέπει να κάνει το διερμηνέα και να "μιλάει"τη γλώσσα και των τριών

35

Ιεράρχηση απαιτήσεωνΔεν είναι όλες οι απαιτήσεις εξίσου σημαντικέςΜια μικρή ‐θεωρητικά‐ απαίτηση μπορεί να οδηγήσει τοέργο εκτός δρόμου/στόχου

Η ομάδα ανάπτυξης ή η επιχειρησιακή ομάδα μπορεί ναμη δώσουν προσοχή ﴾"αφού το ζητάει ο πελάτης"﴿Ο stakeholder ενδέχεται να μην το καταλάβει

Ο Architect πρέπει να το διαγνώσει έγκαιρα και να προτείνειεναλλακτικές

36

ΑντίστοιχαΜια "ακριβή" απαίτηση μπορεί να έχει πιο "φθηνή"εναλλακτικήΜια "σύνθετη" απαίτηση μπορεί να έχει πιο "απλή"εναλλακτικήκ.ο.κ

37

ΠροσοχήΟ ασφαλέστερος τρόπος να αποτύχει ένα έργο είναι ναεπιτραπεί στις "λάθος" απαιτήσεις να γίνουν προδιαγραφές!

38

ΣυμπέρασμαΟ Architect θα πρέπει να έχει απευθείας επαφή με τουςstakeholders

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

Ενώ παράλληλα σχεδιάζει το σύστημαΓια να είναι σε θέση να φιλτράρει τις "λάθος" απαιτήσεις

Και να μεταφράσει τις υπόλοιπες σε προδιαγραφές γιατην ομάδα ανάπτυξης

39

The belief that complex systems require armies ofprogrammers and designers is wrong. A system that is notunderstood in its entirety, or at least to a significant degree ofdetail by a single individual, should probably not be built.

N. Wirth

40

Superman

By J.Schulenklopper, E. Rommes 41

Για να γίνεις SupermanΕνδεικτικά

Ενσυναίσθηση ﴾empathy﴿Για τις έγνοιες ﴾concerns﴿ όλων των εμπλεκόμενων

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

Επικοινωνιακή ικανότηταΣυνεχής επικοινωνία με όλους τους εμπλεκόμενους γιατην εύρεση των βέλτιστων συμβιβασμών ﴾trade‐offs﴿

ΕμπειρίαΓια να μπορούν να γίνουν καλά όλα τα παραπάνω

42

3. Οπτικοποίηση και μοντελοποίησηαπαιτήσεων / προδιαγραφών &σχεδιασμού

43

Μοντελοποίηση και οπτικοποίησηαπαιτήσεων/προδιαγραφώνΕπικοινωνία των ζητούμενων

Διαγράμματα ροής ﴾flow charts﴿

Διαγράμματα ροής δεδομένων ﴾data flow diagrams﴿Πίνακες απόφασης ﴾decision tables﴿Δέντρο απόφασης ﴾decision trees﴿Mind Maps

44

Μοντελοποίηση σχεδιασμούΕπικοινωνία του συστήματος και των συστατικών του

Αντικειμενοστραφές μοντέλο

ΨευδοκώδικαςΔιαγράμματα οντοτήτων‐συσχετίσεων ﴾Entity‐Relationshipdiagrams﴿Οντολογίες ﴾ontologies﴿Πρότυπα σχεδίασης ﴾design patterns﴿

45

UMLΕνοποιημένη γλώσσα μοντελοποίησης

Μοντελοποίηση απαιτήσεων και προδιαγραφών

Μοντελοποίηση σχεδιασμού

46

Γιατί αυτός ο διαχωρισμός;It is almost always incorrect to begin the decomposition of asystem into modules on the basis of a flowchart. We proposeinstead that one begins with a list of difficult design decisionsor design decisions which are likely to change. Each module isthen designed to hide such a decision from the others. Since,in most cases, design decisions transcend time of execution,modules will not correspond to steps in the processing.

David Parnas

47

Η έμφασή μας στο μάθημαΣε επόμενες διαλέξεις

Αντικειμενοστραφές μοντέλοUML

Design Patterns

48

Διάγραμμα ροής ﴾flow chart﴿

49

Διάγραμμα ροής δεδομένων ﴾data flowdiagram﴿

50

Πίνακας αποφασης ﴾decision table﴿Με εφαρμογή στον έλεγχο λογισμικού ﴾testing﴿

51

Δέντρο απόφασης ﴾decision tree﴿Με εφαρμογές στην επιχειρησιακή έρευνα και στη μηχανικήμάθηση

52

Mind Map

53

Ψευδοκώδικας

54

55

Οντολογία ﴾ontology﴿

56

4. Σχεδιαστικές αρχές λογισμικού

57

Αφαίρεση ﴾Abstraction﴿Θεμελιώδης έννοια

"Η εννοιολογική διαδικασία κατά την οποία προκύπτουνγενικοί κανόνες από την εξέταση επιμέρους παραδειγμάτων."﴾Wikipedia﴿Χρησιμοποιείται σε πολλές επιστήμες.

Αποτελεί το κύριο εργαλείο σχεδιασμού.

58

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

59

Παράδειγμαinterface Item {  String getId()  void setId(String id)  Map<String, Object> toMap()  void fromMap(Map<String, Object> map)}

interface Datastore {  Item load(String id)  void save(Item item)}

60

Βελτίωση ﴾Refinement﴿Συμπληρωματική διαδικασία της αφαίρεσης

Τμηματική προσαρμογή των αφαιρέσεων σε νέες απαιτήσεις,περιορισμούς ή αποφάσεις

61

Παράδειγμαinterface Datastore {  boolean exists(String id)  void load(String id, Function<Item> callback)  void save(Item item, Function<Item> callback)}

62

RefactoringΗ διαδικασία επαναπροσαρμογής του κώδικα ως τμήμακάποιας βελτιωτικής απόφασηςΑυτοματοποιείται από πολλά IDEs

Θα τη δούμε λεπτομερώς σε επόμενη διάλεξη

63

Τμηματοποίηση ﴾modularity﴿Αναλύουμε ένα πολύπλοκο σύστημα σε επιμέρουςαπλούστερα τμήματαΣχεδιάζουμε ξεχωριστά το ένα τμήμα από το άλλο

Συνθέτουμε ξανά τα τμήματα και τις αλληλεπιδράσεις τουςσε ένα ενιαίο σύνολοΜε σκοπό τη διευκόλυνση της υλοποίησης, της συντήρησηςκαι της εξέλιξης του λογισμικού

64

The most difficult design task is to find the most appropriatedecomposition of the whole into a module hierarchy,minimizing function and code duplications.

N. Wirth

65

Απόκρυψη πληροφορίας ﴾informationhiding﴿

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

Παροχή σταθερών interfaces ﴾αφαιρέσεων﴿ για τηνεπικοινωνία μεταξύ των τμημάτων

66

Συναφείς έννοιες / αρχέςΕνθυλάκωση ﴾encapsulation﴿Διαχωρισμός ενδιαφερόντων ﴾separation of concerns﴿

67

Ενθυλάκωση ﴾encapsulation﴿Διαχωρισμός της δομής από τη συμπεριφορά ενόςσυστατικούΔιαχωρισμός της αφαίρεσης από την υλοποίησή της

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

68

Παράδειγμαclass MySQLDatastore implements Datastore {  private Connection con  //encapsulation  public boolean exists() {    String query = "select 1 from items where item = $"    ResultSet rs = con.execute(query, getId())    return !rs.isEmpty()  }  ...}

69

Διαχωρισμός ενδιαφερόντων﴾separation of concerns﴿

Κάθε τμήμα του λογισμικού επικεντρώνεται στην επίλυσηενός ξεχωριστού ζητήματος ﴾concern﴿

Αρχιτεκτονικά επίπεδα ﴾επίπεδο παρουσίασης, επίπεδοεπιχειρησιακής λογικής, επίπεδο πρόσβασης δεδομένων﴿

70

Παράδειγμα

Θα επανέλθουμε

71

Επαναχρησιμοποίηση ﴾reuse﴿Το λογισμικό δεν πρέπει να ανακαλύπτει κάθε φορά εκ νέουτον τροχόΟι καλές αφαιρέσεις και τα καλώς διαχωρισμένα συστατικάείναι εύκολο να επαναχρησιμοποιηθούν

72

Παράδειγμαvar animals = ["dog", "cat", "fish"]var len = function(s) { return s.length; }var sum = function(a, b) { return a+b; }animals.map(len).reduce(sum, 0); //10

73

Μήπως ο ίδιος ο κώδικας είναι τοdesign;

TEX would have been a complete failure if I had merelyspecified it and not participated fully in its initialimplementation. The process of implementation constantly ledme to unanticipated questions and to new insights about howthe original specifications could be improved.

Donald Knuth

74

Πρόσθετες σχεδιαστικές αρχές ﴾designprinciples﴿Πώς να δομήσουμε και να υλοποιήσουμε τις αφαιρέσεις﴾abstractions﴿

75

Μην επαναλαμβάνεσαι ﴾Don't RepeatYourself﴿

"Every piece of knowledge must have a single, unambiguous,authoritative representation within a system."

A. Thomas, D. Hunt

76

Μόνο μια φορά ﴾Once and Only Once﴿Αρχή του Extreme Programming ﴾XP﴿

Each and every declaration of behavior should appear Onceand Only Once.

77

DRY vs WETWET: We Enjoy TypingWET: Waste Everybody's Time

78

Εφαρμογή της αρχής DRY στην πράξηΗ επανάληψη ﴾duplication﴿ αυξάνει την τυχαία/τεχνητήπολυπλοκότητα του συστήματος ﴾accidental complexity﴿.Οπουδήποτε στον κύκλο ζωής του λογισμικού υπάρχουν"χειροκίνητες" διαδικασίες, θα πρέπει να αυτοματοποιούνται﴾π.χ. μέσω build system, scripting, κ.ά.﴿.Αν προκύπτουν επαναλήψεις στη λογική, κάπου απαιτείται ηπροσθήκη μιας νέας αφαίρεσης.

79

Σύνολο αρχών S.O.L.I.D.Single responsibility ﴾S﴿

Open/closed ﴾Ο﴿Liskov substitution ﴾L﴿Interface segregation ﴾Ι﴿Dependency inversion ﴾D﴿

80

Μοναδική ευθύνηΚάθε κλάση/συστατικό πρέπει να έχει μία και μοναδικήευθύνη.

A class should have only one reason to change.

81

Ανοικτό/κλειστόΚάθε κλάση/συστατικό πρέπει να είναι ανοικτή σε επεκτάσεις﴾π.χ. προσθήκη νέων πεδίων ή μεθόδων﴿.Κάθε κλάση/συστατικό πρέπει να είναι κλειστή καιοριοθετημένη ﴾έτοιμη προς χρήση από τρίτα συστατικά﴿.

82

Δυνατότητα αντικατάστασηςΑν το  S  είναι υποτύπος του  Τ  τότε όλα τα αντικείμενα τουδεύτερου θα πρέπει να μπορούν να αντικατασταθούν μεαντικείμενα του πρώτου χωρίς να αλλοιωθεί κανένα από ταεπιθυμητά χαρακτηριστικά του συστήματος.

Strong behavioral subtyping.

83

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

84

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

Οι αφαιρέσεις δεν πρέπει να εξαρτώνται από λεπτομέρειες.Οι λεπτομέρειες θα πρέπει να εξαρτώνται από τις αφαιρέσεις.

85

Παράδειγμαclass DataAccessLayer {  private Function<Item> updateIndex = ...  //private MySQLDatastore store //bad  private Datastore store        //good  DataAccessLayer() {    store = new MySQLDatastore()    //bad    store = Config.get('Datastore') //good  }  void save(Item item) {    store.save(Item item, updateIndex)  }}

Dependency Inversion ﴾Injection﴿

86

5. Η έννοια του τεχνικού χρέους﴾technical/design/code debt﴿

87

Ποιοτικά ζητούμενα σχεδιασμούPerformance ‐ Scalability

Maintainability ‐ ExtensibilitySecurity ‐ SafetyRobustness ‐ Fault‐toleranceUsability ‐ Reliability

88

Σχεδιασμός = ΣυμβιβασμόςΣυνήθως δεν είναι εφικτό να γίνουν όλα καλά με την πρώτηΕπιλογή των επιθυμητών trade‐offs

89

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

90

Τέσσερα είδη

By Martin Fowler

91

Το κλασικότερο trade‐offEfficiency vs Abstraction

Programmers have spent far too much time worrying aboutefficiency in the wrong places at the wrong times; prematureoptimization is the root of all evil.

Donald Knuth

92