introducingsoftwareproductlines(36页)-经营管理(编辑修改稿)内容摘要:

levels of ponent reuse  reuse of software ponents over subsequent versions of a product  we know this trick  reuse of ponents over product versions and various products  we’re learning this trick  reuse of ponents over product versions, various products and different anizations  we’re nowhere near learning this trick (except in very restricted domains, ., Visual Basic) Introducting software product lines 18 Software Components Research  Reusable assets are blackbox ponents  Assets have narrow interface through a single point of access. Industry  Assets are large pieces of software (sometimes more than 80 KLOC) with a plex internal structure and no enforced encapsulation boundary, ., objectoriented frameworks  The asset interface is provided through entities, ., classes in the asset. These interface entities have no explicit differences to noninterface entities. Introducting software product lines 19 Software Components Research (cont.)  Assets have few and explicitly defined variation points that are configured during instantiation  Assets implement standardized interfaces and can be traded on ponent markets  Focus is on asset functionality and on the formal verification of functionality Industry (cont.)  Variation is implemented through configuration and specialization or replacement of entities in the asset.  Assets are primarily developed internally. Externally developed assets go through considerable (source code) adaptation to match the productline architecture requirements  Functionality and quality attributes, . performance, reliability, code size, reusability and maintainability, have equal importance Introducting software product lines 20 Software Architecture  software architecture The software architecture of a program or puting system is the structure or structures of the system, which prise software ponents, the externally visible properties of those ponents and the relationships among them. [Bass et al. 98]  quality requirements Quality requirements can be categorised into development QRs, . maintainability, and operational QRs, . performance and reliability Introducting software product lines 21 Why software architecture? first class representation of SA during  design  assessment of quality attributes  software product lines  implementation  configuration management (SPLs)  runtime  dynamic software architectures, postfielding upgrade。
阅读剩余 0%
本站所有文章资讯、展示的图片素材等内容均为注册用户上传(部分报媒/平媒内容转载自网络合作媒体),仅供学习参考。 用户通过本站上传、发布的任何内容的知识产权归属用户或原始著作权人所有。如有侵犯您的版权,请联系我们反馈本站将在三个工作日内改正。