We have senior Enterprise Architects and Software Architects who can provide any level of software architectural service ranging from total revamp to architecture renewal and modernization.
What is Software Architecture?
Software Architecture refers to the organizational structure of the system, which consists of software components. It is about how the different parts fit together to produce the desired effect (the goal of the system, which is: to solve the problem that the software is meant to solve); how they communicate (interact) with each other; what are the rules of interaction between the parts; and what are the constraints for assembling the parts into a unified whole.Let’s decompose this definition into simple concepts.
- Software Architecture is about organization and structure.
- Software consists of components (“parts” of the system).
- Software architecture is concerned with:
- How do these parts fit together?
- What are the externally visible characteristics of these parts? (These play an important role in “fitting” the parts together.)
- How do these parts communicate (interact) with each other?
- What are the rules of communication between the parts?
- What, if any, are the constraints that must be respected while doing the assembly (i.e., fitting the parts together)?
- The software architect has to ask questions like:
- Do we have all the necessary parts?
- Do they fit together?
- Does the proposed organization of the parts and sub-parts promote productivity, flexibility and extensibility?
- Are the parts loosely coupled so as to retain independence? (In other words, a part can be independently modified without much concern about breaking the system.)
- Is the communication between the parts efficient enough?
- Does the final proposal (the architecture) achieve the system goal (which is equivalent to the Functional Specifications of the system)?
- Is this a cost effective solution?
- Is it flexible enough to stand the test of time?
History of Software Architecture
The origin of software architecture as a concept was first identified in the research work of Edsger Dijkstra in 1968 and David Parnas in the early 1970s. These scientists emphasized that the structure of a software system matters and getting the structure right is critical. The study of the field increased in popularity since the early 1990s with research work concentrating on architectural styles (patterns), architecture description languages, architecture documentation, and formal methods.Research institutions have played a prominent role in furthering software architecture as a discipline.
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. The University of California, Irvine's Institute for Software Research's efforts in software architecture research is directed primarily in architectural styles, architecture description languages, and dynamic architectures.The IEEE 1471: 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 adopted in 2007 by ISO as ISO/IEC 42010:2007.
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.
Views
Software architecture is commonly organized in views[7], 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.
Architecture frameworks
Frameworks related to the domain of software architecture are:
- 4+1
- RM-ODP (Reference Model of Open Distributed Processing)
- Service-Oriented Modeling Framework (SOMF)
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, Business Logic and Database tiers)
|
