Software architecture

Encyclopedia : S : SO : SOF : Software architecture

Software Development Process

Activities and Steps
Requirements \| Architecture \| Implementation \| Testing \| Deployment
Models
Agile \| Cleanroom \| Iterative \| RAD \| RUP \| Spiral \| Waterfall \| XP
Supporting Disciplines
Configuration Management \| Documentation \| Project Management

A software architecture or software systems architecture is a representation of a software system, as well as the process and discipline for effectively implementing the design(s) for such a system. It is a representation because it is used to convey the information content of the related elements comprising a system, the relationships among those elements, and the governing those relationships. It is a process because a sequence of steps is prescribed to produce or change the architecture, and/or a design from that architecture, of a system within a set of constraints. It is a discipline because a body of knowledge or a general set of principles of (software) architecture is used to inform practitioners as to the most effective way to design the system within a set of constraints.

A software system is generally part of a larger system encompassing information and general and/or special purpose computer hardware. A software architecture is primarily concerned with the external interfaces among the system's software entities, and between the system and its external environment.

Contents

1 Background
2 History
3 ADL
4 Views
5 Architecture examples
6 Related concepts
7 Tools
8 See also
9 References
10 External links

Background

Prior to the advent of digital computers, the electronics and other engineering disciplines used the term system as it is still commonly used today. However, with the arrival of digital computers on the scene and the development of software engineering as a separate discipline, it was often necessary to distinguish between engineered hardware artifacts, software artifacts, and the combined artifacts. A programmable hardware artifact, or machine, that lacks its software program is impotent; even as a software artifact, or program, is equally impotent unless it can be used to alter the sequential states of a suitable (hardware) machine. However, a hardware machine and its software program can be designed to perform an almost illimitable number of abstract and physical tasks. Within the computer and software engineering disciplines (and, often, other engineering disciplines, such as communications), then, the term system came to be defined as containing all of the elements necessary (which generally includes both hardware and software) to perform a useful function.

The hardware engineer or architect deals (more or less) exclusively with the hardware device; the software engineer or architect deals (more or less) exclusively with the software program; and the systems engineer is responsible for seeing that the software program is capable of properly running within the hardware device, and that the system composed of the two entities is capable of properly interacting with its external environment and performing its intended function.

A software architecture, then, is an abstract representation of the software part of a system, capable of running on a special or general purpose computer. A good architecture may be viewed as a partitioning scheme, or algorithm, which partitions all of the system's present and foreseeable software requirements into a workable set of cleanly bounded subsystems with nothing left over. That is, it is a partitioning scheme which is exclusive, inclusive, and exhaustive. A major purpose of the partitioning is to arrange the elements in the software subsystems so that there is a minimum of communications needed among them. In both software and hardware, a good subsystem tends to be seen to be a meaningful "object." Moreover, a good architecture provides for an easy mapping to the user's requirements and the user's validation/acceptance tests of the user's (software) requirements. If everyone keeps to the religion, a mapping also exists from every least element to every requirement and test.

A robust software architecture is said to be one that exhibits an optimal degree of fault-tolerance, backward compatibility, forward compatibility, extensibility, reliability, maintainability, availability, serviceability, usability, and such other ilities as necessary and/or desirable..

To bring a software architecture user's perspective into the software architecture, it can be said that software architecture gives the direction to take steps and do the tasks involved in each such user's speciality area and interest e.g. the stake holders of software systems, the software developer, the software system operational support group, the software maintenance specialists,the deployer,the tester and also the business end user. In this sense software architecture is really the amalgamation of the multiple perspectives a system always embodies. The fact that those several different perspectives can be put together into a software architecture stands as the vindication of the need and justification of creation of software architecture before the software development in a project attains maturity.

History

Software architecture as a concept was touched upon already in the 1960s by (for example) Edsger Dijkstra, but has increased in popularity since the early 1990s due to the greatly increased activity with very large software systems, e.g., the Boeing 777 aircraft uses in excess of 10 million lines of code just for the basic aircraft. That could represent anywhere from about 5,000 person-years to 50,000 person-years of effort, depending on how thoroughly the coding was controlled and tested.

ANSI/IEEE 1471-2000: Recommended Practice for Architecture Description of Software-Intensive Systems is the first formal standard in the area of software architecture, and was recently adopted by ISO as ISO/IEC DIS 25961.

Carnegie Mellon University and University of California, Irvine (UCI) are doing a lot of research on Software architecture. Mary Shaw and David Garlan of Carnegie Mellon wrote a book titled Software Architecture: Perspectives on an Emerging Discipline in 1996, which brought forward the concepts in Software Architecture, such as components, connectors, styles and so on. UCI's Institute for Software Research's efforts in software architecture research is directed primarily in architectural styles, architecture description languages, and dynamic architectures.

ADL

Architecture Description Languages are used to describe Software Architecture. Now, there are several ADLs, such as 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.

Views

Software architecture is commonly organized in views, which are analogous to the different types of blueprints made in common architecture. Within the ontology establised 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 view
Development/structural view
Concurrency/process/thread view
Physical/deployment view
User action/feedback 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. Some believe that UML will establish a standard for software architecture views. 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. 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.

Architecture examples

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

Client-server
Distributed computing
Peer-to-peer
Blackboard
Implicit invocation
Pipes and filters
Plugin
Monolithic system
Three-tier model
Structured (module-based but usually monolithic within modules)
Software componentry (strictly module-based, usually object-oriented programming within modules, slightly less monolithic)
Service-oriented architecture

Related concepts

There are also a number of concepts which have been used in software architecture including

Tools

It’s important for the IT-sector to have good tools available in order to control different kinds of software architectures. Because the development of new software architecture tools is a relatively new subject nowadays, it's important to look at some functions and requirements of such a tool. These important requirements and functionalities are listed below:

Support Quality System Design
*Evaluate an architecture’s effectiveness, quality and completeness
*Map and verify requirements to arch. Description
*Cycle through all impacted data and products after an architectural modification
*Indicate impact on associated arch. components
*Relate Data Dictionary and component definitions to a defined architecture
*Relate description of inputs, outputs and process to each arch. element
*Allow the user to define/use their own heuristics and rules
*Provide user input definition completeness checking at all levels (e.g. interfaces)
*Checks for input(s), output(s) and process(s) descriptions for each arch. element
*Allow the user to tag architecture elements with requirements
*Assist in developing the operational concept ("Ballpark" or "Blue Sky" perspective)
*Relate operational concept to arch. element
*Allow cost estimation through a spreadsheet feature
*Map cost to arch. elements and maintain in row/column format
*Support architecture evolution with easy editing features
Support Multiple System Views
*Produce architecture views from functional and object oriented (OO) perspectives (examples: WBS, functional, physical, data flow, state diagrams)
*Produce a view of interface connectivity
*Support various physical architectures (view from a number of levels, Black box, Rack, circuit board, chip)
*Support various types (i.e. technology applications) of architectures: Mechanical, electrical, chemical, Information etc.
*Relate views to each other (changes should automatically cycle through all views)
Methodology Independent
*Is your product of general structure allowing definition of tool functions, conventions, and methods
*Enable tailoring to specific standards and requirements, IEEE, ISO, MIL-STD
*Impose a specific design methodology (e.g., only functional, only OO)
*Accommodate other approaches (i.e. Functional, OO, Quality Functional Deployment etc.)
*Allow technology insertion and application customization (API)
*Allow customization of diagrams, icons, heuristics, functions, etc.
User Interface
*User friendly & menu driven (drag and drop capabilities)
*Begin jobs using templates, fill-in lists, etc. to guide the user
*Provide prompts for functional attributes, interface characteristics, objects, etc.
*Provide a standard icon library for architecture development (Vendor supplied)
*Allow drag and drop control of icons within the architecture
*Does your product allow the user to customize icons with definitions for specific architectures
Communication with Other Tools
*Allow import/exchange of data from others formats and tools
*Create files in formats readable by other tools
*Interface to requirements traceability software
*Interface with word processing, spreadsheet and illustration software
*Interface with CAD and software design and coding tools
Documentation Production
*Store standard document outlines - used as starting points. User definable templates or modifiable
*Support production of Operational Concept Document
*Support production of Functional Description Document
*Support production of a Data Dictionary
*Support production of Requirements Allocation Document
*Produce context diagrams, Functional Flow Block Diagrams, Hierarchy charts, Connectivity diagrams, and Physical layouts
*Produce printouts
Computer Environment
*Support a single user or multiple concurrent users
*Which platforms and operating systems does the tool run on
*Does the tool use a proprietary or commercially available database
Resource Requirements
*Please identify hardware/software configuration requirements
*Memory requirements
*CPU requirements
*Disk space requirements

Here are some examples of Software architecture tools:

A4
ACME
Lattix LDM

References

Len Bass, Paul Clements, Rick Kazman: Software Architecture in Practice. Addison Wesley, Reading 1998 ISBN 0-201-19930-0 (gives a good overview of architectural concepts)
Philippe Kruchten: Architectural Blueprints - the 4+1 View Model of Software Architecture. In: IEEE Software. 12 (6) November 1995, pp. 42-50 (also available online at the [Rational website](PDF))

External links

From Wikipedia, the Free Encyclopedia. Original article here. Support Wikipedia by contributing or donating.
All text is available under the terms of the GNU Free Documentation License See Wikipedia Copyrights for details.