Software Architecture Terminologies

Cool terms to put to use as an Engineering Team Lead or Architect

As much as you (like to) throw your weight around as a Team Lead or an Architect because you have many years of experience under your belt and especially as a (budding or present) software architect, be it at Enterprise or Solution level, there are a few terminologies we almost never use on a day-to-day basis and I will cover some of the cool ones (in my view) here; they are not only cool but we must use it often as they make sense and fit for purpose given the scenario. Here it goes…

Single Pane of glass

It is a contentious topic. Also referred to as single-pane view, single pane of glass is an Information Technology phrase used to describe a management tool — such as a unified console or dashboard — that integrates information from varied sources across multiple applications and environments into a single display. The contents f this view can fall into three areas:

Monitoring — automated discovery, flexibility to support new technologies

Obtain Actionable information — normalized data, analyzing historical data

Personalised views — easily configurable dashboards

Black/White box testing

Black-box testing is defined as a testing technique in which functionality of the Application Under Test (AUT) is tested without looking at the internal code structure, implementation details and knowledge of internal paths of the software. This type of testing is based entirely on software requirements and specifications. In BlackBox Testing we just focus on inputs and output of the software system without bothering about internal knowledge of the software program.

White-box testing is a testing technique which checks the internal functioning of the system. In this method, testing is based on coverage of code statements, branches, paths or conditions. White-Box testing is considered as low-level testing. It is also called glass box, transparent box, clear box or code base testing. The white-box Testing method assumes that the path of the logic in a unit or program is known.

In Black Box testing is done without the knowledge of the internal structure of program or application whereas in White Box, testing is done with knowledge of the internal structure of program.

Black Box test doesn’t require programming knowledge whereas the White Box test requires programming knowledge.

Black Box testing has the main goal to test the behavior of the software whereas White Box testing has the main goal to test the internal operation of the system.

Black Box testing is focused on external or end-user perspective whereas White Box testing is focused on code structure, conditions, paths and branches.

Black Box test provides low granularity reports whereas the White Box test provides high granularity reports.

Black Box testing is a not time-consuming process whereas White Box testing is a time-consuming process.

Idempotence

In computing, an idempotent operation is one that has no additional effect if it is called more than once with the same input parameters.

An operation is idempotent if it produces the same result when called over and over. An identical request should return an identical result when done twice, two thousand, or two million times. The source of most confusion around this concept comes with the idea of identical results, however. What we expect to see is identical results in the return form rather than in the return value.

A function looking up a customer’s name and address in a database is typically idempotent, since this will not cause the database to change. Similarly, changing a customer’s address to XYZ is typically idempotent, because the final address will be the same no matter how many times XYZ is submitted. However, placing an order for a cart for the customer is typically not idempotent, since running the call several times will lead to several orders being placed. Canceling an order is idempotent, because the order remains canceled no matter how many requests are made.

Swarming

Swarming is the act of all development team members working on only one requirement at a time during the sprint. Although not a principle specific to scrum, it is such an effective way for teams to execute their sprint backlog that it warrants some more discussion.

Again, one of the main benefits of scrum is that development teams start and finish requirements to satisfy their definition of done to produce a potentially shippable product increment within a relatively short timebox and to repeat that cycle with lessons learned again and again. The goal is to finish, not just start, as many requirements as possible.

It enables teams with the following benefits, but not limited to:

• Maximized chances for success with the skills and abilities of the entire team focused on a single requirement.
• Complete the entire cycle of plan, design, develop, and test to completion for each requirement.
• Dramatically decrease the introduction of defects into a product upfront through pairing and single‐tasking (versus multitasking).
• Eliminate single points of failure in knowledge, process, and skillsets.
• The most important requirements get done, done completely, and get done first.

Cross-cutting concerns

Wiki reference says: Cross-cutting concerns are parts of a program that rely on or must affect many other parts of the system. They form the basis for the development of aspects.

Cross-cutting concerns can be directly responsible for tangling, or system inter-dependencies, within a program. Because procedural and functional language constructs consist entirely of procedure calling, there is no semantic through which two goals (the capability to be implemented and the related cross-cutting concern) can be addressed simultaneously.[3] As a result, the code addressing the cross-cutting concern must be scattered, or duplicated, across the various related locations, resulting in a loss of modularity.[2]

There are a variety of different types of cross-cutting concerns that may be part of a software application. This is by no means an exhaustive list, but some common examples of cross-cutting concerns include the following:

• Caching
• Configuration management
• Auditing
• Security
• Exception management
• Logging

Non-Functional Requirement (NFRs)

A non-functional requirement is any requirement that cannot be derived by examination of a process (for example, use case modelling).

Non-functional requirements can include security, performance, usability, reliability, scalability, testability, maintainability, and constraints.

Non-functional requirements specify how and in what quality the functionalities in a system shall be implemented. Whenever you are architecting a system, you need to consider self-imposed NFRs in your architecture, by default.

Examples including Auditing (bread crumbs of historical requests to enable traceability), Reporting requirements, Legal Requirements etc.

Ready to jump in? Hope you enjoyed that!