Design of complex systems: issues and challenges

Several techniques currently exist to design complex systems. The most common technique used is to divide complex systems into smaller modules (or subsystems), build the modules separately, and later integrate them. Depending on the user requirements and domain-specific and system-specific characteristics, the division is based on factors such as functionality, geographical locations (within the system), and inter-component interactions. Resulting modules have well-defined interfaces. An interface is an abstraction through which the internal details of a module are hidden from other modules. Understanding and tracking the relationships between modules is very important. This paper presents various factors that have to be considered during division of systems. Reuse is the most popular method used to build the modules. Reuse is the process of building systems from existing systems rather than building them from scratch. This concept utilizes general methods and experience of the domain life cycle from earlier product developments, which results in improved productivity, quality and efficiency, while minimizing man-hours, cost, and complexity. Abstraction, selection, customization, and integration are the four steps of this approach (Krueger, 1992). Among these, integration is the most complicated step. Fewer the modules to integrate, easier the integration, but smaller is the chance of reusability. On the other hand, smaller modules result in efficient reuse, but complex integration process. Thus, there is a tradeoff between reusability and integration. Using examples from various domains such as software engineering and health management systems, this paper discusses the concepts mentioned.

[1]  Nasib S. Gill,et al.  Few important considerations for deriving interface complexity metric for component-based systems , 2004, SOEN.

[2]  Stephane Doublait.  Standard reuse practices: many myths vs. a reality , 1997, STAN.

[3]  Angela Lo Surdo,et al.  An integrated approach to software reuse practice , 1995, SSR '95.

[4]  William B. Frakes,et al.  Software reuse: metrics and models , 1996, CSUR.

[5]  D. L. Parnas,et al.  On the criteria to be used in decomposing systems into modules , 1972, Software Pioneers.

[6]  Charles W. Krueger,et al.  Software reuse , 1992, CSUR.

[7]  Jun Han,et al.  Security characterisation and integrity assurance for component-based software , 2000, Proceedings International Conference on Software Methods and Tools. SMT 2000.

[8]  Nasib S. Gill,et al.  Reusability issues in component-based development , 2003, SOEN.

[9]  J. E. Gaffney,et al.  Software reuse—key to enhanced productivity: some quantitative models , 1989 .

[10]  Ravi Mukkamala,et al.  Designing domain-specific hums architectures: an automated approach , 2003, Digital Avionics Systems Conference, 2003. DASC '03. The 22nd.

[11]  Michael Sparling,et al.  Lessons learned through six years of component-based development , 2000, CACM.

[12]  Arvinder Kaur,et al.  Component Based Software Engineering , 2010 .

[13]  Jon Hopkins,et al.  Component primer , 2000, CACM.

[14]  Johan Margono,et al.  Software Reuse Economics: Cost-benefit Analysis On A Large-scale Ada Project , 1992, International Conference on Software Engineering.

[15]  A. S. Peterson,et al.  Reuse: where to begin and why , 1989, TRI-Ada '89.

[16]  Nasib S. Gill,et al.  Component-based measurement: few useful guidelines , 2003, SOEN.

[17]  Mei-Hwa Chen,et al.  Software architecture analysis-a case study , 1999, Proceedings. Twenty-Third Annual International Computer Software and Applications Conference (Cat. No.99CB37032).

[18]  Kristine Stougård Thomsen.  A General Software Architecture for Information Systems , 1992 .