Architecture description languages

Architecture description languages

Architecture description languages (ADLs) are used to describe a Software Architecture. Several different ADLs have been developed by different organizations, including AADL (SAE standard), Wright (developed by Carnegie Mellon), Acme (developed by Carnegie Mellon), xADL (developed by UCI), Darwin (developed by Imperial College London), DAOP-ADL (developed by University of Málaga). Common elements of an ADL are component, connector and configuration.

[edit] Views

Software architecture is commonly organized in views^[8], which are analogous to the different types of blueprints made in building architecture. Within the ontology established by ANSI/IEEE 1471-2000, views are instances of viewpoints, where a viewpoint exists to describe the architecture in question from the perspective of a given set of stakeholders and their concerns.

Some possible views (actually, viewpoints in the 1471 ontology) are:

• Functional/logic view
• Code/module view
• Development/structural view
• Concurrency/process/thread view
• Physical/deployment view
• User action/feedback view
• Data view

Several languages for describing software architectures have been devised, but no consensus has yet been reached on which symbol-set and view-system should be adopted. The UML was established as a standard "to model systems (and not just software)," and thus applies to views about software architecture. Others believe that effective development of software relies on understanding unique constraints of each problem, and so universal notations are doomed because each provides a notational bias that necessarily makes the notation useless or dangerous for some set of tasks^{[citation needed]}. They point to the proliferation of programming languages and a succession of failed attempts to impose a single 'universal language' on programmers, as proof that software thrives on diversity and not on standards.

[edit] Architecture frameworks

This section requires expansion.

• 4+1
• Department of Defense Architecture Framework (DODAF)
• UK Ministry of Defence Architectural Framework (MODAF)
• The Open Group Architecture Framework (TOGAF)
• Zachman Framework
• Federal Enterprise Architecture
• Reference Model of Open Distributed Processing (RM-ODP)
• Service-Oriented Modeling Framework (SOMF)

[edit] The distinction from detailed design

Software architecture, also described as strategic design, is an activity concerned with global design constraints, such as programming paradigms, architectural styles, component-based software engineering standards, design principles, and law-governed regularities. Detailed design, also described as tactical design, is an activity concerned with local design constraints, such as design patterns, architectural patterns, programming idioms, and refactorings. According to the Intension/Locality Hypothesis^[9], the distinction between strategic and tactical design is defined by the Locality Criterion^[9], according to which a statement about software design is non-local if and only if a program that satisfies it can be expanded into a program which does not. For example, the Client-Server style is architectural (strategic) because a program that is built by this principle can be expanded into a program which is not client server; for example, by adding peer-to-peer nodes. Or more simply, it is the distinction of the general from the specific.

Architecture is design but not all design is architectural. In practice, the architect is the one who draws the line between software architecture (architectural design) and detailed design (non-architectural design). There aren't rules or guidelines that fit all cases.

[edit] Examples of Architectural Styles / Patterns

There are many common ways of designing computer software modules and their communications, among them:

• Blackboard
• Client-server (2-tier, n-tier, peer-to-peer, Cloud Computing all use this model)
• Database-centric architecture (broad division can be made for programs which have database at its center and applications which don't have to rely on databases, E.g. desktop application programs, utility programs etc.)
• Distributed computing
• Event Driven Architecture
• Front-end and back-end
• Implicit invocation
• Monolithic application
• Peer-to-peer
• Pipes and filters
• Plugin
• Representational State Transfer
• Rule evaluation
• Search-oriented architecture (A pure SOA implements a service for every data access point)
• Service-oriented architecture
• Shared nothing architecture
• Software componentry (strictly module-based, usually object-oriented programming within modules, slightly less monolithic)
• Space based architecture
• Structured (module-based but usually monolithic within modules)
• Three-tier model (An architecture with Presentation Layer, Business Logic Layer and Database Layer)