Architectural Elements

 Architectural Elements 

As explained previously, we standardize the term architectural element to refer to the pieces from which systems are built.

The nature of an architectural element depends very much on the type of system you are considering and the context within which you are considering its elements. Programming libraries, subsystems, deployable software units (e.g., Enterprise Java Beans or .NET assemblies), reusable software products (e.g., database management systems), or entire applications may form architectural elements in an information system, depending on the system being built. 

An architectural element should possess the following key attributes

• A clearly defined set of responsibilities 

• A clearly defined boundary '

• A set of clearly defined interfaces, which define the services that the element provides to the other architectural elements Architectural elements are often known informally as components or modules, but these terms are already widely used with established specific meaning. In particular, the term component tends to suggest the use of a programming-level component model (such as J2EE or .NET), while module tends to suggest a programming language construct. Although these are valid architectural elements in some contexts, they won’t be the type of fundamental system element used in others.


Comments

Post a Comment

Popular posts from this blog

Architectural Perspectives

 Architectural Perspectives we explained how we use viewpoints (such as the Context, Functional, Information, and Deployment viewpoints) to guide the process of capturing and representing the architecture as a set of views, with the development of each view being guided by the use of a specific viewpoint. When creating a view, your focus is on the issues, concerns, and solutions pertinent to that view. So, for an Information view, for example, you focus on things such as information structure, ownership, transactional integrity, data quality, and timeliness. Many of the important concerns that are pertinent to one view are much less important when considering the others. Data ownership, for example, is not key to formulating the Concurrency view, nor is the development environment a major concern when considering the Functional view. (Of course, the decisions taken in one view can have a considerable impact on the others, and it is a big part of the architect’s job to make sure tha...
Read more

Architecture Review

  Introduction Reviews are an opportunity for others to eyeball your documents/design/code/software architecture and for you to inspect others' work. They facilitate knowledge interchange. But their primary goal is to increase software quality. They help you to spot faults before they become real disasters. This text tries to bring together elements a reviewer can use in his/her software architecture review. Background If you want some formal definitions what a software architecture is, I recommend reading the information  here . The general tone in these definitions is that you need to make high-level decisions about the system you're going to build: Ø   What style are you going to use? What is the structure? Ø   How is it going to function? How do structural components of the architecture work together? Ø   How does it meet the needs of all the stakeholders? For an existing system, you can detect these key factors that will give you an idea of ...
Read more