Software architecture |
Software architecture is a coherent set of abstract patterns guiding the design of each aspect of a larger software system.
Software architecture underlies the practice of building computer software. In the same way as a building architect sets the principles and goals of a building project as the basis for the draftsman s plans, so too, a systems architect or systems architect sets out the software architecture as a basis for actual system design specifications, as per the requirements of the client.
Software architecture is like an Architecture of a building in that it has to do with the purpose, themes, materials, and concept of a structure. A software architect employs extensive knowledge of software theory and appropriate experience to conduct and manage the high-level design of a software product. The software architect develops concepts and plans for software modularity, module interaction methods, user interface dialog style, interface methods with external systems, innovative design features, and high-level business object operations, logic, and flow.
A software architect consults with clients on conceptual issues, managers on broad design issues, software engineers on innovative structural features, and computer programmers on implementation techniques, appearance, and style.
Software architecture is a sketchy map of the system. Software architecture describes the coarse grain components (usually describes the computation) of the system. The connectors between these components describe the communication, which are explicit and pictured in a relatively detailed way. In the implementation phase, the coarse components are refined into actual components , e.g, classes and objects. In the object-oriented field, the connectors are usually implemented as interfaces.
=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, largely due to activity within Rational Software and within Microsoft.
, 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 CMU), Acme (developed by CMU), xADL (developed by UCI), Darwin (developed by Imperial College London). Common elements of an ADL are component, connector and configuration.
=Views=
Software architecture is commonly organised in views, which are analogous to the different types of blueprints made in common Architecture. Some possible views 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 Unified Modeling Language 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:
=Related concepts=
There are also a number of concepts which have been used in software architecture including
ontology (computer science) is often considered as a superset of software architecture, i.e. one ontologist co-ordinates several architects , integrators , data modellers , and the software usability, technical documentation and software training. There may even be some control over marketing and sales presentations if the purpose of these is to determine who the products users are, or to find out their vocabulary or values, to help the product reflect these.
The foundation ontology presently being standardized is intended to simplify and constrain the work of ontologists to a degree, and will to that degree simplify many decisions in software architecture.
=Tools=
Its 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 relativaly 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 architectures 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 a couple of examples of Software architecture tools: *A4 *CAME
=See also=
*Software engineering *Usability engineering *Technical architecture *Systems architect
=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 [http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/Pbk4p1.pdf Rational website](PDF)) *Jim Coplien: Multi-Paradigm Design in C++ . Addison Wesley, Reading 1998 ISBN 0-201-82467-1 (outlines all reasonable design approaches possible in C++, which is a particularly rich language but difficult for beginners)
=External links=
|
|