Software Arhitecture

  • Software elements (modules);

  • Relations among them (connections and communication protocols);

  • Properties of both elements and relations (quality attributes);

  • Constraints.

Definition

Software Architecture is the fundamental organization of a system or the way the highest level components are wired together. High-level design of a software system, showing which desired system properties are achieved, and the reasons for their achievement.

Software architecture:

  • what, where and why but not the how

  • High-level views showing how the system meets the requirements, documents the main software components and how they interact with each other

  • Is very abstract, deliberately hiding any details

Usually, the later changes in the software system need to be made the more expensive it gets to do. The main goal of software architecture is reducing the cost of changes to our app (maintainability, supportability, etc.). So with good architecture, the changes should have almost the same costs at the beginning and at the end of the project.

Software design is the how of a software development process.

Software elements

A component is an architectural entity that:

  • encapsulates a subset of the system’s functionality and/or data

  • restricts access to that subset via an explicitly defined interface

  • has explicitly defined dependencies on its required execution context

Components typically provide application-specific services.They are units of decomposition of a system and can be a software package, Web service or module.

Components provide Interfaces (Specify and document the externally visible features (or public API) offered by the component):

  • Data types and model

  • Operations

  • Properties

  • Events and call-backs

Components require Interfaces (Specify the conditions upon which a component can be (re)used):

  • The platform is compatible

  • The environment is set up correctly

Connectors

Architectural building block that models:

  • Interactions among components

  • Rules that govern those interactions

It provides interaction duct(s) and transfer of control/data

Many interaction types:

  • In many software systems they are simple interactions e.g. procedure calls or shared data accesses

  • Much more complex and semantically rich interactions are possible! e.g. client-server protocols, database access protocols, asynchronous event multicast

They typically provide application-independent interaction facilities, not always directly visible in the code

Constrains

Constraints, as the dictionary definition above indicates, are a limiting factor and severely restrict options for making design decisions

In software architecture design, constraints come in two basic flavors - technical and business. On most projects there are only a handful of constraints, but these constraints are a highly influential architectural driver. Constraints are also fixed design decisions that cannot be changed and must be satisfied. You could think of constraints as the ultimate non-negotiable, "must have" requirement. It is for this reason that architecture design constraints must be created and accepted with care.

Technical Constraints in Software Architecture

Technical constraints are fixed technical design decisions that absolutely cannot be changed. Most often technical constraints are provided by stakeholders (perhaps after some digging) at the outset of the project. Regardless of the origin, these architecture drivers are technical in nature and are considered unchangeable and indeed very soon become so. Examples of technical constraints:

  • Programming language - oftentimes a specific programming language will be required for various reasons. For example, the customer may be a Java or Ruby or Microsoft shop. You might simply prefer a certain language over another, or have specific expertise that dictates using a particular programming language. Nearly always, once you've picked a language you are stuck with that choice for the remainder of the project,

  • Operating system or platforms supported - It must work on Windows, or Linux, or iOS, or Qt on Solaris, or IE 6 on Windows XP, or ... building software that does not satisfy the platform constraint means you have failed to design a software system that satisfies stakeholders' key concerns.

  • Use of a specific library or framework - Sometimes a specific library might be required to be used. The specific origin might come from the business but the influence is very technical. A common example at many companies is the use of specific open source libraries. Some companies might require that open source always be used. Other companies, might have an approved list indicating which open source software may be used.

Business Constraints

Business constraints are unchangeable business decisions that in some way restrict the software architecture design. Business constraints are similar to technical constraints in that they are decisions that cannot be changed, but rather than influencing structures directly through technology, the influence occurs indirectly through business decisions. Examples:

  • Schedule - "We have to be ready to demo at the trade-show in November." The final delivery date is fixed based on input from the business and cannot be changed. It is now up to you to design a system that can be built within the required schedule.

  • Budget - I've found that this is less true for product development, but nearly every development contractor must learn to deal with budget constraints. In some cases you might be able to increase the budget, but often budgets, whether fixed through contract or expectations, become constraints on the project and team building the software.

  • Team composition and make-up - In some cases there may be requirements that specific personnel be used or not used during project. For example, someone may be unavailable, already committed to another project or you may be required to include specific individuals, perhaps for training purposes.

  • Software licensing restrictions or requirements - Often times you will be required to use specific software components because they are already owned. I've also seen situations where components have been used in very... interesting... ways to satisfy specific licensing restrictions. Legal considerations are extremely constraining.

  • Legal requirements - GDPR for EU countries.

Last updated

Was this helpful?