Saturday, April 23, 2011

Software Development: Levels of Languages

Languages of software development operate at several levels: facilitating expectations from a software system to be shared between stakeholders (specification languages), capturing analysis and design artifacts through a common set of idioms and notation (modeling languages), and implementing the system in executable code (programming languages). Each of these levels represents a particular layer of abstraction.

As with natural languages, languages of software development also offer many layers of details. Out of them, only those relevant to the problem at hand need to be considered in a given situation. Some of the factors that lead to the popularity of a programming language are: power of expression, ease of learning by beginners, ease of running on a wide range of architectures, tool support etc. The choice of a particular programming language for developing a system depends on the kind of system it is. Each programming language has a definite focus area; for example C is well suited to systems programming. How high-level a programming language is depends on the degree to which it hides the underlying complexity of the physical machine that executes the instructions given in the language by the human programmer.

A model is based on some assumptions; it highlights some aspects of interest in a system, while hiding others. Challenges to modeling software arise to large extent from its inherent ‘invisibility’ and ‘unvisualizability’. Unified Modeling Language (UML) is a language for visualizing, specifying, constructing, and documenting the artifacts of a software system. UML consists of three kinds of building blocks: things, relationships, and diagrams. UML diagrams are classified as structural and behavioral—the former captures the static aspects of a system while the latter captures the dynamic aspects. Although very popular, UML is not universally accepted in the software engineering community: A common criticism is that it is a product of “design by committee”.

Specification languages such as Z (invented by Jean-Raymond Abrial and named after the mathematician Ernst Friedrich Ferdinand Zermelo) broadly relate to the formal methods of software development, using mathematical concepts and constructs to describe the behavior of a software system; use of formal methods leads to an increase in time and cost earlier in the development life cycle, vis-à-vis the use of traditional, non-formal methods. This is one of the reasons why formal methods are not used widely for commercial software development, where time to market is often given higher importance than quality.The quest for exactitude and completeness is paramount in a specification using a language such as Z. Specification languages and formal methods, when used in combination with traditional approaches can facilitate the construction of quality software.

Software Architecture: In Spirit and Letter

“You employ stone, wood and concrete, and with these materials you build houses and palaces. That is Construction. Ingenuity is at work. But suddenly you touch my heart, you do me good, I am happy and I say ‘This is beautiful.’ That is Architecture.” – Le Corbusier (1923), quoted in Architecture: From Prehistory to Post-Modernism.

The above quotation captures the spirit of architecture. We recognize good architecture when we see it, but it is difficult to define what good architecture is. Seeing the Taj Mahal, one of the greatest architectural wonders of the world, one is struck by its beauty, symmetry, poise, and proportion. But one is also aware, there is something nameless beyond these obvious attributes that endows the Taj with its architectural majesty. This sense is imparted to us by the underlying architecture. Whenever we deal with complex structures, we need to explore architectural ideas to simplify the task as well as make the end-product beautiful and resilient.

If architecture is difficult to define, software architecture is more so. One of the first organized attempts at studying software architecture can be traced back to the 1995 November/December issue of the IEEE Software magazine (Volume 12, Issue 6). Many of the articles published in that issue introduced foundational notions of software architecture, such as Kruchten’s 4+1 view model.

Rumbaugh et al. capture the essence of software architecture as ``The organizational structure of a system, including its decomposition into parts, their connectivity, interaction mechanisms, and the guiding principles that inform the design of a system.” Key themes of software architecture revolve around taking some fundamental decisions about the structure of subsystems, components, and their interactions that together make up the entire system, and relates to reusing some of the wisdom that other people have gathered in working with similar systems.

Architectural patterns facilitate such reuse. As Alexander defines them, “Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution.” Relation is a key term in the above definition—patterns connect problems, solutions, and contexts through relationships. The model-view-controller (MVC) pattern is among the most widely used architectural patterns in Web development, where we have a presentation layer, often called the graphical user interface (GUI), a middle layer to handle business logic for fetching and manipulating data, and a back-end database for storing data.

Software architecture as a discipline can also be seen from different angles: as a strategy for organizing a system’s constituents, as a high-level abstraction of a system’s design, as a vehicle for communicating fundamental ideas about a system’s development. Software architecture is not software design, although there is no clear line where the former ends and the latter starts. Design relates to choices about how specific functionality is to be delivered, architecture is more about decisions regarding the system’s structure. In future, with software systems becoming larger and more complex, software architecture ideas will need to address deeper issues around delivering more sound and durable solutions to user needs.