Software architecture

The software architecture describes in a diagrammatic manner symbolic system and the various components from one or several computer programs, their interrelationships and their interactions. Contrary to the specifications systems resultants of the functional, the software architecture, produced at the time of the phase of design analyzes, does not describe what a program must carry out but rather how it must be conceived so as to answer the specifications. The analysis describes to it “what to make” whereas architecture describes it “how to do it”.

Context and motivation

The phase of software design is the equivalent, in data processing, of the phase of design in traditional engineering (mechanical, civil or electric); this phase consists in entirely carrying out the product in a form abstracted before the effective production. On the other hand, the immaterial nature of the software (modelled in information and not in the matter), returns the border between architecture and the product much fuzzier than in traditional engineering. The use of tools CASA (Computer-aided software engineering) or the production of architecture starting from the code itself and documentation system make it possible to highlight the close link between architecture and the product.

Software architecture constitutes largest deliverable of a software process after the product (software itself). Indeed, the phase of design should consume around 40% of the total effort of development and should be higher or equal, in effort, with the phase of coding. It is important, here, not to confuse the phase of development of the macro-cycle of development of an iterative method like UP (Unified Process) and the phase of design of a straight-line method. In a straight-line method, the activities of design are found gathered in only one great phase whereas they are distributed in the whole of the microcycles of an iterative method. In both cases, the total effort of design should be close to 40% but it can be less. The effort depends largely on the type of developed software, of the expertise of the development team, the rate of re-use and the software process.

The two main aims of any software architecture are the reduction of the costs and the increase in the quality of the software; the reduction of the costs is mainly carried out by the re-use of software components and the reduction in the turn-around time (correction of errors and adaptation of the software). Quality, on the other hand, is distributed through several criteria.

Software quality standards

interworking expresses the capacity of the software to communicate and use the resources of other software like, for example, the documents created by a certain application.

the portability expresses the possibility of compiling the source code and/or of carrying out the software on platforms (machines, operating systems, environments) different.

compatibility expresses the possibility, for a software, to function correctly in an old environment (downward compatibility) or more recent (upward compatibility).

the validity expresses the conformity of the functionalities of the software with those described in the schedule of conditions.

verifiability expresses the simplicity of checking of the validity.

the integrity expresses the faculty of the software to protect its functions and its data of accesses not - authorized.

reliability expresses the faculty of the software to correctly manage its own errors of operation in the course of execution.

maintainability expresses the simplicity of correction and modification of the software, and even, sometimes, the possibility of modification of the software in the course of execution.

the reutilisability expresses the capacity to conceive the software with components already designed while allowing the simple re-use of its own components for the development of other software.

extensibility expresses the possibility of simply extending the functionalities of a software without compromising its integrity and its reliability.

the effectiveness expresses the capacity of the software as well as possible to exploit the resources offered by the machines where the software will be established.

autonomy expresses the capacity of control of its execution, its data and its communications.

the transparency expresses the capacity for a software to mask with the user (human or machine) the useless details with the use of its functionalities.

the composability expresses the capacity for a software to combine information coming from different sources.

the ease of use describes the facility of training and use of the software by the users.

Reduction in the degradation of the software

A weak architecture or goes away can involve serious problems during the maintenance of the software. Indeed, any modification of a badly structured software can destabilize the structure of this one and involve, with long, a degradation. The architect should thus conceive, systematically, a maintainable and extensible architecture.

In the iterative processes like UP (Unified Process), the management of the changes is paramount. Indeed, it is implicitly considered that the needs for the users of the system can change and that the environment of the system can change. The architect has thus the responsibility to envisage the worst and to conceive architecture consequently; most maintainable possible and most extensible possible.

Many software were created without architecture by several generations of developers having used each one of a wild imagination to succeed in maintaining the integrity of the system. Such an absence of architecture can be qualified of organic architecture . Indeed, a developer confronted with such an architecture has more the impression to work with a living organism than with an industrial product. It results from it that the complexity of the software makes so that this one is extremely difficult to include/understand and to modify. In extreme cases, to modify part of the system is closer, in complexity, of the heart transplant that change of carburettor.

Development for and by the re-use

The re-use of software components is the activity making it possible to realize the most substantial savings, still is necessary it to have components to be re-used. Moreover, the re-use of components requires to create a software architecture allowing a harmonious integration of these components. The development by the software re-use thus imposes a perpetual cycle of production-re-use and a standardized software architecture.

A well orchestrated re-use requires the creation and the maintenance of a software Bibliothèque and a change the x-ray one; to create an application amounts creating the components of library necessary then to build the application using these components. Such a library, facilitating the development of application is a Framework (cadriciel) of company and its architecture, as its documentation are the angular stones of the software re-use in company.

The role of the architect thus moves towards that of librarian. The architect must explore the library to find the components software suitable then to create the missing components, to document them and integrate them into the library. In a large company, this role of librarian is filled by the architect as a chief who is responsible for the harmonious development of the library and the conservation of the integrity of his architecture.

Architecture a question from point of view

The description of a complex system as a computer software can be made according to several different points of view but each one obeys the formula of Perry and Wolf: Architecture = Elements + Forms + Motivations . According to the level of Granularity, the elements can vary in the faces (lines of code, procedures or functions, modules or classes, parcellings or layers, applications or computing systems), they can vary in Raffinement (outline, solution to be improved or final solution) and in Abstraction (physical ideas or concepts, classes or objects, software components). The elements can also have a temporality (an existence limited in time) and a localization (an existence limited in space).

If the elements are, in general, represented by rectangles or ovals, the forms as-with are made up, most of the time, of elements connected by lines or arrows. The semantics of the bonds determine the major part of the semantics of the diagram and the aspect of the system which is described there.

Principal types of bonds

the functional dependence , means that the element source requires the element of destination to carry out its functionalities.

the flood of control , means that the element of destination will take the control of the execution after the termination of the element source.

the transition from state , means that the system will pass from the state source to the state of destination.

the change of activity, means that the system will carry out the activity of destination after the source activity.

the flood of data , means that information runs out of the element source towards the element of destination.

the bond of communication , means that two elements exchange information.

the composition, means that the element source is composed of one or several data of the type of the element of destination.

the heritage (generalization) , means that the element source has the whole of the data and the behaviors of the element of destination.

the sending of message , means that the element source sends a message to the element of destination.

Models of architecture

Independently of the form which a diagram of architecture takes, this one represents always only one point of view of on the system considered, most important being the motivations. Indeed, for what is used to produce a diagram if it is useless (not used) or if the reasons of the architectural choices vague and not-are clarified. To avoid formulating the motivations for each diagram, the architect will produce the various diagrams according to a model of design and will re-use owners of tested design.

A model of design (or architecture) is composed of a whole from point of view, each one being composed of a unit of various kinds of diagrams. He also proposes means to bind the various sights and diagrams the ones with the others so as to sail easily, it acts of the mechanisms of architectural Traçabilité. The traceability must also extend to the specifications systems and even until the needs that these specifications fill. The currency of the three founding fathers of UML is “ Centré on architecture, controlled by the cases of use and with the iterative and incremental development ”. This currency states clearly that no architectural decision must be taken without this one not being directed (controlled) by the satisfaction of the specifications systems (case of use).

The conventional model

This diagram described, on the left, the specifications systems which are also represented by diagrams (Entities-relations, Flux of data, State-Transitions). And on the right, we have the various activities of design taking as inputs deliverable phase of analysis. We see that traditional software architecture would require to produce at least four distinct sights: an architecture of the data (design of the data), an functional architecture and/or modular (architectural design), another functional architecture and/or modular for the user interfaces (design of the interfaces) and a detailed architecture (process charts, state-transitions) of the various modules (design of the components).

The pyramid expresses that each layer is built on the preceding one. Indeed, the components carrying out the functionalities of the software must handle elements of data which must thus be described beforehand. In the same way, the components making the user interfaces must use the functionalities of the software described beforehand. And finally, the creation of the detailed architecture of each component of the software requires, obviously, that those are invented beforehand.

This model of architecture imposes a clear separation between the data, the treatments and the presentation. We see here the outline of the Patron of design MVC.

Model of analysis or model of architecture?

Since the analysis also produces diagrams, does it is natural to be questioned, indeed, when finish the analysis and when begins architecture? The answer to this question is extremely simple: the elements of the diagrams of analysis correspond to visible and comprehensible elements by the users of the system, whereas the elements of the diagrams of architectures do not correspond to any tangible reality for those.

The model of 4 + 1 sights

The model of Kruchten says model of 4 + 1 sights is that adopted in the Unified Process. Here still, the model of analysis, baptized seen Case of use, constitutes the binder and justifies the creation of all the diagrams of architecture.

Sight of the cases of use

The sight of the Cas of use is a model of analysis formalized by Ivar Jacobson. A case of use is defined like a whole of scenarios of use, each scenario representing a sequence of interaction of the users (actors) with the system.

The interest of the cases of use is to control the analysis by the requirements of the users. Those feel concerned because they can easily include/understand the cases of use which relate to them. This method thus makes it possible to help to formalize the true needs and expectations users; their criticisms and comments being bricks of the specification of the system.

Each case of use is represented by a diagram of case of use, each scenario of this one being described by one or more dynamic diagrams: activity charts, of sequence, diagrams of communication or of state-transitions.

Logical sight

The logical sight constitutes the principal architectural description of a computing system and much with small projects are satisfied with this only sight. This sight described, in a static and dynamic way, the system in term of objects and classes. The logical sight makes it possible to identify the various elements and mechanisms of the system to be realized. It makes it possible to break up the system into abstractions and is the heart of the re-use. Indeed, the architect will recover a maximum of components of the various bookstores and cadriciels (Framework) at his disposal. An active search for free and/or commercial components could also be considered.

The logical sight is represented, mainly, by static diagrams of classes and of objects enriched by dynamic descriptions: activity charts, of sequence, diagrams of communication or of state-transitions.

Sight of the processes

The sight of the processes describes the interactions between the various processes, threads (wire of execution) or tasks, it also makes it possible to express the synchronization and the allowance of the objects. This sight makes it possible above all to check the respect of the constraints of reliability, effectiveness and performances of the multi-task systems.

The diagrams used in the sight of the processes are exclusively dynamic: activity charts, of sequence, diagrams of communication or of state-transitions.

Sight of realization

The sight of realization makes it possible to visualize the organization of the physical components (dynamic and static bookstore, source code…) in the environment of development. It makes it possible the developers to be found in the jumble which can be a data-processing development project. This sight also makes it possible to manage the configuration (authors, versions…).

The only diagrams of this sight are the diagrams of components.

Sight of deployment

The sight of deployment represents the system in its environment of execution. It treats geographical constraints (distribution of the processors in space), of the constraints of band-widths, the response time and the performances of the system as well as tolerance to the faults and the breakdowns. This sight is extremely useful for the installation and the regular maintenance of the system.

The diagrams of this sight are the diagrams of components and the diagrams of deployment.

Architectural styles

Software architecture, just like traditional architecture, can be categorized in styles. Indeed, in spite of the million computing systems built all over the world with the fifty last year old court, all are classified among an extremely restricted number of architectural styles. We will point out that, as in traditional architecture, it is often by the mixture of old styles that the new ones appear.

Architecture in calls and returns

This architecture is based on the gradual Raffinement suggested by Nicklaus Wirth. This approach, also called functional decomposition, consists in cutting out a functionality under-functionalities which are also divided into under-functionalities and so on; the currency to divide to reign is often used to describe this step.

So in the beginning this architecture was based on the use of functions, the passage to a modular method or object is very natural; the functionality of a module or an object is carried out by hard-working submodules or baptized under-objects (worker). The hierarchy term of control is then used to describe the extension of this architecture to the modular paradigm or object. A form derived from this architecture is the distributed Architecture where the functions, modules or classes are found distributed on a network.

Architecture in layers

The design of software requires to resort to bookstores. A very specialized bookstore uses less specialized bookstores which themselves use generic bookstores. Moreover, as we already mentioned, the effective development of reusable components nécecessite to create a software bookstore; architecture in layer is the inescapable consequence of such an approach. Indeed, the new components use the old ones and so on, the bookstore thus tends to becoming a kind of stacking of components. Division in layers then consists in gathering the components having a great cohesion (semantic similar) so as to create a stacking of parcellings of components; all components of the roadbases dependant functionally on the components of the sub-bases.

Architecture centered on the data

In this architecture, a central component (DBMS, Datawarehouse, Blackboard) is responsible for the management of the data (conservation, addition, withdrawal, setting-with-day, synchronization,…). The peripheral components, baptized customers, use the central component, baptized waiter of data, which behaves, in general, in a passive way (DBMS, Datawarehouse). A passive waiter does nothing but obey blindly the orders whereas an active waiter (Blackboard) can notify a customer if a change with the data which relates to it produces.

This architecture clearly separates the data (waiters) of the treatments and the presentation (customers) and thus allows a very great integrability, indeed, customers can be added without assigning the other customers. On the other hand, all the customers are dependant on the architecture of the data which must remain stable and which is thus not very extensible. This style thus requires a very important investment in the architecture of the data. The datawarehouses and the federate databases are extensions of this architecture.

Architecture in flood of data

This architecture is made up of several software components connected to each other by data flows. Information circulates in the network and is transformed by the various components which it crosses. When the components are distributed on only one line and that they do nothing but pass information transformed to their neighbor, one speaks then about architecture by batch (batch). If the components are distributed on a data-processing network and that they carry out transformations and intelligent syntheses of information, one speaks then about architecture of mediation.

Orientated architecture objects

The components of the system (objects) integrate data and the operations of treatment of these data. The communication and coordination between the objects are carried out by a mechanism of passage of messages. This architecture is often described by the three pillars: encapsulation, heritage and polymorphism. The encapsulation relates to the detailed architecture of each object, the data being protected from direct access by a layer of interface. Moreover, the sub-functions, useless to use the object, are masked with the user of the object. The heritage makes it possible to avoid the redundancy of code and facilitates the extensibility of the software, the functionalities common to several classes of objects being gathered in a common ancestor. Polymorphism makes it possible to use objects different (having distinct behaviors) in an identical way, this possibility is carried out by the definition of interfaces to implement (abstract classes).

Orientated architecture agents

Architecture agent is the product of the passage of the objective component towards the projective component. Indeed, the object is primarily a component liability offering of the services and using other objects to carry out its functionalities; architecture object is thus an extension of architecture in calls and returns. The agent, on the other hand, uses in an intelligent way the other agents to carry out its objectives; it established dialogs with the other agents, it negotiates and exchange of information.

History

1960 to 1970

The origin of the concept of software architecture goes up at the end of the years 1960 with the invention of the structured Programmation. A computer program was then conceptualized like a succession of stages (flow of control) represented by the first diagrams of architecture, the flow charts (process charts). With the beginning of the year 1970, with the development of the modular Programming, the computer programs were regarded as whole of components (the modules) exchanging information. The diagrams of data flow were then used to represent this type of architecture.

1964, creation of Simulated-I
1967, creation of Simulated-67

1970 to 1980

It is during decade 1970-80 that the architectural great principles were elaborate. One distinguished architecture system describing the relations and interactions of the whole of the software components of detailed architecture describing the individual architecture of each Composant S. One separated static architecture describing the temporally invariable interrelationships (functional dependences, flow of control, data flow) from dynamic architecture, describing the interactions and the evolution of the system in time (diagrams of activity, of sequence, of states, Petri nets, etc). It is also during this decade that the guiding principles of contemporary software architecture were elaborate: Masking of information, functional, strong Independence cohesion and weak coupling. The principal architectural styles also transfer the day: Architecture in calls and returns (hierarchy of control), Architecture centered on the data, Architecture in flood of data, Architecture in layers and Orientated architecture objects.

Significant events

1970, E.F. Codd publishes: " has Relational Model off Dated for Broad Shared Data Banks " , ACM, vol. 13, No 6, pp. 377-387.
1971, NR. Wirth creates the language Pascal. " The Programming Language Pascal " , Acta Informatica, No 1, pp. 35-63. The same year, it publishes " Program Development by Stepwise Refinement ", Com. ACM, vol. 14, No 4, pp. 221-227.
1972, O. Dahl, E. Dijkstra and C. Hoare publishes: " Structured Programming ", Academic Near.
1973, J.B. Refusals publishes: " Modularity ", In 4dvanced Race in Software Engineering, F. Bauer, ED., Springer- Verlag, Berlin.
1974, IBM definite language SEQUEL ( Structured English Query Language ) and implements it on prototype SEQUEL-XRM.
1975, Mr. A. Jackson. publish: " Principles off Program Design " , Academic Near.
1976-77, IBM revises SEQUEL called SEQUEL/2 was defined and the name changed into SQL.
1979, Relational Software introduces its product Oracle V2 like management system of relational databases. This version implements a basic language SQL (Requête and Jointure).
1979, E. Yourdon and L.L. Constantine publish: " Structured Design: Fundamentals off has Discipline off Computer Program and Systems Design " , Prentice Hall.

1980 to 1990

The decade 1980-90 was that of the development of orientated architecture object. This type of architecture introduced three new types of software components: the object, the class and the méta-class (parameterized class or gauge of class); as well as ontological relations between these components: is one (heritage), is composed of (composition), etc the relation of heritage is a major innovation allowing the re-use of code and facilitating its adaptation to other contexts of use.

At the industrial level, on the other hand, this decade is without question that of architecture with three layers centered on the data (3-third). This type of software architecture, separating architecture from the programs of the architecture of the data, is opposed thus completely to the principle of strong cohesion preached by architecture object. The stress is laid on the architecture of the data; the diagrams of this type of architecture are the conceptual model data and the diagrams entities relations. The development of the management systems of relational databases, of the protocols multibases as their standardizations (standardizations) constitutes the technological foundations of this architectural choice.

Significant events

1983, Grady Booch publishes: " Software Engineering with Ada " , Benjamin Cummings.
1983, Relational Software becomes Oracle Corporation and introduced Oracle V3 (support of the transactions).
1983-1985, Bjarne Stroustrup develops the C++ with the Beautiful Laboratory.
1984, U. Dayal and H. Hwang publish: " View definition and generalization for database integration in MULTIBASE: With system for heterogeneous distributed databases " , IEEE Trans, Software Engineering, SE-10, No 6,628-644.
1986, SQL was adopted by the institute of American standardization (ANSI), then like international standard by the ISO (ISO/CEI 9075).
1987, Ivar Jacobson founds Objectory Systems to sell its method of development: ObjectOry
1990, A.P. Sheth and J.A. Larson publish: " Federated Database Systems and Managing Distributed, Heterogeneous, and Autonomous Databases ". ACM Computing Surveys.

1990 to 2000

At the beginning of the decade 1990-2000 one counted a very great number of distinct architectural representations. In 1995, UML (Unified Modeling Language) became the international standard of representation of software architecture. The development directed object is spread in industry, the management systems of databases are now perceived like a convenient way to ensure the persistence of the objects. The basic management systems of data object-relational and objects make their appearances. One also sees appearing distributed architectures; the computer programs are not simply any more perceived like having to offer services to human beings but also to other programs. The arrival of the opened networks, in particular Internet, changes the architectural landscape completely. Architecture with three layers centered on the data (3-third) is now carried out by the triplet database server, waiter of application Web and Navigateur Web.

The university research on software architecture concentrates more on the problems of coupling between objects and interworking syntactic and semantic. The problem of the coupling is primarily perceived like a problem of communication between objects, to see dialogs between intelligent agents; orientated architecture agent appears. The principle of re-use of the software components is now applied to architecture. Architectural ways of doing, principles or styles can be re-used; the owners of design appear, of which one of the first is the famous MVC.

Significant events

1992, Gio Wiederhold publishes: " Mediators in the Architecture off Future Information Systems " , IEEE Computer Magazine
1994, the modern definition of software agent is accepted by the scientific community: " Special exit one intelligent services. " , Communication off the ACM.
1994, Sun Microsystems launches the pure computer programming language object Java.
1995, UML is born (OOPSLA' 95).
1995, Gamma and Al publishes: " Patterns Design: Elements off Reusable Object-Oriented Software " , Addison-Wesley.
1998, the W3C recommends the language to beacon XML.

2000 to 2010

Our decade is characterized by a return of the distributed databases made possible thanks to technology XML. The XML is a language of interface, syntactically standardized and having very a semantic great power of expression. Traditional architecture 3-third is found now in the shape of three layers of mediations of data: data management XML, transformation and fusion of data XML and presentation of data XML. Technology XML allows the syntactic specification (DTD, XSD), the transformation (XSLT), the presentation (XSL) and the semantic specification (RDF, RDFS, OWL). There exists now several software libraries making it possible to manage data XML and the majority of DBMS support XML now.

This new type of architecture is opposed to the centralized vision data which one finds in an architecture centered on the data traditional (like the “Datawarehouse” promoted by IBM). This form of architecture names the '' mediation of data '', it is characterized by:

an intelligent treatment of information (of the data supporting an high level of abstraction and generalization).
an access and an integration of several information sources.
a dynamic transformation of flow of information by filters and translators.
the existence of intelligent repertories and bases of information like catalogs.
the management of the uncertainty connected to the data absent or incomplete and the data badly included/understood.
management clarifies semantic interworking thanks to general ontogies and fields.

The development directed agent (OA) leaves gradually the universities, it exists now a multitude of software tools for the design of system baseds on the agents but the majority are not intended yet to become production equipments. The language KQML (Knowledge Query and Handling Language) is a language of communication inter-agent which could be essential very well in the near future. There will be no revolution on the level of the computer programming languages, the various functionalities of the agents are implemented using software libraries. The three types of architectures OA which emerge are: considered architecture , architecture reactivates and hybrid architecture .

Tools

Azuki - Framework Java having for objective the separation of the concerns.
Boulm - a very good software of free modeling UML
IBM Rational - the product of the three amigos founders of UML
Silverrun - a software of modeling for the Datarun method, North-American version of Merise.
solutions MEGA
Acceleo - Generating of code MDA, open source based on Eclipse and EMF
Article Tutorial Acceleo with GMF: Generation of slides starting from a DSL MindMap

Random links: