♦ Define direction for incorporating architectural thinking into IEEE standards♦ Take a “wide sco... more ♦ Define direction for incorporating architectural thinking into IEEE standards♦ Take a “wide scope” interpretation of architecture as applicable to software-intensive systems♦ Establish a conceptual framework and vocabulary for talking about architectural issues of systems♦ ...
This paper examines the central role of an architecture framework within the larger endeavour of ... more This paper examines the central role of an architecture framework within the larger endeavour of the architecting of enteprises, systems-of-systems and complex systems. The paper presents lessons learned from the development and use of IEEE 1471:2000, Recommended Practice for Architectural Description of Software-intensive Systems and its successor, ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description. The lessons learned address areas including: modeling and notations, method and process definition, and tooling, with recommendations for the continued evolution of the NATO Architecture Framework. 1 Background IEEE 1471:2000, Recommended Practice for Architectural Description of Software-intensive Systems, was the first formal standard addressing the architecture of systems, where ''the term system encompasses individual applications , systems in the traditional sense, subsystems, systems of systems, product lines, product families, whole enter...
The First Workshop on Aspects in Architectural Description was held in Vancouver, British Columbi... more The First Workshop on Aspects in Architectural Description was held in Vancouver, British Columbia as a part of Aspect-Oriented Software Development (AOSD) 2007. This workshop report presents a summary of the topics addressed, contributions and issues raised, and workshop conclusions.
There is much interest in using the Unified Modeling Language (UML) for architectural description... more There is much interest in using the Unified Modeling Language (UML) for architectural description-those techniques by which architects sketch, capture, model, document and analyze architectural knowledge and decisions about software-intensive systems. IEEE P1471, the Recommended Practice for Architectural Description, represents an emerging consensus for specifying the content of an architectural description for a software-intensive system. Like the UML, IEEE P1471 does not prescribe a particular architectural method or life cycle, but may be used within a variety of such processes. In this paper, I provide an overview of IEEE P1471, describe its conceptual framework, and investigate the issues of applying the UML to meet the requirements of IEEE P1471.
Abstract-In this paper, the notion of forces as influences upon architecture decisions is introdu... more Abstract-In this paper, the notion of forces as influences upon architecture decisions is introduced. To facilitate the documentation of forces as a part of architecture descriptions, we specify a decision forces viewpoint, which extends our existing framework for architecture decisions, following the conventions of the international architecture description standard ISO/IEC/IEEE 42010. The applicability of the viewpoint was validated in three case studies, in which senior software engineering students used it to document decisions in software projects; two of which conducted for industrial customers. The results show that the forces viewpoint is a well-received documentation approach, satisfying stakeholder concerns related to traceability between decision forces and architecture decisions.
There is much interest in using the Unified Modeling Language (UML) for architectural description... more There is much interest in using the Unified Modeling Language (UML) for architectural description-those techniques by which architects sketch, capture, model, document and analyze architectural knowledge and decisions about software-intensive systems. IEEE P1471, the Recommended Practice for Architectural Description, represents an emerging consensus for specifying the content of an architectural description for a software-intensive system. Like the UML, IEEE P1471 does not prescribe a particular architectural method or life cycle, but may be used within a variety of such processes. In this paper, I provide an overview of IEEE P1471, describe its conceptual framework, and investigate the issues of applying the UML to meet the requirements of IEEE P1471.
This chapter discusses insights for the harmonization of Software Engineering and Systems Enginee... more This chapter discusses insights for the harmonization of Software Engineering and Systems Engineering practices through the lens of one particular practice area: Architecting. These insights derive from the unity of architecting—the observation that whether one is architecting software, or systems, or enterprises, there is an essence which these endeavors share. This essence is elucidated through a case study of ISO/IEC/IEEE 42010:2011, the international standard for Architecture Description (originally IEEE 1471:2000) in the form of lessons learned from the development and use of that Standard over the past 15 years. These lessons are then applied more generally to Software and Systems Engineering. I focus on two areas: the role of first-class concerns as a unifying dimension in the engineering of any complex system; and on the need for knowledge mechanisms, of which methods and practices are one form, to enable continuing progress to be made. I demonstrate this by sketching how Es...
It is commonly agreed that an architectural description (AD) consists of multiple views. Each vie... more It is commonly agreed that an architectural description (AD) consists of multiple views. Each view describes the architecture from the perspective of particular stakeholder concerns. Although views are constructed separately, they are related as they describe the same system. A thorough study of the literature reveals that research on relations between views is fragmented and that a comprehensive study is hampered by an absence of common terminology. This has become apparent in the discussion on interview relational concepts in the revision of IEEE 1471 as ISO/IEC 42010 (Systems and Software Engineering-Architectural Description). This paper puts forward a framework that employs a consistent terminology to characterize relations between views. The framework sheds light on the usage, scope and mechanisms for relations, and is illustrated using several representative approaches from the literature. We conclude with a reflection on whether the revision of ISO 42010 aligns with our findings.
Proceedings of ICECCS '96: 2nd IEEE International Conference on Engineering of Complex Computer Systems (held jointly with 6th CSESAW and 4th IEEE RTAW)
The Architecture Planning Group (APG) was chartered by IEEE's Software Engineering Standards Comm... more The Architecture Planning Group (APG) was chartered by IEEE's Software Engineering Standards Committee to set a direction for incorporating architectural thinking into IEEE standards. In this paper, we present a framework for architectural thinking and use it to review existing architectural practices; summarize the work of the APG and its recommendations; and provide the rationale for those recommendations.
Although primarily studied in the context of product lines, vari-ability is a key fact about most... more Although primarily studied in the context of product lines, vari-ability is a key fact about most systems and therefore a concern for the architectures of those systems. Thus it is essential for the Archi-tect to have suitable tools for representing, managing and reasoning about variation. Most work on product line variation has focused on the variability of components and their connectors within an archi-tecture. Meanwhile, Architects today often use multiple viewpoints to frame diverse stakeholders ’ concerns for an architecture. How can variation be expressed within the representational paradigm of multiple viewpoints? This paper uses a simplified model of vari-ation reflecting current practice and explores the consequences of that model for the representation of variation as a part of archi-tecture description, using the conceptual foundation of ISO/IEC 42010 (the revision of IEEE 1471:2000) and poses a number of questions for discussion at the VARI-ARCH workshop.
If architecture representation is the problem (P), and the UML is the solution (S), how do we get... more If architecture representation is the problem (P), and the UML is the solution (S), how do we get from P to S? In this paper, I introduce the idea of viewpoint modeling as a part of the answer. A viewpoint, as defined in IEEE 1471, defines a set of architectural concerns and the resources needed to address those concerns. A viewpoint gives an architect the resources with which to construct an architectural view. These resouces may include notations, techniques, and guidance. Viewpoint modeling is then a kind of metamodeling to bundle up useful sets of modeling resources for the architect. The main result of this paper is a proposed template for documenting viewpoints. I then conclude with some observations relating this to the UML.
An ISO/IEC 42010 (IEEE Std 1471) Annotated Bibliography version 1.2
This is an annotated bibliography of papers, reports and books pertaining to ANSI/IEEE Std 1471 (... more This is an annotated bibliography of papers, reports and books pertaining to ANSI/IEEE Std 1471 (now also published as international standard ISO/IEC 42010). It was originally prepared for ISO/IEC JTC 1/SC 7 WG 42, the Architecture working group of the Systems and Software Engineering Subcommittee of ISO. WG 42 is the body performing the joint ISO and IEEE revision of IEEE 1471 as ISO/IEC 42010. Pertaining to includes documents which were inspirations for IEEE 1471, citations of IEEE 1471, and documents inspired by IEEE 1471. In some cases, the relationship is provided in the annotations. Please send any additions or corrections to the author at [email protected].
Successful Architecting in-the-large, namely across various architecture genres and domains of ap... more Successful Architecting in-the-large, namely across various architecture genres and domains of application, will require Architecture Description in-the-large. This position paper addresses the issues of the workshop from insights of Architecture Description, as those ideas have evolved from Software Architecture. It is a heretical or minimalist approach maintaining that for the most part Architecting is Architecting, and that the differences across domains and genres derive from the key architectural drivers, namely: Stakeholders and Concerns. In that context, I further argue what is needed to better address stakeholder and concerns in context.
Assessing Migration of a 20-Year-Old System to a Micro-Service Platform Using ATAM
2019 IEEE International Conference on Software Architecture Companion (ICSA-C), 2019
Architecture evaluation is a systematic approach to evaluate target architectures and ATAM (Archi... more Architecture evaluation is a systematic approach to evaluate target architectures and ATAM (Architectural Trade-off Analysis Method) is one of the available methods. Migration of software systems imply many architectural decisions that should be systematically evaluated to assess concrete trade-offs and risks. This article reports on the ATAM usage at a mid-size Chilean specialty software development company to assess the migration of its 20-year old flagship product to a micro-service platform. Over three days, 10 key architectural decisions, addressing 35 scenarios, were considered. Since almost all requirements were deemed essential for legal reasons, the evaluation scheme used a modified importance dimension distinguishing among business-key (first line deal breakers), legally-mandated (second-line deal breakers), and desirable requirements. Key lessons learned include the very positive client feedback on the introduction of systematic evaluation of architectural choices using b...
2017 IEEE 30th Conference on Software Engineering Education and Training (CSEE&T), 2017
The IEEE Computer Society's Guide to the Software Engineering Body of Knowledge (SWEBoK) has ... more The IEEE Computer Society's Guide to the Software Engineering Body of Knowledge (SWEBoK) has been an authoritative basis for software engineering since 2004. It also has served as a foundation for other developments including curriculum development, training, software engineering competence definitions, and licensing and certification. SWEBoK is current being updated through the SWEBoK Evolution effort. This panel session will provide an update and status of the SWEBoK Evolution and its related efforts.
Empirical Bounds of Multicore Cache Interference for Real-Time Schedulability Analysis
Multicore processors offer significant advantages of weight, power, and space to embedded real-ti... more Multicore processors offer significant advantages of weight, power, and space to embedded real-time developers, making their adoption almost inevitable. Also, system sustainability and economies of scale will increasingly make multicore devices indispensable. However, predictability of performance, specifically, establishing realistic upper bounds on execution time for schedulability analysis is a significant challenge to certification. This paper describes a methodology for empirically establishing a reasonable, high-confidence upper bound for cache interference effects in the context of engineering practices commonly used in certifiable real-time systems.
♦ Define direction for incorporating architectural thinking into IEEE standards♦ Take a “wide sco... more ♦ Define direction for incorporating architectural thinking into IEEE standards♦ Take a “wide scope” interpretation of architecture as applicable to software-intensive systems♦ Establish a conceptual framework and vocabulary for talking about architectural issues of systems♦ ...
This paper examines the central role of an architecture framework within the larger endeavour of ... more This paper examines the central role of an architecture framework within the larger endeavour of the architecting of enteprises, systems-of-systems and complex systems. The paper presents lessons learned from the development and use of IEEE 1471:2000, Recommended Practice for Architectural Description of Software-intensive Systems and its successor, ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description. The lessons learned address areas including: modeling and notations, method and process definition, and tooling, with recommendations for the continued evolution of the NATO Architecture Framework. 1 Background IEEE 1471:2000, Recommended Practice for Architectural Description of Software-intensive Systems, was the first formal standard addressing the architecture of systems, where ''the term system encompasses individual applications , systems in the traditional sense, subsystems, systems of systems, product lines, product families, whole enter...
The First Workshop on Aspects in Architectural Description was held in Vancouver, British Columbi... more The First Workshop on Aspects in Architectural Description was held in Vancouver, British Columbia as a part of Aspect-Oriented Software Development (AOSD) 2007. This workshop report presents a summary of the topics addressed, contributions and issues raised, and workshop conclusions.
There is much interest in using the Unified Modeling Language (UML) for architectural description... more There is much interest in using the Unified Modeling Language (UML) for architectural description-those techniques by which architects sketch, capture, model, document and analyze architectural knowledge and decisions about software-intensive systems. IEEE P1471, the Recommended Practice for Architectural Description, represents an emerging consensus for specifying the content of an architectural description for a software-intensive system. Like the UML, IEEE P1471 does not prescribe a particular architectural method or life cycle, but may be used within a variety of such processes. In this paper, I provide an overview of IEEE P1471, describe its conceptual framework, and investigate the issues of applying the UML to meet the requirements of IEEE P1471.
Abstract-In this paper, the notion of forces as influences upon architecture decisions is introdu... more Abstract-In this paper, the notion of forces as influences upon architecture decisions is introduced. To facilitate the documentation of forces as a part of architecture descriptions, we specify a decision forces viewpoint, which extends our existing framework for architecture decisions, following the conventions of the international architecture description standard ISO/IEC/IEEE 42010. The applicability of the viewpoint was validated in three case studies, in which senior software engineering students used it to document decisions in software projects; two of which conducted for industrial customers. The results show that the forces viewpoint is a well-received documentation approach, satisfying stakeholder concerns related to traceability between decision forces and architecture decisions.
There is much interest in using the Unified Modeling Language (UML) for architectural description... more There is much interest in using the Unified Modeling Language (UML) for architectural description-those techniques by which architects sketch, capture, model, document and analyze architectural knowledge and decisions about software-intensive systems. IEEE P1471, the Recommended Practice for Architectural Description, represents an emerging consensus for specifying the content of an architectural description for a software-intensive system. Like the UML, IEEE P1471 does not prescribe a particular architectural method or life cycle, but may be used within a variety of such processes. In this paper, I provide an overview of IEEE P1471, describe its conceptual framework, and investigate the issues of applying the UML to meet the requirements of IEEE P1471.
This chapter discusses insights for the harmonization of Software Engineering and Systems Enginee... more This chapter discusses insights for the harmonization of Software Engineering and Systems Engineering practices through the lens of one particular practice area: Architecting. These insights derive from the unity of architecting—the observation that whether one is architecting software, or systems, or enterprises, there is an essence which these endeavors share. This essence is elucidated through a case study of ISO/IEC/IEEE 42010:2011, the international standard for Architecture Description (originally IEEE 1471:2000) in the form of lessons learned from the development and use of that Standard over the past 15 years. These lessons are then applied more generally to Software and Systems Engineering. I focus on two areas: the role of first-class concerns as a unifying dimension in the engineering of any complex system; and on the need for knowledge mechanisms, of which methods and practices are one form, to enable continuing progress to be made. I demonstrate this by sketching how Es...
It is commonly agreed that an architectural description (AD) consists of multiple views. Each vie... more It is commonly agreed that an architectural description (AD) consists of multiple views. Each view describes the architecture from the perspective of particular stakeholder concerns. Although views are constructed separately, they are related as they describe the same system. A thorough study of the literature reveals that research on relations between views is fragmented and that a comprehensive study is hampered by an absence of common terminology. This has become apparent in the discussion on interview relational concepts in the revision of IEEE 1471 as ISO/IEC 42010 (Systems and Software Engineering-Architectural Description). This paper puts forward a framework that employs a consistent terminology to characterize relations between views. The framework sheds light on the usage, scope and mechanisms for relations, and is illustrated using several representative approaches from the literature. We conclude with a reflection on whether the revision of ISO 42010 aligns with our findings.
Proceedings of ICECCS '96: 2nd IEEE International Conference on Engineering of Complex Computer Systems (held jointly with 6th CSESAW and 4th IEEE RTAW)
The Architecture Planning Group (APG) was chartered by IEEE's Software Engineering Standards Comm... more The Architecture Planning Group (APG) was chartered by IEEE's Software Engineering Standards Committee to set a direction for incorporating architectural thinking into IEEE standards. In this paper, we present a framework for architectural thinking and use it to review existing architectural practices; summarize the work of the APG and its recommendations; and provide the rationale for those recommendations.
Although primarily studied in the context of product lines, vari-ability is a key fact about most... more Although primarily studied in the context of product lines, vari-ability is a key fact about most systems and therefore a concern for the architectures of those systems. Thus it is essential for the Archi-tect to have suitable tools for representing, managing and reasoning about variation. Most work on product line variation has focused on the variability of components and their connectors within an archi-tecture. Meanwhile, Architects today often use multiple viewpoints to frame diverse stakeholders ’ concerns for an architecture. How can variation be expressed within the representational paradigm of multiple viewpoints? This paper uses a simplified model of vari-ation reflecting current practice and explores the consequences of that model for the representation of variation as a part of archi-tecture description, using the conceptual foundation of ISO/IEC 42010 (the revision of IEEE 1471:2000) and poses a number of questions for discussion at the VARI-ARCH workshop.
If architecture representation is the problem (P), and the UML is the solution (S), how do we get... more If architecture representation is the problem (P), and the UML is the solution (S), how do we get from P to S? In this paper, I introduce the idea of viewpoint modeling as a part of the answer. A viewpoint, as defined in IEEE 1471, defines a set of architectural concerns and the resources needed to address those concerns. A viewpoint gives an architect the resources with which to construct an architectural view. These resouces may include notations, techniques, and guidance. Viewpoint modeling is then a kind of metamodeling to bundle up useful sets of modeling resources for the architect. The main result of this paper is a proposed template for documenting viewpoints. I then conclude with some observations relating this to the UML.
An ISO/IEC 42010 (IEEE Std 1471) Annotated Bibliography version 1.2
This is an annotated bibliography of papers, reports and books pertaining to ANSI/IEEE Std 1471 (... more This is an annotated bibliography of papers, reports and books pertaining to ANSI/IEEE Std 1471 (now also published as international standard ISO/IEC 42010). It was originally prepared for ISO/IEC JTC 1/SC 7 WG 42, the Architecture working group of the Systems and Software Engineering Subcommittee of ISO. WG 42 is the body performing the joint ISO and IEEE revision of IEEE 1471 as ISO/IEC 42010. Pertaining to includes documents which were inspirations for IEEE 1471, citations of IEEE 1471, and documents inspired by IEEE 1471. In some cases, the relationship is provided in the annotations. Please send any additions or corrections to the author at [email protected].
Successful Architecting in-the-large, namely across various architecture genres and domains of ap... more Successful Architecting in-the-large, namely across various architecture genres and domains of application, will require Architecture Description in-the-large. This position paper addresses the issues of the workshop from insights of Architecture Description, as those ideas have evolved from Software Architecture. It is a heretical or minimalist approach maintaining that for the most part Architecting is Architecting, and that the differences across domains and genres derive from the key architectural drivers, namely: Stakeholders and Concerns. In that context, I further argue what is needed to better address stakeholder and concerns in context.
Assessing Migration of a 20-Year-Old System to a Micro-Service Platform Using ATAM
2019 IEEE International Conference on Software Architecture Companion (ICSA-C), 2019
Architecture evaluation is a systematic approach to evaluate target architectures and ATAM (Archi... more Architecture evaluation is a systematic approach to evaluate target architectures and ATAM (Architectural Trade-off Analysis Method) is one of the available methods. Migration of software systems imply many architectural decisions that should be systematically evaluated to assess concrete trade-offs and risks. This article reports on the ATAM usage at a mid-size Chilean specialty software development company to assess the migration of its 20-year old flagship product to a micro-service platform. Over three days, 10 key architectural decisions, addressing 35 scenarios, were considered. Since almost all requirements were deemed essential for legal reasons, the evaluation scheme used a modified importance dimension distinguishing among business-key (first line deal breakers), legally-mandated (second-line deal breakers), and desirable requirements. Key lessons learned include the very positive client feedback on the introduction of systematic evaluation of architectural choices using b...
2017 IEEE 30th Conference on Software Engineering Education and Training (CSEE&T), 2017
The IEEE Computer Society's Guide to the Software Engineering Body of Knowledge (SWEBoK) has ... more The IEEE Computer Society's Guide to the Software Engineering Body of Knowledge (SWEBoK) has been an authoritative basis for software engineering since 2004. It also has served as a foundation for other developments including curriculum development, training, software engineering competence definitions, and licensing and certification. SWEBoK is current being updated through the SWEBoK Evolution effort. This panel session will provide an update and status of the SWEBoK Evolution and its related efforts.
Empirical Bounds of Multicore Cache Interference for Real-Time Schedulability Analysis
Multicore processors offer significant advantages of weight, power, and space to embedded real-ti... more Multicore processors offer significant advantages of weight, power, and space to embedded real-time developers, making their adoption almost inevitable. Also, system sustainability and economies of scale will increasingly make multicore devices indispensable. However, predictability of performance, specifically, establishing realistic upper bounds on execution time for schedulability analysis is a significant challenge to certification. This paper describes a methodology for empirically establishing a reasonable, high-confidence upper bound for cache interference effects in the context of engineering practices commonly used in certifiable real-time systems.
Uploads
Papers by Rich Hilliard