Dai Moduli alle Componenti

Modularità: Vantaggi Diminuzione della complessità del problema Information hiding Incapsulazione degli errori Distribuzione del lavoro Sviluppo separato Chiara attribuzione delle responsabilità Riuso Interno al progetto in versioni successive Da parte del programmatore in altri progetti (raro) Da parte di altri programmatori (rarissimo) Facilità di manutenzione ed evoluzione (fino ad un certo punto)

Modularità: Svantaggi Perdita di efficienza Aggiunta di nuove funzionalità può richiedere di riorganizzare la distribuzione in moduli Investimento di tempo e fatica nella definizione di interfacce fra le parti Però… Senza modularità si perde il controllo di ogni progetto meno che banale Inutile avere sw efficiente ma scorretto Nel complesso si ha un’economia di tempo dedicato allo sviluppo usando tecniche basate sulla modularità

Riuso: perché? La produzione del sw avviene sempre in condizioni di tempo critiche Tempo (dei progettisti) è denaro quindi incide sul costo finale al cliente Il primo che arriva sul mercato di solito lo domina Poter riutilizzare delle parti di sw permetterebbe di migliorare le prestazioni Diminuire i costi suddividendo la spesa del pezzo fra vari progetti Terminare prima avendo già dei pezzi fatti Ottenere codice finale migliore usando pezzi “di qualità” Eppure il riuso non è così comune Tranne nelle linee di prodotti

Scrivere per riusare Scrivere codice in modo da poter essere riutilizzato è più difficile (quindi lento, costoso) perché non si possono fare assunzioni implicite sul modo in cui verrà usato produce codice più “generale” quindi intrinsecamente meno efficiente è una spesa inutile se non si è sicuri di riuscire a rivenderlo. Per vendere bisogna produrre documentazione convincente ed utilizzabile avere visibilità sul mercato convincere i potenziali utenti ad aver fiducia

Che fanno gli altri? Lo stesso tipo di problema si incontra in altre linee di produzione Bisogna passare dall’artigianato alla produzione industriale Attenzione: una grossa differenza del sw rispetto ad altri tipi di prodotto è l’insostanzialità del prodotto replicare un “pezzo” non costa nulla verificare un “pezzo” è discutibile Le analogie sono quindi valide solo fino ad un certo punto

Letteratura Mass Produced Software Components M.D. McIlroy Software Engineering, Report on a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7th to 11th October 1968 Planning the Software Industrial Revolution Brad J. Cox Ph.D IEEE Software magazine (November 1990) Software Technologies of the 1990's. Component Software Beyond OO-Programming Chapter 1 C. Szyperski 1999, Addison-Wesley

The Software Industry is Not Industrialized We undoubtedly produce software by backward techniques. We undoubtedly get the short end of the stick in confrontations with hardware people because they are the industrialists and we are the crofters. Software production today appears in the scale of industrialization somewhere below the more backward construction industries. I think its proper place is considerably higher, and would like to investigate the prospects for mass-production techniques in software. McIlroy 1968

Industrial Techniques But certain ideas from industrial technique I claim are relevant. The idea of subassemblies carries over directly and is well exploited. The idea of interchangeable parts corresponds roughly to our term `modularity,' and is fitfully respected. The idea of machine tools has an analogue in assembly programs and compilers. Yet this fragile analogy is belied when we seek for analogues of other tangible symbols of mass production. There do not exist manufacturers of standard parts, much less catalogues of standard parts. One may not order parts to individual specifications of size, ruggedness, speed, capacity, precision or character set. McIlroy 1968

Components The pinnacle of software is systems - systems to the exclusion of almost all other considerations. Components, dignified as a hardware field, is unknown as a legitimate branch of software. …My thesis is that the software industry is weakly founded, and that one aspect of this weakness is the absence of a software components subindustry. We have enough experience to perceive the outline of such a subindustry. McIlroy 1968

Industrial Revolution…20 anni dopo The possibility of a software industrial revolution, in which programmers stop coding everything from scratch and begin assembling applications from well-stocked catalogs of reusable software components, is an enduring dream that continues to elude our grasp. Although object-oriented programming has brought the software industrial revolution a step closer, common-sense organizational principles like reusability and interchangeability are still the exception rather than the rule. Cox 1990

Industrial Revolution…NOW From my experiences as Component Competency Lead for IBM Global Services’ Center of Competency for Enterprise Application Development, I encounter many recurrent issues and problems that large organizations face in their application architecture life cycle. I have noticed many significant trends and a high level of interest in designing and integrating components across the enterprise, both green-field…and legacy transformation… Ali Arsanjani Communication ACM October 2002

Why Components? What is the motive for producing, distributing, buying, or using software components? What are the benefits of component software? The simplest answer is: Components are the way to go because all other engineering disciplines introduced components as they become mature - and still use them. Szyperski 1999

Standardized Components Needed It is easy to see how interchangeable parts could help in manufacturing. But manufacturing involves replicating a standard product, while programming does not. Programming is not an assembly-line business but a build-to-order one, more akin to plumbing than gun manufacturing. But the principles of standardization and interchangeability pioneered for standard products apply directly to build-to-order industries like plumbing. They enabled the markets of today where all manner of specialized problems can be solved by binding standardized components into new and larger assemblies. Cox 1990

Motivazioni “economiche” delle componenti Per una ditta usare un supporto sw è costoso Acquisizione e mantenimento i costi possono essere abbattuti se si usa sw standard Ristrutturazione del lavoro/processo interno per adeguare le procedure a quelle supportate dal sw i costi possono essere abbattuti se si usa sw ad hoc Per una ditta usare un supporto sw è utile nella misura in cui li rende “migliori” delle concorrenti Se tutti nel settore usano sw, richiede di avere sw ad hoc ottimizzato Autoprodurre del sw è rischioso perché in caso di ritardo sirischia di restare senza nessun supporto Vi è quindi una tensione fra vantaggi e svantaggi di usare sw standard rispetto a (farsi) produrre un sw ad hoc Parziale soluzione: assemblaggio personalizzato (=sw ad hoc) a partire da componenti standard Liberamente tratto da Szyperski 1999