The Rise and Fall of Product Line Architectures

During the 14 International Software Product Line Conference (SPLC), I was co-organizing a panel with Isabel John and Christa Schwanninger about the The Rise and Fall of Product Line Architectures.

The panel had the goldfish bowl format and had as panelists the main experts in the field: Paul Clements, Charles W. Krueger, John McGregor, Dirk Muthig, and David Weiss.

The panel discussed issues as: How do you think a good product line architecture should look like? How much up-front design do we need for a product line architecture? What are hot research topics in product line architecture?

The mind-map summarizing the panel can be seen here. [thanks to Klaus Schmid].

Software Architecture Recovery as a Tool to Introduce Reuse in Companies

According to Ducasse and Pollet, software architecture reconstruction is a reverse engineering approach that aims at reconstructing viable architectural views of a software application [1]. The process of software architecture recovery (SAR) may be utilized in many ways, namely redocumentatation, understanding of already existing systems, evolution, conformance between the conceptual and concrete architectures, and some other applications.

In general, the SAR approaches can be classified as Bottom-Up, Top-Down and Hybrid. In the Bottom-Up approach, starts with the low level knowledge, such as source-code, and progressively tries to reach the higher level understanding using reverse engineering. The Top-Down approach is the opposite, as it begins with high-level concepts, such as architectural views and requirements, and tries to build the architecture through hypotheses that are confirmed by the source-code. The Hybrid approach merges the last two approaches, abstracting the low-level knowledge and refining the high-level knowledge ratifying correspondences between both the conceptual and concrete architectures.

In the SAR approaches we can have inputs of architectural nature, like viewpoints and styles, and non-architectural inputs, like souce-code, human knowledge, etc. As output we can have, for example, visual software views, the architectural conformance and the architecture analysis.

Some approaches that aim at the investigation of reuse and software product line (SPL) migration have been identified: ARES[2], ARMIN[3][4], MAP[5] and PULSE[6]. As a goal for these approaches we can highlight the identification of commonalities, variabilities, components that can be extracted of pre-existing systems that, for example, might be turned into services.

Now, our studies focus on identifying if SAR can be used as a tool to support the introduction of reuse in organizations. Our main challenges are:
– What approaches are more complete/ to introduce Reuse?
– What approach can we use?
– Are the companies producing these artifacts?
– Can these processes be agile?
– How much of this processes can be automated?
– How to systematize this approach?

[1] D. Stéphane, P. Damien, "Software Architecture Reconstruction: A Process-Oriented Taxonomy", IEEE Transactions on Software Engineering., Vol 35, No. 4, 2009.

[2] W. Eixelsberger, M. Ogris, H. Gall, and B. Bellay, “Software Architecture Recovery of a Program Family,” Proc. Int’l Conf. Software Eng., pp. 508-511, 1998.

[3] R. Kazman, L. O’Brien, and C. Verhoef, “Architecture Reconstruction Guidelines,” technical report, third ed., Carnegie Mellon Univ., SEI, 2003.

[4] L. O’Brien, D. Smith, and G. Lewis, “Supporting Migration to Services Using Software Architecture Reconstruction,” Proc. Int’l Workshop Software Technology and Eng. Practice, pp. 81-91.

[5] C. Stoermer and L. O’Brien, “Map—Mining Architectures for Product Line Evaluations,” Proc. Working IEEE/IFIP Conf. Software Architecture, pp. 35-41, 2001.

[6] J. Knodel, D. Muthig, M. Naab, and M. Lindvall, “Static Evaluation of Software Architectures,” Proc. Conf. Software Maintenance and Reeng., pp. 279-294, 2006.

Revisiting Parnas: On the Design and Development of Program Families

The paper presents a comparison between techniques to develop program families. “Stepwise refinement”, introduced by Dijkstra, tries to develop programs through the use of informal, intermediate representations of programs that are then refined. The refinement introduces the design decisions by implementing the informal program in actual languages.

The technique introduced by Parnas is called “Module Specification”.  In this technique, the intermediate stages are specifications of behavior that is “encapsulated” into modules. He asserts that this approach leads to decrease the final cost of producing the software as the modularization helps to deal with complexity. Also, the use of modules and specifications helps to postpone design decisions, particularly those that will differentiate family members.

Sometimes, Parnas focus seems to be only to broaden the family possibility, in other words, increase the amount of variation points. This occurs specially at the beginning of the process. His strategy aims in making the design to enable the postponement of the decisions. In some sense, he puts the focus of a software family as it was to have as many members as possible.

Although the use of information hiding to postpone design decisions points is an excellent way to create variation points, leading to the Strategy design pattern, I think it should be used with care because it could lead to overgeneralization of the modules. Modules that are unlikely to change or vary may have to carry the complexity needed to implement the improbable variation. Maybe, this occurs only at early stages in the process.

The most interesting point is that the author starts thinking about planning before developing a program family. He also gives importance to the order in which the design decisions are made. This suggests that an approach for software families should choose the degree of importance of each aspect and characteristic so that the resulting program addresses its purposes properly.

Revisiting Parnas: The influence of software structure on reliability

Here, Parnas steps aside from software correctness and formal proof of programs and discusses another problem: Is a program that outputs correct useful if we cannot rely on it when we demand?

He introduces the term Reliability “a measure of the extent to which the system can be expected to deliver usable services when those services are demanded”. In other words, a system is considered to be highly reliable, if it is highly probable that, when we demand a service from the system, it will perform to our satisfaction.

Software structure may harm reliability when build upon the wrong assumption that nothing can go wrong. Parnas consider some situations that can influence reliability, among them the influence of external dependencies and the correctness of the software itself.

The author explains that the error detection and handling mechanism is often neglected or poorly done. It is important that the interface between modules enable communication about errors as well. The means to express this possibility of errors between interrelated modules seems to be well solved, e.g., by Exceptions and try-catch blocks in modern languages such as Java. Still, the way to use them correctly is easily overlooked.

Nowadays, software architecture studies contemplate a whole bunch of other attributes of software architectures. Yet, the influence of software structure on reliability is still a hot topic in software architecture. And although some of the early questions can be answered, new ones arrive.

Revisiting Parnas: Use of the concept of transparency in the design of hierarchically structured systems

In year 1975, Parnas publishes with D.P. Siewiorek “Use of the Concept of Transparency in the Design of Hierarchically Structured Systems”.  The publication talks about the difficulties in using an Outside In (aka Top down) approach to design and develop software. The main point discussed in the piece is the cost of using abstraction in software constructions.

For the authors, the use of abstractions is an excellent way to make big systems understandable as a whole, as higher level abstractions hide the inner workings of a piece of software. The approach that starts from the outside in can have some difficulties, however. (1) The difficulty to obtain a good specification of the “outside” and (2) even harder to express it without implying internal design decisions, (3) the derivation from such a specification is frequently not feasible, (4) inner details of the implementation can already be fixed, such as hardware or an operating system.

The term Transparency is then discussed. Considering a two level system, say a lower, hardware level and a higher, control software level. Transparency is the measure of how much of a lower level capability is available at a higher level. Complete transparency means that if it is feasible in a lower level tier, it should be feasible in an upper level tier. When a design decision restricts the possibilities of a lower level tier when used through an upper level tier, there is a loss of transparency. For instance, if our Data Access Object layer only permits data selection from the database, there is clearly a loss of transparency as the ability to insert and delete data was suppressed.

Complete transparency is not always a good thing. There is a trade-off between transparency and flexibility of a design. The increase of transparency between two levels can lead to great implementation difficulties and inefficiencies. The designer should be aware and ponder. As stated: “Loss of transparency is often one of the goals of a design”.

Concluding on the difficulties with the outside in approach, the authors affirm that usually the design comprises many inter-related objects. Moreover, there is limited experience with man-man symbiosis, so it is often impossible to specify the outside before construction and not want to change it afterwards.

I would say that we still have limited experience with human-human symbiosis, what one could name as managerial issues in software development. Also, there usually is a lack of engineering expertise, where software designers and developers forget about key principles stated decades ago.

Revisiting Parnas: On the Criteria to be Used in Decomposing Systems into Modules

In the paper called "On the Criteria to be Used in Decomposing Systems into Modules", from 1972*, David L. Parnas discusses modularization as a mechanism for improving flexibility and comprehensibility of a system. David Parnas also emphasizes the shortening of development time because each module can be developed by separate groups. The main point of the paper is the introduction of some criteria that can be used to decompose systems into modules.

A comparison of two different ways to decompose a system is presented. The former decomposition is based on a flowchart, which makes each major part of a process as a module. This kind of decomposition can bring some problems such as:

• Changeability: changes to a specific module require modification of other modules;
• Understandability and Independent Development: modules cannot be understandable or even developed separately.

The second decomposition presented is based on the principles of information hiding, and normally solves the problems listed above. In this case, the modules no longer correspond to steps in the process; each module is characterized by its knowledge of a design decision which it hides from the others. It is also emphasized that the modules’ interfaces must reveal as little as possible about its inner workings.

The design by contract is also commented in the paper, Parnas mentioned that the inputs and outputs of each module must be well defined before implementation starts, what is obvious currently.

In a subsequent post, the remarkable “Uses of the Concept of Transparency in the Design of Hierarchically Structured Systems” shall be discussed.

Revisiting Parnas: A Technique for Software Module Specification with Examples

During this month, in a series of posts we shall revisit the works from David L. Parnas. The exploration will concentrate itself in particular on the publication concerning software architecture and design, from 1970 to 2000. 

In the paper called “A Technique for Software Module Specification with Examples”, from 1972*, Parnas introduces a way to specify software pieces. His ideas could be considered the early stages of Bertrand Meyer’s, Design By Contract. The technique is based on formal description of initial possible values and its types, parameters and effects. 

The effects session also describes errors states in which an error handling routine will be called, even though the error handling routine itself is not described by the specification. This is very well argued by Parnas and totally coherent for me: errors can be handled differently in many levels and should be a concern for the user of the function.

The main point of the article, is not the notation itself, but the set of principles upon which it was build. Those principles state for (1) the need of a concise specification for the function’s user and for the implementer. (2) It promotes Information Hiding by stating that no information about the structure calling program should be conveyed. The principles are also in favor of (3) a more formal specification that can possibly be machine tested. Finally, (4) it encourages the use of a Domain Language for the specification. 

The set of four principles define succinctly the main characteristic any software specification technique should have. I see the use of formal methods as a weak point, when it comes to certain contexts of development, such as large information systems, where the formal specification could be worthy only in small chunks of the system.  On the other hand, I think the machine testability should gain more focus nowadays, as AOP and unit testing techniques and frameworks are so widespread.

In a subsequent post, the remarkable “On the criteria to be used in decomposing systems into modules” shall be discussed. ‘Till then.

*There is an earlier paper, from 1971, entitled “Information Distribution aspects of design Methodology”, but it wasn’t possible to retrieve it from the available internet academic databases.

Architecture vs. Design

This post discusses a philosophic question: Are there differences between architecture and design activities? Before answering this question, I would like to tell some assertions found in literature. Eden and Kazman discuss differences among Architecture, Design and Implementation fields. According to them: "Architecture is concerned with the selection of architectural elements, their interaction, and the constraints on those elements and their interactions... Design is concerned with the modularization and detailed interfaces of the design elements, their algorithms and procedures, and the data types needed to support the architecture and to satisfy the requirements". Following this idea, Bass et al. defines software architecture as "the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them". The SEI (Software Engineering Institute) considers two distinct activities in the life-cycle development: Architecture design and Detailed design.

We can found several methods, methodologies, approaches, and so on, that can be seen as an architecture or design activity. For example OOAD (Object-Oriented Analysis and Design) methods, CBD (Component-Based Development) methods, SOA (Service-Oriented Architecture) methods. Can these methods be considered design methods? In architecture point of view, we have other methods, such as ADD method by SEI and 4+1 Model View by RUP. These methods present some steps to design a high-level architecture on several views.
In this context, I have some questions:
- Design comprises architecture activities? Or is it the opposite? Do analysis and design discipline in the life-cycle development encompasses an architecture method?
- OOAD is a design method, architecture method or design technique?
- Are UML Components and Catalysis (CBD methods) design methods?

At the end, my final question is: How is named an approach that defines components of the system in a high-level architecture with different views (architecture concept), and defines details of these components such as their operations(design concept)?

More on Software Product Line Design

In this post I'll bring some initial work from my master thesis, which will bring some contribution on Software Product Line in the Digital Television Domain. Entitled "Designing Software Product Line Architecture", this talk was presented today at the Seminars in Software Reuse course at Cin/UFPE. It shows a survey on the well known Product Line Architecture Methods, comparison of those mathods by Marinlassi, M. and a nice state-of-art work by Hendrickson, S. A. & van derHoek A..

Software product line engineering is a pro-active reuse approach. It introduces software reuse in large scale, throughout the organization. Its adoption benefits from lowering costs and time-to-market as well as raising product quality.
The five best known architecting methods for Software Product lines, which were surveyed in this presentation were the FAST method, by David Weiss; FORM by Kio Kang, that focuses in the feature analysis and develops its architectural model based on its feature model; COPA, developed inside Philips, which is probably the most extense method, covering also organizational issues; the QADA method, by Matinlassi, focuses on architectural quality attributes and proposes designing and assessing the architecture; and last, but not least, the KobrA method, developd by Atkinson, inside the Fraunhofer Institute as a concrete, component-based, object-oriented instantiation of PuLSE-DSSA.
Besides the well known methods proposing a new way of modeling product line architectures, Hendrickson bases his work on change sets and relationships between those change sets. An interesting alternative for tackling complexity.
Agreeing with Matinlassi's comparison of the well known methods, the KobrA approach is the simplest one. It is very pragmatic and focuses directly on defining a conceptual architecture and realizing it through component-based development. The key activities in the KobrA approach are those related to context realization (Application Context, Framework Context...). Therefore, a worthy contribution shall come from closing this gap between the conceptual approach and the Digital TV application domain.

The slides are available here for download, already with some extensions suggested this morning, at the classroom.

Software Product Line Design

In this post I will bring topics about my master thesis presented (see) in Seminars in Software Reuse course at Cin/UFPE. The title is "An approach to software product line Design" where I brought an evaluation of existing Software Product Line (SPL) Design approaches for discussion.

Nowadays software reuse is very important for every software company mainly because it reduces software construction effort and consequently the time to market. SPL is an approach that has being adopted for organizations to address the software reuse issue. The Main objective of SPL is to organize the common assets from a software application domain and instantiate a new application based on these assets including just specific ones from the application. An important point to address in SPL is the variability and commonality from domain. This make possible the mass customization what bring to SPL configuration mechanisms to address specific client needs from the software application.

The focus of my work is on the Domain Design subprocess from the Software Product Line Process in Mobile Game domain. The motivation for the work is the lack of works in academy addressing this issue and the need of the industry to have a process where they can reuse the maximum number of possible assets and address the difficult task of porting the same game on different platforms and models. It was evaluated the FAST process developed by David Weiss at Lucent Technologies Lab. The FAST process focus on variability in a family of products to the telecommunication infrastructure and real-time systems domain, using a commonality analysis as the entrance for design and an architectural modeling language (AML) for specifying family members. After the FAST process guides to design the family and mapping between the AML and the family design. Another presented method was the QUASAR developed by Jan Bosch at Technical Research Center of Finland. QUASAR method focus on the quality of architecture and have two phases: Design and analysis. CoPAM approach is used for sharing knowledge between domains in a company with commonality layers. This brings an increase in reuse, since there is a mix of domains in the sense of commonality. Hassan Gomaa developed the PLUS method that is compatible with the Rational Unified Process (RUP) focusing on the domain architecture with the design of components. The RiSE process for Domain Engineering (RiDE) was developed by Eduado Almeida with the purpose of addressing a general domain. The RiDE process design method has steps where the architect should decompose the modules, define the architectural and design patterns of the domain and structure use cases in components.

It was presented a draft approach based on the CoPAM approach for reuse the major part of the available assets in the game architecture domain architecture reference.

Ednaldo Dilorenzo

What views are necessary to represent a SOA?

Service-Oriented Architecture (SOA) is a system architecture in which a collection of loosely coupled services communicate with each other using standard interfaces and message-exchanging protocols. As an emerging technology in software development, SOA presents a new paradigm, and some authors affirms that it affects the entire software development cycle including analysis, specification, design, implementation, verification, validation, maintenance and evolution [see 1, 2 and 3].

In this context, we discussed about the paper "SOA Views: A Coherent View Model of the SOA in the Enterprise", published at IEEE International Conference on Services Computing in 2006. The authors, Ibrahim and Misic, proposed a set of nine views to represent an SOA-based architecture software: Business view, Interface view, Discovery view, Transformation view, Invocation view, Component view, Data view, Infrastructure view, and Test view.

In our discussion, the first question was: Do current approaches, such as RUP 4+1 Model View and ADD method by SEI, attend the particularities within context of SOA design?

We agree with some views and we considerate interesting within SOA approach, such as Interface view and Discovery view. The first describes the service contract, and the second provides the information necessary to discover, bind, and invoke the service.

Additionally, I agree with the paper about to have several views for SOA, because they can conduct the architects to construct a solution with the particularities of SOA and to address the quality attributes of this kind of enterprise system.

Finally, I think that misses in this paper the relation among the stakeholders and the quality attributes that each view can be address. Besides, the paper does not show how each view can be represented. For architects, it is important to have models in order to help the architects to design the solution for each view. One example of this, it is using the UML sequence diagram for Discovery view, showing how the consumer can find the services in the service registry.