9th RiSE Day

Next wednesday, on July 1st, right after IV WIRE(*), RiSE will promote its 9th internal workshop, the RiSE Day, an environment in which RiSE Members present their master and doctoral works, some concluded and some 'working in progress', in order to discuss and have feedback on the issues they have been devoted effort.

The 9th RiSE Day will be held at C.E.S.A.R, in Recife-PE, Brazil, at 10:00 a.m. Software reuse practitioners are welcome to make discussions more interesting!

(*) IV WIRE - Workshop to Introduce Reuse in Enterprises - is promoted by RiSE in conjunction with C.E.S.A.R and CIn, and it will be held in next June 29 and 30, 2009.



*UPDATE - Jul 1st, 2009*

This edition included the following presentations:

• Towards an Approach for Service-Oriented Product Line Architectures - Lecturer: Flavio Medeiros
• RiPLE-DE - The RiSE Process for Product Line Engineering Design - Lecturer: Ednaldo Dilorenzo
• RiSE Adoption Process Framework for Software Reuse Adoption in Brazilian Companies - Lecturer: Vinicius Garcia
  
• Towards an approach to deal with feature interaction in software product lines - Lecturer: Hernan Muñoz
• SPL Architectures - Variability in Quality Attributes - Lecturer: Ricardo Cavalcanti
• Towards an effective Software Product Line Testing Approach - Lecturers: Paulo Anselmo and Ivan Machado
  
  

The Ph.D. student Pàdraig O'Leary, from Lero, The Irish Software Engineering Research Centre, came to this workshop to experience the research the RiSE group has been conducted and exchange ideas with RiSE members as well. He presented the research he's been worked on, entitled A Process Framework for Product Derivation.

We are glad for the comments and contributions from John D. McGregor and Frank van der Linden, who also joined this international RiSE Day.

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.

Patent Development - China going Deep

In a previous post, I commented the possible Computer Scientists Crisis, especially, involving Americans. This situation can be showing some the future consequences that the country will have to deal.

According to China's State Intellectual Property Office, in the last year, China received more patent applications that any country (694.000). The U.S had the second most applications (484.955), followed by Japan (443,150). [see the note in Communications of the ACM]

Still according to the note, if China's number of patent applications continues at its current rate, it will lead the world in invention patent application by 2012.

About it, some Americans are wondering about this situation in the short future. Yesterday, I had a dinner with David Weiss, director from Avaya Labs, in New Jersey, and we were discussing about politics, previous presidents, their legacy and consequences. David highlighted exactly this issue: The lost of investments for research and education, the interest for students in the area, the fact that nowadays most graduates are not Americans and they are returning for their country. Maybe, we have to wait for the next years and analyze this point which could have a great impact in science and technology around the world.

Computer Scientists Crisis?

Last July, Rick Rashid, Senior VP of Microsoft Research, published an interesting [discussion] paper in Communications of the ACM (see the paper here) about the future of computer science in the U.S. His first sentence was trick for a first look: "Is computer science a dying profession? ".

He argues that a recent UCLA survey in 2006, 1% of incoming freshman planned to major in computer science, compared with 5%, 25 years ago. In addition, he states that in 2007 occurred a one-year drop of almost 20% in computer science and computer engineering degrees and more than half of M.Sc. and Ph.D. degrees granted by U.S. universities were awarded to non-U.S. citizens.

On the other hand, everybody knows that the demands for services in the area is increasing a lot and it can be a problem soon [for some people it is happening currently].

One of Rick's issue now is try to understand why this interest is decreasing. If we talk about women the problem is still bigger. So, what Can we do? I do not know exactly the numbers in Brazil, but I know that the Brazilian Computer Society is working on this direction, especially, about women in computer science. In my environment, at C.E.S.A.R there are initial and interesting initiatives to improve this situation. Called Education for the Future, it combines researchers and practitioners from different areas where C.E.S.AR is starting Games Labs Lan Houses, Academic Social Networks for undergraduate students. The initial results are being very good and it will be better in the future with new investments from government, funding agencies and private companies.

Other good initiative is the Alice project or other incredibles one at Carnegie Mellon University. A good place to discuss it is the IEEE Conference on Software Engineering Education and Training (CSEE&T). This year, I presented our experience with software reuse and I could see good efforts in the software engineering are. About this conference, the call for paper is available for the next year.

Product Line Stakeholders - Do you know them?

Managers, Architects, Analysists, Testers, Software Engineers, CEOs...

It was a discussion with RiSE members about who are the stakeholders in a product line approach.

The idea is to define who they are, what they do, and in which phase during the life cycle they participate in the process. We would like to know your opnion based on your research, practical experience or just ideas.

6th RiSE Day

Last Saturday was accomplished the 6th RiSE Day. A special day in which we discussed all works performed by the RiSE members - some concluded, some "working in progress" and some in the "embryonal state".

The first section was devoted to the concluding work. We discussed some aspects related to reuse adoption {motivation, problems, goals and the framework proposed as solution}; new research trends in the LiFT - Legacy Information retrieval Tool (link in portuguese); the current state of the ToolDay, a tool for Domain Analysis (link in portuguese); set of work related to search and retrieval reusable assets {such as, Data Mining, Semantic, Ontology, Context-aware}; and, a systematic architecture method for SOA-based enterprise applications.

The second section covered work related to Software Product Lines such as: requirement engineering for SPL; domain design methods; core assets development in SPL (using the Mobile domain); and, aspects related to evolution and maintenance in SPL. This section finished with a discussion about an effective component testing approach.

The last section was a mix of other research trends, such as: new approaches for improve the reusable assets search and retrieval; duplicate bug and change requests detection; and a cost model for SPL.

This RiSE Day showed that the group is covering different aspects {technological, organizational, business and financial} related to software reuse {introduction, evolution and maintenance}.

In the 6th edition of the RISE Day, we had about 30 participants, from other groups of the CIn-UFPE, UPE and others universities; software companies like SERPRO, Pitang, C.E.S.A.R, Porto Digital among others.

We would like to thank all RiSE members, to dedicate your time to discuss a lot of work and help in disseminate the reuse practices in the Recife software environment.

Thank you guys! See you in the 7th RiSE Day.

* UPDATED *
See all pictures here !

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?

Using Requirements Management Tools in Software Product Line Engineering: The State of the Practice

Last week we discussed the paper "Using Requirements Management Tools in Software Product Line Engineering: The State of the Practice" which was published in SPLC 2007. The paper analysis the current scenario of requirements tools being used in Germany companies, and identifies the tools weakness to support software product lines requirements. As result, the authors proposes a set of requirements for requirements management tools.
The majority of the authors work in the industry, and because of that they did not define a systematic approach to do the analysis. They said that it was all based on practical experience, but should it be enough? Doing it does not increase the chance of bias in the research?
Besides, the requirements defined for requirements managements tools were too superficial described, some lacked of reasons why to include it, while others did not explained how it could aid the a software product line process.
On the other hand, the paper was derivated from a report, which may explain what was not very clear in the paper.

Quality Certification of Reusable Components

Yesterday, RiSE group discussed a paper titled “Reuse Strategy based on Quality Certification of Reusable Components”. The main idea of the paper is: reuse components without quality could be worst than doesn’t reuse anything and one form of promoting reuse and reducing risks is guaranteeing the quality of software components. The paper presents 7 activities that should be executed in order to promote reuse with quality in software organizations: (1) Incorporation of Domain Analysis into the development process; (2) Incorporation of a Domain Analyst; (3) Incorporation of reuse into the development process; (4) Use of patterns; (5) Use of standards; (6) Certification of all types of reusable components; and (7) Use of reusable components repository. These activities show that we need a well-define software reuse process in order to incorporate this reuse process in the organization’s software process (i.e. process adaptation). After that, we need to store and manage the software assets developed in the organization, however, the quality evaluation of those assets are primordial before stored those assets. In this way, the assets certification could be useful in this case, certifying software assets in general (i.e. requirements, use case, architecture, source-code, etc.). The authors presented a set of quality characteristics that could be useful for requirements specification, design specification and source-code. After that, they considering a set of V&V techniques which should be considered in three quality layers cited above.

One interesting aspect of this paper is that we, from RiSE, are developing a robust software reuse framework that considering the same ideas of the activities stands out in the paper (and other ones also). Besides, we are applying this framework in real case environments and a set of tools were developed to support this environment. The main goal is increase the software productivity of software companies. Is it interested?? Contact RiSE.

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.

Investments in reusable software

Today, we had another interesting discussion in the RiSE group involving a work of David Rine and Robert Sonnemann entitled "Investments in reusable software. A study of software reuse investment success factors", published at Journal of Systems and Software, v. 41 pages 17-32, 1998. Rine and Sonemann support the theory that a set of success factors that are common among the organizations exist and have some previsibility relationships with software reuse. Besides, the research of Rine and Sonemann also investigated if the reuse really has influence in the software productivity and quality.

The success factors were grouped into the following categories: administration (management) commitment; investment strategy; business strategy; technological transfer; organizational structure; process maturity, product line approach; software architecture, components availability; and components quality. To measure the experience in software reuse (reuse capability), productivity, quality and the set of success factors, Rine and Sonemann developed a questionnaire.

During the discussion some topics and positions adopted by Rine and Sonemann were questioned, such as: (1) why specify five levels to reuse capability model? Is the level approach the better choice? why do not use scenarios, for example, to suggest and to aid the organizations to identify their position in the reuse practices? (2) the model to calculate the overall probability of reuse success is subjective. (3) the success factors is not a big surprise for us, but this occur because we are reuse practitioners and researches or because is it the obvious choice? (4) the focus on productivity and quality is a better way to target the organizations and to advocate in favor of reuse practices. (5) to get the support of the management people, and the industry, we need ways to show the benefits and the better way is measure the activities, so the utilization of metrics to measuring the software reuse capability. (6) more studies and details are needed to explain the reuse capability model, specially the process of assessment of reuse capability of an organization and the process of reuse implementation in this organization, according to reuse capability model.

So, I think that this work is a very good contribution in the reuse adoption area. We know that reuse adoption is a great advantage for organizations, and this is the main issue to "hide" some activities, tasks and some information about that. I believe that our reuse adoption model can evolve in our environments (such as CESAR and PITANG) to reach a maturity to be shared with other organizations.