培训私人教练On the Notions of Abstraction, Consistency, and Design
in the ODP Framework of Viewpoints
Kazi Farooqui, Luigi Logrippo,
Department of Computer Science,
University of Ottawa,cost的用法
Ottawa K1N 6N5, Canada.
(Internet: farooqui|luigi@csi.uottawa.ca)
Abstract
One of the most fundamental systems analysis and design principle is that of “abstraction”. Esntially, the purpo of abstraction is to clarify or highlight some features of a problem by concealing others. The t of viewpoints identified in the ODP architecture is merely a pragmatic classification of concerns. A viewpoint leads to a reprentation of the system with emphasis on a specific t of concer
ns, and the resulting repren-tation is an abstraction of the system, i.e., a description which recognizes some distinctions that are relevant to the concern and ignores others. The viewpoint models exhibit very subtle concepts with respect to the notion of abstraction and consistency between them. They offer a very powerful structuring paradigm suitable for a design activity. In this paper we explore the notion of abstraction, consistency between viewpoint mod-els, and the role of viewpoint models in the design process framework. The correct understanding of the rela-tionship between viewpoint models and their role in design activity is crucial for the construction of ODP development tools.
Keywords: Viewpoint modelling, enterpri model, information model, computational model, engineering model, technology model, viewpoint consistency, design process framework.
1.0 Viewpoint Model: System Abstraction
Different abstract models of a (distributed) system are appropriate from different viewpoints. In order to man-age the complexity involved, it is necessary to consider a system from different viewpoints, rather than attempt to capture the whole picture at once [1,2]. Each viewpoint focus on different concerns (or aspects) of the system; the whole picture is the summation of different viewpoints.
The ODP viewpoints should not be en as architectural layers, but rather as different abstractions of the same system, and should all be ud to completely analyze the system. With this approach, consistent and complete system models may be described and developed bad on concepts and methods still to be designed for individual view-points.
Specifying a distributed system in each of the viewpoints allows an otherwi large and complex specification of a (distributed) system to be parated into manageable pieces, each focusd on the issues relevant to different mem-bers of the design team.
2.0 Abstraction Principle in the ODP Framework of Viewpoints
A viewpoint is not necessarily an abstraction of another and there is no hierarchy (or layering) between view-points. However, each viewpoint in some way or the other acknowledges the concerns expresd in other viewpoints but with a lesr emphasis (or detail) [3]. For example, the interaction between application components can be dis-cusd in veral viewpoints. In a particular viewpoint, the detail of interactions between objects is simultaneously incread and decread. There is a more detailed description of the interaction in the terminology lected for that viewpoint. There will be a less detailed description of interaction in the terminology lected for all other viewpoints. In ter
ms of type systems [4,5], this detail is reduced to a single name for each viewpoint. This name is taken to stand for the attributes of objects in a viewpoint other than the one currently considered [6].
In the computational viewpoint, for example, it is not possible to elaborate on the names that stand for attributes of objects that are discusd in other viewpoints [6]. For instance, the attributes of engineering objects (which enable, regulate, and hide distribution) are treated in the computational model as abstractions of the distribution (interaction) requirement between application components.
Each viewpoint-model is lf-contained and complete. The difference between the models is not how much of the system they describe, but rather what aspects of the system they emphasize.
3.0 Viewpoint Languages
The Reference Model of ODP [7,8,9,10] defines a t of five viewpoint models and then identifies key generic functions which are related to the models. A t of concepts,structures, and rules, is given for each of the view-points, providing a “language” for the specification of the system in that viewpoint [9].
The specification of a (distributed) system in any viewpoint is bad on the concepts of that viewpoin
t and satis-fies the structuring rules specified for the viewpoint. For example, the computational language is bad on the con-cepts of activity, operations, environment constraints, computational interface, computational object, etc. and contains the structuring rules such as interface binding rules, interface subtyping rules, invocation rules, activity rules, portability rules, etc. [9].
Any existing language can, in principle, be ud for specification of a system from a particular viewpoint pro-vided that tho specifications can be interpreted in terms of relevant viewpoint concepts. What is required is to map the viewpoint-specific concepts and rules onto the formal syntax and mantics of the language.
Since ODP viewpoints are ud to model different aspects of a distributed system, the language requirements for modelling the concerns in different viewpoints vary considerably from one viewpoint to another.
It is desirable to u a single formal language for the specification of all the viewpoint models. This would facili-tate transformations and consistency checks between viewpoints to be developed within the single framework of the mantic model of the language. However, it is interesting to note that different modelling techniques are required to reprent the specific system view in each of the view
points. This means that the whole system is described by the integrated view of the different viewpoints and therefore, by different models.
This approach immediately points to another important aspect that needs further investigation and studies: the definition of a methodology that allows to correlate the objects defined by means of different techniques in different viewpoints in order to make consistent the overall system model.
4.0 Consistency between Viewpoints
As mentioned before, a single model of a (distributed) system would be overwhelming in complexity. Therefore, we need a way to parate concerns such that we can check consistency between alternate specifications of the same system. Hence, the viewpoint concept - each viewpoint looks at the whole system, but us modelling concepts spe-cific to a defined subt of modelling concerns.
Viewpoint specifications correspond to alternate views of the same system. Since each viewpoint encompass the whole system, we can asrt consistency (between viewpoints) by identifying matching terms (concepts) in the corresponding viewpoint specifications.
polo是什么意思A concept in a viewpoint may be reprented by multiple concepts in another viewpoint; similarly multiple con-cepts in a viewpoint may be reprented by a single (or fewer) concept(s) in another viewpoint. Additionally, con-cepts in one viewpoint (specification) may be abstractions or refinements of concepts in another.
Any complete specification of a system should include not only the viewpoint specifications but also t
he map-ping between them.
Although different viewpoints address different concerns, there is a common ground between them. The frame-work of viewpoints must treat this common ground consistently, in order to relate viewpoint models and to make it possible to asrt correspondence between the reprentations of the same system in different viewpoints. As men-tioned in [11], achieving consistency may not be an easy job. Changes to requirements in one of the viewpoint models may require adapting requirements in other models. Moreover, the required adaptations may be quite complex; it is desired to define transformations such that minimal changes to other viewpoint models are necessitated as a result of a change in one of the models.
It may be noted that the viewpoint models are both a source of requirements and constraints on the design of a (distributed) system, and any changes to one of the models affects the specifications in other models. Although it may be argued that enterpri and information viewpoints are a source of design requirements, and computational, engineering, and technology viewpoints are a source of constraints on the system design, the design requirements and constraints originate from across all viewpoint models (albeit to different degree). The issue is identifying the require-ments and constraints in all viewpoints and satisfying them in the system design. The design template may be s
een as a unification of (and consistent with) all the viewpoint models.
As mentioned in [12], the viewpoint models have a direct impact on the design. The more the prescription in the enterpri and information specification, the less freedom of interpretation of desig
n requirements. Similarly, the more the prescription in computational, engineering, and technology specification, the less freedom the design has in its choice of components and their configuration.
Specifications from different viewpoints may be checked for consistency (by applying some transformations) in order to ensure that incompatible or otherwi contradictory requirements are not placed in individual viewpoint models.
Formally, one can identify the relationship or consistency constraints that must be satisfied to demonstrate that a specification of a (distributed) system in one viewpoint language is consistent with the specification of the same (dis-
tributed) system in other viewpoint languages. The consistency rules specify valid transformations of a specification in one viewpoint to a specification in another.
The consistency constraints ensure that the specification of the system in different viewpoints are not in conflict with respect to the structuring rules of the corresponding viewpoints. However, consistency constraints are not suffi-cient to ensure exact equivalence of the specifications. As stated in [9], equivalence is not decidable, in general, since to do so requires the validation of asrtions relating to the meaning of concepts (terms) in each specification.
5.0 Viewpoint Modelling
This ction prents a brief and informal review of what is involved in viewpoint modelling before dwelling into the issue of their u in system design. It is apparent that viewpoints can be thought of as constituencies of concerns involved in the system specification process. The system specification concerns that are addresd in the individual viewpoints are outlined below. It is not intended to give a ‘formal’ treatment to the concepts that ari in a viewpoint. Instead individual concerns specific to a viewpoint are itemized1 in order to relate them in inter-viewpoint consis-tency exerci performed in ction 7.
5.1 Enterpri Modelling: The enterpri modelling deals with the objectives of the system. The main concerns addresd in the enterpri modelling are:
(Purpo + Scope + Role + Policies + Obligation) of SYSTEM
Enterpri Modelling allows us to make statements such as:
ER1: What is the purpo of the system (or its components) in the enterpri.
tigerER2: What is the scope of the system (or its components) in the enterpri.
ER3: What is the role of the system (or its components) in the enterpri.
ER4: What policies are associated to the system (or its components) in the enterpri.
ER5: What are the obligations of the system (or its components) in the enterpri.
ER6: What are the distribution requirements of the system (or its components).
ER7: What are the interactions between the system and its environment.
ER8: What are the application-specific requirements of the enterpri from the system.
The enterpri specification is compod of a combination of the kinds of statements. The statements are made with respect to the system or its components, called enterpri objects. The specification from this viewpoint captures requirements that justify and orient (impact) the design of the system. The enterpri specification is at the most abstract level of detail suitable for reprenting ur concerns and requirements.
5.2 Information Modelling: The information modelling deals with aspects related to information content of the enterpri. The concerns addresd in the information viewpoint are:
Identification of (Information Objects + Quality Attributes of Information Objects + Manipulations on Information Objects + Rules/constraints for Information manipulation + Relationship between Information Objects + Semantics of information stored and exchanged between components + Information Flows) of SYSTEM.
奥斯卡 2017
ambrosiaInformation objects are information elements or structures of information. Information objects define the subt of the information content of the enterpri.
The specification of the system from the information viewpoint consists of the following statements:
IN1: What are the information objects of the system.
IN2: What are the quality attributes of the information objects of the system.
IN3: What manipulations/processing can be performed on the information objects of the system.
IN4: What are the rules and constraints for information manipulation
IN5: What is the relationship between information objects.
IN6: What mantics a human would associate with the information stored in and exchanged between information
1. Although, some of the items their scope, the intention is to relate them with the concerns in
other viewpoint(s).
objects.
IN7: What are the sources, sinks, and information flows in the system.
5.3 Computational Modelling: The computational modelling deals with the functional decomposition of the system into components, called computational objects, which are candidates for distribution and identification of interactions between the components. It consists of:
Identification of (Computational Objects + Activities that occur within Computational Objects + Interfaces of Com-putational Objects + Operations of Computational Interfaces + Behavior obrvable at Computational Interface + Role of Computational Interfaces + Environment Constraints associated with Computational Objects and their Inter-faces + Interactions between Com
putational Interfaces) of SYSTEM.
The computational modelling activity consists of the following concerns:
ongCO1: What are the computational objects of the system.
CO2: What activities occur within the computational objects of the system.
CO3: What are the interfaces of computational objects of the system.
CO4: What operations can be invoked to/from the computational interfaces.
CO5: What behavior is obrvable at the computational interfaces.
CO6: What is the role of the computational interface.
CO7: What environment constraints are associated with the computational objects and their interfaces.
CO8: What interactions are possible between computational objects (interfaces).
5.4 Engineering Modelling: The engineering modelling deals with the infrastructure required to support the system components and interaction between them. It is concerned with:
Identification of (Infrastructure Objects and their configuration required to support the distribution of components) of SYSTEM.
Infrastructure objects are engineering objects which are either obtained from computational objects or provide spe-cific distribution support functionality.
5.5 Technology Modelling: The technology modelling is concerned with the identification of technology artifacts to support the system or its components.
6.0 Design Methodology bad on ODP Viewpoints
As mentioned in [13], there are a number of ways to interpret the concept of viewpoints. The basic interpretation of a viewpoint is that of a constituency framework - expression of concerns of different players involved in system development. This ction and the following one prents two alternatives of using viewpoints in a design process framework.丹顶鹤的英文
Although there is no (explicit) ordering or hierarchy between viewpoints, the issue in the design proc
ess frame-work relates to the consistency between viewpoints. The specification in a given viewpoint must reflect the require-ments pod in other viewpoints and not contradict them.
The design process framework is ud to illustrate the relationships that can be identified between viewpoints, and is not intended to suggest that other relationships are unsuitable. The design process interpretation ascribes to each viewpoint a different role in the design process.
Although, as suggested in ction 8, the viewpoints can be ud at all stages of the design of the system in order to ensure consistency between viewpoint specification during the design process, some viewpoints play a predomi-nant role (than other viewpoints) in particular phas of system design. In particular some stages of system design tra-jectory are heavily dependent on the specifications in some viewpoint(s) than others. Of particular importance is the obrvation that some viewpoint specification(s) capture much details of a certain stage of design trajectory than oth-ers.
In particular, the system specification in one viewpoint is bad upon requirements expresd in some other viewpoint(s). This relationship between viewpoints, which is related to the concerns in different phas of system design, is illustrated in figure 3.
瑜伽基本动作
The system design process potentially involves all the viewpoint specifications. One specification may be
responsible for the generation of other specifications through the application of appropriate transformations.
The viewpoints can be ud to structure the specification of a (distributed) system, and can be related to a design methodology. As outlined in [7], design of the system can be regarded as a process that may be subdivided into phas related to different viewpoints. The phas and their relationship to the ODP viewpoints are shown in figure 3.
upon
In the figure, the four major phas in the system design trajectory are considered:requirement capture(and analysis),functional specification, (detail)design,implementation. This corresponds to the three major design steps identified in the classical waterfall model described in [14] and [15]. The phas related to testing and maintenance are not shown. Each of the viewpoints can be ud as problem analysis technique as well as a solution space of the relevant issues of the problem domain.
Apart from their u in the (parallel and) alternate system specification, the u of the viewpoints can be orga-nized to assist the design trajectory from requirements specification to final design and impl
ementation.
1.Requirement capture and analysis: The classical “waterfall” model of the software life cycle [14], [15], begins with requirement analysis and definition pha. According to the model, the system’s rvices, constraints and goals are established, in this pha, by consultation with system urs. This is precily the concern of the enterpri view-point in the ODP framework of viewpoints.
The enterpri view covers the enterpri objectives of an information system. It focus on the requirements, objectives, and the role of the system within the organization. It is the most abstract of the ODP framework of view-points stating high-level enterpri requirements. This allows the designer to develop a clod (i.e., bounded) model which reprents all the real world requirements which the designer must incorporate, later in the design trajectory, into the final realization of the system.
The classical “waterfall” model identifies a single pha corresponding to “system design”. For complex (dis-tributed) systems, it is not possible to achieve an implementable design in a single step from requirement specifica-tion. The ODP framework of viewpoints allows the identification (and specification) of an intermediate design step-the architectural or functional design of the system which is followed by a detailed design of the system.
2.Functional specification (architectural design): This step consists of decomposition of system into functional or architectural components and identification of interconnections between them using the requirement definition as the ba. The interaction requirements of the functional components are identified. This is the domain of the compu-tational viewpoint. The computational specification of the system contains detailed design constraints (reflected in terms of environment constraints associated with computational objects, computational interfaces, and interactions between them). This forms the basis for the detailed system design in the next step.
Apart from functional decomposition, it is also possible to specify the system bad on its information content [16,17,18]. This activity, referred to as information modelling is concerned with the mantics of information, infor-mation processing activities, and information flow in the system. The conceptual decomposition of the system is performed as part of information modelling.
Although the information model does not directly impact the system design process, the computational view-point plays a central role in the design process. While the computational viewpoint helps in the functional decompo-sition of the system, the information viewpoint enables the conceptual decomposition of the system. Together they help in constructing the architectural specification of the system. For example, the information model ascribes meaning to the information
that is exchanged in interactions between functional components identified in the com-putational model.
3.(Detail)design: The detailed design step fills in the gap of the architectural design by completing the design step corresponding to some special system requirements such as distribution of the system. The functional or architec-tural components identified in the previous design step need to interact in order to perform the objectives of the sys-tem identified in the enterpri viewpoint. The components required to support the interactions between architectural components and the configuration of the supporting components are identified in the engineering viewpoint. The functionality of the supporting components is consistent with the requirements of interaction (envi-ronment constraints) between the architectural components identified in the computational view. Moreover the identified architectural components may be decompod, in the final design step, to enable mapping onto an imple-mentable design.
