Ανάπτυξη και διαχείριση πληροφοριακών συστημάτων

Πρότυπα κωδικοποίησης

#define O(b,f,u,s,c,a)b(){int o=f();switch(*p++){X u:_ o s b();X c:_ o a b();default:p--;_ o;}}
#define t(e,d,_,C)X e:f=fopen(B+d,_);C;fclose(f)
#define U(y,z)while(p=Q(s,y))*p++=z,*p=' '
#define N for(i=0;i<11*R;i++)m[i]&&
#define I "%d %s\n",i,m[i]
#define X ;break;case
#define _ return
#define R 999
typedef char*A;int*C,E[R],L[R],M[R],P[R],l,i,j;char B[R],F[2];A m[12*R],malloc
(),p,q,x,y,z,s,d,f,fopen();A Q(s,o)A s,o;{for(x=s;*x;x++){for(y=x,z=o;*z&&*y==
*z;y++)z++;if(z>o&&!*z)_ x;}_	0;}main(){m[11*R]="E";while(puts("Ok"),gets(B)
)switch(*B){X'R':C=E;l=1;for(i=0;i<R;P[i++]=0);while(l){while(!(s=m[l]))l++;if
(!Q(s,"\"")){U("<>",'#');U("<=",'$');U(">=",'!');}d=B;while(*F=*s){*s=='"'&&j
++;if(j&1||!Q(" \t",F))*d++=*s;s++;}*d--=j=0;if(B[1]!='=')switch(*B){X'E':l=-1
X'R':B[2]!='M'&&(l=*--C)X'I':B[1]=='N'?gets(p=B),P[*d]=S():(*(q=Q(B,"TH"))=0,p
=B+2,S()&&(p=q+4,l=S()-1))X'P':B[5]=='"'?*d=0,puts(B+6):(p=B+5,printf("%d\n",S
()))X'G':p=B+4,B[2]=='S'&&(*C++=l,p++),l=S()-1 X'F':*(q=Q(B,"TO"))=0;p=B+5;P[i
=B[3]]=S();p=q+2;M[i]=S();L[i]=l X'N':++P[*d]<=M[*d]&&(l=L[*d]);}else p=B+2,P[
*B]=S();l++;}X'L':N printf(I)X'N':N free(m[i]),m[i]=0	X'B':_ 0 t('S',5,"w",N
fprintf(f,I))t('O',4,"r",while(fgets(B,R,f))(*Q(B,"\n")=0,G()))X 0:default:G()
;}_ 0;}G(){l=atoi(B);m[l]&&free(m[l]);(p=Q(B," "))?strcpy(m[l]=malloc(strlen(p
)),p+1):(m[l]=0,0);}O(S,J,'=',==,'#',!=)O(J,K,'<',<,'>',>)O(K,V,'$',<=,'!',>=)
O(V,W,'+',+,'-',-)O(W,Y,'*',*,'/',/)Y(){int o;_*p=='-'?p++,-Y():*p>='0'&&*p<=
'9'?strtol(p,&p,0):*p=='('?p++,o=S(),p++,o:P[*p++];}

• File Organization
• Comments
• Declarations
• Function Declarations
• Whitespace
• Examples
• Simple Statements
• Compound Statements
• Operators
• Naming Conventions
• Constants
• Macros
• Conditional Compilation
• Program Structure
• Debugging
• Portability
• ANSI C
• Special Considerations
• Make
• Project-Dependent Standards

Δομές δεδομένων

• Πίνακας (array)
• Ουρά (Queue)
• Διπλή ουρά (Dequeue)
• Συνδεδεμένη λίστα (Linked list)
• Διπλά συνδεδεμένη λίστα (Doubly linked list)
• Σύνολο (Set)
• Απεικόνιση (Map)
• Πίνακας κατακερματισμού (Hash table)
• Στοίβα (Stack)
• Δέντρο (Tree)
• Γράφημα (Graph)

Χρήση βεβαιώσεων

• Προϋποθέσεις
• Μετασυνθήκες
• Αναλλοίωτες συνθήκες (Invariants)
• Συνθήκες σύγκλισης (Convergents)

Παράδειγμα

Είσοδος:
  Α(1..Ν): πίνακας ακεραίων
  N : ακέραιος
Έξοδος:
  Β(1..Ν): πίνακας ακεραίων

Προϋποθέσεις:
  Ν >= 1
Μετασυνθήκες:
  Β(1..Ν) περιέχει τις τιμές του Α(1..Ν)

Μεταβλητές
  Ι : Ακέραιος

I := 1
Όσο Ι <= Ν
  Β(Ι) := Α(Ι)
  Αναλλοίωτη συνθήκη: Β(1..Ι) := Α(1..Ι)
  Συνθήκη σύγκλισης: Ν - Ι
  Ι := Ι + 1
Τέλος

Απλοί κανόνες

• Αυτοματοποιήστε όσα στοιχεία της διεργασίας μπορείτε
• Τακτοποιείτε τον κώδικα σε τακτά διαστήματα
• Χρησιμοποιείτε έτοιμες βιβλιοθήκες
• Βάζετε παρενθέσεις για να κάνετε τον κώδικα πιο σαφή
• Να εκφράζετε περίπλοκες δομές ελέγχου ως δεδομένα
  static const int month_days[2][12] = {
    { 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 },
    { 31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 }
  };
  
• Μετά την πρώτη έκδοση του προγράμματος, βελτιώστε τον κώδικα
• Μη διορθώνετε κακογραμμένο κώδικα, ξαναγράψτε τον
• Χρησιμοποιείτε αναδρομικές διαδικασίες για αναδρομικές δομές δεδομένων
• Να ελέγχετε την είσοδο του προγράμματός σας
• Όταν βρείτε ένα λάθος, ψάξτε για παρόμοια και για το επόμενο
• Τα σχόλια να μην επαναλαμβάνουν ό,τι λέει ο κώδικας
• Μην επεξηγείτε τον κακό κώδικα με σχόλια, ξαναγράψτε τον
• Μη χρησιμοποιείτε υπερβολικά πολλά σχόλια
• Ο κώδικας να συμφωνεί με τα σχόλια
• Αποφεύγετε τα "έξυπνα" τεχνάσματα
          int a, b;
          a ^= b;
          b ^= a;
          a ^= b;
  
          int a, b, tmp;
          tmp = a;
          a = b;
          b = tmp;
  
• Αποφεύγετε τις καθολικές μεταβλητές
• Το πρόγραμμά σας να διαβάζεται από πάνω προς τα κάτω
• Αποφεύγετε τα παράπλευρα αποτελέσματα (side effects)
• Χρησιμοποιείτε κατανοητά ονόματα μεταβλητών
• Ο κώδικάς σας να στοχεύει κύρια τους ανθρώπους
• Να χρησιμοποιείτε αποδοτικές δομές δεδομένων και αλγορίθμους
• Να στοχεύετε στην ορθότητα πριν την ταχύτητα
• Γράφετε τα σχόλια από την αρχή
• Τεκμηριώστε πριν αρχίσετε να γράφετε τον κώδικα
• Να εκτελείτε με το χέρι το κάθε τμήμα του κώδικα
• Επιθεωρείτε τον κώδικα
• Γράφετε δομημένα ακόμα και σε αδόμητες γλώσσες
• Αποφεύγετε την υπερβολική εμφώλευση
• Να χρησιμοποιείτε την κατάλληλη γλώσσα για κάθε εφαρμογή
• Προσέχετε την όψη του κώδικα
• Να χρησιμοποιείτε βεβαιώσεις
• Να γράφετε ρουτίνες ελέγχου του κώδικα
• Μη βιαστείτε να αρχίσετε

Εσωτερική και εξωτερική τεκμηρίωση

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

Βιβλιογραφία

• Εμμανουήλ Σκορδαλάκης. Εισαγωγή στην Τεχνολογία Λογισμικού, σελίδες 119-132. Εκδόσεις Συμμετρία, 1991.

• Εμμ. Α. Γιακουμάκης Τεχνολογία Λογισμικού: Απαιτήσεις Λογισμικού, σχεδίαση λογισμικού, σελίδες 157-196. Εκδόσεις Α. Σταμούλης, Αθήνα, Πειραιάς, 1994.

• Εμμ. Α. Γιακουμάκης Τεχνολογία Λογισμικού: Κωδικοποίηση, έλεγχος και συντήρηση λογισμικού. σελίδες 17-54. Εκδόσεις Α. Σταμούλης, Αθήνα, Πειραιάς, 1993.

• L.W. Cannon, R.A. Elliott, L.W. Kirchhoff, J.H. Miller, J.M. Milner, R.W. Mitze, E.P. Schan, N.O. Whittington, Henry Spencer, David Keppel, and Mark Brader. Recommended C style and coding standards. Available online http://sunland.gsfc.nasa.gov/info/cstyle.html (December 2001). Updated version of the Indian Hill C Style and Coding Standards paper.

• Edsger Wybe Dijkstra. Go to statement considered harmful. Communications of the ACM, 11(3):147–148, March 1968.

• Richard Stallman et al. GNU coding standards. Available online http://www.gnu.org/prep/standards_toc.html (December 2001), October 2001.

• The FreeBSD Project. Style – Kernel Source File Style Guide, December 1995. FreeBSD Kernel Developer's Manual: style(9).

• Andrew Hunt and David Thomas. The Pragmatic Programmer: From Journeyman to Master. Addison Wesley Longman, 2000.

• Brian W. Kernighan and Rob Pike. The Practice of Programming. Addison-Wesley, 1999.

• Brian W. Kernighan and P. J. Plauger. Software Tools. Addison-Wesley, 1976.

• Brian W. Kernighan and P. J. Plauger. The Elements of Programming Style. McGraw-Hill, second edition, 1978.

• Karl Lieberherr and Ian Holland. Assuring good style for object-oriented programs (ftp://ftp.ccs.neu.edu/pub/research/demeter/documents/papers/LH89-law-of-demeter.ps). IEEE Software, pages 38–48, September 1989.

• Roger S. Pressman. Software Engineering: A Practitioner's Approach, pages 420–425. McGraw-Hill, 1987.

• Roger S. Pressman. Software Engineering: A Practitioner's Approach, pages 413–425. McGraw-Hill, fifth edition, 2000. European Adaptation. Adapted by Darrel Ince.

• Charles Simonyi. Hungarian notation (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvsgen/html/hunganotat.asp). Available online http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvsgen/html/hunganotat.asp (December 2001), November 1999. Microsoft Developer Network Library.

• Ian Sommerville. Software Engineering, pages 260–284,392–416. Addison-Wesley, sixth edition, 2001.

• Henry Spencer. The Ten Commandments for C programmers (annotated edition). ;login:, 18(2):29–31, March slash April 1993.

• Sun Microsystems Inc. Java code conventions (http://java.sun.com/docs/codeconv/). Available online http://java.sun.com/docs/codeconv/ (December 2001), April 1999.

Ασκήσεις

1. Ξαναγράψτε μερικά από τα παλιά σας προγράμματα σύμφωνα με τις αρχές του μαθήματος αυτού.
2. Αξιολογείστε προγράμματα ανοιχτού κώδικα που θα βρείτε στο Internet ως προς τις αρχές κωδικοποίησης που ακολουθούν.
3. Διαβάστε προσεκτικά έναν πλήρη οδηγό ύφους προγραμματισμού (βλ. βιβλιογραφία).

Εργαλεία και τεχνικές ανάπτυξης

Ταξινόμηση εργαλείων

• Εργαλεία ανάλυσης και ελέγχου του αρχικού κώδικα (source program analysis and testing tools)
• Εργαλεία διαχείρισης, ελέγχου και συντήρησης (software management, control and maintenance tools)
• Εργαλεία προδιαγραφών και ανάλυσης απαιτήσεων (Requirements, design, specification, and analysis tools)
• Εργαλεία κατασκευής και γέννησης προγραμμάτων (program construction and generation tools)
• Εργαλεία εξομοίωσης και μοντελοποίησης (software modeling and simulation tools)
• Εργαλεία υποστήριξης / περιβάλλοντα προγραμματισμού (software support systems / programming environment tools)

Διορθωτές

• Εύρεση και αλλαγή με κανονικές εκφράσεις (regular expressions)
• Αυτόματη στοίχιση (indentation)
• Ταίριαγμα παρενθέσεων, αγκυλών, κ.λπ.
• Χρωματισμός σύμφωνα με τη σύνταξη της γλώσσας
• Αναίρεση πολλαπλών επιπέδων,
• Σύνδεση με πρόγραμμα βοήθειας
• Σύνδεση με περιβάλλον μεταγλώττισης
• Ταυτόχρονη διόρθωση σε πολλαπλά παράθυρα και αρχεία
• Ιεραρχική απόκρυψη περιοχών
• Αναγνώριση της σύνταξης της γλώσσας και αυτόματος σχηματισμός του προγράμματος
• Σελιδοδείκτες
• Συμπλήρωση ή επιλογή όρων της γλώσσας

Διερμηνευτές και μεταγλωττιστές

• Εύρεση σημασιολογικών λαθών (semantic errors):
  class Test {
          int a;
  public:
          void setA(int v) { a == v; }
  };
  

  Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
  Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
  
  t.cpp
  t.cpp(4) : warning C4553: '==' : operator has no effect; did you intend '='?
  

• Δημιουργία βάσης δεδομένων του προγράμματος
• Βελτιστοποίηση
• Προσθήκη δεδομένων και εντολών για αποσφαλμάτωση και ανάλυση κατανομής
• Μεταγλώττιση για άλλα περιβάλλοντα εκτέλεσης (cross compiling)
• Δημιουργία αναφοράς των εντολών του προγράμματος

Γεννήτριες κώδικα

• Γεννήτριες εφαρμογών (application generators) (ονομάζονται και wizards).
• Γεννήτριες εκθέσεων (report generators)
• Γλώσσες εξειδικευμένου πεδίου (domain-pecific languages) (ΓΕΠ - DSL)

Παραδείγματα wizard

Αποσφαλματωτές

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

Αναλυτές κατανομής

• Την εύρεση των τμημάτων του προγράμματος που καταναλώνεται ο περισσότερος χρόνος
• Την εμφάνιση του δυναμικού δέντρου κλήσης (dynamic call graph)
• Την κατανομή του χρόνου προς τα άνω
• Την ανάλυση του ποσοστού κάλυψης της εκτέλεσης (execution coverage)

Φυλλομετρητές

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

Σύστημα βοήθειας

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

Ολοκληρωμένα περιβάλλοντα ανάπτυξης

• Η διαδικασία της κωδικοποίησης είναι περίπλοκη και χρονοβόρα.
• Για τη διευκόλυνσή της έχουν σχεδιαστεί και αναπτυχθεί περιβάλλοντα υποστήριξης της κωδικοποίησης (programming support environments).
• Σε ένα περιβάλλον υποστήριξης της κωδικοποίησης όλος ο κύκλος της κωδικοποίησης από την αρχική εισαγωγή του προγράμματος μέχρι την τελική αποσφαλμάτωση υποστηρίζεται από ένα ολοκληρωμένο σύστημα. Έτσι ένα περιβάλλον υποστήριξης της κωδικοποίησης μπορεί να περιέχει σε ένα ολοκληρωμένο περιβάλλον:
  • έξυπνο διορθωτή,
  • μεταγλωττιστή,
  • συνδέτη,
  • αποσφαλματωτή,
  • ψηφιακή τεκμηρίωση,
  • σύστημα υπολογισμού της σειράς μεταγλώττισης,
  • σύστημα σχεδιασμού της διεπαφής με το χρήστη,
  • φυλλομετρητή του πηγαίου κώδικα (source code browser) και φυλλομετρητή των κλάσεων (class browser),
  • υπολογιστή κατανομής (profiler) του κόστους της επεξεργασίας μέσα στο πρόγραμμα.
• Υπερσύνολο του περιβάλλοντος υποστήριξης της κωδικοποίησης αποτελεί το περιβάλλον τεχνολογίας λογισμικού (software engineering environment) το οποίο παρέχει υποστήριξη για όλον το κύκλο ζωής του λογισμικού συμπεριλαμβάνοντας δηλαδή υποστήριξη για
  • την ανάλυση των απαιτήσεων,
  • το σχεδιασμό,
  • την κωδικοποίηση,
  • τη διοίκηση του έργου,
  • τον έλεγχο των εκδόσεων και του σχηματισμού,
  • τη διαχείριση εξαρτημάτων λογισμικού (software components),
  • τη διασφάλιση ποιότητας και
  • τη συντήρηση.
• Η τάση που εμφανίζεται είναι τα περιβάλλοντα υποστήριξης της κωδικοποίησης τα περιέχουν όλο και περισσότερα στοιχεία από περιβάλλοντα τεχνολογίας λογισμικού ενώ παράλληλα περιβάλλοντα τεχνολογίας λογισμικού να υποστηρίζουν όλο και περισσότερο την κωδικοποίηση με τη χρήση γεννητριών κώδικα.

Περιβάλλοντα εργαλειοσυνόλων

• Διορθωτές (emacs, vi, sed, ex)
• Μεταγλωττιστές (C, C++, Fortran, Java)
• Εργαλεία διαχείρισης σχηματισμών (SCCS, RCS, CVS)
• Διερμηνευόμενες γλώσσες (sh, awk, Perl, Python, Ruby, Tcl/Tk)
• Εργαλεία μορφοποίησης προγραμμάτων (cb, indent)
• Αναλυτές κατανομής (prof, gprof, tcov)
• Αποσφαλματωτές (gdb, adb, dbx)
• Χρήσιμα αρχεία (λεξικά, χάρτες, πίνακες χαρακτήρων, πόλεων, τηλεφώνων)
• Μικρά εργαλεία επεξεργασίας αρχείων κειμένου:

  grep

  Εύρεση κανονικής έκφρασης

  egrep

  Εύρεση επαυξημένης κανονικής έκφρασης

  fgrep

  Εύρεση σταθερών συμβολοσειρών

  tr

  Μετάφραση χαρακτήρων

  fmt

  Συμπλήρωση λέξεων σε γραμμές

  wc

  Μέτρηση λέξεων, γραμμάτων, γραμμών

  rev

  Αντιστροφή των περιεχομένων κάθε γραμμής

  diff

  Εκτύπωση της διαφοράς δύο αρχείων

• Μικρά εργαλεία επεξεργασίας ταξινομημένων αρχείων και αρχείων με πεδία

  sort

  Ταξινόμηση

  uniq

  Αφαίρεση ή επιλογή επαναλαμβανόμενων γραμμών σε ένα ταξινομημένο αρχείο

  cut

  Επιλογή πεδίων

  join

  Σχεσιακή σύνδεση αρχείων

• Τρόπο σύνδεσης των παραπάνω με τη χρήση σωληνώσεων (pipes)
• Σύστημα βοήθειας που τεκμηριώνει όλο το περιβάλλον:
  1. Εντολές χρήστη
  2. Κλήσεις λειτουργικού συστήματος
  3. Βιβλιοθήκες
  4. Επικοινωνία με τις συσκευές
  5. Διάταξη αρχείων
  6. Εντολές διαχειριστή

Ολοκλήρωση της διαδικασίας μεταγλώττισης

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

Ανάπτυξη με γλώσσες εξειδικευμένου πεδίου

Σύζευξη γνωστικού πεδίου - λογισμικού

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

Απαιτήσεις διαλεκτικής επαΐοντα

Αξιοποίηση γνωστικών δεξιοτήτων

Υποστήριξη φορμαλισμών του γνωστικού πεδίου

Δημοσίευση

Διάχυση, εκπαίδευση, ανασκόπηση

Ανασκόπηση από ομότιμους επαΐοντες

Αρχειοθέτηση

Σε μορφή κατάλληλη για ανιχνευσιμότητα

Επιλεκτική επέμβαση

Βελτίωση, συντήρηση, υποστήριξη

Επαναχρησιμοποίηση

Προβλήματα των γλωσσών γενικής χρήσης

Δύσκολες στην εκμάθηση

C++ 1997 910 σ.

Απαιτούν μεγάλες βιβλιοθήκες υποστήριξης

Windows API 3433 συναρτήσεις

Ακατάλληλες για συγκεκριμένες εφαρμογές

Συστήματα πελάτη εξυπηρετητή

Απόσταση από το φορμαλισμό του επαΐοντα

Γλώσσες εξειδικευμένου πεδίου (ΓΕΠ)

• Γλώσσες προγραμματισμού προσαρμοσμένες σε συγκεκριμένο πεδίο
• Παραδείγματα
  • Lex/yacc
  • HTML
  • VHDL
  • Γλώσσες τέταρτης γενιάς
• Ευσύνοπτη περιγραφή της λογικής της εφαρμογής
• Ελάττωση της σημασιολογικής απόστασης ανάμεσα στο πρόβλημα και το πρόγραμμα

Παράδειγμα ΓΕΠ στην υλοποίηση μεταγλωττιστών

• Lex - δημιουργεί κώδικα λεκτικής ανάλυσης
• Yacc - δημιουργεί κώδικα συντακτικής ανάλυσης

Βιβλιογραφία

• Εμμανουήλ Σκορδαλάκης. Εισαγωγή στην Τεχνολογία Λογισμικού, σελίδες 241-298. Εκδόσεις Συμμετρία, 1991.

• Jon Louis Bentley. Programming Pearls. Addison-Wesley, 1986.

• Jon Louis Bentley. More Programming Pearls: Confessions of a Coder. Addison-Wesley, 1988.

• Jon Louis Bentley. More Programming Pearls: Confessions of a Coder, chapter Little Languages, pages 83–100. Addison-Wesley, 1988.

• R. C. Houghton. Software development tools: a profile. Computer, pages 63–70, May 1983.

• Roger S. Pressman. Software Engineering: A Practitioner's Approach, pages 404–420. McGraw-Hill, 1987.

• Roger S. Pressman. Software Engineering: A Practitioner's Approach, pages 868–886. McGraw-Hill, fifth edition, 2000. European Adaptation. Adapted by Darrel Ince.

• J. Christopher Ramming, editor. USENIX Conference on Domain-Specific Languages, Santa Monica, CA, USA, October 1997. Usenix Association.

• Diomidis Spinellis and V. Guruprasad. Lightweight languages as software engineering tools (http://www.dmst.aueb.gr/dds/pubs/conf/1997-DSL-Lightweight/html/paper.html). In Ramming [Ramming, 1997], pages 67–76.

• Diomidis Spinellis. Reliable software implementation using domain specific languages (http://www.dmst.aueb.gr/dds/pubs/conf/1999-ESREL-SoftRel/html/dsl.html). In G. I. Schuëller and P. Kafka, editors, Proceedings ESREL '99 — The Tenth European Conference on Safety and Reliability, pages 627–631, Munich-Garching, Germany, September 1999. ESRA, VDI, TUM, A. A. Balkema.

• Diomidis Spinellis. Notable design patterns for domain specific languages (http://www.dmst.aueb.gr/dds/pubs/jrnl/2000-JSS-DSLPatterns/html/dslpat.html). Journal of Systems and Software, 56(1):91–99, February 2001.

Ασκήσεις

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

Επαναχρησιμοποίηση

Τρόποι επαναχρησιμοποίησης

• Επαναχρησιμοποίηση διεργασίας (process reuse)
• Πρότυπα σχέδια (design patterns)
• Προγραμματισμός με εξαρτήματα (component-based programming)
• Πλαίσια εφαρμογών (application frameworks)

Πλεονεκτήματα επαναχρησιμοποίησης

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

Προβλήματα επαναχρησιμοποίησης

• Προβληματική συντήρηση
• Υποστήριξη από εργαλεία
• Το σύνδρομο του δεν ανακαλύφθηκε εδώ (not invented here syndome)
• Συντήρηση της βιβλιοθήκης των εξαρτημάτων
• Εύρεση και προσαρμογή υπαρχόντων εξαρτημάτων

Υποστήριξη από εργαλεία

c:\gcc\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..\include\g++-3\stl_
iterator.h: In method `class ostream_iterator<pair<const basic_string<char,strin
g_char_traits<char>,__default_alloc_template<false,0> >,int> > & ostream_iterato
r<pair<const basic_string<char,string_char_traits<char>,__default_alloc_template
<false,0> >,int> >::operator =(const pair<const basic_string<char,string_char_tr
aits<char>,__default_alloc_template<false,0> >,int> &)':
c:\gcc\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..\include\g++-3\stl_
algobase.h:129:   instantiated from `__copy<_Rb_tree_iterator<pair<const basic_s
tring<char,string_char_traits<char>,__default_alloc_template<false,0> >,int>,pai
r<const basic_string<char,string_char_traits<char>,__default_alloc_template<fals
e,0> >,int> &,pair<const basic_string<char,string_char_traits<char>,__default_al
loc_template<false,0> >,int> *>, ostream_iterator<pair<const basic_string<char,s
tring_char_traits<char>,__default_alloc_template<false,0> >,int> >, ptrdiff_t>(_
Rb_tree_iterator<pair<const basic_string<char,string_char_traits<char>,__default
_alloc_template<false,0> >,int>,pair<const basic_string<char,string_char_traits<
char>,__default_alloc_template<false,0> >,int> &,pair<const basic_string<char,st
ring_char_traits<char>,__default_alloc_template<false,0> >,int> *>, _Rb_tree_ite
rator<pair<const basic_string<char,string_char_traits<char>,__default_alloc_temp
late<false,0> >,int>,pair<const basic_string<char,string_char_traits<char>,__def
ault_alloc_template<false,0> >,int> &,pair<const basic_string<char,string_char_t
raits<char>,__default_alloc_template<false,0> >,int> *>, ostream_iterator<pair<c
onst basic_string<char,string_char_traits<char>,__default_alloc_template<false,0
> >,int> >, input_iterator_tag, ptrdiff_t *)'
c:\gcc\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..\include\g++-3\stl_
algobase.h:161:   instantiated from `__copy_dispatch<_Rb_tree_iterator<pair<cons
t basic_string<char,string_char_traits<char>,__default_alloc_template<false,0> >
,int>,pair<const basic_string<char,string_char_traits<char>,__default_alloc_temp
late<false,0> >,int> &,pair<const basic_string<char,string_char_traits<char>,__d
efault_alloc_template<false,0> >,int> *>,ostream_iterator<pair<const basic_strin
g<char,string_char_traits<char>,__default_alloc_template<false,0> >,int> >,__fal
se_type>::copy(_Rb_tree_iterator<pair<const basic_string<char,string_char_traits
<char>,__default_alloc_template<false,0> >,int>,pair<const basic_string<char,str
ing_char_traits<char>,__default_alloc_template<false,0> >,int> &,pair<const basi
c_string<char,string_char_traits<char>,__default_alloc_template<false,0> >,int>
*>, _Rb_tree_iterator<pair<const basic_string<char,string_char_traits<char>,__de
fault_alloc_template<false,0> >,int>,pair<const basic_string<char,string_char_tr
aits<char>,__default_alloc_template<false,0> >,int> &,pair<const basic_string<ch
ar,string_char_traits<char>,__default_alloc_template<false,0> >,int> *>, ostream
_iterator<pair<const basic_string<char,string_char_traits<char>,__default_alloc_
template<false,0> >,int> >)'
c:\gcc\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..\include\g++-3\stl_
algobase.h:188:   instantiated from `copy<_Rb_tree_iterator<pair<const basic_str
ing<char,string_char_traits<char>,__default_alloc_template<false,0> >,int>,pair<
const basic_string<char,string_char_traits<char>,__default_alloc_template<false,
0> >,int> &,pair<const basic_string<char,string_char_traits<char>,__default_allo
c_template<false,0> >,int> *>, ostream_iterator<pair<const basic_string<char,str
ing_char_traits<char>,__default_alloc_template<false,0> >,int> > >(_Rb_tree_iter
ator<pair<const basic_string<char,string_char_traits<char>,__default_alloc_templ
ate<false,0> >,int>,pair<const basic_string<char,string_char_traits<char>,__defa
ult_alloc_template<false,0> >,int> &,pair<const basic_string<char,string_char_tr
aits<char>,__default_alloc_template<false,0> >,int> *>, _Rb_tree_iterator<pair<c
onst basic_string<char,string_char_traits<char>,__default_alloc_template<false,0
> >,int>,pair<const basic_string<char,string_char_traits<char>,__default_alloc_t
emplate<false,0> >,int> &,pair<const basic_string<char,string_char_traits<char>,
__default_alloc_template<false,0> >,int> *>, ostream_iterator<pair<const basic_s
tring<char,string_char_traits<char>,__default_alloc_template<false,0> >,int> >)'

t.cpp:21:   instantiated from here
c:\gcc\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..\include\g++-3\stl_
iterator.h:890: no match for `ostream & << const pair<const basic_string<char,st
ring_char_traits<char>,__default_alloc_template<false,0> >,int> &'
c:\gcc\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..\include\g++-3\iost
ream.h:77: candidates are: class ostream & ostream::operator <<(char)
c:\gcc\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..\include\g++-3\iost
ream.h:78:                 class ostream & ostream::operator <<(unsigned char)
c:\gcc\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..\include\g++-3\iost
ream.h:79:                 class ostream & ostream::operator <<(signed char)

Παράδειγμα λάθους που εμφανίζεται κατά τη μεταγλώττιση προγράμματος C++ με τη χρήση της βιβλιοθήκης STL κάτω από Microsoft C/C++ compiler:

        t.cpp(24) : see reference to function template instantiation 'class std:
:basic_ostream<char,struct std::char_traits<char> > &__cdecl std::operator <<(cl
ass std::basic_ostream<char,struct std::char_traits<char> > &,const char *)' bei
ng compiled
C:\PROGRA~1\MICROS~4\VC98\INCLUDE\iterator(203) : error C2679: binary '<<' : no
operator defined which takes a right-hand operand of type 'const struct std::pai
r<class std::basic_string<char,struct std::char_traits<char>,class std::allocato
r<char> > const ,int>' (or there is no acceptable conversion)
        C:\PROGRA~1\MICROS~4\VC98\INCLUDE\iterator(203) : while compiling class-
template member function 'class std::ostream_iterator<struct std::pair<class std
::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > c
onst ,int>,char,struct std::char_traits<char> > &__thiscall std::ostream_iterato
r<struct std::pair<class std::basic_string<char,struct std::char_traits<char>,cl
ass std::allocator<char> > const ,int>,char,struct std::char_traits<char> >::ope
rator =(const struct std::pair<class std::basic_string<char,struct std::char_tra
its<char>,class std::allocator<char> > const ,int> &)'

Πρότυπα σχέδια

Τα πρότυπα σχέδια μας επιτρέπουν τη

• σύλληψη,
• τεκμηρίωση,
• οργάνωση και
• διάχυση

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

Επίσης, τα πρότυπα σχέδια περιγράφονται με τέτοιο τρόπο έτσι ώστε να μπορούν να συνδυάζονται μεταξύ τους.

Κάθε περιγραφή ενός σχεδίου περιλαμβάνει:

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

Παράδειγμα προτύπου σχεδίου

Component Composition - Structural

Intent

Motivation

Applicability

Structure

Figure 4 depicts the component interaction diagram of a filter-based spell checker built from Unix-mined and glue components. The text to be spell-checked is retrieved from the GUI edit box using a data source glue component. It is transformed into a list of words using the translate component which is a direct equivalent of the Unix tr command. The word list is then transformed into a sorted list of unique words using the sort and unique components which correspond to the Unix sort and uniq commands. At the same time, the system dictionary and a user dictionary are passed using appropriate file connectors to the merge component which merges two sorted streams; the merge component is a specialisation of sort which provides this functionality. Finally, the two sorted streams of words to be spelled and acceptable words are checked by common - derived from the Unix comm command - which outputs a list of words contained in the first stream and not contained in the second one. This stream of misspelled words is sent using the ListBoxSink glue component to a GUI list box. It is important to note that the integration of GUI elements using the same component object paradigm and the merging of two data streams could not be implemented using the standard Unix linear pipeline system.

Participants

Consequences

Implementations

Προγραμματισμός με εξαρτήματα

• τη διεπαφή του
• το πλαίσιο εφαρμογής του

• αυτόνομα
• από τρίτους

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

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

Παραδείγματα εξαρτημάτων

• 3D Modeling Components
• Accounts Interface Components
• Addressing, Postcode and ZipCode Components
• Artificial Intelligence Components
• Audio, MIDI and Sound Components
• Barcode Components
• Biometrics and Authentication Components
• Business Rules Components
• Button and Cursor Design Components
• CAD Components
• Calendar and Scheduling Components
• Charting and Graphing Components
• Code Components
• Component Development and Design
• Configuration and Initialization Components
• Credit Card Authorization Components
• Data Compression Components
• Data Conversion Components
• Data Entry Components
• Data Entry Verification Components
• Data Mining Components
• Data Storage Components
• Database Connectivity Components
• Database Management Components
• Database Reporting
• Debugging and Testing Components
• Deduplication and Data Cleansing Components
• Device Driver Components
• Diagramming Components
• DirectX Components
• Distributed Component Management
• eCommerce Components
• Email Components
• Encryption Components
• Explorer Components
• Facsimile Components
• File Handling Components
• File Upload Components
• Financial Components
• Find and Replace Components
• Function and Source Libraries
• Grid Components
• Imaging Components
• Instrumentation Components
• Internet Communication Components
• Localization Components
• Manufacturing Components
• Mapping and GIS Components
• Math and Stats Components
• Message Queuing Components
• Multimedia Components
• Network Administration Components
• Network Communication Components
• On-Line Analytical Processing Components
• Print and Preview Components
• Product Suites
• Reporting Components
• Resizing Components
• Search Components
• Security and Administration Components
• Serial Communication Components
• Software Licensing Components
• Software Upgrade Components
• Source Code Generators
• Speech Recognition Components
• Spelling Components
• Spreadsheet Components
• SQL Components
• Telephony Components
• Text Components
• Toolbar Components
• Training Courses
• Treeview and List Components
• User Interface Collections
• User Interface Components
• VBA and Scripting Components
• Version Control Components
• Web Site Components
• Windows API Components
• Windows Registry Components
• Wireless, Handheld and Mobile Components
• XML Components

Πλαίσια εφαρμογών

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

Μελέτη περίπτωσης: Java Beans

• Εργαλεία προγραμματισμού μπορούν να δουν τα χαρακτηριστικά ενός bean με τη διαδικασία ενδοσκόπησης (introspection). Αυτή η διαδικασία μπορεί να γίνει
  • αυτόματα με τη χρήση ανάκλασης (reflection) ή
  • με την υποστήριξη από το bean της κλάσης BeanInformation.
• Κάθε bean έχει ένα σύνολο από ιδιότητες (properties) που καθορίζουν την εμφάνιση και συμπεριφορά του. Τα εργαλεία προγραμματισμού ανακαλύπτουν τις ιδιότητες του κάθε bean και επιτρέπουν την αλλαγή τους.
• Κάθε bean μπορεί να παραμετροποιηθεί (μέσω των ιδιοτήτων του) κατά τη διάρκεια της υλοποίησης της εφαρμογής που το χρησιμοποιεί με τη χρήση ενός διορθωτή ιδιοτήτων ή ενός bean customiser.
• Τα bean χρησιμοποιούν γεγονότα (events) για να επικοινωνήσουν με άλλα bean. Κάθε bean που ενδιαφέρεται να λαμβάνει κάποιο γεγονός πρέπει να καταχωρίσει το ενδιαφέρον του με το αντίστοιχο bean που το στέλνει. Τα εργαλεία προγραμματισμού μπορούν να βρουν από ένα bean το σύνολο των γεγονότων που στέλνει και ενδιαφέρεται να λαμβάνει.
• Με τη χρήση τεχνολογίας διατήρησης (persistance) κάθε bean αποθηκεύει και ανακτά την κατάστασή του όπως αυτή έχει προγραμματιστεί κατά την υλοποίηση της εφαρμογής.
• Οι μέθοδοι που υποστηρίζει κάθε bean είναι οι δημόσιες μέθοδοι της αντίστοιχης κλάσης της Java

Περιέχοντες και επαναλήπτες στην STL

Στην STL ορίζονται οι παρακάτω πρότυποι (ως προς τα στοιχεία που περιέχουν) περιέχοντες:

list

διπλά συνδεδεμένη λίστα

queue

ουρά

deque

ουρά με πρόσβαση και στις δύο άκρες

map

απεικόνιση (π.χ. από συμβολοσειρές σε ακέραιους)

set

απεικόνιση με μοναδικά στοιχεία στο πεδίο τιμών

stack

στοίβα

vector

πίνακας

Η πρόσβαση των στοιχείων ενός περιέχοντα από τους αλγορίθμους γίνεται μέσω επαναληπτών (iterators). Οι επαναλήπτες - ανάλογα με τη δομή των δεδομένων του περιέχοντα - μπορούν να επιτρέπουν την παρακάτω ιεραρχία κινήσεων:

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

• Είσοδο και έξοδο
• Μόνο είσοδο, ή μόνο έξοδο

• advance
• distance
• ==, !=, <, >, >=, <=
• +, -
• ++, --

assign

ανάθεση τιμής

at

αναφορά σε στοιχείο

back

το τελευταίο στοιχείο

begin

επαναλήπτης που δείχνει στην αρχή της δομής

clear

διαγραφή όλων των στοιχείων

empty

αληθές αν η δομή είναι άδεια

end

επαναλήπτης που δείχνει στο τέλος της δομής

erase

διαγραφή σειράς στοιχείων

front

το πρώτο στοιχείο

insert

προσθήκη στοιχείου

operator[]

πρόσβαση σε στοιχείο

pop_back

αφαίρεση στοιχείου από το τέλος

pop_front

αφαίρεση στοιχείου από την αρχή

push_back

προσθήκη στοιχείου στο τέλος

push_front

προσθήκη στοιχείου στην αρχή

rbegin

ανάστροφος επαναλήπτης που δείχνει στην αρχή της δομής

rend

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

resize

καθορισμός του αριθμού των στοιχείων

size

αριθμός των στοιχείων

swap

εναλλαγή δύο στοιχείων μεταξύ τους

Παράδειγμα STL: απεικόνιση

Πρόσθετες λειτουργίες στην STL

Επικεφαλίδα algorithm

adjacent_find

βρίσκει δύο ίσα στοιχεία σε διπλανές θέσεις

binary_search

δυαδική ανίχνευση

copy

αντιγραφή περιοχής

copy_backward

αντίστροφη αντιγραφή περιοχής

count

μέτρημα

count_if

μέτρημα υπό συνθήκη

equal

σύγκριση περιοχών

equal_range

σύγκριση περιοχών με συγκεκριμένη ακρίβεια

fill

πλήρωση περιοχής με τιμή

fill_n

πλήρωση αριθμού στοιχείων με τιμή

find

εύρεση στοιχείου

find_end

εύρεση στοιχείου από το τέλος

find_first_of

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

find_if

εύρεση στοιχείου που να ικανοποιεί συνθήκη

for_each

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

generate

πλήρωση περιοχής με αποτέλεσμα συνάρτησης

generate_n

πλήρωση αριθμού στοιχείων με αποτέλεσμα συνάρτησης

includes

έλεγχος αν μια περιοχή εμπεριέχει μια άλλη

inplace_merge

σύζευξη δεδομένων στον ίδιο περιέχοντα

iter_swap

εναλλαγή δύο τιμών

lexicographical_compare

σύγκριση δύο περιοχών α, β για α < β

lower_bound

εύρεση μιας ελάχιστης τιμής σε περιοχή σε σχέση με μιαν άλλη τιμή

make_heap

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

max

το μέγιστο από δύο στοιχεία

max_element

εύρεση του μέγιστου στοιχείου σε περιοχή

merge

σύζευξη δύο περιοχών σε τρίτη

min

το ελάχιστο από δύο στοιχεία

min_element

εύρεση του ελαχίστου στοιχείου σε περιοχή

mismatch

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

next_permutation

υπολογισμός της επόμενης μετάθεσης σε μια περιοχή

nth_element

θέτει ένα στοιχείο στη θέση που θα έπρεπε να έχει αν η περιοχή ήταν ταξινομημένη

partial_sort

ταξινομεί τα πρώτα στοιχεία μιας περιοχής

partial_sort_copy

ταξινομεί τα πρώτα στοιχεία μιας περιοχής σε μιαν άλλη

partition

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

pop_heap

αφαίρεση στοιχείου από σωρό

prev_permutation

υπολογισμός της προηγούμενης μετάθεσης σε μια περιοχή

push_heap

προσθήκη στοιχείου από σωρό

random_shuffle

ανακατεύει μια περιοχή

remove

αφαιρεί στοιχεία ίσα με μια τιμή

remove_copy

αφαιρεί στοιχεία ίσα με μια τιμή μεταφέροντας το αποτέλεσμα σε μιαν άλλη περιοχή

remove_copy_if

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

remove_if

αφαιρεί στοιχεία για τα οποία μια συνάρτηση είναι αληθής

replace

αλλάζει τιμή σε στοιχεία ίσα με μια τιμή

replace_copy

αλλάζει τιμή σε στοιχεία ίσα με μια τιμή μεταφέροντας το αποτέλεσμα σε μιαν άλλη περιοχή

replace_copy_if

αλλάζει τιμή σε στοιχεία για τα οποία μια συνάρτηση είναι αληθής μεταφέροντας το αποτέλεσμα σε μιαν άλλη περιοχή

replace_if

αλλάζει τιμή σε στοιχεία για τα οποία μια συνάρτηση είναι αληθής

reverse

αντιστρέφει τη σειρά σε μια περιοχή

reverse_copy

αντιστρέφει τη σειρά σε μια περιοχή μεταφέροντάς την σε μιαν άλλη περιοχή

rotate

περιστρέφει τη σειρά των στοιχείων σε μια περιοχή

rotate_copy

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

search

εύρεση σειράς στοιχείων σε μια περιοχή ίσης με στοιχεία μιας άλλης

search_n

εύρεση σειράς στοιχείων σε μια περιοχή ίσης με αριθμό στοιχείων μιας άλλης

set_difference

θέτει μια περιοχή ίση με τη διαφορά των στοιχείων δύο άλλων περιοχών (διαφορά συνόλων)

set_intersection

θέτει μια περιοχή ίση με την τομή των στοιχείων δύο άλλων περιοχών (τομή συνόλων)

set_symmetric_difference

θέτει μια περιοχή ίση με τα μη κοινά των στοιχείων δύο άλλων περιοχών

set_union

θέτει μια περιοχή ίση με την ένωση των στοιχείων δύο άλλων περιοχών (ένωση συνόλων)

sort

ταξινομεί μια περιοχή

sort_heap

ταξινομεί έναν σωρό

stable_partition

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

stable_sort

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

swap

αντιστρέφει μεταξύ τους δύο στοιχεία

swap_ranges

αντιστρέφει μεταξύ τους δύο περιοχές

transform

εφαρμόζει έναν τελεστή σε μια περιοχή ή μεταξύ δύο περιοχών

unique

αφαιρεί τα όμοια στοιχεία από μια περιοχή

unique_copy

αφαιρεί τα όμοια στοιχεία από μια περιοχή μεταφέροντάς την σε μιαν άλλη περιοχή

upper_bound

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

Επικεφαλίδα numeric

accumulate

υπολογίζει ένα σύνολο πάνω σε μια περιοχή

adjacent_difference

υπολογίζει τις διαφορές τιμών μεταξύ στοιχείων μιας περιοχής

inner_product

υπολογίζει ένα εσωτερικό γινόμενο μεταξύ δύο περιοχών

partial_sum

υπολογίζει ένα μερικό άθροισμα τιμών μιας περιοχής σε μιαν άλλη

Άλλες επικεφαλίδες

utility

πρότυπη κλάση που ορίζει διάταξη σε ζεύγη τιμών

functional

κλάση που επιτρέπει συναρτησιακό προγραμματισμό

memory

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

Κατανεμημένα συστήματα βασισμένα σε εξαρτήματα

Με την εμφάνιση και την ανάπτυξη των προσωπικών υπολογιστών και καθώς οι εφαρμογές άρχισαν να γίνονται ολοένα και πιο μεγάλες και σύνθετες, άρχισαν να μεταμορφώνονται από ενιαία προγράμματα σε κομμάτια ικανά να συνεργάζονται μεταξύ τους. Στην διάσπαση των εφαρμογών σε περισσότερα από ένα μέρη, συνέβαλλε η ανάπτυξη της αρχιτεκτονικής πελάτη/εξυπηρετητή (client/server) βάσει της οποίας γινόταν η υλοποίησή τους. Κατά την αρχιτεκτονική πελάτη/εξυπηρετητή, μία διεργασία καλείται πελάτης (client process) όταν αιτείται την υλοποίηση κάποιων υπηρεσιών-μεθόδων από μία διεργασία η οποία είναι ικανή να της προσφέρει τις επιθυμητές υπηρεσίες. Η τελευταία αυτή διεργασία καλείται διεργασία του εξυπηρετητή (server process).

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

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

Τεχνολογίες διαλειτουργικότητας κατανεμημένων εφαρμογών

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

Τρία είναι τα βασικά μοντέλα των οποίων σκοπός είναι η υλοποίηση των παραπάνω και αυτά είναι:

• Η "CORBA" (Common Object Request Broker Architecture) της Object Management Group (OMG).
• H "COM/DCOM" (Component Object Model / Distributed Component Object Model) της Microsoft.
• Η "Java RMI" (Remote Method Invocation) της Sun.

OMG CORBA

Σύμφωνα με την αρχιτεκτονική που προτείνεται από την OMG, την OMA (Object Management Architecture), το κάθε κομμάτι λογισμικού παρουσιάζεται σαν αντικείμενο (Object).

Τα διάφορα αντικείμενα επικοινωνούν μεταξύ τους μέσω του ORB (Object Request Broker), ο οποίος αποτελεί το στοιχείο-κλειδί γι' αυτήν την επικοινωνία. Ο ORB παρέχει τους μηχανισμούς εκείνους μέσω των οποίων τα αντικείμενα κάνουν τις αιτήσεις και συλλέγουν τις αποκρίσεις.

Η CORBA (Common Object Request Broker Architecture) αποτελεί το πρότυπο της OMG για τον ORB.

Κατά την CORBA, ένας πελάτης ο οποίος ζητάει κάποιες υπηρεσίες από κάποιο αντικείμενο, κάνει μία αίτηση (request) η οποία μεταβιβάζεται στον ORB και ο οποίος είναι στη συνέχεια υπεύθυνος για την προώθηση της αίτησης προς τον κατάλληλο εξυπηρετητή.

Η αίτηση αυτή περιέχει όλες τις απαραίτητες πληροφορίες που απαιτούνται προκειμένου να υλοποιηθεί και αυτές είναι:

• το επιθυμητό αντικείμενο,
• επιθυμητές υπηρεσίες,
• τυχόν παραμέτρους.

Για να είναι κατανοητή όμως η αίτηση θα πρέπει να έχει μία κατάλληλη μορφή και γι' αυτό το λόγο γίνεται προς τον ORB μέσω διασυνδετών (interfaces: "Dynamic Invocation" και "IDL Stubs").

Για τον ίδιο λόγο η προώθηση της αίτησης προς τον εξυπηρετητή γίνεται μέσω διασυνδετών ("Static IDL Skeleton" και "IDL Skeleton").

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

Ένα αντικείμενο ικανοποιεί έναν διασυνδέτη εάν μπορεί να προσδιοριστεί σαν το αντικείμενο-στόχος (target object) για κάθε δυνατή αίτηση η οποία περιγράφεται από τον διασυνδέτη.

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

Οι διασυνδέτες καθορίζονται πλήρως μέσω της OMG IDL (Interface Definition Language). Η IDL δεν αποτελεί γλώσσα προγραμματισμού, όπως οι γνωστές γλώσσες προγραμματισμού, αλλά μία καθαρά περιγραφική γλώσσα η οποία δεν περιλαμβάνει δομές αλγορίθμων ή μεταβλητές. Η γραμματική της αποτελεί υποσύνολο της ANSI C++ με πρόσθετες κατασκευές για την υποστήριξη μηχανισμών για την επίκληση απομακρυσμένων λειτουργιών.

Οι πελάτες δεν είναι "γραμμένοι" σε OMG IDL αλλά σε γλώσσα για την οποία έχει προσδιοριστεί η αντιστοιχία της με την OMG IDL.

Microsoft COM/DCOM/COM+

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

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

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

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

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

στην ίδια διεργασία (in-process), τοπικός (local) ή απομακρυσμένος (remote).

Όπως έγινε σαφές, ο κάθε πελάτης μπορεί να είναι υλοποιημένος σε οποιαδήποτε γλώσσα προγραμματισμού, αρκεί αυτή να υποστηρίζει την κατασκευή και την χρήση δεικτών. Για τα "interfaces", όμως, υπάρχει και εδώ μία "IDL" (interface Definition Language) η οποία επιτρέπει και βοηθάει τους σχεδιαστές να κατασκευάζουν διασυνδέτες.

Sun Java RMI

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

Η αρχιτεκτονική ενός RMI συστήματος ακολουθεί την δομή των στρωμάτων-επιπέδων (layers). Υπάρχουν τρία (συν ένα) επίπεδα:

• Το επίπεδο "Stub/Skeleton".
• Το επίπεδο απομακρυσμένης αναφοράς (Remote Reference).
• Το επίπεδο μεταφοράς (Transport)

Η διαδικασία επίκλησης κάποιων υπηρεσιών από έναν πελάτη, δεν διαφέρει, ιδιαίτερα, σε σχέση με τις προαναφερθείσες τεχνολογίες. Ένας πελάτης, ο οποίος επιθυμεί την υλοποίηση κάποιων υπηρεσιών, υποβάλλει μία αίτηση προς το RMI-σύστημα. Στην αίτηση αυτή θα πρέπει να αναφέρονται οι κατάλληλες εκείνες πληροφορίες οι οποίες απαιτούνται για την αποστολή της αίτησης προς τον κατάλληλο εξυπηρετητή. Αυτές οι πληροφορίες-παράμετροι είναι: μία αναφορά του επιθυμητού αντικειμένου (object reference), οι επιθυμητές μέθοδοι και οι κατάλληλες παράμετροι για την υλοποίηση των μεθόδων.

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

Όμοια με την CORBA και την COM/DCOM, σε ένα RMI-σύστημα, οι πελάτες δεν έρχονται ποτέ σε απευθείας επικοινωνία με τα επιθυμητά αντικείμενα παρά μόνο μέσω των διασυνδετών αυτών των αντικειμένων. Και εδώ ο διασυνδέτης είναι αυτός που περιέχει τις μεθόδους-υπηρεσίες τις οποίες μπορεί να υλοποιήσει το αντικείμενο.

Η επικοινωνία πελάτη-αντικειμένου, σΤ ένα σύστημα RMI, είναι η ίδια ανεξάρτητα με το που βρίσκεται το επιθυμητό αντικείμενο (αν δηλαδή βρίσκεται στην ίδια διεργασία με τον πελάτη, αν βρίσκεται τοπικά ή απομακρυσμένα).

Βιβλιογραφία

• Christopher Alexander, Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl-King, and Shlomo Angel. A Pattern Language. Oxford University Press, 1977.

• Matthew H. Austern. Generic Programming and the STL: Using and Extending the C++ Standard Template Library. Addison-Wesley, 1998.

• James O. Coplien and Douglas C. Schmidt. Pattern Languages of Program Design. Addison-Wesley, 1995.

• Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.

• Institute of Electrical and Electronics Engineers, Inc., New York, NY, USA. Information Technology - Software Packages - Quality Requirements and Testing, 1998. IEEE Standard 1465-1998 (ISO/IEC 12119:1998).

• Institute of Electrical and Electronics Engineers, Inc., New York, NY, USA. Information Technology - Software Life Cycle Processes - Reuse Processes, 1999. IEEE Standard 1517-1999.

• Roger S. Pressman. Software Engineering: A Practitioner's Approach, pages 738–763. McGraw-Hill, fifth edition, 2000. European Adaptation. Adapted by Darrel Ince.

• Ian Sommerville. Software Engineering, pages 306–326. Addison-Wesley, sixth edition, 2001.

• Diomidis Spinellis and Konstantinos Raptis. Component mining: A process and its pattern language (http://www.dmst.aueb.gr/dds/pubs/jrnl/2000-IST-Components/html/comp.html). Information and Software Technology, 42(9):609–617, June 2000.

• Diomidis Spinellis. Explore, excogitate, exploit: Component mining (http://www.dmst.aueb.gr/dds/pubs/jrnl/1999-Computer-Components/html/comp.html). IEEE Computer, 32(9):114–116, September 1999.

• Clemens Szyperski. Component Software: Behind Object-Oriented Programming. Addison-Wesley, 1998.

Ασκήσεις

1. Ερευνήστε το περιβάλλον Windows και τις εφαρμογές που τρέχουν σε αυτό για παραδείγματα επαναχρησιμοποίησης.
2. Εξετάστε τα εξαρτήματα με τις μεγαλύτερες πωλήσεις που εμφανίζει η εταιρία Componentsource (http://www.componentsource.com). Τι συμπεράσματα βγάζετε για το είδος των εφαρμογών που υλοποιούνται, τα εργαλεία που χρησιμοποιούνται, και τις αντίστοιχες αδυναμίες τους;

Απόδοση και μεταφερσιμότητα

Απόδοση

• Την ταχύτητα εκτέλεσης του προγράμματος ή συγκεκριμένων λειτουργιών του.
• Τη χρήση μνήμης του προγράμματος.

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

• Ο όγκος δεδομένων κατά τη μεταφορά τους
• Η κατανάλωση ενέργειας
• Η μεταβλητότητα (variability) χαρακτηριστικών της απόδοσης.

Πότε βελτιστοποιούμε

• Το πρόγραμμα είναι πραγματικά αργό
• Το ταχύτερο πρόγραμμα θα συνεχίσει να έχει σωστά αποτελέσματα (αντιπαράδειγμα, αλλαγή αριθμών κινητής υποδιαστολής με ακέραιους σε MP3 player)
• Το ταχύτερο πρόγραμμα είναι ευανάγνωστο
• Το ταχύτερο πρόγραμμα είναι στιβαρό (αντιπαράδειγμα έλεγχοι ορίων πινάκων στη C και στη Java)

• Ασκήσεις στο πανεπιστήμιο
• Προσωπικά προγράμματα
• Εργαλεία που δε χρησιμοποιούνται συχνά
• Προγράμματα ελέγχου
• Δοκιμαστικά προγράμματα
• Αρχέτυπα

Χρήση επεξεργαστή κατά τη διόρθωση ενός προγράμματος

Χρήση επεξεργαστή κατά την αποκωδικοποίηση MP3

Χρήση επεξεργαστή κατά τον ορθογραφικό έλεγχο

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

Τρόποι βελτιστοποίησης

Γενικές τεχνικές είναι οι παρακάτω:

• Χρήση αποδοτικότερων αλγορίθμων και δομών δεδομένων
• Ανάλυση κατανομής χρόνου του προγράμματος και βελτιστοποίηση συγκεκριμένων τμημάτων
• Υλοποίηση σε αποδοτικότερο περιβάλλον (π.χ. από 4GL σε C++)
• Ενεργοποίηση βελτιστοποιήσεων του μεταγλωττιστή
• Βελτιστοποίηση του κώδικα
• (Μη επέμβαση όταν δεν είναι απαραίτητο)

• Ενσωματωμένες συσκευές
• Μεταφορά δεδομένων
• Σχεσιακές βάσεις δεδομένων
• Γραφικά

Ανάλυση κατανομής χρόνου

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

  $ time fmt /usr/share/dict/words  >/dev/null
  
  real    0m3.238s
  user    0m2.527s
  sys     0m0.294s
  

• Την κατανάλωση πόρων του συστήματος
  
• Το χρόνο εκτέλεσης συγκεκριμένων συναρτήσεων του προγράμματος μέσα στο πρόγραμμα (π.χ. με τη χρήση της System.currentTimeMillis() στη Java ή της time() στη C).
• To χρόνο εκτέλεσης των συναρτήσεων του προγράμματος με τη χρήση ενός εργαλείου ελέγχου κατανομής χρόνου (profiler). Το παρακάτω απόσπασμα παριστάνει την κατανομή χρόνου στο πρόγραμμα συμπίεσης MP3 bladeenc:

                                    called/total       parents
  index  %time    self descendents  called+self    name           index
                                    called/total       children
  
                                                       <spontaneous>
  [1]    100.0    0.00       41.07                 main [1]
                  0.03       40.93     211/211         codecEncodeChunk [2]
                  0.00        0.06     106/106         updateProgressIndicator [34]
                  0.00        0.02       1/1           codecInit [48]
                  0.00        0.01     212/212         readSamples [61]
                  0.00        0.01     212/212         fwrite [70]
                  0.00        0.01      15/121         fprintf [39]
                  0.00        0.00       1/1           addCommandlineJob [77]
                  0.00        0.00       1/1           findConfigFile [79]
                  0.00        0.00       1/3           fopen [66]
                  0.00        0.00     211/211         be_kbhit [84]
                  0.00        0.00       2/2           timerStart [95]
                  0.00        0.00       2/2           timerStop [96]
                  0.00        0.00       1/2           fclose [97]
                  0.00        0.00       1/1           codecExit [101]
  [...]
  

• Τις φορές εκτέλεσης συγκεκριμένων εντολών. Παράδειγμα από πρόγραμμα μέτρησης γραμμάτων, λέξεων, γραμμών:

         1 -> gotsp = 1;                                 
     1,3,1 -> while ((len = read(fd, buf, MAXBSIZE)) > 0) {
         2 ->         charct += len;
  2,6151,2 ->         for (C = buf; len--; ++C) {              
      6149 ->                 if (isspace(*C)) {
      1487 ->                         gotsp = 1;
      1487 ->                         if (*C == '\n') {
       269 ->                                 ++linect;
                                      }
      1487 ->                 } else {
      4662 ->                         if (gotsp) {
       968 ->                                 gotsp = 0;
       968 ->                                 ++wordct;
                                      }
                              }
                      }
         2 -> }
         1 -> if (len == -1) {
     ##### ->         warn("%s", file);
     ##### ->         rval = 1;
  

Αποδοτικότητα των αλγορίθμων

• Η απόδοση ενός προγράμματος εξαρτάται κύρια από τους αλγορίθμους και τις δομές δεδομένων που χρησιμοποιεί.
• Πολλές φορές μπορούμε να βελτιώσουμε την απόδοση ενός αλγορίθμου αλλάζοντας εντολές.
  • Παράδειγμα 1:
    // Return the position of X in the first N elements of A; -1 if not found
    for (i = 0; i < N; i++)
            if (A[i] == X)
                    return i;
    return -1;
    
  • Παράδειγμα 2:
    A[N] = X;
    for (i = 0; A[i] != X; i++)
            ;
    if (i == N)
            return -1;
    else
            return i;
    
  • Παρατηρήστε τη διαφορά εντολών από το πρώτο στο δεύτερο παράδειγμα.
  • Μπορεί να υπάρχει αποδοτικότερος αλγόριθμος;
• Για μεγάλο όγκο δεδομένων οι παραπάνω διαφορές είναι ασήμαντες.
• Για να μετρήσουμε την απόδοση χρησιμοποιούμε τη σημειογραφία Ο().
• Αυτή δείχνει την τάξη του χρόνου ή της μνήμης που απαιτεί ένας αλγόριθμος χωρίς να λαμβάνονται υπόψη σταθεροί (ανεξάρτητοι του ν) παράγοντες.
• Παραδείγματα:
  • Γραμμική ανίχνευση Ο(ν)
  • Δυαδική ανίχνευση Ο(log ν)
  • Διπλός βρόχος Ο(ν²)
• Όταν δύο Ο() διαφέρουν μεταξύ τους θα υπάρχει πάντα κάποιος όγκος δεδομένων για τον οποίο η διαφορά θα είναι αντιληπτή και στην πράξη.
• Η σημειογραφία χρησιμοποιείται για να εξετάσουμε τόσο το χρόνο, όσο και το χώρο που απαιτεί ένας αλγόριθμος.

Παράδειγμα

• Πρώτη λύση
  for (i = L.begin(); i != L.end(); i++) {
          for (j = L2.begin(); j != L2.end(); j++)
                  if (*j == i)
                          return true;
          L2.push_back(i);
  }
  return false;
  
  Ο(ν²) χρόνος, Ο(ν) χώρος
• Δεύτερη λύση
  for (i = L.begin(), ci = 0; i != L.end(); i++, ci++)
          for (j = L.begin(), cj= 0; j < i; j++, cj++) {
                  for (k = j + 1, ck = 0; ck < ci - cj; k++, ck++)
                          if (k == j)
                                  return true;
  return false;
  
  Ο(ν³) χρόνος, Ο(1) χώρος
• Τρίτη λύση
  for (i = L.begin(), j = L.begin(); j != L.end(); i++, j++, j++)
          if (j == i)
                  return true;
  return false;
  
  Ο(ν) χρόνος, Ο(1) χώρος

Τεχνικές βελτιστοποίησης του κώδικα

• Αποδοτική χρήση του υλικού
  • ειδικές εντολές επεξεργαστή
  • συνεπεξεργαστές,
  • πολλαπλοί επεξεργαστές
  • σωλήνωση εντολών (instruction pipelining)
• Αποφυγή κλήσης του λειτουργικού συστήματος
• Οικονομία στη χρήση εξωτερικών δεδομένων (ειδικά αν το πρόγραμμα δεσμεύεται από το χρόνο εκτέλεσής τους)
• Αντικατάσταση ακριβών εντολών με φθηνές
• Ξετύλιγμα των βρόχων
• Φύλαξη ενδιάμεσων τιμών
• Ενταμίευση εισόδου και εξόδου (input / output buffering)
• Ειδικός κώδικας για τις ειδικές περιπτώσεις (έτσι ώστε οι γενικές να είναι γρήγορες). (παράδειγμα: βρόχοι σε συστήματα γραφικών).
• Προ-υπολογισμός αποτελεσμάτων
• Χρήση χαμηλότερης ακρίβειας στους υπολογισμούς
• Υλοποίηση σε γλώσσα χαμηλότερου επιπέδου (π.χ. PHP -> Java -> C -> Assembly)

Χρήση μνήμης

Κώδικας (code)

Οι εντολές του προγράμματος, τυπικά σταθερές κατά την εκτέλεσή του.

Δεδομένα (data)

Τα δεδομένα που έχουν οριστεί στατικά μέσα στο πρόγραμμα (π.χ. αρχικές τιμές) καθώς και η δυναμική μνήμη που απαιτείται κατά τη λειτουργία του (εντολή new στη Java / C++, malloc στη C). Σε πολλά προγράμματα αυτή είναι η κατηγορία της μνήμης που μας ενδιαφέρει να βελτιστοποιήσουμε.

Στοίβα (stack)

Τοπικές μεταβλητές, κλήση συναρτήσεων ιδίως σε αναδρομικές συναρτήσεις.

      1906  average shared memory size (κώδικας)
      9232  average unshared data size (δεδομένα)
       195  average unshared stack size (στοίβα)

• ιδεατή μνήμη στο δίσκο (virtual memory)
• εξωτερικό αρχείο υπό τον έλεγχο του προγράμματος
• βάση δεδομένων

Μεταφορά δεδομένων

• Συμπίεση των δεδομένων:
  • χωρίς απώλειες (lossless) (π.χ. αλγόριθμοι Lempel-Ziv, Huffman, Burrows-Wheeler)
  • με απώλειες (lossy) (π.χ. συμπίεση JPEG, MP3, MPEG)
• Κατανεμημένα αντίγραφα των δεδομένων
• Φύλαξη αντιγράφου των δεδομένων σε κρυφή μνήμη (cache memory).

Ενσωματωμένες συσκευές

• Κατανάλωση ενέργειας με
  • χρήση αποδοτικών αλγορίθμων
  • περιορισμένη χρήση περιφερειακών
  • χρήση πόρων κατά μικρά διαστήματα
• Μέγεθος κώδικα (συχνά με χρήση συμπίεσης)
• Χρήση της μη ασταθούς μνήμης (non volatile memory) (συχνά είναι αργή και περιορισμένης χωρητικότητας)

Τεχνικές ΣΒΔ

• Ορισμός δεικτών (indexes) στα κατάλληλα πεδία.
• Μη ορισμός δεικτών σε πεδία που δεν το απαιτούν.
• Βελτιστοποίηση της δομής των πινάκων
• Ελαχιστοποίηση των δεδομένων που μεταφέρονται από τον εξυπηρετητή στον πελάτη.
• Χρήση εντολών της SQL αντί για βρόχους κώδικα. Για παράδειγμα, αντικατάσταση του κώδικα
          Do While Not tblPersons.EOF
              If tblPersons("Name") = looking Then
                  MsgBox "Your number is " & tblPersons("Number")
              End If
              tblPersons.MoveNext
          Loop
  
  με τον κώδικα
          Set qryPersons = dbsDb.OpenQuery("SELECT Number from Persons Where Name ='" & looking & "'")
          Set rstPersons = qryPersons.OpenRecordset
          If Not rstTables.EOF
              MsgBox "Your number is " & rstPersons("Number")
          End If
  
• Χρήση πινάκων με ενδιάμεσα αποτελέσματα και αυτόματη ενημέρωσή τους σε νεκρούς χρόνους (π.χ. βράδυ), για στοιχεία που δεν απαιτούν απόλυτη ακρίβεια, ή με trigger procedures.
• Χρήση εργαλείων βελτιστοποίησης της βάσης του κατασκευαστή.

Μεταφερσιμότητα

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

• Να χρησιμοποιούνται μόνο στοιχεία που περιέχονται στον πρότυπο ορισμό της γλώσσας και όχι επεκτάσεις (π.χ. πίνακες με μεταβλητό μήκος στη GNU C).
• Να αποφεύγεται η χρήση "εξωτικών" στοιχείων της γλώσσας προγραμματισμού (π.χ. ο τύπος complex στη C, member templates στη C++, εσωτερικές κλάσεις στη Java) αν δεν είναι απολύτως απαραίτητο.
• Να μη βασίζεται ο κώδικας σε ιδιότητες της γλώσσας που δεν ορίζονται με συνέπεια (π.χ. το πρόσημο των χαρακτήρων στη C/C++).
• Να μη βασίζεστε στη σειρά εκτέλεσης των πράξεων (π.χ. printf("%d, %d", x++, x++) τυπώνει 0, 0 με το μεταγλωττιστή Microsoft C και 0, 1 με το μεταγλωττιστή GNU C).
• Να μη βασίζεστε στο μέγεθος των αριθμητικών τύπων. Αν και αυτό ορίζεται αυστηρά στη Java, σε άλλες γλώσσες αλλάζει συχνά ανάλογα με το μεταγλωττιστή και τον επεξεργαστή (π.χ. το μέγεθος του τύπου char * μπορεί να είναι 16, 32, ή 64 bit στη C++).
• Να μη βασίζεται ο κώδικας στη σειρά φύλαξης των byte κάθε τύπου στη μνήμη, ούτε στη σειρά φύλαξης των μελών των κλάσεων και των δομών.
• Να χρησιμοποιείτε μόνο τις πρότυπες βιβλιοθήκες ή μεταφέρσιμες βιβλιοθήκες λογισμικού ανοιχτού κώδικα (open source software).
• Αρχεία που μεταφέρονται ανάμεσα σε υπολογιστές να περιέχουν απλό κείμενο.

Απομόνωση

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

Διεθνοποίηση και τοπική προσαρμογή

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

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

en_US

Sun 05 May 2002 03:19:46 AM EEST

de_DE

Son Mai 5 03:19:46 EEST 2002

it_IT

dom 05 mag 2002 03:19:46 EEST

af_ZA

So 05 Mei 2002 03:19:46 EEST

Βιβλιογραφία

• Jon Louis Bentley. Writing Efficient Programs. Prentice-Hall, 1982.

• Andrew Deitsch, David Czarnecki, and Andy Deitsch. Java Internationalization. O'Reilly and Associates, Sebastopol, CA, USA, 2001.

• A. Dolenc, A. Lemmke, D. Keppel, and G. V. Reilly. Notes on writing portable programs in C. Available by anonymous ftp from sauna.hut.fi:pub/CompSciLab/doc, November 1990.

• David Harel. Algorithmics: the Spirit of Computing, pages 119–147. Addison-Wesley, 1987.

• Nadine Kano. Developing International Software for Windows 95 Windows NT. Microsoft Press, 1995.

• Brian W. Kernighan and Rob Pike. The Practice of Programming, pages 165–212. Addison-Wesley, 1999.

• Sandra Martin O'Donnell. Programming for the World: How to Modify Software to Meet the Needs of the Global Market. Prentice Hall, 1994.

• Roger S. Pressman. Software Engineering: A Practitioner's Approach, pages 426–428. McGraw-Hill, 1987.

• Roger S. Pressman. Software Engineering: A Practitioner's Approach, pages 494–500. McGraw-Hill, fifth edition, 2000. European Adaptation. Adapted by Darrel Ince.

• Henry Rabinowitz and Chaim Schaap. Portable C. Prentice Hall, 1990.

• Diomidis Spinellis. Optimal peripheral access using pipe-based double-buffering (http://www.dmst.aueb.gr/dds/pubs/trade/1999-login-dd/html/dd.html). ;login:, 24(4):43–45, August 1999.

• Dave Taylor. Global Software: Developing Applications for the International Market. Springer-Verlag, New York, NY, USA, 1992.

Ασκήσεις

1. Έχετε να επιλέξετε ανάμεσα σε αλγορίθμους που απαιτούν
   • 5000 + 1000 λογ₁₀ ν,
   • ν² / 1000, και
   • 50 ν πράξεις.
   Υπολογίστε πόσες πράξεις θα χρειαστούν για την επεξεργασία 10, 1.000, 1.000.000, 1.000.000.000 στοιχείων και εξηγήστε ποιόν αλγόριθμο θα διαλέγατε σε κάθε περίπτωση. Εκφράστε τα παραπάνω με τη χρήση της σημειογραφίας Ο().
2. Διαβάστε και αναλύστε πως η γλώσσα Java διευκολύνει το πρόβλημα της μεταφερσιμότητας των προγραμμάτων.
3. Αναλύστε τις τοπικές προσαρμογές που επιτρέπει το σύστημα Microsoft Windows.

Έλεγχος

Στόχοι του ελέγχου

"On January 23, 2003, a Singapore Airlines (SIA) Boeing 747-400 experienced a complete loss of information on all six integrated display units (IDU) on the flight deck instrument panels while in cruise flight from Singapore to Sydney, Australia. The pilots flew the airplane for 45 minutes using standby flight instruments while they communicated with SIA maintenance personnel about the problem. SIA maintenance personnel advised the flight crew to pull out then push back in (or cycle) the circuit breakers for the EFIS/EICAS interface units (EIU), which returned the IDUs to normal operation. The flight continued to Sydney and landed without further incident."

Μια ακραία θεώρηση της διεργασίας του ελέγχου είναι η παρακάτω:

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

Βασικές αρχές

• Κάθε έλεγχος πρέπει να αφορά μια συγκεκριμένη απαίτηση
• Η προετοιμασία των ελέγχων αρχίζει πολύ πριν την εκτέλεσή τους
• Αρχή του Pareto: 80% των λαθών θα αφορούν 20% των τμημάτων του λογισμικού
• Ο έλεγχος πρέπει να αρχίζει από τις μικρές δομικές μονάδες και να καταλήγει στο ολοκληρωμένο σύστημα
• Δεν είναι δυνατό να ελεγχθεί ένα σύστημα πλήρως
• Ο αποτελεσματικός έλεγχος εκτελείται από τρίτους

Επαλήθευση και επικύρωση

• Επαλήθευση (verification): Υλοποιούμε σωστά το λογισμικό;
• Επικύρωση (validation): Υλοποιούμε το σωστό λογισμικό;

Λογισμικό που μπορεί να ελεγχθεί

• Λειτουργικότητα
• Παρατηρησιμότητα
• Ελεγξιμότητα
• Αποσυνθεσιμότητα
• Απλότητα
• Ευστάθεια
• Τεκμηρίωση

• Λειτουργικότητα
  • Λίγα λάθη
  • Τα λάθη να μην εμποδίζουν τον έλεγχο
  • Η ανάπτυξη υλοποιεί ολοκληρωμένες λειτουργίες (που μπορούν να ελεγχθούν)
• Παρατηρησιμότητα
  • Κάθε είσοδος δημιουργεί διακριτά αποτελέσματα
  • Η κατάσταση του συστήματος και των μεταβλητών του είναι ορατή
  • Η προηγούμενη κατάσταση του συστήματος και των μεταβλητών του μπορεί να είναι ορατή (π.χ. από καταγραφές)
  • Εύκολη ανίχνευση λανθασμένων αποτελεσμάτων
  • Αυτόματη ανίχνευση εσωτερικών σφαλμάτων
  • Αυτόματη αναφορά εσωτερικών σφαλμάτων
  • Πρόσβαση στον πηγαίο κώδικα
• Ελεγξιμότητα
  • Κάθε πιθανή έξοδος μπορεί να δημιουργηθεί με κατάλληλες εισόδους
  • Όλος ο κώδικας μπορεί να εκτελεστεί με κατάλληλες εισόδους
  • Ο ελεγκτής μπορεί να μεταβάλει άμεσα την κατάσταση του λογισμικού και του υλικού
  • Η μορφή της εισόδου και της εξόδου είναι τακτική και ευνόητη
  • Οι έλεγχοι είναι εύκολο να προδιαγραφούν, να αυτοματοποιηθούν και να αναπαραχθούν.
• Αποσυνθεσιμότητα
  • Το λογισμικό αποτελείται από ανεξάρτητα αρθρώματα
  • Κάθε άρθρωμα μπορεί να ελεγχθεί αυτόνομα
• Απλότητα
  • Λειτουργική απλότητα: δεν υπάρχουν περιττές λειτουργίες
  • Δομική απλότητα: τα σφάλματα μπορούν να απομονωθούν σε συγκεκριμένα αρθρώματα
  • Απλότητα κώδικα: ο κώδικας μπορεί εύκολα να ελεγχθεί.
• Ευστάθεια
  • Το λογισμικό δεν αλλάζει συχνά
  • Οι αλλαγές στο λογισμικό ελέγχονται
  • Οι αλλαγές δεν αναιρούν προηγούμενους ελέγχους
  • Προβλήματα στο λογισμικό δεν το αχρηστεύουν
• Τεκμηρίωση
  • Κατανοητό σχέδιο λογισμικού
  • Κατανόηση της δομής του λογισμικού και των σχέσεων των τμημάτων του
  • Τεκμηρίωση των αλλαγών
  • Εύκολη πρόσβαση στην τεκμηρίωση
  • Καλή οργάνωση της τεκμηρίωσης

Κατηγορίες ελέγχων

• Στατικές τεχνικές (δεν απαιτούν την εκτέλεση του προγράμματος)
  • Στατική ανάλυση (π.χ. Java bytecode verification)
  • Επιθεώρηση (review)
    • περιήγηση (walkthrough)
    • επισκόπηση (inspection)
• Δυναμικές τεχνικές (βασίζονται στην εκτέλεση του προγράμματος)
  • Συμβολική εκτέλεση
  • Δυναμικός έλεγχος
    • έλεγχος μονάδας (unit testing)
    • έλεγχος συνένωσης (integration testing)
    • έλεγχος συστήματος (system testing)
    • έλεγχος αποδοχής (acceptance testing)

Στρατηγικές δυναμικού ελέγχου

• Στρατηγική μαύρου κουτιού (black box)
  Ελέγχουμε το λογισμικό ως ένα σύστημα με γνωστές προδιαγραφές αλλά άγνωστη υλοποίηση. Μπορούμε έτσι να βρούμε:
  • Λειτουργικότητα που απoυσιάζει ή που έχει υλοποιηθεί με λανθασμένο τρόπο
  • Λάθη διεπαφών
  • Λάθη σε δομές δεδομένων και πρόσβαση στην εξωτερική βάση δεδομένων
  • Προβλήματα απόδοσης
  • Λάθη κατά την εκκίνηση και τον τερματισμό
• Στρατηγική άσπρου κουτιού (white box) ή γυάλινου κουτιού (glass box)
  Ελέγχουμε το λογισμικό με βάση την εσωτερική δομή του. Μπορούμε έτσι να βρούμε:
  • Λογικά λάθη σε μέρη του προγράμματος που σπάνια εκτελούνται
  • Λάθη σε λογικές διαδρομές του προγράμματος που θεωρούμε πως δε θα έπρεπε να εκτελούνται
  • Τυπογραφικά λάθη σε μέρη του προγράμματος που σπάνια εκτελούνται
  Δεν μπορούμε όμως να βρούμε:
  • Μη συμμόρφωση με τις προδιαγραφές
  • Μονοπάτια που απουσιάζουν
  • Λάθη που αποκαλύπτονται με ειδικές τιμές δεδομένων

Στρατηγική μαύρου κουτιού

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

Στρατηγική άσπρου κουτιού

• Κάθε εντολή να εκτελεστεί μια τουλάχιστο φορά.
• Κάθε συνθήκη πρέπει να ελέγχεται για κάθε συνδυασμό αληθών και ψευδών τιμών.
• Κάθε βρόχος πρέπει να εκτελείται 0, 1, 2, n-1, n, και n+1 φορές.

Σχέδιο δυναμικού ελέγχου

1. Ταυτότητα
2. Εισαγωγή
   1. Στόχοι
   2. Υποδομή
   3. Έκταση του ελέγχου
   4. Παραπομπές
3. Στοιχεία προς έλεγχο
4. Χαρακτηριστικά που θα ελεγχθούν
5. Χαρακτηριστικά που δε θα ελεγχθούν
6. Μεθοδολογία
7. Κριτήρια αποδοχής
8. Κριτήρια αναστολής και απαιτήσεις επανάληψης
   1. Αναστολή ελέγχου
   2. Επανάληψη ελέγχων
9. Παραδοτέα
10. Εργασίες ελέγχου
11. Περιβάλλον ελέγχου
12. Ευθύνες
    1. Ομάδα διοίκησης ελέγχου
    2. Ομάδα ανάπτυξης
    3. Ομάδα ελέγχου
13. Προσωπικό και εκπαίδευση
    1. Προσωπικό
    2. Εκπαίδευση
14. Χρονοδιάγραμμα
15. Αντιμετώπιση προβλημάτων
16. Έγκριση

• Προδιαγραφές σχεδίου ελέγχου
• Προδιαγραφές περίπτωσης ελέγχου
  1. Αναγνωριστικό
  2. Τμήματα που θα δοκιμαστούν
  3. Καθορισμός εισόδων
  4. Καθορισμός αναμενόμενων αποτελεσμάτων
  5. Ανάγκες περιβάλλοντος
  6. Διαδικαστικές απαιτήσεις
  7. Εξαρτήσεις
• Προδιαγραφές διαδικασίας διεκπεραίωσης ελέγχου
• Έκθεση διαβίβασης οντοτήτων προς έλεγχο
• Ημερολόγιο ελέγχου
• Περιληπτική έκθεση ελέγχου

Αυτοματοποιημένος έλεγχος

• Πρέπει να προσπαθούμε οι έλεγχοι να εκτελούνται αυτόματα
• Έτσι μπορούν να εκτελούνται μετά από κάθε αλλαγή στο λογισμικό
• Έλεγχοι δομικών μονάδων μπορούν να περιλαμβάνονται στον κώδικα του προγράμματος. Παράδειγμα (με τη χρήση της κλάσης της Java Junit):
  public class MoneyTest extends TestCase { 
      private Money f12CHF; 
      private Money f14CHF; 
      private Money f28USD; 
      
      protected void setUp() { 
          f12CHF= new Money(12, "CHF"); 
          f14CHF= new Money(14, "CHF"); 
          f28USD= new Money(28, "USD"); 
      }
  }
  
  public void testMoneyMoneyBag() { 
      // [12 CHF] + [14 CHF] + [28 USD] == {[26 CHF][28 USD]} 
      Money bag[]= { f26CHF, f28USD }; 
      MoneyBag expected= new MoneyBag(bag); 
      assertEquals(expected, f12CHF.add(f28USD.add(f14CHF)));
  }
  
  public static Test suite() { 
      TestSuite suite= new TestSuite(); 
      suite.addTest(new MoneyTest("testMoneyEquals")); 
      suite.addTest(new MoneyTest("testSimpleAdd")); 
      return suite;
  }
  
• Αυτοματοποιημένοι έλεγχοι μπορούν να εκτελούνται μαζικά με τη βοήθεια εργαλείων:
  
  
  
  

Διαχείριση λαθών

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

Βιβλιογραφία

• Εμμανουήλ Σκορδαλάκης. Εισαγωγή στην Τεχνολογία Λογισμικού, σελίδες 133-155. Εκδόσεις Συμμετρία, 1991.

• Εμμ. Α. Γιακουμάκης Τεχνολογία Λογισμικού: Κωδικοποίηση, έλεγχος και συντήρηση λογισμικού. σελίδες 55-157. Εκδόσεις Α. Σταμούλης, Αθήνα, Πειραιάς, 1993.

• Kent Beck and Erich Gamma. Test infected: Programmers love writing tests. Java Report, July 1998.

• Watts S. Humphrey. Managing the Software Process, pages 171–223. Addison-Wesley, 1989.

• IEEE standard for software verification and validation plans. Published by the American National Standards Institute, 1430 Broadway, New York, New York 10018, February 1987. ANSI/IEEE Std 1012-1986.

• Institute of Electrical and Electronics Engineers, Inc., New York, NY, USA. Software Test Documentation, 1998. IEEE Standard 829-1998.

• Cem Kaner, Jack Falk, and Hung Quoc Nguyen. Testing Computer Software. Wiley, 1999.

• Roger S. Pressman. Software Engineering: A Practitioner's Approach, pages 468–522. McGraw-Hill, 1987.

• Roger S. Pressman. Software Engineering: A Practitioner's Approach, pages 426–493. McGraw-Hill, fifth edition, 2000. European Adaptation. Adapted by Darrel Ince.

• Ian Sommerville. Software Engineering, pages 419–466. Addison-Wesley, sixth edition, 2001.

Παράρτημα: έλεγχοι συμμόρφωσης στο σύστημα Windows

1	Set Up the Application
1.1	Setup program should start when CD is inserted.
1.2	Setup should also run from:
1.2.1	Control Panel's add/remove programs applet (Application Manager).
1.2.2	Taskbar's Start.Run.
1.2.3	Command line.
1.2.4	Windows Explorer (double-click the Setup program in Windows Explorer).
1.2.5	Off the Internet (as a self-extracting executable).
1.3	Aborting Setup, exiting or canceling Setup before completion should mean that:
1.3.1	Temp directories are removed.
1.3.2	Registry is rolled back (if changed).
1.3.3	No files are installed.
1.3.4	No system files are updated.
1.3.5	No program groups or folders are left on the Start menu.
1.4	Setup options should include:
1.4.1	Change name of install directory.
1.4.2	Install to compressed directory.
1.4.3	Install on a drive different from the OS. (Install application on a FAT32 drive if Windows NT is installed on NTFS, for example.)
1.4.4	Install on a system where the OS is not on C.
1.4.5	Install on a system that has no autoexec.bat or config.sys in the root of C.
1.4.6	Installation options to test:
1.4.6.1	Choose "full" or "complete" to make sure everything installs.
1.4.6.2	Choose partial options, to make sure core parts of the application are still installed.
1.4.6.3	Rerun Setup to add options not installed during the partial installation, and verify that those options have been added.
1.4.6.4	Update/patch installation from the Internet, if files are available.
1.4.6.5	Administrative installation: Install on a server, and then test a local workstation installation.
1.5	Setup should detect the following environment variables:
1.5.1	The current version of Windows.
1.5.2	A previous installation of the same application.
1.5.3	Earlier versions of the application. (Setup should upgrade these.)
1.5.4	Other, possibly newer, versions of applications it integrates with. (Test installation on machines with newest versions of Office suites and browsers, for example.)
1.5.5	Disk space, including:
1.5.5.1	Drives with "not enough" space.
1.5.5.2	Very large drives (more than 8 gigabytes [GB]).
1.5.5.3	Removable media (ZIP, Jazz).
1.5.6	The presence or absence of sound cards and other special hardware. (Setup should then select the correct installation options.)
1.5.7	Fonts:
1.5.7.1	Verify that installed fonts are visible in \Fonts folder (Control Panel).
1.5.7.2	Verify installed fonts in other applications (WordPad, Office suites).
1.5.7.3	Print hard copy using fonts and verify.
1.6	Program group/folder tests should verify that:
1.6.1	The "Change default name" option works.
1.6.2	All expected links (icons) appear.
1.6.3	All links (icons) work.
1.6.4	Only one group/folder is created.
1.7	If the installation continues across two or more CDs:
1.7.1	The installation should proceed without user intervention after the user mounts the next CD.
1.7.2	If the application accesses content on the CDs (such as Clipart) after installation, open representative files from each CD, using:
1.7.2.1	The same CD drive used to install the application.
1.7.2.2	A separate CD drive for data CDs.
1.7.2.3	Two or more drives for data CDs simultaneously.
1.8	Uninstall should:
1.8.1	Be available from Control Panel's add/remove programs applet (Application Manager).
1.8.2	Remove all program files and folders.
1.8.3	Remove all registry entries.
1.8.4	Remove the program group/folder.
1.8.5	Retain all shared files.
1.8.6	Retain all system files.
2	Start the Application
2.1	From a Start program/shortcut.
2.2	From Start, Run.
2.3	From an Explorer icon/shortcut.
2.4	From a desktop icon/shortcut.
2.5	From a command line.
2.6	By double-clicking the icon of a file associated with the application.
2.7	From a shortcut in the Startup group:
2.7.1	From a personal or common group on reboot.
2.7.2	From a common group only when changing logged-on user.
2.8	As service (when applicable):
2.8.1	Manual, automatic, disabled.
2.8.2	Log on as system account.
2.8.3	Log on as specific user:
2.8.3.1	With that user logged on.
2.8.3.2	With a different user logged on.
2.9	As a Darwin-aware application (when applicable):
2.9.1	Advertised.
2.9.2	Published.
2.10	As a second instance of the same app
3	Close the Application
3.1	Using File.Close or app's equivalent.
3.2	Using the Close button.
3.3	Using the system menu and accelerator.
3.4	From the minimized icon on the taskbar.
3.5	From the tray icon (for tray-enabled applications).
3.6	From system shutdown:
3.6.1	No dialog should appear if no "documents" are open and unsaved.
3.6.2	If unsaved "documents" are open, the user should be prompted to save them.
4	Run the Application
4.1	File I/O:
4.1.1	Open sample documents that ship with the application, or make several documents and use them in future testing.
4.1.2	Save each document in each supported format using Long File Names (max path name length, using all legal naming characters) to:
4.1.2.1	Local drives:
4.1.2.1.1	NTFS drives:
4.1.2.1.1.1	Compressed
4.1.2.1.1.2	Uncompressed
4.1.2.1.1.3	Encrypted
4.1.2.1.1.4	Through reparse point to local machine
4.1.2.1.1.5	Through reparse point to remote share
4.1.2.1.2	FAT16 drives
4.1.2.1.3	FAT32 drives
4.1.2.2	Remote (network) machines mapped to drive letters:
4.1.2.2.1	NTFS drives:
4.1.2.2.1.1	Compressed
4.1.2.2.1.2	Uncompressed
4.1.2.2.1.3	Encrypted
4.1.2.2.1.4	Through reparse point to local machine
4.1.2.2.1.5	Through reparse point to remote share
4.1.2.2.2	FAT16 drives
4.1.2.2.3	FAT32 drives
4.1.2.2.4	Win9x systems
4.1.2.2.5	Netware network
4.1.2.2.6	Macintosh systems
4.1.2.2.7	Other operating systems (if mounting systems are available)
4.1.2.3	Remote (network) machines using UNC (Uniform Naming Convention):
4.1.2.3.1	NTFS drives:
4.1.2.3.1.1	Compressed
4.1.2.3.1.2	Uncompressed
4.1.2.3.1.3	Through reparse point to local machine
4.1.2.3.1.4	Through reparse point to remote share
4.1.2.3.2	FAT16 drives
4.1.2.3.3	FAT32 drives
4.1.2.3.4	Win9x systems
4.1.2.3.5	Netware network
4.1.2.3.6	Macintosh systems
4.1.2.3.7	Other operating systems (if mounting systems are available)
4.1.3	Open each of the saved documents from each drive or share:
4.1.3.1	Verify that document is unchanged from the original.
4.1.3.2	Change the document, resave, reopen, and verify changes.
4.1.4	Open (create), save, reopen, and verify special-case files, including:
4.1.4.1	Very small (zero length) files.
4.1.4.2	Very large files.
4.1.4.3	Files in formats not native to the application.
4.1.4.4	Damaged or misnamed files.
4.1.4.5	Files the application can recognize from earlier versions or other applications.
4.1.5	Open a large number of files:
4.1.5.1	In MDI applications:
4.1.5.1.1	Cascade windows.
4.1.5.1.2	Tile windows.
4.1.5.1.3	Minimize windows.
4.1.5.1.4	Switch among windows.
4.1.5.2	Verify that Most Recently Used file lists behave as expected.
4.1.5.3	Verify Close All, if implemented.
4.1.6	Open by drag/dropping file icons onto open application window.
4.2	Printing
4.2.1	Create or open sample documents that contain the following, if supported:
4.2.1.1	Text in various sizes, styles and colors using:
4.2.1.1.1	TrueType fonts, including at least one font not resident on attached printers.
4.2.1.1.2	Postscript fonts.
4.2.1.1.3	Printer resident fonts.
4.2.1.2	Rotated text.
4.2.1.3	Reversed text.
4.2.1.4	Plain and reversed text:
4.2.1.4.1	On top of other text.
4.2.1.4.2	Under other text.
4.2.1.4.3	On top of other lines created by application.
4.2.1.4.4	Under other lines created by application.
4.2.1.4.5	On top of other graphics.
4.2.1.4.6	Under other graphics.
4.2.1.5	Graphics:
4.2.1.5.1	Vector
4.2.1.5.2	Bitmap
4.2.1.5.3	Scripted (.wmf files, for example)
4.2.1.5.4	Opaque and transparent backgrounds
4.2.1.5.5	Rotated graphics
4.2.1.5.6	Graphics that extend off the edge of the page
4.2.1.5.7	Graphics framed and cropped by the app
4.2.1.6	Objects drawn by the application (arrows, lines, borders, shapes):
4.2.1.6.1	Thick objects
4.2.1.6.2	Thin objects (hairlines)
4.2.1.6.3	Hatching, dotted, dashed, solid colors and grays
4.2.1.7	Objects embedded from other OLE/COM servers.
4.2.2	Print each sample to printers with Long File Names (printer names include all legal Long File Name characters and are at least 128 characters long):
4.2.2.1	Ink jet
4.2.2.2	PostScript black
4.2.2.3	PostScript printer
4.2.2.4	Non-Postscript black laser
4.2.2.5	Non-Postscript color laser
4.2.2.6	Fax
4.2.2.7	Special printers supported by the application (pen plotters, for example)
4.2.2.8	Local printers created from network print servers
4.2.2.9	Printers connected from net servers
4.2.2.10	Set properties and print in the following formats:
4.2.2.10.1	Landscape
4.2.2.10.2	Portrait
4.2.2.10.3	Rotated
4.2.2.10.4	Duplex
4.2.2.10.5	Enlarged/reduced
4.2.2.10.6	Stapled/collated
4.2.2.10.7	Color as black-and-white
4.3	Normal Windows user actions:
4.3.1	Check all menus.
4.3.1.1	Open documents or perform other actions that expose new menus.  (For example, some applications do not show menus or disable/gray-out choices unless objects are selected on a document.)
4.3.1.2	Open all second-level and lower-level menus.
4.3.1.3	Choose menu options and verify results using:
4.3.1.3.1	Menu command.
4.3.1.3.2	Access key (Alt+underlined-letter).
4.3.1.3.3	Accelerator. (For example, Ctrl+O often performs File.Open.)
4.3.1.4	Toggle and verify checked menu commands.
4.3.1.5	Tear off and float menus (if supported).
4.3.1.6	Add and remove menu commands (if supported).
4.3.1.7	Close and reopen the application, verify persistence of menu changes.
4.3.2	Test dialogs:
4.3.2.1	Resize (if supported) and look for text clipping or controls that overlap.
4.3.2.2	Move dialog over application and off application to desktop and other running applications, verify repainting.
4.3.2.3	Test all controls for "normal" operation. (Note: Many controls can have restricted behaviors on some dialogs by design and custom controls that simulate standard Windows controls may have unusual behaviors, by design.)
4.3.2.3.1	Enter unexpected text in Edit boxes .
4.3.2.3.2	Move scroll bars and spin controls to extreme limits.
4.3.2.3.3	Click check boxes several times to toggle states.
4.3.2.3.4	Only one option (radio) button in a group should be "set" at any time, although by default all may be un-set when a dialog opens.
4.3.2.3.5	Select several contiguous and discontiguous items in multiline list boxes.
4.3.2.3.6	Select several different items in sequence from combo boxes.
4.3.2.3.7	Click header controls to change sort order of lists.
4.3.2.3.8	Right-click in all dialogs at several places. Any context menus that appear should make sense in the context of the dialog and click location. (For example, the "copy," "cut," "clear," and "delete" commands, if present, should be disabled or grayed out if nothing is selected.)
4.3.2.3.9	Click on areas that do not look like controls to verify that nothing happens.
4.3.2.4	Check all labels (static text) for clipping or truncated strings.
4.3.2.5	Check appearance of bitmaps that are not controls.
4.3.2.6	Close the dialog using:
4.3.2.6.1	OK button.
4.3.2.6.2	Cancel button.
4.3.2.6.3	Close button.
4.3.2.6.4	System menu and accelerator (usually Ctrl+F4).
4.3.2.6.5	Escape key.
4.3.3	Test toolbars:
4.3.3.1	Show/hide toolbars.
4.3.3.2	Verify that buttons' states (either enabled or grayed-out) track the state of the application.
4.3.3.3	Show/hide text.
4.3.3.4	Change size, style of icons/bitmaps.
4.3.3.5	Tear off/dock (on all edges).
4.3.3.6	Overlap.
4.3.3.7	Move off parent application's window.
4.3.3.8	Resize, verify expected button behavior (some buttons disappear off the end of the toolbar, others warp to multiple lines).
4.3.3.9	Customize:
4.3.3.9.1	Remove buttons.
4.3.3.9.2	Add buttons.
4.3.3.9.3	Change button sequence.
4.3.3.9.4	Change button properties:
4.3.3.9.4.1	Bitmap/icon.
4.3.3.9.4.2	Text.
4.3.3.9.4.3	Action the button controls.
4.3.3.10	Close the application, reopen, and verify that the expected toolbar preferences persist.
4.4	Editing functions
4.4.1	Select, using:
4.4.1.1	Menu (Select All).
4.4.1.2	Context menu.
4.4.1.3	Accelerators (Ctrl+A).
4.4.1.4	Mouse (click, drag).
4.4.1.5	Arrow keys.
4.4.2	Copy/cut/paste:
4.4.2.1	From Menus.
4.4.2.2	From Toolbars.
4.4.2.3	Using Windows accelerators (Ctrl+C and Ctrl+Insert for Copy, and so on).
4.4.2.4	Using context (right-click) menus.
4.4.2.5	From other applications via the Clipboard (including text and graphics).
4.4.2.6	To other applications (including text and graphics).
4.4.3	Move items, using:
4.4.3.1	Mouse (click, drag).
4.4.3.2	Arrow keys.
4.4.4	Delete items, (and verify they are not on the Clipboard), using:
4.4.4.1	Menu.
4.4.4.2	Context menu.
4.4.4.3	Accelerators.
4.4.4.4	Mouse (click, drag).
4.4.4.5	Arrow keys.
4.4.5	Test editing with application's Clipboard (if it's separate from the Windows Clipboard).
4.5	OLE, ActiveX, COM, DCOM:
4.5.1	Test containers with objects from a variety of servers.
4.5.2	Drag/drop embedded objects from servers to containers.
4.5.3	Use Insert or Paste.Special to embed objects in containers (test all variations); If the test application is an OLE/ActiveX server, insert its objects in other containers.
4.5.4	In all documents with embedded objects, launch the servers from the objects:
4.5.4.1	Test editing the objects in place.
4.5.4.2	Test saving the objects in place.
4.5.5	Save and reopen documents with embedded objects, verify results.
4.5.6	Print documents with embedded objects, verify results.
4.6	Appearance
4.6.1	Test at various color depths (watch for changes in bitmaps on dialogs and toolbars, especially when grayed-out); test at various resolutions.
4.6.2	Test maximize, minimize, restore/resize.
4.6.3	Test with Taskbar:
4.6.3.1	Select "Always on top" option.
4.6.3.2	Select "Autohide" option.
4.6.3.3	Show/hide clock.
4.6.3.4	Dock the taskbar to all four sides of desktop.
4.6.3.5	Make the taskbar larger (more rows/columns) than standard size.
4.6.3.6	For applications that switch to full-screen mode (such as presentations applications) verify that taskbar appears normally after application returns from full-screen mode.
4.6.4	Move the application over and under other running applications' windows to verify all for proper repainting.
4.6.5	Test with "always on top" toolbars and trays from other applications, such as Office suites.
4.6.6	Test on multiple monitors:
4.6.6.1	Use at least two monitors, one offset below and to the right of the other.
4.6.6.2	Use each available monitor as the primary monitor.
4.6.6.3	Maximize the application on each monitor.
4.6.6.4	Drag across multiple monitors.
4.6.6.5	Verify that dialogs from the application do appear on parts of the virtual monitor not represented by real monitor screens, where the user cannot reach them with the mouse.
4.6.6.6	Test left- and right-mouse clicks on all dialogs and application surfaces on all monitors for all combinations.
4.6.6.7	Move the taskbar so it sits on divisions between the monitors.
4.6.6.8	Float all possible application elements off the parent's monitor to other monitors; Verify that all toolbar and other functions still work.
4.6.6.9	Test animation such as graphics rotations, drawing rendering, movies and screen savers across all monitors.
4.7	Help:
4.7.1	Open Help, using:
4.7.1.1	Menu commands.
4.7.1.2	The toolbar.
4.7.1.3	Context menus, if supported.
4.7.1.4	F1.
4.7.1.5	Shift+F1.
4.7.2	Verify all supported:
4.7.2.1	Bookmarks.
4.7.2.2	Annotations.
4.7.2.3	Search Index.
4.7.2.4	Links.
4.7.2.5	Scrolling.
4.7.2.6	Special functions and controls, such as buttons.
4.7.3	Open all supported Help files, including files from other applications, if linked.
4.8	Supported hardware:
4.8.1	Scanners:
4.8.1.1	Twain
4.8.1.2	SCSI
4.8.1.3	Parallel
4.8.1.4	Serial
4.8.1.5	USB
4.8.2	Tape drives:
4.8.2.1	SCSI
4.8.2.2	Parallel
4.8.2.3	IDE
4.8.2.4	USB
4.8.2.5	Proprietary driver hardware
4.8.3	Video:
4.8.3.1	Cameras
4.8.3.2	Editing/frame capture
4.8.3.3	Tuner
4.8.4	Sound:
4.8.4.1	Playback
4.8.4.2	Record
4.8.4.3	Tuner
4.8.5	Telephony devices:
4.8.5.1	POTS Modems
4.8.5.2	ISDN
4.8.5.3	ADSL
4.8.6	Pointing devices:
4.8.6.1	Touch pads
4.8.6.2	Touch screens
4.8.6.3	Mice with multiple buttons and wheels
4.8.6.4	Trackballs and mice requiring special drivers
4.8.7	Mass storage:
4.8.7.1	Removable drives:
4.8.7.1.1	SCSI
4.8.7.1.2	IDE
4.8.7.1.3	Parallel
4.8.7.1.4	USB
4.8.7.1.5	CD-R/W
4.8.7.1.6	SCSI
4.8.7.1.7	IDE
4.8.7.1.8	USB
4.8.8	IRDA
4.9	Special functions:
4.9.1	Send to.
4.9.2	Launch applications from toolbars.
4.9.3	Run in background, or as service, or scheduled. (Test other applications with background services/systems running.)
4.9.4	Export to HTML. (Test resulting HTML with common browsers and other apps that can read or import HTML.)
4.9.5	Databases:
4.9.5.1	Concurrent user access, file locking.
4.9.5.2	Complex queries.
4.9.6	Other application-specific functions

Ασκήσεις

1. Περιγράψτε τις τιμές εισόδου για κάθε συνάρτηση για να ελεγχθεί ο παρακάτω κώδικας:
   int 
   min(int t1, int t2)
   {
     return t2 > t1 ? t1 : t2;
   }
   
   int 
   max(int t1, int t2)
   {
     return t1 > t2 ? t1 : t2;
   }
   
   int 
   min(int t1, int t2, int t3)
   {
     return min(min(t1, t2), t3);
   }
   
   int 
   max(int t1, int t2, int t3)
   {
     return max(max(t1, t2), t3);
   }
   
   int 
   range(int min, int max, int val)
   {
     return min(max(min, val), max);
   }
   
2. Γράψτε ένα πρόγραμμα ελέγχου για τις παραπάνω συναρτήσεις
3. Δοκιμάστε τη χρήση της κλάσης JUnit
4. Υλοποιήστε στη ΒΔ Access ένα απλό σύστημα παρακολούθησης λαθών

Αλλαγή και συντήρηση

Τύποι συστημάτων

S

Ένα πρόγραμμα τύπου S πρέπει να ικανοποιεί μια συγκεκριμένη και γνωστή από πριν απαίτηση (specification).

P

Ένα πρόγραμμα τύπου P απαιτείται να δίνει λύση σε ένα πραγματικό πρόβλημα (problem).

E

Ένα πρόγραμμα τύπου E (evolutionary) ελέγχεται με βάση το περιβάλλον μέσα στο οποίο εκτελείται και εξελίσσεται. Κριτήρια για την αποδοχή του προγράμματος είναι τα αποτελέσματα της εκτέλεσής του μέσα στο περιβάλλον αυτό.

Στρατηγικές αλλαγής του λογισμικού

• Συντήρηση: αλλαγές για ικανοποίηση νέων απαιτήσεων
• Αρχιτεκτονικός μετασχηματισμός π.χ. από αρχιτεκτονική βασισμένη σε δεδομένα σε αρχιτεκτονική πελάτη εξυπηρετητή
• Επανυλοποίηση (re-engineering) (συνήθως χωρίς σημαντικές αρχιτεκτονικές αλλαγές)

Δυναμική συντήρησης, οι νόμοι του Lehman

Συνεχιζόμενη αλλαγή

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

Αυξανόμενη πολυπλοκότητα

Καθώς ένα πρόγραμμα αλλάζει γίνεται όλο και πιο πολύπλοκο απαιτώντας όλο και περισσότερους πόρους για τη συντήρησή του.

Εξέλιξη μεγάλων συστημάτων

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

Οργανωσιακή σταθερότητα

Κατά τη διάρκεια ζωής ενός προγράμματος η ανάπτυξή του παραμένει σταθερή και ανεξάρτητη των πόρων που αφιερώνονται σε αυτή

Διατήρηση της εξοικείωσης

Κατά τη διάρκεια ζωής ενός προγράμματος το μέγεθος των αλλαγών από τη μια έκδοση στην επόμενη παραμένει σταθερό.

Διατήρηση του ρυθμού αύξησης

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

Φθίνουσα ποιότητα

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

Ανατροφοδοτούμενο σύστημα

Η διεργασία προγραμματισμού συστημάτων τύπου Ε πρέπει να αντιμετωπίζεται ως μια ανατροφοδοτούμενη διεργασία για να μπορέσει να βελτιωθεί.

Είδη συντήρησης

• Διόρθωση σφαλμάτων (17%)
• Προσαρμογή σε άλλο περιβάλλον λειτουργίας (18%)
• Προσθήκες ή αλλαγές στη λειτουργικότητα (65%)

Το κόστος της συντήρησης

• Σταθερότητα της ομάδας: μετά την παράδοση η ομάδα ανάπτυξης συνήθως αποσυντίθεται.
• Συμβατικές υποχρεώσεις: συχνά η σύμβαση ανάπτυξης είναι διαφορετική από αυτή της συντήρησης. Έτσι δεν υπάρχει κίνητρο για την ανάπτυξη συστημάτων που να συντηρούνται εύκολα.
• Ικανότητα του προσωπικού: συχνά το προσωπικό της συντήρησης δε γνωρίζει την εφαρμογή και έχει και μικρότερη πείρα από το προσωπικό ανάπτυξης.
• Δομή του προγράμματος: καθώς το πρόγραμμα "γερνάει" γίνεται όλο και πιο πολύπλοκο και δύσκολο στη συντήρηση.

Διεργασία συντήρησης

Προγραμματισμένες

• Απαιτήσεις για αλλαγές
• Ανάλυση του αντίκτυπου
• Προγραμματισμός έκδοσης
  • Έκδοση με διορθωμένα σφάλματα
  • Προσαρμογή σε νέο περιβάλλον
  • Βελτίωση
• Υλοποίηση αλλαγών
• Έκδοση του συστήματος

Με πίεση χρόνου

• Απαιτήσεις για αλλαγές
• Ανάλυση πηγαίου κώδικα
• Αλλαγή πηγαίου κώδικα
• Παράδοση αλλαγμένου συστήματος

Μετρικές

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

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

Αρχιτεκτονική εξέλιξη

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

Κληρονομημένα συστήματα

• Διεπαφή χρήστη
• Έλεγχος δεδομένων εισόδου
• Υπολογισμοί της εφαρμογής
• Βάση δεδομένων

Επανυλοποίηση

• Μετάφραση του πηγαίου κώδικα σε άλλη γλώσσα. Λόγοι:
  • Αλλαγή υλικού
  • Προβλήματα στελέχωσης
  • Αλλαγή εταιρικής πολιτικής
  • Προβλήματα υποστήριξης
• Αντίστροφος σχεδιασμός. Διεργασία:
  • Αυτόματη ανάλυση
  • Χειροκίνητη επισημείωση
  • Τεκμηρίωση δομής του προγράμματος και των δεδομένων
• Βελτίωση της δομής ελέγχου του προγράμματος - συχνά με τη χρήση αυτόματων εργαλείων
• Χωρισμός του προγράμματος σε αρθρώματα ανάλογα με
  • δομές δεδομένων
  • λειτουργικότητα
  • πρόσβαση στο υλικό
  • σχέση με εξωτερικές διεργασίες
• Επανυλοποίηση των δομών δεδομένων του προγράμματος. Αντιμετώπιση των παρακάτω προβλημάτων:
  • Ατυχείς ονομασίες
  • Μέγεθος πεδίων
  • Οργάνωση πεδίων σε εγγραφές
  • Χρήση σταθερών αντί για μεταβλητές στο πρόγραμμα (π.χ. ποσοστό ΦΠΑ)
  • Μη ύπαρξη λεξικού δεδομένων (data dictionary)

Βιβλιογραφία

• Εμμανουήλ Σκορδαλάκης. Εισαγωγή στην Τεχνολογία Λογισμικού, σελίδες 299-314. Εκδόσεις Συμμετρία, 1991.

• Εμμ. Α. Γιακουμάκης Τεχνολογία Λογισμικού: Κωδικοποίηση, έλεγχος και συντήρηση λογισμικού. σελίδες 179-220. Εκδόσεις Α. Σταμούλης, Αθήνα, Πειραιάς, 1993.

• Institute of Electrical and Electronics Engineers, Inc., New York, NY, USA. Software Maintenance, 1998. IEEE Standard 1219-1998.

• M. M. Lehman. Software engineering, the software process and their support. Software Engineering Journal, 6(5):243–258, September 1991.

• Roger S. Pressman. Software Engineering: A Practitioner's Approach, pages 526–543. McGraw-Hill, 1987.

• Roger S. Pressman. Software Engineering: A Practitioner's Approach, pages 843–867. McGraw-Hill, fifth edition, 2000. European Adaptation. Adapted by Darrel Ince.

• Ian Sommerville. Software Engineering, pages 581–689. Addison-Wesley, sixth edition, 2001.

Ασκήσεις

1. Δώστε παραδείγματα για προγράμματα τύπου S, P, E.
2. Κατηγοριοποίστε το είδος των αλλαγών που οδήγησαν στα παρακάτω προϊόντα:
   • Windows 95 Service Pack 2
   • Windows CE
   • Windows 98
   • Windows NT 3.51
   • Windows NT 3.51 for Alpha architecture
   • Windows NT 3.51 Service Pack 2
   • Windows XP
3. Επανυλοποιήστε ένα δικό σας παλιό πρόγραμμα. Κατηγοριοποιήστε τα είδη των αλλαγών που κάνατε.
4. Προσπαθήστε να απαριθμήσετε αρθρώματα από τα οποία πιθανώς αποτελείται το πρόγραμμα Microsoft Word.

Διαχείριση σχηματισμών

Ανάγκες

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

Απαντήσεις

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

Τα στοιχεία ενός σχηματισμού

• Προδιαγραφές
• Λεξικό δεδομένων
• Αρχιτεκτονικό σχέδιο
• Σχέδια αρθρωμάτων
• Σχέδια διεπαφών
• Σχέδιο ελέγχου
• Διαδικασίες ελέγχου
• Περιπτώσεις ελέγχου
• Πηγαίος κώδικας
• Τεκμηρίωση

Σχέδιο διαχείρισης σχηματισμών

1. Εισαγωγή
   1. Σκοπός
   2. Εμβέλεια
   3. Ορισμοί και συντομογραφίες
   4. Αναφορές
2. Διοίκηση
   1. Οργανισμός
   2. Υπευθυνότητες
   3. Ορισμός διεπαφών
   4. Τρόπος υλοποίησης
   5. Εφαρμόσιμες πολιτικές, κατευθύνσεις, διαδικασίες
3. Δραστηριότητες
   1. Καθορισμός σχηματισμού
   2. Έλεγχος αλλαγών
   3. Προσδιορισμός κατάστασης σχηματισμού
   4. Έλεγχος σχηματισμού
4. Εργαλεία, τεχνικές, μέθοδοι
   • Βασικές εκδόσεις
   • Τρόπος αναγνώρισης τμημάτων
   • Επιθεωρήσεις
   • Αυτόματες και μη διεργασίες
   • Έντυπα και αρχεία
   • Εργαλεία
5. Έλεγχος προμηθευτή
6. Συλλογή και διαφύλαξη στοιχείων

Ονομασία οντοτήτων

• Το είδος του (πηγαίος κώδικας, προδιαγραφή, τεκμηρίωση κ.λπ.)
• Το όνομά του (π.χ. PaymentAdvice.java)
• Τον αριθμό έκδοσης (version), αναθεώρησης (revision), παραλλαγής (variant) και αναθεώρησης της παραλλαγής του (π.χ. στη μορφή Ε.Α.Π.ΑΠ)

Εκδόσεις και παραλλαγές του στοιχείου cat.c στο λειτουργικό σύστημα NetBSD.

Στοιχεία σχηματισμού του προγράμματος cat στο λειτουργικό σύστημα FreeBSD:

$FreeBSD: src/lib/libc/i386/string/strncmp.S,v 1.6 1999/08/27 23:59:35 peter Exp $
$FreeBSD: src/lib/libc/i386/string/strchr.S,v 1.5 1999/08/27 23:59:33 peter Exp $
$FreeBSD: src/lib/libc/i386/string/strcat.S,v 1.5 1999/08/27 23:59:33 peter Exp $
$FreeBSD: src/lib/libc/i386/string/strcpy.S,v 1.5 1999/08/27 23:59:34 peter Exp $
$FreeBSD: src/lib/libc/i386/string/strcmp.S,v 1.5 1999/08/27 23:59:33 peter Exp $
$FreeBSD: src/lib/libc/i386/string/memchr.S,v 1.8 1999/08/27 23:59:31 peter Exp $
$NetBSD: bcopy.S,v 1.6 1996/11/12 00:50:06 jtc Exp $
$FreeBSD: src/lib/libc/i386/string/memset.S,v 1.5 1999/08/27 23:59:32 peter Exp $
$NetBSD: bcopy.S,v 1.6 1996/11/12 00:50:06 jtc Exp $
$FreeBSD: src/lib/libc/i386/sys/brk.S,v 1.7 1999/08/27 23:59:38 peter Exp $
$FreeBSD: src/lib/libc/i386/sys/sbrk.S,v 1.7 1999/08/27 23:59:44 peter Exp $
$FreeBSD: src/lib/libc/i386/sys/cerror.S,v 1.10 1999/08/27 23:59:38 peter Exp $
$FreeBSD: src/bin/cat/cat.c,v 1.14.2.1 2000/05/16 08:38:49 asmodai Exp $
$FreeBSD: src/lib/libc/locale/setlocale.c,v 1.25.2.1 2000/06/04 21:47:39 ache Exp $
$FreeBSD: src/lib/libc/gen/err.c,v 1.6 1999/08/27 23:58:33 peter Exp $
$FreeBSD: src/lib/libc/i386/gen/isinf.c,v 1.6 1999/08/27 23:59:21 peter Exp $

Διαχείριση αλλαγών

• Παραλαβή έντυπου αίτησης αλλαγής (change request form)
• Ανάλυση της αίτησης σύμφωνα με
  • Εγκυρότητα
  • Τρόπο υλοποίησης
  • Κόστος
• Καταχώρηση της αίτησης στη ΒΔ
• Απόφαση για την αλλαγή
• Αλλαγές στον πηγαίο κώδικα
• Καταχώρηση αλλαγών στο σύστημα ελέγχου σχηματισμών
• Έλεγχος ποιότητας
• Δημιουργία νέας έκδοσης προϊόντος

Διαχείριση εκδόσεων

• Εκτελέσιμο πρόγραμμα
• Εργαλεία εγκατάστασης και διαμόρφωσης (installation and configuration tools)
• Αρχεία δεδομένων
• Τεκμηρίωση
• Συνοδευτικό υλικό (συσκευασία, ενημέρωση αλλαγών, κ.λπ.)

• Ποιότητα του υπάρχοντος συστήματος
• Ανταγωνισμός
• Ανάγκες του τμήματος της αγοραστικής (μάρκετινγκ)
• Αιτήσεις αλλαγών των πελατών

Βάση δεδομένων σχηματισμών

• Όνομα του στοιχείου
• Περιεχόμενα του στοιχείου (π.χ. πηγαίος κώδικας)
• Τρέχουσα έκδοση
• Στοιχεία του προσώπου που έκανε την αλλαγή
• Ημερομηνία και ώρα της αλλαγής
• Εκδόσεις του λογισμικού που συμμετέχει το στοιχείο αυτό
• Σχόλια για την αλλαγή
• Παραπομπή στη ΒΔ ελέγχου αλλαγών
• Διαφορές από την προηγούμενη έκδοση

RCS file: RCS/thread.pl
Working file: thread.pl
head: 1.20
branch:
locks: strict
	dds: 1.20
access list:
symbolic names:
keyword substitution: kv
total revisions: 20;	selected revisions: 20
description:
Thread HTML pages.
----------------------------
revision 1.20	locked by: dds;
date: 2001/12/25 20:20:21;  author: dds;  state: Exp;  lines: +2 -2
Fixed missing quote.
----------------------------
revision 1.19
date: 2001/12/03 17:13:39;  author: dds;  state: Exp;  lines: +21 -10
Calculate and print the time of last modification in the "whole" files.
Better handling of greek language indentification in the face of caching.
----------------------------
revision 1.18
date: 2001/12/03 16:51:00;  author: dds;  state: Exp;  lines: +12 -7
Added URLs
Fixed bug with handling of fmtcode.
----------------------------
revision 1.17
date: 2001/12/03 14:19:12;  author: dds;  state: Exp;  lines: +2 -2
Print already defined words in english.
----------------------------
revision 1.16
date: 2001/11/16 15:12:27;  author: dds;  state: Exp;  lines: +27 -4
Fixed handling of optimised formatted code scetions using a cache.
----------------------------
revision 1.15
date: 2001/11/16 14:43:53;  author: dds;  state: Exp;  lines: +5 -1
Optimise fmtcode generation.
----------------------------
revision 1.14
date: 2001/11/12 21:52:31;  author: dds;  state: Exp;  lines: +25 -1
Can format code.
----------------------------
revision 1.13
date: 2001/10/16 20:16:09;  author: dds;  state: Exp;  lines: +37 -32
Works with native character set.
----------------------------
revision 1.12
date: 2001/09/30 16:50:52;  author: dds;  state: Exp;  lines: +31 -31
Convert to ISO-8859-7
----------------------------
revision 1.11
date: 2001/09/30 16:48:09;  author: dds;  state: Exp;  lines: +2 -2
Handle multiple hrefs to images on a line.
----------------------------
revision 1.10
date: 2001/06/29 11:19:57;  author: dds;  state: Exp;  lines: +28 -1
Display my details in printed pages.
----------------------------
revision 1.9
date: 2001/06/29 10:31:49;  author: dds;  state: Exp;  lines: +25 -11
Can now create english text.
----------------------------
revision 1.8
date: 2001/06/29 10:05:11;  author: dds;  state: Exp;  lines: +28 -2
Only update changed items.
----------------------------
revision 1.7
date: 2001/03/19 23:24:28;  author: dds;  state: Exp;  lines: +3 -2
Change file destination.
----------------------------
revision 1.6
date: 2000/08/19 18:23:05;  author: dds;  state: Exp;  lines: +3 -3
Indexprint is now idxprint to work with 16 bit programs.
----------------------------
revision 1.5
date: 1999/12/07 22:35:50;  author: dds;  state: Exp;  lines: +4 -1
Added pointer to toc in the detailed toc page.
----------------------------
revision 1.4
date: 1999/11/10 09:41:34;  author: dds;  state: Exp;  lines: +12 -3
Added better support for printable pages.
----------------------------
revision 1.3
date: 1999/11/10 00:33:12;  author: dds;  state: Exp;  lines: +30 -3
Added detailed table of contents.
----------------------------
revision 1.2
date: 1999/05/31 17:27:31;  author: dds;  state: Exp;  lines: +26 -11
Added local file references.
Added improved indexing.
----------------------------
revision 1.1
date: 1999/01/12 10:18:53;  author: dds;  state: Exp;
Initial revision
=============================================================================

Εργαλεία ελέγχου σχηματισμών

add

Add a new file/directory to the repository

admin

Administration front end for rcs

annotate

Show last revision where each line was modified

checkout

Checkout sources for editing

commit

Check files into the repository

diff

Show differences between revisions

edit

Get ready to edit a watched file

editors

See who is editing a watched file

export

Export sources from CVS, similar to checkout

history

Show repository access history

import

Import sources into CVS, using vendor branches

init

Create a CVS repository if it doesn't exist

log

Print out history information for files

login

Prompt for password for authenticating server.

logout

Removes entry in .cvspass for remote repository.

rdiff

Create 'patch' format diffs between releases

release

Indicate that a Module is no longer in use

remove

Remove an entry from the repository

rtag

Add a symbolic tag to a module

status

Display status information on checked out files

tag

Add a symbolic tag to checked out version of files

unedit

Undo an edit command

update

Bring work tree in sync with repository

watch

Set watches

watchers

See who is watching a file

Εργαλεία ελέγχου παραγωγής κώδικα

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

Βιβλιογραφία

• Εμμανουήλ Σκορδαλάκης. Εισαγωγή στην Τεχνολογία Λογισμικού, σελίδες 227-237. Εκδόσεις Συμμετρία, 1991.

• Εμμ. Α. Γιακουμάκης Τεχνολογία Λογισμικού: Κωδικοποίηση, έλεγχος και συντήρηση λογισμικού. σελίδες 159-177. Εκδόσεις Α. Σταμούλης, Αθήνα, Πειραιάς, 1993.

• Stephen P. Berczuk and Brad Appleton. Software Configuration Management Patterns: Effective Teamwork, Practical Integration. Addison-Wesley, Boston, MA, 2002.
• Don Bolinger, Tan Bronson, and Mike Loukides. Applying RCS and SCCS : From Source Control to Project Control. O'Reilly and Associates, Sebastopol, CA, USA, 1995.
• Per Cederqvist and et al. Version Management with CVS, 2001. Available online http://www.cvshome.org/docs/manual/ (January 2002).
• Watts S. Humphrey. Managing the Software Process, pages 113–134, 225–246. Addison-Wesley, 1989.
• Institute of Electrical and Electronics Engineers, Inc., New York, NY, USA. Software Configuration Management Plans, 1998. IEEE Standard 828-1998.
• Andrew Oram, Steve Talbott, and Steve Talbot. Managing Projects With make. O'Reilly and Associates, Sebastopol, CA, USA, second edition, 1991.
• Roger S. Pressman. Software Engineering: A Practitioner's Approach, pages 544–550. McGraw-Hill, 1987.
• Roger S. Pressman. Software Engineering: A Practitioner's Approach, pages 223–238. McGraw-Hill, fifth edition, 2000. European Adaptation. Adapted by Darrel Ince.
• Ian Sommerville. Software Engineering, pages 641–661. Addison-Wesley, sixth edition, 2001.

Ασκήσεις

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

Διοίκηση έργου

Οι δυσκολίες

• Το προϊόν δεν έχει φυσική έκφανση
• Δεν υπάρχουν κοινώς αποδεκτές και κοινές διεργασίες υλοποίησης
• Τα μεγάλα έργα κατασκευάζονται κατά παραγγελία για συγκεκριμένες απαιτήσεις
• Υπάρχει η ψευδαίσθηση πως το λογισμικό είναι εύπλαστο
• Μικρές αλλαγές στο λογισμικό επηρεάζουν συχνά δυσανάλογα πολλά τμήματα
• Δε χρησιμοποιούνται συχνά έτοιμα εξαρτήματα

Ενέργειες της διαχείρισης

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

Στοιχεία της διαχείρισης

• Πρόσωπα
  • Διοικητικό προσωπικό
  • Υπεύθυνοι έργου
  • Στελέχη υλοποίησης
  • Πελάτες
  • Τελικοί χρήστες
• Προϊόν
• Διεργασία
• Έργο

Τεκμηρίωση σχεδιασμού

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

Το σχέδιο του έργου

• Εισαγωγή
  • Στόχοι
  • Περιορισμοί (κόστος, χρόνος)
• Οργάνωση
  • Οργάνωση σε ομάδες
  • Ευθύνες
• Ανάλυση κινδύνων (risk analysis)
• Ανάγκες σε υλικό και λογισμικό
  • Κόστος
  • Χρονοδιάγραμμα υλοποίησης παραγγελιών
• Διαίρεση του έργου σε πακέτα εργασίας (workpackages)
  • Πακέτα εργασίας
  • Παραδοτέα (deliverables) (προς τον πελάτη) Παράδειγμα:
    • Μελέτη σκοπιμότητας
    • Απαιτήσεις συστήματος
    • Αρχέτυπο
    • Αρχιτεκτονικός σχεδιασμός
    • Αποτελέσματα ελέγχων
    • Λογισμικό
  • Ορόσημα (milestones) (παραδοτέα ή άλλα καλά καθορισμένα αποτελέσματα (π.χ. μεταγλώττιση χωρίς λάθη)
• Χρονοδιάγραμμα
• Μηχανισμοί ελέγχου και αναφορών

Ο ρόλος της δέσμευσης

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

Διαχείριση κινδύνων

1. Προσδιορισμός των κινδύνων
2. Ανάλυση των κινδύνων ως προς
   • την πιθανότητα (%)
   • τα αποτελέσματα (καταστροφικά, σοβαρά, υποφερτά, ασήμαντα)
3. Προγραμματισμός διαχείρισης
   • Στρατηγικές αποφυγής
   • Στρατηγικές ελαχιστοποίησης του αποτελέσματος
   • Εναλλακτικά σχέδια (contingency plan)
4. Παρακολούθηση των κινδύνων και αναθεώρηση του σχεδίου

Κίνδυνοι του έργου

• Το έργο
• Το προϊόν
• Την επιχείρηση

• Τεχνολογία
• Προσωπικό
• Οργάνωση και δομή της επιχείρησης
• Εργαλεία
• Απαιτήσεις
• Εκτίμηση

Οι σημαντικότεροι κίνδυνοι

• Έλλειψη προσωπικού
• Μη ρεαλιστικό χρονοδιάγραμμα
• Κακή κατανόηση των απαιτήσεων
• Δύσχρηστη διεπαφή του χρήστη με το λογισμικό
• Λογισμικό υπερβολικά περίπλοκο για τις ανάγκες του πελάτη
• Μη ύπαρξη ελέγχου σε αλλαγές απαιτήσεων
• Προβλήματα σε επαναχρησιμοποιούμενα εξαρτήματα ή σε εξωτερικό λογισμικό
• Προβλήματα σε έργα που εκτελούνται από τρίτους
• Χαμηλός χρόνος απόκρισης
• Έργο πέρα από τις δυνατότητες της τεχνολογίας

Επιτήρηση

• Τα ορόσημα που έχουν / δεν έχουν επιτευχθεί
• Ανάλωση πόρων
• Ανοικτά θέματα
• Σχόλια του προσωπικού
• Χρήση της τεχνολογίας
• Παραγωγικότητα
• Ποιότητα

Οργάνωση ομάδων

Δημοκρατικά και αποκεντρωμένα (democratic decentralised)
Οι αποφάσεις λαμβάνονται ομαδικά και όλα τα μέλη της ομάδας επικοινωνούν μεταξύ τους.
Ελεγχόμενα και αποκεντρωμένα (controlled decentralised)
Υπάρχει αρχηγός στην ομάδα που ελέγχει τις ενέργειες, αλλά η εργασία και η επικοινωνία γίνεται ομαδικά.
Ελεγχόμενα και με κεντρική επικοινωνία (controlled centralised)
Ο αρχηγός της ομάδας αναλαμβάνει τόσο τον έλεγχο όσο και την επικοινωνία της ομάδας. Οι γραμμές επικοινωνίας είναι κάθετες.

• Δυσκολία του προβλήματος (δύσκολο -> DD)
• Μέγεθος του προβλήματος (μεγάλος -> CC, CD)
• Χρόνος που η ομάδα θα βρίσκεται μαζί (μεγάλος -> DD)
• Κατά πόσο το πρόγραμμα μπορεί να χωριστεί σε μικρότερα τμήματα (αν ναι -> CC, CD)
• Απαιτούμενη ποιότητα και αξιοπιστία (μεγάλη -> CC, CD)
• Αυστηρότητα στην τήρηση του χρόνου παράδοσης (αν ναι -> CC)
• Απαιτούμενη από το έργο επικοινωνία μεταξύ των μελών

Παράδειγμα στελέχωσης

• Κύρια ομάδα. Ασχολείται με
  • Διαχείριση του έργου
  • Ανάπτυξη λογισμικού
  • Διασφάλιση ποιότητας
  • Εκπαίδευση χρηστών
  • Ευχρηστία (usability) λογισμικού
  • Διεπαφή χρήστη
  • Οργάνωση της τελικής έκδοσης
• Ομάδα υποστήριξης. Ασχολείται με
  • Διαχείριση του προϊόντος
  • Διάθεση στην αγορά
  • Υποστήριξη
  • Διαχείριση του ελέγχου beta

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

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

• Αρχιτεκτονική και τεχνικά στοιχεία του έργου
• Επιλογή εργαλείων, τεχνολογιών και προτύπων
• Το ρόλο του Μέντορα στα άλλα μέλη της ομάδας
• Επίβλεψη των προβλημάτων του έργου
• Συγγραφή κώδικα

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

Καθήκοντα μετά την υλοποίηση

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

Βιβλιογραφία

• Εμμανουήλ Σκορδαλάκης. Εισαγωγή στην Τεχνολογία Λογισμικού, σελίδες 159-179. Εκδόσεις Συμμετρία, 1991.

• Barry Boehm. Software risk management: Principles and practices. IEEE Software, 9(1):32–39, January/February 1991.

• Watts S. Humphrey. Managing the Software Process, pages 69–82. Addison-Wesley, 1989.

• Institute of Electrical and Electronics Engineers, Inc., New York, NY, USA. Software Productivity Metrics, 1992. IEEE Standard 1045-1992.

• Institute of Electrical and Electronics Engineers, Inc., New York, NY, USA. Adoption of PMI Standard- A Guide to the Project Management Body of Knowledge, 1998. IEEE Standard 1490-1998.

• Institute of Electrical and Electronics Engineers, Inc., New York, NY, USA. Software Life Cycle Processes-Risk Management, 2001. IEEE Standard 1540-2001.

• Roger S. Pressman. Software Engineering: A Practitioner's Approach, pages 118–132. McGraw-Hill, 1987.

• Roger S. Pressman. Software Engineering: A Practitioner's Approach, pages 54–190. McGraw-Hill, fifth edition, 2000. European Adaptation. Adapted by Darrel Ince.

• Ian Sommerville. Software Engineering, pages 71–92. Addison-Wesley, sixth edition, 2001.

• Ed Sullivan. Under Pressure and On Time, pages 42–60. Microsoft Press, Redmond, Washington, USA, 2001.

Ασκήσεις

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

Παραγωγικότητα και κοστολόγηση

Στοιχεία του προγραμματισμού

• Πόση προσπάθεια θα χρειαστεί (ανθρωπομήνες (person months))
• Πόσος ημερολογιακός χρόνος θα απαιτηθεί (Μ)
• Πόσο θα κοστίσει (€)

Δέκα εμπειρικοί αφορισμοί

1. Η ανακάλυψη και διόρθωση ενός προβλήματος του λογισμικού μετά την παράδοση, είναι 100 φορές πιο ακριβή από την ανακάλυψη και διόρθωσή του στο στάδιο των απαιτήσεων.
2. Το πρόγραμμα ανάπτυξης του λογισμικού μπορεί να συμπιεστεί κατά 25% του ονομαστικού, αλλά όχι περισσότερο.
3. Για κάθε 1 Ευρώ που ξοδεύεται στην ανάπτυξη του λογισμικού, θα ξοδεύονται 2 Ευρώ στη συντήρηση.
4. Το κόστος ανάπτυξης και συντήρησης του λογισμικού είναι πρωταρχικά συνάρτηση του αριθμού των πηγαίων γραμμών στο προϊόν.
5. Η ετερογένεια των ατόμων ευθύνεται για τις μεγαλύτερες διαφορές στην παραγωγικότητα λογισμικού.
6. Η γενική αναλογία κόστους λογισμικού προς κόστος υλικού μεταβλήθηκε από 15/85 το 1955 σε 85/15 το 1985 και συνεχίζει να διευρύνεται.
7. Η ανάπτυξη λογισμικού σήμερα ακολουθεί μια κατανομή 60-15-25. Το 60% της ανάπτυξης αφιερώνεται στην ανάλυση και σχεδιασμό, το 15% στον προγραμματισμό και 25% στον έλεγχο.
8. Τα συστήματα λογισμικού και τα προϊόντα λογισμικού κοστίζουν τρεις φορές περισσότερο για να αναπτυχθούν από ότι ένα αυτόνομο πρόγραμμα λογισμικού.
9. Στη διαδικασία του ελέγχου ανακαλύπτεται το 60% των λαθών.
10. Πολλές πρακτικές και φαινόμενα λογισμικού ακολουθούν κατανομή Pareto, όπου το 80% της συνεισφοράς προέρχεται από το 20% των συμμετεχόντων.
    

Ποσοτικά στοιχεία του κόστους

• Ανθρώπινο δυναμικό (Α/Μ)
• Υλικό και λογισμικό (αγορά και συντήρηση)
• Ταξίδια και εκπαίδευση

• Εργοδοτικές εισφορές και άλλα προγράμματα ασφάλισης
• Κόστος γραφείων
• Αναλώσιμα (toner, χαρτί, μαγνητικά μέσα αποθήκευσης, είδη γραφείου)
• Φωτισμός, θέρμανση, κλιματισμός
• Βοηθητικό προσωπικό: διοικητικό, λογιστές, γραμματειακή υποστήριξη, τεχνικοί, καθαριστές.
• Δικτύωση και επικοινωνίες
• Κοινές εγκαταστάσεις (βιβλιοθήκη, κυλικείο, γυμναστήριο, παιδικός σταθμός)

Παράγοντες που επηρεάζουν την τιμή

• Προσδοκία εισόδου σε νέες αγορές (-)
• Αβεβαιότητα της εκτίμησης (+)
• Όροι της σύμβασης
  • Ποινικές ρήτρες (+)
  • Καθυστέρηση πληρωμής (+)
  • Πληρωμές δημοσίου (+)
  • Εγγυητικές επιστολές (+)
  • Μη απόδοση των πνευματικών δικαιωμάτων (-)
• Δυνατότητα μεταβολής των προδιαγραφών και του κόστους (- και μετά +)
• Οικονομική κατάσταση της εταιρίας (- αν δεν είναι καλή)

Τρόποι μέτρησης

• Μέγεθος (π.χ. γραμμές κώδικα)
• Λειτουργικά χαρακτηριστικά (function points)
• Λειτουργικά αντικείμενα (object points)

Γραμμές κώδικα

• Πολύ εύκολο να μετρηθούν
• Χρήσιμο μέγεθος για συμβολικές γλώσσες και γλώσσες όπως FORTRAN, COBOL.
• Δυσκολίες σε γλώσσες όπως C++ και Java (δηλώσεις, κλάσεις, προεπεξεργαστής)
• Συχνά αδύνατη η χρήση σε 4GL
• Αποπροσανατολιστικά αποτελέσματα ανάμεσα σε διαφορετικές γλώσσες (π.χ. σύγκριση παραγωγικότητας συμβολικής γλώσσας με Java)

Παραδείγματα

• Γραμμές κώδικα σε γνωστά συστήματα λογισμικού ανοικτού πηγαίου κώδικα (open source software) (χιλιάδες):

  Apache Web Server (C)	108
  GNU C Compiler (C)	342
  Jakarta Tomcat 4 (Java)	164
  Perl (C)	153
  X Window System (C)	1623
  ArgoUML (Java)	123
  Adaptive Communication Environment (C++)	1546

• Γραμμές κώδικα σε διάφορα στοιχεία του BSD Unix (γραμμές):

  Πυρήνας (FreeBSD 4.1)	1448721
  apply	242
  apropos	242
  ar	1810
  at	1499
  banner	2349
  basename	148
  biff	113
  cal	434
  calendar	559
  checknr	622
  chflags	187
  chpass	1484
  cksum	804
  cmp	490
  col	546
  colcrt	269
  colrm	145
  column	312
  comm	196
  compress	1230
  crunch	2048
  ctags	1587
  cut	285
  dirname	155
  du	253
  eject	385
  elfstrip	267
  env	104
  error	3076
  expand	185
  false	0
  fdformat	344
  file	3374
  find	2334
  finger	1539
  fmt	500
  fold	232
  fpr	380
  from	163
  fsplit	439
  fstat	803
  ftp	7417
  gencat	804
  getconf	238
  getopt	40
  gprof	5112
  head	159
  hexdump	1639
  id	328
  indent	4094
  join	616
  jot	399
  kdump	547
  ktrace	334
  lam	237
  last	444
  lastcomm	279
  leave	188
  less	20992
  lex	12221
  locate	602
  lock	270
  logger	198
  login	1290
  logname	92
  look	376
  lorder	0
  m4	2691
  machine	59
  mail	9585
  make	24936
  man	1030
  menuc	967
  mesg	112
  mkfifo	113
  mkstr	335
  modstat	194
  msgc	453
  msgs	937
  netstat	4448
  nice	122
  nm	653
  nohup	143
  pagesize	0
  passwd	1781
  paste	251
  patch	4338
  pr	2176
  printenv	104
  printf	544
  quota	733
  ranlib	660
  rdist	3675
  renice	135
  rev	117
  rlogin	1589
  script	248
  sed	2178
  shar	0
  showmount	371
  size	338
  skey	131
  skeyinfo	102
  skeyinit	233
  split	294
  strings	247
  strip	322
  su	475
  systat	3496
  tail	1167
  talk	1582
  tcopy	339
  tee	156
  telnet	9830
  tftp	1561
  time	173
  tip	6165
  tn3270	12393
  touch	369
  tput	239
  tr	655
  true	0
  tset	1293
  tsort	442
  tty	89
  ul	542
  uname	138
  unexpand	142
  unifdef	664
  uniq	255
  units	758
  unvis	121
  users	122
  uudecode	199
  uuencode	160
  vacation	451
  vgrind	1858
  vi	47838
  vis	267
  vmstat	1268
  w	740
  wall	197
  wc	269
  what	96
  whatis	241
  whereis	128
  which	0
  who	273
  whois	132
  window	15675
  write	328
  xargs	371
  xinstall	557
  xlint	16617
  yacc	9726
  yes	63

Λειτουργικά χαρακτηριστικά

• Εμπειρικός τρόπος μέτρησης
• Υποκειμενικός
• Κατάλληλος για πληροφοριακά συστήματα
• Βασίζεται σε στοιχεία που είναι γνωστά πριν αρχίσει το έργο
• Υπολογίζεται ως ΣΤΟΙΧΕΙΑ * (0.65 + 0.01 * ΡΥΘΜΙΣΕΙΣ)

1. Απαιτείται αξιόπιστο σύστημα εφεδρείας των στοιχείων;
2. Απαιτείται επικοινωνία δεδομένων;
3. Απαιτείται κατανεμημένη επεξεργασία;
4. Είναι σημαντική η απόδοση;
5. Το σύστημα θα τρέξει σε υπάρχον περιβάλλον;
6. Απαιτείται διεπαφή για την είσοδο των στοιχείων;
7. Η είσοδος των στοιχείων θα είναι σε πολλαπλές οθόνες;
8. Η ενημέρωση των κυρίων αρχείων θα γίνεται άμεσα;
9. Είναι περίπλοκες οι είσοδοι, έξοδοι, ή οι ερωτήσεις;
10. Είναι περίπλοκοι οι εσωτερικοί υπολογισμοί;
11. Ο κώδικας θα πρέπει να επαναχρησιμοποιηθεί;
12. Περιλαμβάνεται στο σχεδιασμό η μετάπτωση και η εγκατάσταση;
13. Το σύστημα θα χρησιμοποιείται από διαφορετικούς οργανισμούς ή σε διαφορετικές εγκαταστάσεις;
14. Θα μπορούν οι χρήστες να τροποποιούν το σύστημα;

Λειτουργικά αντικείμενα

• Παρόμοια με ΛΧ αλλά πιο κατάλληλα για 4GL
• Ευκολότερο να υπολογιστούν από τις προδιαγραφές

Σχέση ΛΧ και ΓΚ

• Συχνά είναι χρήσιμο να μετατρέψουμε από ΓΚ σε ΛΧ ή αντίστροφο
• Με βάση άλλα στοιχεία παραγωγικότητας (ΓΚ / μήνα, λάθη / ΓΚ) μπορούμε να να βγάλουμε χρήσιμα συμπεράσματα.
• Η μετατροπή καλό είναι να γίνεται με βάση ιστορικά στοιχεία του δικού μας παραγωγικού μηχανισμού

Τεχνικές εκτίμησης της τιμής

Αλγοριθμικές

Χρησιμοποιούμε ιστορικά στοιχεία για να συσχετίσουμε μέγεθος με κόστος. Το μοντέλο υπολογίζει το έργο με βάση το μέγεθος. Παράδειγμα τέτοιων τεχνικών είναι οι τεχνικές COCOMO και COCOMO II.

Κρίση του ειδικού (expert judgement)

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

Κατακερματισμός της εργασίας

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

Εκτίμηση με αναλογία

Συγκρίνουμε το έργο με παρόμοια έργα.

Νόμος του Parkinson

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

Κέρδος

Το κόστος καθορίζεται με βάση το ποσό που είναι διατεθειμένος να διαθέσει ο πελάτης.

Η τεχνική COCOMO 2

• Constructive Cost Model
• Αλγοριθμική τεχνική
• Εξέλιξη της τεχνικής COCOMO (81): PM = C * KLOC ^K (C: 2.4 - 3.6), (M: multiplier)
• Διαφορετικά επίπεδα εκτίμησης, ανάλογα με το στάδιο του έργου
  • Αρχέτυπο
  • Αρχικό σχέδιο
  • Μετά τον αρχιτεκτονικό σχεδιασμό

Αρχέτυπο

PM

ΑΜ

NOP

Αριθμός από λειτουργικά αντικείμενα (number of object points)

%reuse

Ποσοστό επαναχρησιμοποίησης

PROD

Ικανότητα και εμπειρία των προγραμματιστών (4: πολύ χαμηλή, 6: χαμηλή, 15: μέση, 25: υψηλή, 50: πολύ υψηλή)

Αρχικό σχέδιο

A

2.5

Size

Χιλιάδες γραμμές πηγαίου κώδικα

B

Βλ. "υπολογισμός του εκθέτη"

Μ

PERS * RCPX * RUSE * RDIF * PREX * FCIL * SCED
Όπου:

PERS

Ικανότητα προσωπικού

RCPX

Αξιοπιστία και πολυπλοκότητα (reliability and complexity)

RUSE

Επαναχρησιμοποίηση (reuse)

RDIF

Δυσκολία της πλατφόρμας υλοποίησης (platform difficulty)

PREX

Εμπειρία προσωπικού (personel experience)

FCIL

Μέσα υποστήριξης (support facilities)

SCED

Πρόγραμμα (schedule)

PM^M

Υπολογίζεται σε έργα που μεγάλο ποσοστό του κώδικα παράγεται αυτόματα.
PM^M = (ASLOC * (AT / 100)) / ATPROD
Όπου

ASLOC

Αυτόματα παραγόμενες γραμμές

AT

Ποσοστό του κώδικα που είναι αυτόματα παραγόμενος

AT

Παραγωγικότητα για αυτόματα παραγόμενο κώδικα

Μετά τον αρχιτεκτονικό σχεδιασμό

• Προϊόν

  RELY

  Αξιοπιστία (reliability)

  CPLX

  Πολυπλοκότητα (complexity)

  DOCU

  Απαιτούμενη τεκμηρίωση (documentation)

  DATA

  Μέγεθος της βάσης δεδομένων

  RUSE

  Επαναχρησιμοποίηση (reuse)

• Υπολογιστής

  TIME

  Περιορισμοί χρόνου

  STOR

  Περιορισμοί μνήμης (storage)

  PVOL

  Αστάθεια (volatility)

• Προσωπικό

  ACAP

  Ικανότητα προσωπικού στην ανάλυση (programmer capability)

  PCAP

  Ικανότητα προσωπικού στον προγραμματισμό (analyst capability)

  PCON

  Σταθερότητα απασχόλησης του προσωπικού (personnel continuity)

  AEXP

  Εμπειρία του αναλυτή στο συγκεκριμένο αντικείμενο (analyst experience)

  PEXP

  Εμπειρία του προγραμματιστή στο συγκεκριμένο αντικείμενο (programmer experience)

  LTEX

  Εμπειρία του προγραμματιστή στη γλώσσα και τα εργαλεία (language and tool experience)

• Έργο

  TOOL

  Χρήση εργαλείων

  SCED

  Συμπιεσμένο πρόγραμμα (schedule)

  SITE

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

ESLOC

Ανάλογες χιλιάδες γραμμές πηγαίου κώδικα

ASLOC

Χιλιάδες γραμμές επαναχρησιμοποιούμενου κώδικα

AA

Έργο για εκτίμηση του κώδικα (0-8)

SU

Κόστος κατανόησης του κώδικα (50: κακογραμμένος, 10: δομημένος)

DM

Ποσοστό αλλαγής του σχεδίου

CM

Ποσοστό αλλαγής του κώδικα

IM

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

Υπολογισμός του εκθέτη

• Προηγούμενη εμπειρία
• Ελαστικότητα διεργασίας ανάπτυξης
• Βαθμός ανάλυσης κινδύνων
• Συνοχή της ομάδας ανάπτυξης
• Ωριμότητα της διεργασίας ανάπτυξης (5 - CMM)

Βαθμονόμηση των πολλαπλασιαστών

Εκτίμηση χρόνου με βάση την τεχνική COCOMO

Παράγοντες που επηρεάζουν την παραγωγικότητα

Εμπειρία στο συγκεκριμένο τομέα

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

Ποιότητα της διεργασίας ανάπτυξης (+)

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

Μέγεθος του έργου (-)

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

Τεχνολογική υποστήριξη (+)

• Χρησιμοποιώντας προηγμένα και σύγχρονα εργαλεία, βελτιώνεται η παραγωγικότητα.
  

Περιβάλλον εργασίας (+)

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

Βιβλιογραφία

• Εμμανουήλ Σκορδαλάκης. Εισαγωγή στην Τεχνολογία Λογισμικού, σελίδες 187-191. Εκδόσεις Συμμετρία, 1991.

• Barry Boehm, Bradford Clark, Ellis Horowitz, Ray Madachy, Richard Shelby, and Chris Westland. Cost models for future life cycle processes: COCOMO 2. Annals of Software Engineering, 1:57–94, 1995.

• Barry W. Boehm. Software Engineering Economics. Prentice-Hall, 1981.

• Barry Boehm. Software risk management: Principles and practices. IEEE Software, 9(1):32–39, January/February 1991.

• Roger S. Pressman. Software Engineering: A Practitioner's Approach, pages 101–117. McGraw-Hill, 1987.

• Roger S. Pressman. Software Engineering: A Practitioner's Approach, pages 77–144. McGraw-Hill, fifth edition, 2000. European Adaptation. Adapted by Darrel Ince.

• Ian Sommerville. Software Engineering, pages 511–534. Addison-Wesley, sixth edition, 2001.

Ασκήσεις

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

Μη συμβατικές μεθοδολογίες

Ευέλικτη ανάπτυξη: στοιχεία

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

Ευέλικτη ανάπτυξη: αρχές

1. Η μεγαλύτερή μας προτεραιότητα είναι η ικανοποίηση του πελάτη μέσω της άμεσης και συνεχούς παράδοσης χρήσιμου λογισμικού.
2. Οι αλλαγές στις προδιαγραφές είναι ευπρόσδεκτες, ακόμα και αργά στο στάδιο της ανάπτυξης. Οι ευέλικτες διεργασίες δαμάζουν τις αλλαγές προς όφελος της ανταγωνιστικότητας του πελάτη.
3. Παραδίδουμε λογισμικό τακτικά, σε διαστήματα μερικών εβδομάδων ή μηνών, προτιμώντας τα μικρά διαστήματα.
4. Αυτοί που ασχολούνται με το επιχειρηματικό τμήμα και αυτοί που ασχολούνται με την ανάπτυξη πρέπει να συνεργάζονται καθημερινά σε όλη τη διάρκεια του έργου.
5. Βάση για τα έργα είναι οι άνθρωποι με κίνητρα και το αντίστοιχο ενδιαφέρον. Δώστε τους το περιβάλλον και την υποστήριξη που χρειάζονται και εμπιστευτείτε τους να περατώσουν το έργο.
6. Ο πιο αποδοτικός και αποτελεσματικός τρόπος μεταφοράς πληροφορίας προς την και μέσα στην ομάδα ανάπτυξης είναι η συζήτηση πρόσωπο-με-πρόσωπο.
7. Η κύριος τρόπος μέτρησης της προόδου είναι το λογισμικό που λειτουργεί.
8. Οι εύκαμπτες διεργασίες συμβάλλουν σε μια αειφόρο διεργασία ανάπτυξης. Οι χρηματοδότες, το προσωπικό ανάπτυξης και οι χρήστες θα πρέπει να μπορούν να συνεχίζουν για πάντα με τον ίδιο σταθερό ρυθμό.
9. Συνεχής προσοχή στην τεχνολογική αρτιότητα και το σωστό σχεδιασμό βελτιώνει την ευελιξία.
10. Η απλότητα--η τέχνη της μεγιστοποίησης του ποσού της εργασίας που δεν πραγματοποιείται-- είναι απαραίτητη.
11. Οι καλύτερες αρχιτεκτονικές, απαιτήσεις, και τα καλύτερα σχέδια πηγάζουν από αυτο-οργανωνόμενες ομάδες.
12. Σε τακτά διαστήματα η ομάδα αναλογίζεται πως μπορεί να γίνει πιο αποδοτική. Έτσι συντονίζει και προσαρμόζει ανάλογα τη συμπεριφορά της.

Ακραίος προγραμματισμός

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

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

Αξίες του ΑΠ

• Επικοινωνία (έλεγχος, ζεύγη, εκτίμηση κόστους)
• Απλότητα (καλύτερα το απλό σήμερα, και πιθανώς κάποιο πρόσθετο κόστος αύριο, παρά το πρόσθετο κόστος σήμερα για λειτουργικότητα που δε θα απαιτηθεί)
• Ανάδραση (έλεγχοι, γρήγορη παράδοση)
• Θάρρος (για αλλαγή σχεδίου, πέταγμα κώδικα, δοκιμή απλών ιδεών (πχ merge sort μέσω shell script))

Αρχές του ΑΠ

• ´Αμεση ανάδραση
• Υπόθεση της απλότητας
• Επαυξητική αλλαγή (incremental change)
• Ενστέρνιση της αλλαγής
• Ποιοτική εργασία

Ενέργειες του ΑΠ

• Συγγραφή κώδικα
• Έλεγχος
• Ακρόαση
• Σχεδιασμός

Πρακτικές του ΑΠ

Πλάνο της κάθε έκδοσης

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

• το εύρος,
• τις προτεραιότητες,
• τι θα περιέχει η έκδοση,
• ημερομηνίες των εκδόσεων.

Τα στελέχη ανάπτυξης έχουν τον τελικό λόγο για:

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

Μικρές εκδόσεις

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

Μεταφορά (metaphor)

Χρήση μιας μεταφοράς που εκφράζει την αρχιτεκτονική του συστήματος.

Απλό σχέδιο

Το σχέδιο πρέπει να είναι το απλούστερο δυνατό με την προϋπόθεση να:

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

Έλεγχος

Για κάθε λειτουργία του προγράμματος πρέπει να υπάρχει ο αντίστοιχος έλεγχος. Οι έλεγχοι γράφονται σε συνεργασία με τον πελάτη.

Αναπαραγοντοθέτηση (refactoring)

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

Προγραμματισμός σε ζευγάρια

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

• Θα δουλέψει το σύνολο της προσέγγισης;
• Υπάρχουν έλεγχοι που δεν έχουν υλοποιηθεί;
• Μήπως μπορεί το σύστημα να απλοποιηθεί;

Τα ζευγάρια αλλάζουν δυναμικά.

Συλλογική ιδιοκτησία (collective ownership)

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

Συνεχής ολοκλήρωση

Τα τμήματα του κώδικα ενώνονται τακτικά μεταξύ τους.

Εβδομάδα 40 ωρών

Οι υπερωρίες είναι δείγμα προβλημάτων στο έργο.

Πελάτης στο χώρο της εργασίας

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

Πρότυπα κώδικα

Με βάση τα πρότυπα ο κώδικας μπορεί να είναι ιδιοκτησία όλης της ομάδας.

Σημείωση

Ανάπτυξη λογισμικού στη Microsoft

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

Βιβλιογραφία

• Kent Beck. Extreme Programming Explained: Embrace Change. Addison Wesley Longman, 2000.

• William J. Brown, Raphael C. Malveau, Hays W. McCormick III, and Thomas J. Mowbray. AntiPatterns Refactoring Software, Architectures, and Projects in Crisis. Wiley, 1998.

• Alistair Cockburn. Agile Software Development. Addison-Wesley, 2001.

• Michael A. Cusumano and Richard W. Selby. Microsoft Secrets. The Free Press, 1995.

• Institute of Electrical and Electronics Engineers, Inc., New York, NY, USA. Information Technology—Software Life Cycle Processes—Software Development Acquirer-Supplier Agreement, 1995. EIA/IEEE Interim Standard J-Std-016-1995 (Issued for Trial Use).

• Watts S. Humphrey. Managing the Software Process, pages 411–428. Addison-Wesley, 1989.

• Institute of Electrical and Electronics Engineers, Inc., New York, NY, USA. IEEE Recommended Practice for Software Acquisition (includes IEEE 1062a), 1998. IEEE Standard 1062-1998.

• P. J. Plauger. Programming on Purpose II: Essays on Software People, pages 123–129. Prentice-Hall, 1993.

• M Poppendieck and T. Poppendieck. Lean Software Development. Addison-Wesley, 2003.

• Diomidis Spinellis. Taking common sense to the extreme (http://www.dmst.aueb.gr/dds/pubs/Breview/2000-IEEE-XP/html/review.html). IEEE Software, 17(4):113–114, July/August 2000. Book review: eXtreme Programming Explained: Embrace Change.

• Diomidis Spinellis. Fear of coding, and how to reduce it (http://www.dmst.aueb.gr/dds/pubs/jrnl/2001-05-Computer-Fear-of-Coding/html/foc.html). IEEE Computer, 34(8):98–100, August 2001.

• Laurie Williams and Alistair Cockburn. Agile software development: It's about feedback and change. IEEE Computer, 36(6):39–43, July 2003. Feature issue on Agile Methods.

• Laurie Williams. The XP programmer: The few-minutes programmer. IEEE Software, 20(3):16–20, May/June 2003. Extreme programming theme issue.

Ασκήσεις

1. Θα μπορούσατε να υιοθετήσετε ΑΠ για την υλοποίηση της άσκηση του μαθήματος; Ποιες πρακτικές του ΑΠ δε θα μπορούσαν να εφαρμοστούν;
2. Εντοπίστε και σχολιάστε διαφορές ανάμεσα στον τρόπο που υλοποιείται λογισμικό στη Microsoft και το μοντέλο διεργασίας ανάπτυξης του καταρράκτη.

Ανάπτυξη εφαρμογών Internet

Η δομή του Internet

Εφαρμογή

HTTP/HTML

πρόσβαση στο Web

FTP

μεταφορά αρχείων

SMTP

μεταφορά email

POP/IMAP

ανάγνωση email

Telnet

χρήση από απόσταση

Μια σειρά από πρωτόκολλα στο επίπεδο αυτό υποστηρίζουν τη λειτουργία και τη διαχείριση του δικτύου:

DNS

Κατανεμημένος κατάλογος ονομάτων

SNMP

Διαχείριση από απόσταση

BOOTP

Αρχικό φόρτωμα κώδικα

RARP

Αντίστροφη μετατροπή διευθύνσεων

Μεταφορά

TCP

Transmission Control Protocol

UDP

User Datagram Protoco

Δίκτυο

Αρχιτεκτονική του παγκόσμιου ιστού

• Ο παγκόσμιος ιστός (world wide web) είναι υλοποιημένες σύμφωνα με το μοντέλο πελάτη-υπηρέτη (client-server).
• Υπηρέτες ακούν για εντολές του πρωτοκόλλου HTTP στη θύρα TCP 80 και απαντούν ανάλογα με το περιεχόμενο της εντολής.
• Οι απαντήσεις είναι συνήθως υπερκείμενο (hypertext) δομημένο σύμφωνα με το πρότυπο HTML.
• Παραπομπές σε άλλες σελίδες ή περιεχόμενο γίνονται με την τυποποιημένη χρήση των Uniform Resource Locators (URL).
• Τόσο ο πελάτης, όσο και ο υπηρέτης μπορούν να προσαρμόσουν δυναμικά το περιεχόμενο μιας σελίδας.

Προσδιορισμός στοιχείων με URI

http://www.dmst.aueb.gr/dds
http://www.altavista.com/cgi-bin/query?pg=q&text=yes&q=link%3akerkis%2emath%2eaegean%2egr%2f%7edspin+%2dhost%3akerkis%2emath%2eaegean%2egr&stq=10&c9k

Το πρωτόκολλο HTTP

• GET
• HEAD
• POST
• PUT
• DELETE
• TRACE

GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org

Περιγραφή σελίδων με HTML

<όνομα ετικέτας παράμετροι>

<ετικέτα>
περιοχή που σημειώνεται
</ετικέτα>

HTML

περιγραφή ολόκληρης σελίδας

HEAD

επικεφαλίδα της σελίδας

BODY

κείμενο της σελίδας

H1-H6

επικεφαλίδες του κειμένου

P

αλλαγή παραγράφου

UL

λίστα με τελείες

OL

αριθμημένη λίστας

LI

στοιχείο λίστας

BR

αλλαγή γραμμής

HR

οριζόντια γραμμή

IMG

εικόνα

A

(anchor) σημείο πρόσβασης από ή σε υπερκείμενο

PRE

προστοιχειοθετημένο κείμενο

DL, DT, DD

λίστα περιγραφών, περιγραφές

I

πλάγιοι χαρακτήρες

B

έντονοι χαρακτήρες

<!doctype html public "-//IETF//DTD HTML//EN">
<HTML>
<HEAD>
<TITLE>Τίτλος της σελίδας</title>

<META NAME="GENERATOR" CONTENT="thread.pl">
<META NAME="AUTHOR" CONTENT="Diomidis Spinellis">
<META HTTP-EQUIV="Content-type" CONTENT="text/html; charset=ISO-8859-7">
<LINK REV="made" HREF="mailto:dds@aueb.gr"> 
<LINK REL="ToC" href="./web/index.htm">
<LINK REV="Subdocument" href="./web/index.htm">
<LINK REL="previous" href="./web/http.htm">
<LINK REL="next" href="./web/cgi.htm">

</HEAD>

<BODY>
<H1>Επικεφαλίδα πρώτου επιπέδου</H1><HR>
Κείμενο που περιέχει ένα σημείο κατάληξης υπερκειμένου
<a name="G42"> (<em>με έντονο κείμενο</em>)</a> 
και μια λίστα:
<ul>
<li> στοιχείο 1
<li> στοιχείο 2
</ul>

<p>
Νέα παράγραφος με ένωση υπερκειμένου στο
<A HREF="http://www.aueb.gr">Οικονομικό Πανεπιστήμιο</A>

<HR>
</BODY>
</HTML>

Επικεφαλίδα πρώτου επιπέδου

• στοιχείο 1
• στοιχείο 2

Νέα παράγραφος με ένωση υπερκειμένου στο Οικονομικό Πανεπιστήμιο (http://www.aueb.gr)

Χαρακτηριστικά της Java

• Απλή
• Αντικεμενοστρεφής
• Μεταφέρσιμη (portable) (και σε επίπεδο μεταγλωττισμένου κώδικα)
• Ανιχνεύει προβλήματα κατά την εκτέλεση και εμφανίζει κατανοητά μηνύματα
• Υποστηρίζει κατανεμημένο προγραμματισμό (distributed programming)
• Επιτρέπει την υλοποίηση ασφαλών προγραμμάτων
• Υποστηρίζει πολυνηματική επεξεργασία (multithreaded processing)
• Αυτόματη αποκομιδή αχρήστων (garbage collection)
• Κατάλληλη για εφαρμογές στο Internet στον πελάτη (applets) και στον εξυπηρετητή (servlets)

Κατηγορίες ενεργού περιεχομένου

• Ενεργό περιεχόμενο στον πελάτη
• Ενεργό περιεχόμενο στον εξυπηρετητή
• Υβριδικό μοντέλο

Ενεργό περιεχόμενο στον πελάτη

• Animated GIF files, sound files, movies, ALT tags
• Javascript και DOM
• Macromedia Flash
• Java applets
• Active-X

Επικοινωνία πελάτη εξυπηρετητή

• Εφαρμογές που ακολουθούν το μοντέλο του Web
• Εφαρμογές που χρησιμοποιούν πρωτόκολλο HTTP
• Εφαρμογές που χρησιμοποιούν το πρωτόκολλο TCP/IP

Τρόποι υλοποίησης ενεργού περιεχομένου στον εξυπηρετητή

• Εκτέλεση ανά αίτηση
• Δεξαμενή με διεργασίες ή νήματα
• Χρήση προτύπων σελίδων
• Επεκτάσεις του Web Server

Τεχνολογίες υλοποίησης ενεργού περιεχομένου στον εξυπηρετητή

• Εκτέλεση ανά αίτηση: CGI
• Δεξαμενή με διεργασίες ή νήματα:
  • Fast CGI
  • Java Servlets
• Χρήση προτύπων σελίδων:
  • Microsoft Active Server Pages (ASP),
  • Sun Java Server Pages (JSP)
  • Hypertext Pre-Processor (PHP)
• Επεκτάσεις του Web Server
  • NSAPI (Netscape FastTrack)
  • ISAPI (Microsoft IIS)
  • Apache extension API (mod_*)

CGI

Υλοποίηση

• sh
• C
• Perl

Προβλήματα

• Απόδοση
• Ανίχνευση συνεδρίας
• Στενή σύνδεση της επεξεργασίας με την εμφάνιση

Fast CGI

Υλοποίηση στον εξυπηρετητή

• Μοναδική εκκίνηση
• Mini application server
• FIFO queue

Προβλήματα

• Εργαλεία ανάπτυξης
• Ειδικές βιβλιοθήκες για ανίχνευση συνεδρίας (session afinity)

Παράδειγμα

Servlets

Υλοποίηση

• Java
• Ένα νήμα ανά αίτηση
• Servlet container (JVM + κλάσεις υποστήριξης)

Πλεονεκτήματα

• Κάλυψη συνεδρίας μέσω καθολικών αντικειμένων
• Πρόσβαση σε όλες τις βιβλιοθήκες της Java (JDBC, XML, XSLT, cookies)
• Java Server Pages - Jasper JSP pre-compiler
• Μεταφερσιμότητα

Υποστήριξη

• Tomcat (apache)
• iPlanet
• WebSphere

Παράδειγμα

PHP

Παρόμοια αυστήματα

• PHP
• JSP
• ASP

Χαρακτηριστικά PHP

• Σελίδες που περιέχουν HTML και κώδικα PHP
• Η γλώσσα περιέχει στοιχεία από την Perl και τη C
• Πλούσιες βιβλιοθήκες
  • Πρόσβαση σε ΒΔ
  • Γραφικά
  • Ανίχνευση συνεδρίας
  • Μεταφορά αρχείων
  • Δημιουργία PDF
  • Email
• Εκτέλεση ώς Apache extension (mod_php) ή CGI

Παράδειγμα

API εξυπηρετητή

Υλοποιήσεις

• NSAPI (Netscape)
• ISAPI (Microsoft)
• Apache API (apache)

Μεταφορά δεδομένων

• URL

  http://www.amazon.com/exec/obidos/shopping-basket/ref=top_nav_sb_gateway/103-2141875-9969416)
  

• POST

  POST http://www.amazon.com/exec/obidos/search-handle-form/103-2141875-9969416 HTTP/1.0
  ...
  
  url=index%3Daps&field-keywords=java+enterprise&explorer-type=gift&Go.x=10&Go.y=10
  

• Cookie

  GET http://www.amazon.com
  ...
  Cookie: ubid-main=430-7602259-8325423; x-main=hQFiIxHUFj8mCscT@Yb5Z7xsVsOFQjBf;session-id=103-2141875-9969416; session-id-time=1038902400; obidos_path_continue-shopping=continue-shopping-url=/subst/home/home.html/103-2141875-9969416&continue-shopping-post-data=&continue-shopping-description=generic.gateway.default
  

Υλοποίηση συνεδρίας

• Αποθήκευση όλων των πληροφοριών στο URL
• Αποθήκευση κωδικού συνεδρίας στο URL
• Αποθήκευση όλων των πληροφοριών σε cookie
• Αποθήκευση κωδικού συνεδρίας σε cookie

http://www.driveme.gr/Athens/AthensMap.ASP?wcu=$cmd=2$id=4_2000_11_09_08_00_20_296
http://www.perseus.tufts.edu/cgi-bin/perscoll?collection=Perseus:collection:Greco-Roman
http://terraserver.microsoft.com/GetPageByXY.asp?XId=9782&YId=12293&SrcId=2&ImgDate=05/17/1992&ImgSize=2&DSize=0

bbs.cordis.lu	FALSE	/	FALSE	2137621534	CFID	47215
bbs.cordis.lu	FALSE	/	FALSE	2137621534	CFTOKEN	18919068
.harvard.edu	TRUE	/	FALSE	2051222305	SITESERVER	ID=7f29e95efe695b0ab41c161acdfb0163
search.support.microsoft.com	FALSE	/	FALSE	1019403742	AnswerWiz	1=serial+mouse+detection&Count=1
search.support.microsoft.com	FALSE	/	FALSE	1019403742	Params	S=F&VR=http%3A%2F%2Fsupport%2Emicrosoft%2Ecom%2Fsupport%3Bhttp%3A%2F%2Fsupport%2Emicrosoft%2Ecom%2Fservicedesks%2Fwebcasts%3Bhttp%3A%2F%2Fsupport%2Emicrosoft%2Ecom%2Fhighlights&KT=ALL&FR=0&HSL=0&LN=EN%2DUS&FSL=0&TSL=0&A=T&SD=GN&SPR=W95&PSL=0&LQ=serial+mouse+detection&T=B&T1=7d&DU=C
search.support.microsoft.com	FALSE	/	FALSE	1019403742	Global	LN=EN%2DUS

Απλοί κανόνες

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

Βιβλιογραφία

• The perl-apache intergration project. Available online http://perl.apache.org.

• Bouchaib Bahli and Dany Di Tullio. Web engineering: An assessment of empirical research. Communications of AIS, 12(14), 2003.

• T. Berners-Lee and D. Connolly. RFC 1866: Hypertext Markup Language — 2.0, November 1995.

• T. Berners-Lee, L. Masinter, and M. McCahill. RFC 1738: Uniform Resource Locators (URL), December 1994.

• S.B. Subrhamanya B.M. Subraya. Object driven performance testing of web applications. In First Asia-Pacific conference on Quality Software. IEEE, 2000.

• R. Braden. RFC 1122: Requirements for Internet hosts — communication layers, October 1989. See also STD3 [STD0003].

• R. Braden. RFC 1123: Requirements for Internet hosts — application and support, October 1989. See also STD3 [STD0003].

• Microsoft Corporation. The component object model specification. Technical report, Microsoft Corporation, Redmond, WA, USA, October 1995.

• R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, et al. RFC 2068: Hypertext transfer protocol — HTTP/1.1, January 1997.

• Piero Fraternali. Tools and approaches for developing data-intensive web applications: A survey. ACM Computing Surveys, 31(9):227–263, September 1999.

• Giorgos Gousios and Diomidis Spinellis. A comparison of portable dynamic web content technologies for the apache web server. In Proceedings of the 3rd International System Administration and Networking Conference SANE 2002, pages 103–119, Maastricht, The Netherlands, May 2002. Best refereed paper award.

• Stefanos Gritzalis and Diomidis Spinellis. Addressing threats and security issues in World Wide Web technology. In Proceedings CMS '97 3rd IFIP TC6/TC11 International joint working Conference on Communications and Multimedia Security, pages 33–46, Athens, Greece, September 1997. IFIP, Chapman & Hall.

• Elisabeth Hendrickson and Martin Fowler. The software engineering of internet software. IEEE Software, 19(2):23–24, March/April 2002.

• Arun Ivengar, Jim Challerger, and Paul Dantzing. High-performance web design techniques. IEEE Internet Computing, March-April 2000.

• The jakarta project. Available online http://jakarta.apache.org.

• K. N. King. Java Programming: from the Beginning, pages 1–38. W. W. Norton & Company, New York, NY, USA, 2000.

• Evangelia Kopanaki, Vangelis Karkaletsis, Constantine D. Spyropoulos, Nikos Avradinis, Nikos Fakotakis, Theodore Kalamboukis, Basilis Kladis, Yannis Lazarou, Themis Panayiotopoulos, and Diomidis Spinellis. MITOS: An integrated web-based system for information management (http://www.dmst.aueb.gr/dds/pubs/conf/2001-EPY-Mitos/html/mitos.html). In 8th Panhellenic Informatics Conference, Nicosia, Cyprus, November 2001. Greek Computer Society.

• E. Krol. RFC 1118: Hitchhikers guide to the Internet, September 1989.

• Mike Morrison, Joline Morrison, and Anthony Keyes. Integrating web sites and databases. Communications of the ACM, 45(9):81–86, September 2002.

• Object Management Group, Inc. The common object request broker: Architecture and specification, July 1996. Revision 2.0 (Updated).

• J. Postel. RFC 768: User Datagram Protocol, August 1980. See also STD6 [STD0006].

• J. Postel. RFC 774: Internet protocol handbook: Table of contents, October 1980. Obsoletes RFC0766 [RFC0766].

• J. Postel. RFC 791: Internet protocol, September 1981. Obsoletes RFC0760 [RFC0760].

• J. Postel. RFC 792: Internet control message protocol, September 1981. Obsoletes RFC0777 [RFC0777]. See also STD5 [STD0005].

• J. Postel. RFC 793: Transmission Control Protocol, September 1981. See also STD7 [STD0007]. Updates RFC0761 [RFC0761].

• Konstantinos Raptis, Diomidis Spinellis, and Sokratis Katsikas. Multi-technology distributed objects and their integration (http://www.dmst.aueb.gr/dds/pubs/jrnl/2001-CSI-Components/html/imtd.html). Computer Standards & Interfaces, 23:157–168, July 2001.

• Jesse Reisman. Web site design: Less is more. IT Professional, 1(5):63–64, September/October 1999.

• J. Siegel. A preview of CORBA 3. Computer, 32(5):114–116, May 1999.

• Shikharesh Majumdar Sucheta Nandipalli. Techniques for achieving high performance web servers. In International Conference for Parallel Processing. IEEE, 2000.

• Sun Microsystems Inc. Java remote method invocation specification. Available online http://java.sun.com/docs/guide/rmi/spec/rmiTOC.html/ (February 2002), December 1999. Revision 1.7, Java 2 SDK, Standard Edition, v1.3.0.

• Jason Hunter with William Crawford. Java Servlet Programming. O' Reilly, 2001.

Διαχείριση υπολογιστικών συστημάτων

Σταθμοί εργασίας

• Εγκατάσταση λειτουργικού συστήματος και εφαρμογών
  • Αυτοματοποίηση
  • Αποφεύγουμε προεγκατεστημένα συστήματα
• Ενημέρωση λειτουργικού συστήματος και εφαρμογών
• Καθορισμός παραμέτρων δικτύου (DHCP)

Εξυπηρετητές

• Υλικό
  • Εσωτερικός χώρος
  • Δυνατότητες επέκτασης
  • Είσοδος και έξοδος
  • Εγκατάσταση σε ικρίωμα
  • Πρόσβαση μόνο στο εμπρόσθιο μέρος
  • Αντικατάσταση εξαρτημάτων σε λειτουργία
  • Συστήματα RAID
• Πολιτική συντήρησης
• Αντίγραφα εφεδρείας
• Εγκατάσταση το κέντρο υπολογιστών
• Διαφορετικό λογισμικό
• Απομακρυσμένη πρόσβαση
• Διαχωρισμός του δικτύου της διαχείρισης των υπολογιστών από το δίκτυο της χρήσης τους

Εξυπηρετητές σε ικρίωμα (rack)

Υπηρεσίες

• Ανοιχτή αρχιτεκτονική
• Πρωτόκολλα και προϊόντα
• Σύνδεση ανεξάρτητα από το τον εξυπηρετητή (π.χ. mail.company.gr)
• Λειτουργία στο υπολογιστικό κέντρο
• Πολλαπλοί εξυπηρετητές για την ίδια υπηρεσία
• Παρακολούθηση της λειτουργίας
• Ένα μηχάνημα ανά υπηρεσία

Τεχνικές αποσφαλμάτωσης

• Κατανόηση του προβλήματος
• Εύρεση της αιτίας (όχι του συμπτώματος) και αποκατάσταση
• Χρήση εργαλείων

• Διαδοχική εξάλειψη πιθανών αιτιών (π.χ. αφαίρεση οδηγών)
• Διαδοχική εκλέπτυνση πιθανών αιτιών (π.χ. traceroute)

• ping
• traceroute / tracert
• nslookup
• strace / truss / apispy
• grep / locate / regedit
• "Use the source Luke"

Η αρχή της μοναδικής διόρθωσης

• Διορθώνουμε το πρόβλημα και όχι το σύμπτωμα
• ... για πάντα ...
• ... χωρίς να ανακαλύψουμε ξανά τον τροχό ...
• ... σε όλα τα μηχανήματα ...
• Η αυτοματοποίηση συνήθως βοηθά

Χώροι ονοματοδοσίας

• Χρήστες
• Μηχανήματα
• Διευθύνσεις δικτύου
• Αρχεία
• Ομάδες χρηστών

• Τύπος ονομάτων
  • Αλγοριθμικός (π.χ. pc01, pc02, dspin, gvour, ptsah, gpap02)
  • Θεματικός (π.χ. thira, naxos, paros, kriti, thasos, samos, ithaki)
  • Λειτουργικός (π.χ. finance, admin, guest)
  • Ελεύθερος, με προτεραιότητα
• Τοπική κάλυψη
• Εύρος έκθεσης

• Προσθήκη
• Αλλαγή
• Διαγραφή
• Οι παραπάνω διαδικασίες εκτελούνται κατά προτίμηση κεντρικά

Καταστροφές: σχεδιασμός και αποκατάσταση

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

Ενέργειες:

• Ελαχιστοποίηση ζημιών (π.χ. χρήση ικριωμάτων μειώνει ζημιές από σεισμούς, σύστημα αδιάλειπτης τροφοδοσίας (uninterruptible power supply (UPS)))
• Προετοιμασία (σχέδιο αποκατάστασης, εφεδρικό κέντρο υπολογιστών)

Διαχείριση αλλαγών

• Χρήση εργαλείων διαχείρισης αλλαγών (π.χ. CVS, RCS)
• Αρχείο των αλλαγών
• Έλεγχος μετά από κάθε αλλαγή
• Ενημέρωση όσων επηρεάζονται

Αναβαθμίσεις

1. Κατάσταση προσφερομένων υπηρεσιών
   1. Ποιες υπηρεσίες προσφέρει ο υπηρέτης
   2. Ποιοι τις χρησιμοποιούν
   3. Ποιο λογισμικό τις προσφέρει
2. Επιβεβαίωση πως κάθε λογισμικό θα δουλεύει στη νέα έκδοση
3. Προγραμματισμός διαδικασίας ελέγχου για κάθε υπηρεσία
4. Προγραμματισμός εφεδρείας
5. Επιλογή του κατάλληλου χρόνου συντήρησης
6. Ανακοίνωση
7. Εκτέλεση των ελέγχων στην παλιά υπηρεσία
8. Αναβάθμιση (μαζί με βοηθό)
9. Επανάληψη των ελέγχων
10. Αν αποτύχει, υποχώρηση σύμφωνα με την εφεδρεία
11. Επικοινωνία με τους πελάτες

Αναβάθμιση στην υπηρεσία TAXISnet.

Συγκέντρωση και αποκέντρωση

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

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

Η υπηρεσία βοηθείας

• Τι υποστηρίζεται
• Ποιος υποστηρίζεται
• Πότε παρέχεται η υποστήριξη
• Ποιος είναι ο χρόνος απόκρισης

Υποστήριξη πελατών

1. Χαιρετισμός
2. Μαθαίνουμε το πρόβλημα
3. Επαναλαμβάνουμε το πρόβλημα και συμφωνούμε με τον πελάτη
4. Δοκιμάζουμε το πρόβλημα
5. Μαζεύουμε προτάσεις για την αντιμετώπιση
6. Επιλέγουμε τη λύση
7. Εκτελούμε τη λύση
8. Ελέγχουμε τη λύση
9. Συμφωνούμε με τον πελάτη πως το πρόβλημα έχει λυθεί

Οργάνωση του κέντρου πληροφορικής

• Φυσική πρόσβαση και ασφάλεια
• Ικριώματα
• Πυροπροστασία
• Ασφάλεια από φυσικές καταστροφές
• Δικτύωση και ψευδοπατώματα
• Ηλεκτρικό ρεύμα
• Κλιματισμός
• Έλεγχος θερμοκρασίας, πρόσβασης, ρεύματος
• Επιγραφές
• Εργαλεία
• Χώροι εργασίας
• Χώροι αποθήκευσης
• Τρόπος μετακίνησης εξοπλισμού

Εσωτερικό αίθουσας υπολογιστών

Το κέντρο υπολογιστών στο εργαστήριο πολυμέσων του ΟΤΕ

Δίκτυα

• Επίπεδα (όλα τα στοιχεία του δικτύου βρίσκονται στο ίδιο επίπεδο 3)
• Με βάση τη φυσική διάταξη του δικτύου
• Με βάση τη λειτουργική διάταξη του δικτύου