Objects, components, and frameworks with UML: the catalysis approach
Objects, components, and frameworks with UML: the catalysis approach
Extreme programming explained: embrace change
Extreme programming explained: embrace change
UML components: a simple process for specifying component-based software
UML components: a simple process for specifying component-based software
Component-based product line engineering with UML
Component-based product line engineering with UML
Component Software: Beyond Object-Oriented Programming
Component Software: Beyond Object-Oriented Programming
MDA Explained: The Model Driven Architecture: Practice and Promise
MDA Explained: The Model Driven Architecture: Practice and Promise
Barriers to adoption of software reuse a qualitative study
Information and Management
Agile Project Management With Scrum
Agile Project Management With Scrum
Service-Oriented Architecture: Concepts, Technology, and Design
Service-Oriented Architecture: Concepts, Technology, and Design
IEEE Software
Component-Based Development Process and Component Lifecycle
ICSEA '06 Proceedings of the International Conference on Software Engineering Advances
IEEE Transactions on Software Engineering
Modeling Components and Component-Based Systems in KobrA
The Common Component Modeling Example
Code Conjurer: Pulling Reusable Software out of Thin Air
IEEE Software
Towards mining informal online data to guide component-reuse decisions
Proceedings of the 16th International ACM Sigsoft symposium on Component-based software engineering
Hi-index | 0.00 |
While the notion of components has had a major positive impact on the way software architectures are conceptualized and represented, they have had relatively little impact on the processes and procedures used to develop software systems. In terms of software development processes, use case-driven iterative and incremental development has become the predominant paradigm, which at best ignores components and at worse is even antagonistic to them. However, use-case driven, I&I development (as popularized by agile methods) and component-based development have opposite strengths and weaknesses. The former's techniques for risk mitigation and prioritization greatly reduce the risks associated with software engineering, but often give rise to suboptimal architectures that emerge in a semi-ad hoc fashion over time. In contrast, the latter gives rise to robust, optimized architectures, but to date has poor process support. In principle, therefore, there is a lot to be gained by fundamentally aligning the core principles of component-based and I&I development into a single, unified development approach. In this position paper we discuss the key issues involved in attaining such a synergy and suggest some core ideas for merging the principles of component-based and I&I development.