An introduction to software architectures

1

So%ware Architecture Gothenburg, February 2013

Università degli Studi dell’Aquila

Patrizio Pelliccione [email protected] Università degli Studi dell’Aquila

DiparHmento di Ingegneria e Scienze dell’Informazione e MatemaHca L’Aquila (Italy)

DiparHmento di Ingegneria e Scienze dell’Informazione e MatemaHca (DISIM)

So.ware Architecture

[Renzo Piano: Architecture of the

new Auditorium in L’Aquila -‐ Italy]

2


The architecture of buildings

o  No comparable intuiHon for so%ware §  We must be more methodological and analyHcal in our approach

o  So%ware is intrinsically intangible §  More difficult to measure, analyze, and evaluate qualiHes

o  So%ware more malleable than physical building materials §  Types of changes unthinkable in a physical domain

The Crooked House (Sopot, Pola

nd)

Source: h\p://www.flickr.com/photos/brocha

/2240736671

Museum of Contemporary Art (Niteroi, Brazil) Source: h\p://www.flickr.com/photos/howvin/7457617764/

Kansas City Public Library (Missouri, USA) Source: h\p://www.flickr.com/photos/jonathan_moreau/418008212

3


So.ware Architecture and So.ware Engineering

o Every applicaHon has an architecture

Russian Embassy (Havana, Cuba) h\p://upload.wikimedia.org/wikipedia/commons/d/d2/Russian_embassy_in_Havana.jpg

[MedTaylor2009]

4



o Every applicaHon has an architecture § The architecture of a system can be characterized by the principal design decisions made during its development

[MedTaylor2009]

Architecture underlying command-‐line shell programs

ls invoices | grep –e August | sort

Quickly and easily compose new applicaHons from exisHng ones by following simple rules

Filter: program that takes a stream of text characters as input and produces a stream of characters as its output

Pipe: a way to connect two filters – it routes the character stream output of the first filter to the character stream input of the second filter

5




[MedTaylor2009]

Architecture underlying command-‐line shell programs

ls invoices | grep –e August | sort

Quickly and easily compose new applicaHons from exisHng ones by following simple rules

Filter: program that takes a stream of text characters as input and produces a stream of characters as its output

Pipe: a way to connect two filters – it routes the character stream output of the first filter to the character stream input of the second filter

Architectural style pipe-and-filter

6




o Every applicaHon has at least one architect § Perhaps not known by that Htle or recognized for what is done

o Architecture is not a phase of development § Where did the so%ware architecture come from?

§ How does it change?

[MedTaylor2009]

7


General workflow

stakeholders

concerns

[HKNORA07,PIM09]

Architectural constraints and requirements

Ideas

Constraints

Req1:..Req2:..Req3:..………

Architectural requirements

C2

C3C1

C4Software Architecture

Software Architecture

synthesis

Evaluation and Decisions making

8


So.ware architecture characterisLcs o MulHtude of stakeholders

§  Dealing with a broad variety of concerns and stakeholders, and has a mulHdisciplinary nature.

o  SeparaHon of concerns §  Stakeholder concerns are addressed by modeling and describing the architecture from separate points of view associated with the various stakeholder concerns.

o  Quality-‐driven §  Architecture of a system is closely related to its quality a\ributes, such as fault-‐tolerance, backward compaHbility, extensibility, reliability, maintainability, availability, security, usability, and other such –iliHes.

o  Recurring styles §  Common terms for recurring soluHons are architectural style, strategy or tacHc, reference architecture and architectural pa\erns.

o  Conceptual integrity §  The architect assumes the role of “keeper of the vision”, making sure that changes to the systems are in line with the architecture, hence preserving conceptual integrity.

9


So.ware architecture benefits o  Basis for analysis of so,ware systems' behavior before the system has been built.

§  SubstanHal cost-‐saving and risk-‐miHgaHon.

o  Basis for re-‐use of elements and decisions. §  Saving design costs and miHgaHng the risk of design mistakes.

o  Support for early design decisions which have high impact on a system's development, deployment and maintenance life. §  Prevent schedule and budget overruns.

o  Facilitate communica?on among stakeholders, contribu?ng to a system that beAer fulfills their needs. §  SubstanHal cost-‐saving and risk-‐miHgaHon: communicate about design decisions before the system is implemented, when they are sHll relaHvely easy to adapt.

10


History -‐ past “Architecture is concerned with the selecHon of architectural elements, their interacHons, and the constraints on those elements and their interacHons necessary to provide a framework in which to saHsfy the requirements and serve as a basis for the design.”

Elements are divided into processing elements, data elements and connecHon elements [PerryWolf92]

SA for a specific system may be captured as “a collecHon of computaHonal components -‐ or simply components -‐ together with a descripHon of the interacHons between these components -‐ the connectors”

[GarlanShaw93]

“An architectural descripHon is organized into one or more consHtuents called (architectural) views. Each view addresses one or more of the concerns of the system stakeholders. A view is a parHal expression of a system’s architecture with respect to a parHcular viewpoint.” [IEEE 1471-‐2000]

11


History -‐ present

A system architecture is the fundamental concepts or properHes of a system in its environment embodied in its elements, relaHonships, and in the principles of its design and evoluHon. [ISO/IEC/IEEE 2011]

12


History -‐ present

A system architecture is the fundamental concepts or properHes of a system in its environment embodied in its elements, relaHonships, and in the principles of its design and evoluHon. [ISO/IEC/IEEE 2011]

“A so%ware system’s architecture is the set of principal design decisions about the system.”

Design decisions related to system: structure, behavior, interac?on, non-‐func?onal proper?es, development, business posiHon.

[MedTaylor2007, MedTaylor2009]

13


History -‐ near future So%ware industry is moving from a “Specify-‐Code-‐Test”

philosophy to a “Explore-‐Integrate-‐Validate” one.

Explore

•  ExploraHon of available so%ware and makes explicit the degree of uncertainty associated with it in relaHon to an opportunisHc goal G

Integrate •  Assistance of the producer in creaHng the appropriate integraHon means towards G

Validate •  ValidaHon of the integrated system to assess its quality with respect to G and the current context

[ACDIPT2011]

14


Architectures and architecture descripLons

[ISO/IEC/IEEE 2011]

15


Architecture DescripLon Languages: history o  First generaHon (1990-‐2000)

§  Purpose to define the ideal ADL

§  Mainly based on component-‐connector view

§  Supported features •  C&C specificaHon, composiHon, abstracHon, reusability, analysis…

o  Second generaHon (2000 up to today) §  Supported features

•  ConfiguraHon management, distribuHon, product-‐line modeling, …

o  Result: ProliferaHon of ADLs (in a recent survey we count 125 ADLs)

[MedTaylor2007, MLMPT13, MT00]

16


What Industry needs from ADLs: A Survey

o  Research quesHons §  RQ1: What are the architectural descripHon needs of

pracHHoners?

§  RQ2: What features typically supported by exisHng ADLs are useful (or not useful) for the so%ware industry?

o  Main findings §  F1: All top used ADLs have been originated in industry

§  F2: ALs should combine features supporHng both communicaHon and disciplined development. We call this introvert versus extrovert nature of architects role

§  …

17


What Industry needs from ADLs: A Survey

ADLs used by the interviewed populaHon

18


Being so.ware architect…

19


References o  [ACDIPT2011] M. AuHli, V. Cortellessa, D. Di Ruscio, P. Inverardi, P. Pelliccione, and M. Tivoli. Eagle: engineering so%ware in the ubiquitous

globe by leveraging uncertainty. In Proceedings of the 19th ACM SIGSOFT symposium and the 13th European conference on FoundaHons of so%ware engineering, ESEC/FSE ’11, pages 488–491, New York, NY, USA, 2011. ACM.

o  [GarlanShaw93] Garlan, D. & Shaw, M. “An IntroducHon to So%ware Architecture,” 1–39. Advances in So%ware Engineering and Knowledge Engineering, Vol. 2. Edited by V. Ambriola and G. Tortora. New Jersey: World ScienHfic Publishing Company, 1993.

o  [HKNORA07] C. Hofmeister, P. Kruchten, R.L. Nord, H. Obbink, A. Ran, and P. America, “A General Model of So%ware Architecture Design Derived from Five Industrial Approaches,” J. Systems and So%ware, vol. 80, no. 1, pp. 106-‐126, 2007.

o  [IEEE 1471-‐2000] IEEE 1471: ANSI/IEEE 1471-‐2000: Recommended PracHce for Architecture DescripHon of So%ware-‐Intensive Systems

o  [ISO/IEC/IEEE 2011] ISO/IEC/IEEE 42010:2011 Systems and so%ware engineering – Architecture descripHon, 2011.

o  [MedTaylor2007] Medvidovic, N., Dashofy, E. M., and Taylor, R. N. 2007. Moving architectural descripHon from under the technology lamppost. Inf. So,w. Technol. 49, 1 (Jan. 2007), 12-‐31.

o  [MedTaylor2009] Taylor, R. N., Medvidovic, N., and Dashofy, E. M. 2009 So,ware Architecture: Founda?ons, Theory, and Prac?ce. Wiley Publishing.

o  [MLMPT13] Ivano Malavolta, Patricia Lago, Henry Muccini, Patrizio Pelliccione, Antony Tang, "What Industry Needs from Architectural Languages: A Survey," IEEE TransacHons on So%ware Engineering, 2013. IEEE computer Society Digital Library. IEEE Computer Society.

o  [MT00] Nenad Medvidovic and Richard N. Taylor. 2000. A ClassificaHon and Comparison Framework for So%ware Architecture DescripHon Languages. IEEE Trans. So%w. Eng. 26, 1 (January 2000), 70-‐93.

o  [PerryWolf92] Dewayne E. Perry and Alexander L. Wolf. ``FoundaHons for the Study of So%ware Architecture''. ACM SIGSOFT So,ware Engineering Notes, 17:4 (October 1992). (Original paper: Dewayne E. Perry and Alexander L. Wolf. "So,ware Architecture". August 1989)

o  [PIM09] Patrizio Pelliccione, Paola Inverardi and Henry Muccini, CHARMY: A Framework for Designing and Verifying Architectural SpecificaHons (2009), in: IEEE TransacHons on So%ware Engineering (TSE), 35:3(325 -‐ 346)

20


Università degli Studi dell’Aquila

Patrizio Pelliccione [email protected] Università degli Studi dell’Aquila

DiparHmento di Ingegneria e Scienze dell’Informazione e MatemaHca L’Aquila (Italy)

DiparHmento di Ingegneria e Scienze dell’Informazione e MatemaHca (DISIM)

QuesLons?

[Renzo Piano: Architecture of the

new Auditorium in L’Aquila -‐ Italy]

An introduction to software architectures

Documents

Transcript of An introduction to software architectures