Kĩ thuật lập trình - Chapter 17: Architectural support for reuse

Chapter 17Architectural Support for Reuse Page Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse OverviewIndustrial Automation Systems The Motivation for a Platform The ArchitectureDeveloping a Domain Specific Application Page Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse Industrial Automation Systems Highly specialized, independent, and incompatible hardware and software system solutions. A flexible combination of basic hardware and software components, communications infrastructure, and application components. Page Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse The 6-layer Model of a Technical Process Page Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse The Motivation for a Platform Envisioned seamless link between front-end business processes and plant control processes: Motivations for a large global company to invest into the development of a “single” platform. Avoidance of parallel developments in different business segments. Harmonization of the diversity of ‘legacy’ automation platforms acquired through company mergers or resulting from previous parallel developments. Adoption of product line business strategies (i.e. pursuing a system family concept both within and across vertical market segments).Implicit expectation of a reuse payoff.Page Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse The ArchitectureAspectObject, Object Type, Aspect and Aspect Type. Aspect SystemA collection of Aspect Types for a certain context or purpose.Domain-related reuse. AspectSystemObjectSome Aspect-specific software is needed.(binary) Software component; Microsoft COM component following specific rules The basic set of ASOs distributed with the AIP contains functionality for alarming, event handling etc.Page Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse AspectObjectsThe most central type of entity in the modelAspectObjects model physical objectsE.g. a specific valve in a dairy (“FIC 201 Valve”)Does not contain any dataRelated data is carried by its AspectsAspectObjectAspectAspectAspectAspectPage Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse AspectEncapsulates a subset of the data related to an AspectObjectDifferent types of electronic information (e.g. documents)Page Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse Aspect TypesDefines how the data in an Aspect is usedIn a “Mechanical Drawing” Aspect, the data is opened with AutoCadIn a “Maintenance Instructions” Aspect, the data is opened with Acrobat ReaderReuse!Page Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse Aspect Types, cont.Page Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse Object TypesModels the type of an AspectObjectThe type of “FIC 201” is “Valve”Defines what Aspect Types an AspectObject can haveA “Valve” can have a “Mechanical drawing” etc.Reuse!Page Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse Object Types, cont.Page Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse StructuresModels a structureLocation structureFunctional structureBatch structure...Typically, each AspectObject is part of several structuresPage Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse Structures, cont.Page Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse Structures, cont.Location structureEnables browsing through the physical layoutSee what valves are physically connected to a pipeFunctional structureEnables browsing through the functional layoutSee what control units are connected to a valvePage Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse Physical viewClient-server systemFreedom to choose number of serversScalabilityReliabilityFreedom to choose number of servicesPage Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse Physical view, cont.Page Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse Developing a Domain Specific Application Jacobson et al. have introduced the distinction between an application system and a component system: Reusing a single component is usually insufficient. Requires the reuse of a set of components.A set of components must be reused to obtain the alarm handling functionality. Page Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse 4-Layer RepresentationApplication system layer: Offers a coherent set of use cases to some end users. The business-specific: Layer several component systems used by the application engineer.The middleware layer: Independent of particular types of businessGUI builders, database management systems, etc. The system software layer:Operating systems. Indistinct boundaries between itself and middleware.Page Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse AIP Reuse Hierarchy W2kAIP base infrastructureAIP base ASOsproject specific ASOsAIP base Servicesproject specific ServicesAIP built-in admin Aspect Typesproject specific Aspect TypesAIP built-in general-purpose Aspect TypesAIP built-in admin Object Typesproject specific Object TypesAIP built-in general-purpose Object Typesdomain specific Aspect Typesdomain specific Object Typesdomain specific templates and patternsproject specific templates and patternsenablersengineering guidelines and toolsAIP library conceptAIP export/importOT inheritanceAIP export/importAT inheritanceCOM VC++configuration3rd party applicationsPage Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse Some Words of Caution Possible risks:Only relying on a platform, not having a reuse-driven process or product line practice with a top-down and planned approach to reuse will not succeed.Requirements management:Requirements elicitation, prioritisation and trade-offs across products, domains, and organizational units are extremely complex. Bugs in a released version Page Building Reliable Component-based Systems Chapter 17 - Architectural Support for Reuse