1. A Generic Model for Software Architecture 2009.04.14 Yun Sang-hyun Rossak. W. / Kirova. V. / Jolian. L. / Lawson. H. / Zemel. T. Software, IEEE Jul/Aug 1997

2. Introduction  complex systems require an especially high level of coordination and integration.  The IEEE ECBS TC has developed a specification for the ECBS model’s architecture constituent and published its preliminary results.  building upon the ECBS work by further refining the existing characterization of the ECBS architecture element into a generic framework  the Generic Systems Integration Framework (GenSIF) ※ IEEE ECBS TC : IEEE Engineering of Computer-Based Systems Technical Committee 2

3. ECBS model  identifies the major artifacts and their interrelationships in computer-based systems development 3

4. GenSIF (1/3)  Purpose –to help developers understand software and integration issues in domain-specific, large- scale systems development in a specific business domain.  The basic architectural principle used in GenSIF –a distributed set of independently developed and functioning systems  “building blocks”  Focus –delineating new techniques and artifacts that will assure that independently developed or pre-existing building blocks and systems will interoperate in a large and complex system of systems  3 elements –domain model –domain architecture –infrastructure 4

5. GenSIF (2/3)  Domain model –creates a comprehensive knowledge base and influences the outcome of all development and integration initiatives in the domain  Domain architecture –is a unifying, coherent, multilevel software architecture specification  Infrastructure –uniform development and operations-support environment 5

6. GenSIF (3/3)  To achieve goals –the architecture on an analysis of a comprehensive domain model –the architecture imposes a standardized set of tools and common services that constitute the infrastructure  The domain architecture in GenSIF –a domain-specific design model targeted at systems integration –is specified at two levels  conceptual architecture prescribes the cooperative behavior of the target systems in terms of generic system structures and behaviors but does not include any application-specific elements is specified using a generic architecture reference model  derived application architectures instantiating the generic concepts, rules, and principles defined as application- specific structures and interaction patterns within the conceptual architecture 6

7. Process Model (1/2)  planned-for integration –prepares systems for integration without assuming to know all potential megasystem parts or domain requirements –opposed to approaches such as post-facto integration or pre-facto integration  In trying to keep projects as independent as possible while at the same time coordinating and integration them –two-tiered development  domain level : domain model  project level : requirements  The building blocks derive their design from the domain architecture which provides a standardized infrastructure as a common tool platform 7

8. Process Model (2/2)  The architecture- driven development process used in GenSIF 8

9. Generic Architecture Reference Model  architecture reference model can help us analyze and understand software architectures  generic architecture reference model must be compatible with and integrated into the corresponding development process  a refinement of the current ECBS architecture model  The most important influences on the GenSIF model have been the OSCA architecture and the application machine concept  GenSIF architecture reference model has 2 parts –captures the design rationale(concepts, rules, principles, guidelines) –introduces the architectural elements 9

10. GenSIF’s generic architecture reference model (1/2) 10

11. GenSIF’s generic architecture reference model (2/2)  concepts –include the required system properties and the elements available to build the system that the architecture must support –are decisions about the many different aspects of an architecture  rules –limit the set of possible interactions and structures and impose constraints on how elements may be combined to form systems  principles –list and evaluate useful structures and patterns that help you meet particular needs while staying within the boundaries of concepts and rules  guidelines –provide general hints and techniques to help you stay out of trouble when using concepts, rules, and design principles 11

12. GenSIF’s generic architecture reference model Conceptual elements  Properties –are goal statements derived from the domain characteristics –should be reflected in all systems developed in the domain  Generally, properties are the nonfunctional, quality aspects of systems –However, if the constructive property is both a supporting quality element and a basic concept in the architecture’s characteristics, it can state a more constructive goal  When you specify rules for the architecture, you can further refine the properties –Thus, the architecture can implicitly enforce properties by limiting use of constructive elements to a set of approved structures 12

13. GenSIF’s generic architecture reference model Constructive elements  Components –are the sources of activity and organize a system’s architecture –can come in a variety of types and specializations, such as building blocks, objects, data capsules, filters, subroutines, and tasks  Connectors –facilitate interaction between components and form executable structures –messages, procedure calls, remote procedure calls, buffers, event broadcasts… –In GenSIF,  data-carrying connectors  control-oriented connectors  hybrid forms  Abstraction types –let you handle more complicated architecture model –two relationships  aggregation / decomposition : “Part-Of”  generalization / specialization : “Is-A” 13

14. GenSIF’s generic architecture reference model Rules, principles, and guidelines  Rules –specify constraints on concepts –can be targeted toward the constructive, structural aspect of concepts –can also focus on an architecture’s properties  Concepts and rules are the backbone of an architecture  Principles –describe what is considered to be “good practice” –reduce design effort and guarantee practical solutions of good quality –correspond to software design patterns, in software development  Guidelines –try to anticipate design problems you might encounter within the given set of concepts and rules –are subsumed in the architecture principles, in many cases –are the accumulated knowledge that build up during the actual use of a conceptual architecture –do not exhibit the same technical completeness and rigor as rules and principles 14

15. GenSIF’s generic architecture reference model Architectural elements  Concepts and rules give you a complete specification of a conceptual architecture –They maybe described in natural language or in any suitable formalism –They exhibit a clear focus on system semantics and non-constructive, rule-based characteristic  project designers and tool manufacturers –use the conceptual architecture as a generic template that lets them instantiate their designs –The focus shifts from rule-based thinking to a more constructive thinking (syntax- and notation-oriented view)  Concepts, rules, and principles –are ill-suited for the day-to-day handling of the architecture model –are not intuitive to use  To accommodate a more construction-oriented perception –we suggest providing a representation of the architecture that hides rules and calculus behind an easy-to-use, point-and-click, icon-driven view 15

16. GenSIF’s generic architecture reference model Ontological elements (1/3)  The GenSIF architectural elements serve as a basis for the architecture specification  Architectural elements repeat most of the aspects captured in concepts and rules  These elements form an ontology  This ontology –can help you unify vocabulary, compare alternative, and check for completeness –also had to be capable of modeling a software system’s static and dynamic structure 16

17. GenSIF’s generic architecture reference model Ontological elements (2/3)  building block –autonomous structural primitive of the architecture –representing processing and data management –building blocks and components relate directly to the layering aspect of the reference model –architectural building block adds to the specification given in the conceptual architecture  component –cluster of building blocks or components with defined external behavior  clusters let you map abstraction types(Part-Of, Is-A)  interface is a component abstraction that represents a component’s expected external behavior  contract –set of requirements and constraints on one or more components prescribing a collective behavior –packs all associated properties and rules into one unified architectural element 17

18. GenSIF’s generic architecture reference model Ontological elements (3/3)  scenario –dynamic configuration of architecture components –let you chain many components and contracts together to form complete execution structures that model dynamic system aspects –to store complete design patterns –to show how a thread of execution runs through a complex system 18

19. Conclusion  Proposed reference model for architecture specification and development is organized around a set of aspects that structure concepts and rules  Adding principles and guidelines to the concepts and rules –to give a more complete picture of the architecture –to provide a place to store and communicate successfully applied design patterns and other knowledge related to the architecture  Adding architectural element –step toward a more constructive type of architecture representation  Future work –further refining these concepts and developing a formal specification of the architecture reference model –test ideas in case studies (use OSCA architecture) –developing a prototype architecture editor –testing different tools to learn more about integrating them into a real infrastructure and to learn what typical services an infrastructure must provide 19