UC researcher celebrated for reuse in software product lines

Software product lines, however, are not perfect and come with a number of challenges, ranging from investment of time to financial constraints. Additionally, the way engineers determine their assets is not always the most efficient process.

That’s where Niu’s research comes in. 

Niu and his PhD advisor, Steve Easterbrook, PhD, recently received the prestigious Most Influential Paper Award at the International Requirements Engineering Conference for their paper, “Extracting and Modeling Product Line Functional Requirements.” The honor, awarded by the Institute of Electrical and Electronics Engineers (IEEE), is given annually to the most influential paper from the conference 10 years earlier.

Niu’s paper, which addresses reusable assets in software product lines, has been monumental to research, and its concepts have been widely applied to the field, its relevance rippling through both academia and industry.  

Niu’s paper addresses the extraction method within the software product line. Software developers use three approaches to reuse core assets: proactive, reactive and extractive.

In a proactive model, manufacturers develop nearly all core assets for reuse so that products can be reused at maximum efficiency.

“In this extreme case, you wouldn’t even build a frame of the engine in the first place without thinking about doing a reusable thing first,” says Niu, referring back to the car manufacturing example.

The proactive approach, though most effective, requires a large upfront cost and a transition time that some companies can’t afford. Retrofitting an entire product line to meet a proactive model can be a lengthy process, sometimes shutting down production facilities for months at a time. Its benefits, however, are immediately noticeable: Over time, the cumulative costs for building each product is significantly less than other approaches.

On the other hand, the reactive, or “one-of-a-kind,” approach creates product lines with little regard for reuse. Reusable assets – like designs or user documents – are developed as needed or as they come up in production. Though this method doesn’t require any prior planning – or the costs in time and energy associated with that planning – it can put businesses behind the competition in the long run.

The extractive model, the model Niu addresses in his paper, is a third approach that splits the difference between proactive and reactive models. The extractive approach selectively reuses several existing assets to build a product line asset base. 

“The extractive approach strikes a balance,” says Niu. “It may never be as dramatic as the proactive approach, but the key is that you can survive in the market competition.”

Rather than overhaul an entire operation, companies can increase efficiency and stay competitive in the market by selectively choosing several assets to reuse down the road and strategically investing in assets as they can afford to do so.

“If I’m a car manufacturer, I may build an engine or two without reusable assets,” says Niu. “After building those two engines, however, I realize I have common themes. While making a third engine, I can afford to invest time in determining reusable assets and shaping that product line infrastructure, so that the third and fourth engine can be produced at a lower cost.”

As a manufacturer develops more products in the line, the number of reusable assets increases and become more advantageous simply because of the financial and time-saving benefits of reuse.

How do manufacturers determine the assets to extract? That is the second part of Niu’s paper. 

Niu is working with requirements assets for building reusable assets within software product lines. When people build software systems, for example, they use requirement assets to instruct what each software system should do for a user. Niu found that these assets are typically written in natural language, with a verb-direct object pair.

The paper uses an example of an academic grading and feedback system employed at the University of Toronto. In this system, students can submit papers, follow assignments and view grades online. If a software developer wanted to allow students to view their grades, she would write that into the functional requirements – “student” is the agent, “view” is the verb and “grades” is the direct object that pairs with that verb. When somebody builds the site’s functions, these requirements would provide a convenient framework. 

“You use this frame of verb-direct object pairs to allow you to express the concerns or the key functionalities of the software,” says Niu. “In a nutshell, this technique recognizes the verb and direct object pairs that are happening in a natural language context, extracts the pairs and later models them using semantic analysis.”

By employing this approach, a user or developer is left with a set of reusable verb and direct object pairs that expresses the contents of the software product line. Manufacturers can use this set to develop the foundations for their software product lines. 

Featured image at top: Production line for engines in a car manufacturing facility. Photo/Hamik/Shutterstock.