Architectural Descriptions

 Architectural Descriptions 

An architecture for a software system can be an incredibly complex thing. Part of the architect’s role is to describe this complexity to the people who need to understand it. The architect does this by means of an architectural description.

Products” in this context consist of a range of things—particularly architectural models, but also scope definition, constraints, and principles. We discuss each of these in more detail in Parts II and III. A description of an architecture has to present its essence and its detail at the same time—in other words, it must provide an overall picture that summarizes the whole system, but it also must decompose into enough detail that it can be validated and the described system can be built. Although it is true that every system has an architecture, it is unfortunately not true that every system has an AD. Even if an architecture is documented, it may be documented only in part, or the documentation may be out-of-date or unused. Strictly speaking, therefore, our definition describes a good AD. However, an AD that its stakeholders cannot understand or that doesn’t demonstrate to them that their concerns have been met is really not worth having—in fact, it can be more of a liability than an asset. The AD needs to contain all of (and ideally only) the information needed to communicate the architecture effectively to those stakeholders who need to understand it.

Of course, the chances of your architectural ideas being implemented as you envisaged them are far less if the AD is inadequate.

The architect writes the AD and is also one of its major users. You use the AD as a memory aid, a basis for analysis, a record of decisions, and so on. However, you are only one of the users of the AD. To a lesser or greater extent, all of the other stakeholders need to understand the architecture (or at least parts of it) as it relates to them. If the AD does not help with this, it has failed.

Nowadays there is a plethora of techniques, models, architecture description languages, and other ways to document architectures. Choosing the right ones for a particular system development is a significant challenge in its own right; you need to take into account the characteristics of the system and the skills and capabilities of its stakeholders. Part II explores the concept of ADs in more detail, and Parts III and IV explain the different elements of an AD and how to create them.

Relationships between the Core Concepts 

The important relationships between our core concepts are illustrated in the UMLclass diagram . The diagram brings out the following relationships among the concepts we have discussed so far. • A system is built to address the needs, concerns, goals, and objectives of its stakeholders. • The architecture of a system comprises a number of architectural elements and their interelement relationships. • The architecture of a system can potentially be documented by an AD (fully, partly, or not at all).In fact, there are many potential ADs for a given architecture, some good, some bad. • An AD documents an architecture for its stakeholders and demonstrates to them that it has met their needs. 

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

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 ...
Read more