The Scoping Process in Software Product Lines - Is there any relationship with Design?

I believe that the scoping process is very important to start a product line project. [If you are not familiar with the topic see Isabel John's papers about it and our systematic review].

However, I would like to understand more the relationship between it and the design. Let me explain better: Suppose that I am starting a product line based on a set of products. We collect all the documentation, define a product map with their features, understand and document all the commonality and variability, and that is it!

But in this case, we are defining the SPL scoping based on the existing assets (source code and documentation). From here, we can move, for example, to design the SPL architecture. However, you can observe that we are taking decisions based on the current state of the family, i.e., how it is. What are the implications for the next steps? Are we repeating the same decisions problems when the previous team created the products?

What could be a better solution: define the scope, recovery the SPL design, evaluate this design, reflect it in Scoping and moving forward?

In general sense the point is: for you, what is the relationship between scoping and design? is there any one?

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.

How big should a reusable component be?

Bill Frakes in his website asked to Ted Biggerstaff one of the pioneers in software reuse and specialist in the software generators area, how big should be a reusable component.

What do you thing about it?

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)?