IDS 2013 - ROSKO 3

Copyright © Zdravko Roško. All rights reserved.

Business Applications Reference Architecture based on Software

Product Lines Approach

Zdravko Roškowww.foi.hr

INTERNATIONAL DOCTORAL SEMINAR 2013, May 13-15, 2013, Dubrovnik, Croatia

2

Research Problem Software development project disasters and lost of billions due to

poor project implementations (Nash, 2000) Only a third of the more than 13,500 projects evaluated in 2003

were successful (Standish Group) Half of the software development projects over budget

(Larkowski, 2003) Project size success rate: large 28%, medium 25% and small

20% (Gartner, 2011) Croatian e-government projects (6 billion kunas) Author’s experience of not seeing planned reuse while

working on projects (travel, manufacturing, pharmacy, telecomunications, finacial, insurance, banking, utility) except the world class software companies


3

Research Motivation

Developers of today’s business applications are using J2EE, Spring Framework, Hibernate, iBatis, JPA, Top Link, The IBM Insurance Application Architecture, Unisys 3D Blueprints, Eclipse 4 Applicatin model, and etc. as application models

Most of the named models represents inter-organizational reuse (? not intra-organizational)

Level of abstraction - most of the time is low or high (missing a common business application level, e.g. mobile phone, cars, insurance, banking, etc.)


4

Research Issues (RI)

1. Lack of approaches and solut ions explicit ly support ing business application ’s reference architecture at the appropriate level of abstraction in software product l ine engineering

2. Weak work division between client/server and application/domain infrastructure developers

3. Lack of reference architecture quality metrics and it’s product stabil i ty predict ing techniques in software product l ine engineering


5

Research Questions (RQ)

1. What are the required characteristics (features, capabilities, variability points, optimal structure, scope, etc.) of an effective Business Application Reference Architecture that organizations can expect from, in order to be used as a template for concrete architectures for a family of business software systems to accelerate delivery through the reuse of a solution based on software product lines approach?

2. How can we build the reference architecture with the required characteristics?

3. Is the referenced architecture providing required characteristics efective and usefull in practice?


6

Research Questions - Addressed RQ1 will be addressed by analyzing state-of-the-art of

business application software architecture based on software product lines and defining it’s required characteristics. Feedback from the experienced developers will increase confidence on the defined characteristics (mandatory, optional, importance, relevance, etc.).

RQ2 will be addressed by designing and implementing the reference architecture solution that provides the required characteristics.

RQ3 will be addressed by applying the developed solution in practical case study and by collecting the data for analysis. Test for: usefulness (utility, usability), effectiveness by asking 3 groups of 10 experienced business application developers/architects to reply on questionnaire (s).


7

Research Objectives (RO1)

1. Define and evaluate required characteristics of Business Application Reference Architecture based on Software Product Line approach.

a) Analyze existing research on reference architecture in SPL for business applications and identify key issues

b) Analyze existing reference architecture or programming models used by developers of business applications

c) Define the required characteristics for reference architecture

d) Analyze the opinion of experienced developers regarding the importance of the defined required characteristics


8


2. The purpose of this research is to create the Business Applications Reference Architecture (SPL Platform Framework, Components, Tools, Documentation) based on Software Product Line approach by using: Java 7+, Eclipse 4+, MD, CB, AO, Patterns (Dependency Injection,...), as a template for concrete architectures for a family of business software systems (level of abstraction), to accelerate delivery through the reuse of an “effective” solution.


9


3. Validate the developed reference architecture (RA) and its effectiveness and usefuleness in practice. a) Access the usefulness (utility and usabil i ty) of the

RAb) Access the effectiveness of the RAc) Apply the RA in case study(s) in different domains(?)d) Analyze the usefuleness and effectiveness of the of

the RA based on qustionariee from 3 groups of 10 experienced developers


10

Research Approach

The world is satisfied with words.Few appreciate the things beneath.

Blaise Pascal


11

Research Methodology - Design Science Design Science Research in Information Systems

Research (Alan R. Hevner, 2004) History key distinction: natulal science and “science of

the art i f icial” (Simon, 1969) All or part of the phenomenon may be created as

opposed to naturally occurring Design scientists create IS art ifacts, behavioral

scientists create IS theories Design Science Research (DSR) types of artifacts:

constructs, models, methods, and instantiations


12

Research Methodology (DSR)

Design Science Researchers work on understanding, explaining, and improving information systems

DSR addresses important unsolved problems in unique or innovative ways or solve problem in more effective or efficient ways

Design science is an iterative, problem solving process which seeks to extend the boundaries of human and organizational capabilities by creating new and innovative artifacts and by evaluating it’s effectiveness

Risk management for the design science research framework, six areas of potential risk (Jan Pries-Heje)


13

Research Methodology (DSR)

Robert W. Lucky, IEEE Spectrum, July 2009General design cycle framework (GDC),Vaishnavi and Kuechler (2004)


14

General Design Cycle Framework (GDC) Awareness of Problem: the problem identified in the

current research is the lack of effective solutions explicitly supporting business application’s reference architecture at the appropriate level of abstraction in software product line engineering,…

Suggestion: Analyze existing research on reference architecture by using : DSR pattern Industry and Practice Awareness and/or technique of: a systematic literature review [Kitchenham, 2004]. Analyze existing reference architecture, define the required characteristics for reference architecture, analyze the opinion of experienced developers, survey based on questionnaires [Yin, 2004].


15

General Design Cycle Framework (GDC) Development: design and create artifact - the Business

Applications Reference Architecture (SPL Reference Architecture, Components, Aspects, Eclipse plug/in, Documentation, Test cases)

Evaluation: evaluate the artifact using empirical methods “to determine how well an artifact works” (Hevner et al., 2004). Case study(s) (“research-in-the-typical“) for collecting data – predicting stability, controlled experiment (“research-in-the-small “, Wohlin 2000, initial usability test), DSR patterns: Using Metrics and Benchmarking, survey for usabiliy (Perceived Usefulness and Ease of Use, Davis, 1989) and effectiveness questionaire (http://hcibib.org/perlman/question.html)

http://hcibib.org/perlman/question.html


16

General Design Cycle Framework (GDC) Conclusion: Findings, Knowledge gained,

Further work, Metrics (proposed), case-based reasoning for predicting Mainainability:Stability

Limitations: it is possible that the evaluation of effectiveness may not be general enough since it will be applied in one case study, but we will try to use the solution in multiple products of the same product line, and in multiple version of the products (longitudinal study) to collect more data for analysis


17

Research Plan / Summary


Architecture – we can not buy!

An architecture is important since ≈80% of effort in systems occurs after deployment

Systems can be built from large, externally developed components that are tied together via architecture.

An architecture is an abstraction: enables a one-to-many mapping (one architecture, many systems).

Architecture is the basis for product (system) commonality.

Entire software product lines can share a single architecture.

18


Why Software Product Line

19Frank van der Linden, 2010.


Reuse History: From Ad Hoc To Systematic (planed)

20

Software Product Lines Linda Northrop © 2008 Carnegie Mellon University.


Software Product Lines

A software product l ine is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way (L. N. Paul Clement, 2001)

Standard Practice (planed) that proposes a proactive reuse, stimulating interchangeable components to construct high-quality products faster and cheaper.

NOKIA, CelsiusTech, Motorola, Hewlett Packard, Market Maker…

21


Software Product Lines – core assets

requirements and requirements analysisdomain modelsoftware architecture and designperformance engineeringdocumentationtest plans, test cases, and datapeople: their knowledge and skillsprocesses, methods, and toolsbudgets, schedules, and work planscomponents

22


23

Software Product Lines


SPL Scope, Commonality, Variability, Products

24


25

Not using planed approach to reuse - traditional

Product1

Product 2

Product3

Product 4

Product 5


Software Product Line approach

26

Managed Central Asset Repository

Product1

Product 2

Product3

Product 4

Product 5


SPL Production Process Perspectives

27Copyright © 2010 BigLever Software, Inc.


Multiple Dimensions in a SPL Solution

28


SPL Process and Organization

29


30

Software Product Line Architecture (SPLA)

A product-line architecture is an abstraction: it is a specification of the high level structures of a family of applications. These structures reveal complementary facets of an architecture (static structure, dynamic structure, etc… ) and contain elements like components, connections, data, processes [Bass et al, 1998].

A product-line architecture has to capture both architectural commonalities and variability's of a family of applications (components, topology, dynamics and physical environment, etc.)


Benefits of a Software Production Line

Economy of Scale from Automated Production� Increase in the scope of product diversity� Increase in the scale of different products effectively delivered and maintained

Cost Savings from Eff iciency and Productivity� Increase in productivity and efficiency� Reduction in per-product development cost and overhead� Higher profit margins

Faster Profi ts from Faster Time to Market� Reduction in time-to-market for new and updated products� Increased agility to react to new opportunities and changing market conditions

Better Products from Better Quality� Increase in customer-perceived product quality� Reduction in defect density� Improved risk management

31


32

Examples of Domains Compilers for programming languages Consumer electronics Electronic commerce Video games Business applications

� Basic/Standard/“Pro”

We can subdivide, too:� Avionics systems

Boeing Jets Boeing 747-400

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission.


33

Capturing Product Line Architectures

Common: features common to all products A: features specific to product A B: features specific to product B Product A = Common + A Product B = Common + B

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with permission.


Product Line Architectures

A product-line architecture has to meet three fundamental requirements:� It has to drive the architectural design of new

applications in the product-line;� It has to facilitate the reuse of components at the

product-line level;� I t has to permit various analyses in order to

assess the impact (cost, performance, etc… )

of specif ic requirements for the development of new applications in the product-l ine.

34


Business Applications Parts

35


36


Prod 1 Prod 2 Prod 3 Prod 4

Business-specific components

SPL Reference Architecture (common services)

External Components

OS/Language Environment


Client feature model (proposal)

37


Server Feature Model (proposal)

38


Evaluation – Dependent Variables (ISO/IEC9126-2001)

39

MaintainabilityPortabilityReusabilityTestability

Time To MarketCost and BenefitsProjected life timeTargeted MarketIntegration with Legacy SystemRoll back Schedule

End User’s view

Developer’s view

BusinessCommunityview

Performance Availability Usability Security

A list of quality attributes exists inISO/IEC 9126-2001 Information Technology – Software Product Quality


40

Proposed structural model and dependencies - Metrics


Evaluation by DSR Using Metrics (Maintainability: Stability)

41

Zdravko Rosko CECIIS (C) 2013



42



SPL Reference Architecture Quality

43



44

D3 D4 D5 PRP1 4 3 3 0,60P2 4 3 0 0,43P3 4 0 0 0,00

Total 12 6 3 0,43

Measure type Measure name

Size Number of Platform/environment (language) class dependencies (D1)

Number of Platform/external components class dependencies (D2)

Number of Product/Platform class dependencies (D3)

Number of Product/environment (language) class dependencies (D4)

Number of Product/external components class dependencies (D5)

Complexity Platform framework responsibility (PR)



Questionnaire to 3 groups of 10 developers (usability)

45

Method Research Question Questionnaire Questions

PUEU

What is the usefulnessperceived by users

(developrs/architects) of thetools (reference architecture RA

and helper plug-in tool)?

Using RA in my job would enable me to accomplish tasks more quickly

Using RA would improve my job performance

Using RA in my job would increase my productivity

Using RA would enhance my effectiveness on the job

Using RA would make it easier to do my job

I would find RA useful in my job

-2: strongly disagree, -1: disagree, 0: undecided, 1: agree, 2: strongly agree


Questionnaire to 3 groups of 10 developers (effectiveness)

46

Can you program the same functionality with ?

Less programming code (eg. Java, XML, CSS)

Less needed knowledge about the required APIs

Less dependencies on external componentes (eg. Jdbc, JSP, Reporting)

Less dependencies on Java platform (rt.jar)

Less time for developing

Less time for testing (having the size of code in mind)

Less documentation needed for somebody new to take maintenance over

Less dependencies on specific tools to help while developing

Less complicated design (simpler UML diagrams)

Likert scale (7): 1 - not possible at all2 - not as far as I know3 - may be but not sure4 - not sure5 - it is possible6 - it is possible as far as I know7 - sure it is possible


Conclusion – Contribution of this Thesis Systematic analysis of the state-of-the-art in business

applications reference architecture based on software product line approach

Definition and evalutaion of required characteristics for the reference architecture

Reference architecture solution and tools (Eclipse plug-in) to help development of applications based on the architecture

Case study of the effectivenes and usefulness of the solution Metrics for reference architecture “responsibility” used at the

“early stage” of the product line, case-base reasoning technique to predict the product stability, feature models, and entities structural model

47


Thank YOU!

48


Research approach

49

Research Question Research Approach ValidationWhat are the required characteristics (features capabil i t ies, variabi l i ty points, optimal structure, metrics, scope, etc.) of an effective Business Application Reference Architecture that organizations can expect from, in order to be used as a template for concrete architectures for a family of business software systems to accelerate delivery through the reuse of a solution based on software product l ines approach?

Analyzing state-of-the-art of business application software architecture based on software product l ines.

Systematicl i terature review (reference architecture, software product l ine, research) and review of existing reference architectures

Define cahracterist ics andrevise them based on experineced deveopers/architects opinion

Survey amongdevelopers/architects

How can we build the reference architecture with the required characteristics?

Iteratively designing and implementing the reference architecture solut ion that provides the required characterist ics

Describe approachand reference architecture and show the way theyprovide the required characterist ics

Is the referenced architecture providing required characterist ics efective and usefull in practice?

Show that the reference architecture is effective and usable in practice

Usabili ty and effectiveness test

Use the reference architecture in practice and col lect the data about its usage, i .e., the metrics for maintainabil i ty:stabil ity, usage, performance, etc.

Case study


Evaluation – 3 Groups (10+ people – developers/architects) Group A (2-3 years) Group B (4-5 years) Group C (6+ years)

50


CASE-BASED Reasoning used to predict the Maintainability

51

D3 D4 D5 PCC PVC PSC PBO PSS OSU OOM Σ1 wi

D3 1 1 1 1 1 1 1 2 2 7 0,27

D4 2 2 2 2 2 2 2 2 0 0 0,00

D5 2 1 1 1 1 1 1 2 0 6 0,23

PCC 2 1 2 2 0 0 0 2 2 1 0,04

PVC 2 1 2 1 0 1 0 2 2 3 0,12

PSC 2 1 2 0 0 2 2 2 0 1 0,04

PBO 2 1 2 0 2 1 1 2 0 3 0,12

PSS 2 1 2 0 0 1 2 2 0 2 0,08

OSU 1 1 1 1 1 1 1 1 0 7 0,27

OOM 1 0 0 1 1 0 0 0 0 3 0,12

Σ 26 1,00


Initial Usability test: Variables in an Controlled Experiment (Wohlin)

52

1. DesignStandard design: (1) One independent variable with two values; (2) One independent variable with two values, paired design; (3) One independent variable with more than two values; (4) More than one independent variable

2. Operation Commit participants, Prepare instrumentation, Execution

3. Analysis and interpretationDescriptive statistics, outliers (scatter-plots), hypothesis testing (parametric: t-test, paired t-test, ANOVA), non-parametric (normally distributed?); internal validity; external validity


Feedback from Expert - Survey

Required characteristics for Reference Architecture(RA) Parallel to survey we design and develop RA Questions to participants:

1. Year of experience (development, architecture, OO,…)

2. Importance of capabilities (-2 totally irrelevant ,-1 unimportant, 1- important, 2- very important)

3. What other characteristics do you propose as important part of RA

53


Case Study

Sample over variables (not being manipulated as experiment) but that represent the typical situation

Harder to generalize (but having more products, and periods: 2012, 2013, 2014 will empower the generalization)

Robert K. Yin: � 6 data sources (documents, interviews, participant

observations, archival records, direct observations, physical artifacts)

� 3 principles (? Multiple sources of evidence, create case study data base, maintain a chain of evidence)

Comparing the results of using two approaches (defect rate, productivity, stability)

54


Answer to Etnographic

55

No. Feature Name Feature Implementation C L I E N T1 Clent Type RCP, Swing, GWT, SWT, JSP,...2 Client Communication REST, JMS, RMI, HTTP, IIOP, LOCAL,...3 Logging Log4j, Xyz,...4 Session Xyz session,...5 Reporting HTML, PDF, Jasper, Excel,...6 Caching Client RAM, Cookie,...7 Security LDAP, Xyz Security,...8 Language English, Xyz Language,...9 Data Validation Rule Engine, Xyz Validation,...10 UI Components Component 1-N,... S E R V E R11 Logging Log4j, Xyz,...12 Server Communication REST, JMS, RMI, HTTP, IIOP, LOCAL,...13 Transaction JTA, EJB, Xyz,...14 Business Object POJO, EJB,...15 Data Access Object JDBC, CICS, JMS, iSeries,...16 Data Source Connection Application Server, Apache Pool, Xyz Pool,...17 Session Container, Xyz Session,...18 Caching Server RAM, File,Container, Data Base,...19 Security LDAP, Xyz Security,...20 Language English, Xyz Language,...21 Data Validation Rule Engine, Xyz Validation,...22 Business Component Component 1-N,...


Software Product Lines…

Scope (domain, sub-domain, abstraction level) Commonality Variability Organization (4 types) Process (PuLSE) Methods (for Architecture: COPA, Kobra, FORM, FODA

56


SPL Process

57


Domain Specific Software Architecture

58

Domain Specific Software Architecture is a set of principal design decisions composed of:1) A reference architecture which describes a general

computational framework for a significant domain of applications

2) A component library of reusable chunks of domain expertise

3) An application configuration method for selecting and configuring components within the architecture to meet particular application requirements


59


There must be an up-front (and on-going) investment in developing a reusable architecture that can be instantiated for each product.

Documents

IDS 2013 - ROSKO 3