首页> 外文OA文献 >Applying of component system development in object methodology
【2h】

Applying of component system development in object methodology

机译:应用组件系统开发在对象方法中的应用

代理获取
本网站仅为用户提供外文OA文献查询和代理获取服务,本网站没有原文。下单后我们将采用程序或人工为您竭诚获取高质量的原文,但由于OA文献来源多样且变更频繁,仍可能出现获取不到、文献不完整或与标题不符等情况,如果获取不到我们将提供退款服务。请知悉。

摘要

In the last three decades, the concept and implementation of component-based architectures have been promoted in software systems creation. Increasingly complex demands are placed on the software component systems, in particular relating to the dynamic properties. The emergence of such requirements has been gradually enforced by the practice of development and implementation of these systems, especially for information systems software.Just the information systems (robust IS) of different types require that target software meets their requirements. Among other things, we mean primarily the adaptive processes of different domains, high distributives due to the possibilities of the Internet 2.0, acceptance of high integrity of life domains (process, data and communications integrity), scalability, and flexible adaptation to process changes, a good context for external devices and transparent structure of the sub-process modules and architectural units.Of course, the target software of required qualities and the type robust cannot be a monolith. As commonly known, development of design toward information systems software has clearly come to the need for the software composition of completely autonomous, but cooperating architectural units that communicate with each other using messages of prescribed formats.Although for such units there were often used the so called subsystems and modules, see (Jac, Boo, Rumbo, 1998) and (Arlo, Neus, 2007), their abstraction being gradually enacted as the term component. In other words, the subsystems and modules are specific types of components.In (Král, Žeml, 2000) and (Král, Žeml, 2003) there are considered two types of target software of information systems. The first type – there are SWC (Software Components), composed of permanently available components, which are thought as services – Confederate software. The second type – SWA (Software Alliance), called semi Confederate, formed during the run-time of the software system and referred to as software alliance.In both of these mentioned publications there is delivered ​​deep philosophy of relevant issues relating to SWC / SWA as creating copies of components (cloning), the establishment and destruction of components at software run-time (dynamic reconfiguration), cooperation of autonomous components, programmable management of components interface in depending on internal components functionality and customer requirements (functionality, security, versioning).Nevertheless, even today we can meet numerous cases of SWC / SWA existence, with a highly developed architecture that is accepting vast majority of these requests. On the other hand, in the development practice of component-based systems with a dynamic architecture (i.e. architecture with dynamic reconfiguration), and finally with a mobile architecture (i.e. architecture with dynamic component mobility) confirms the inadequacy of the design methods contained in UML 2.0. It proves especially the dissertation thesis (Rych, Weis, 2008). Software Engineering currently has two different approaches to systems SWC / SWA. The first approach is known as component-oriented software development CBD (Component based Development). According to (Szyper, 2002) that is a collection of CBD methodologies that are heavily focused on the setting up and software components re-usability within the architecture. Although CBD does not show high theoretical approach, nevertheless, it is classified under the general evolution of SDP (Software Development Process), see (Sommer, 2010) as one of its two dominant directions.From a structural point of view, a software system consists of self-contained, interoperable architectural units – components based on well-defined interfaces. Classical procedural object-oriented methodologies significantly do not use the component meta-models, based on which the target component systems are formed, then. Component meta-models describe the syntax, semantics of components. They are a system of rules for components, connectors and configuration. Component meta-models for dynamic and mobile architectures also describe the concept of rules for configuration changes (rules for reconfiguration). As well-known meta-models are now considered: Wright for static architecture, SOFA and Darvin for dynamic architecture and SOFA 2.0 for mobile architecture, see (Rych, Weis, 2008).The CBD approach verbally defines the basic terms as component (primitive / composite), interface, component system, configuration, reconfiguration, logical (structural) view, process view (behavioral), static component architecture, dynamic architecture, mobile architecture (fully dynamic architecture), see (IEEE Report, 2000) and (Crnk, Chaud, 2006).The CBD approach also presents several ​​ADL languages (Architecture Description Languages) which are able to describe software architecture. The known languages ​​are integration ACME and UML (Unified Modeling Language), see (Garl, Mon, Wil, 2000) and (UNIFEM, 2005).The second approach to SWC / SWA systems is formed on SOA, but this article does not deal with it consistently.SOA is a philosophy of architecture. SOA is not a methodology for the comprehensive development of the target software. Nevertheless, SOA successfully filled the role of software design philosophy and on the other hand, also gave an important concept linking software components and their architectural units – business services. SOA understands any software as a Component System of a business service and solved life components in it. The physical implementation of components is given by a Web services platform. A certain lack of SOA is its weak link to the business processes that are a universally recognized platform for business activities and the source for the creation of enterprise services.This paper deals with a specific activity in the CBD, i.e. the integration of the concept of component-based system into an advanced procedural, object-oriented methodology (Arlo, Neust, 2007), (Kan, Müller, 2005), (​​Krutch, 2003) for problem domains with double-layer process logic. There is indicated an integration method, based on a certain meta-model (Applying of the Component system Development in object Methodology) and leading to the component system formation. The mentioned meta-model is divided into partial workflows that are located in different stages of a classic object process-based methodology. Into account there are taken the consistency of the input and output artifacts in working practices of the meta-model and mentioned object methodology. This paper focuses on static component systems that are starting to explore dynamic and mobile component systems.In addition, in the contribution the component system is understood as a specific system, for its system properties and basic terms notation being used a set and graph and system algebra.
机译:在过去的三年中,基于组件的体系结构的概念和实现在软件系统创建中得到了推广。对软件组件系统提出了越来越复杂的要求,尤其是与动态特性相关的要求。这种需求的出现,已经被这些系统的开发和实现实践所逐渐强化,尤其是信息系统软件。只是不同类型的信息系统(鲁棒IS)要求目标软件满足其需求。其中,我们主要指的是不同领域的适应性过程,由于 Internet 2.0 的可能性而产生的高分配性,对生命领域(过程、数据和通信完整性)的高度完整性的接受、可扩展性以及对过程变化的灵活适应,外部设备的良好上下文以及子流程模块和架构单元的透明结构。当然,所需质量和类型健壮的目标软件不能是单体。众所周知,针对信息系统软件的设计开发显然需要完全自主但协作的架构单元的软件组合,这些架构单元使用规定格式的消息相互通信。称为子系统和模块,参见 (Jac, Boo, Rumbo, 1998) 和 (Arlo, Neus, 2007),它们的抽象被逐渐制定为术语组件。换句话说,子系统和模块是特定类型的组件。在 (Král, Žeml, 2000) 和 (Král, Žeml, 2003) 中,考虑了两种类型的信息系统目标软件。第一种类型——SWC(软件组件),由永久可用的组件组成,被认为是服务——同盟软件。第二种——SWA(软件联盟),称为半联盟,在软件系统运行期间形成,简称软件联盟。在这两篇提到的出版物中,都传达了与SWC相关的相关问题的深刻哲学/ SWA 作为创建组件的副本(克隆)、在软件运行时建立和销毁组件(动态重新配置)、自主组件的协作、组件接口的可编程管理取决于内部组件功能和客户要求(功能、安全性) ,版本控制)。尽管如此,即使在今天,我们仍然可以遇到许多 SWC/SWA 存在的情况,高度发达的架构接受了这些请求中的绝大多数。另一方面,在基于组件的系统的开发实践中,具有动态架构(即具有动态重新配置的架构),最终具有移动架构(即具有动态组件移动性的架构)证实了 UML 中包含的设计方法的不足2.0.它尤其证明了论文 (Rych, Weis, 2008)。软件工程目前有两种不同的方法来处理系统 SWC/SWA。第一种方法被称为面向组件的软件开发 CBD(基于组件的开发)。根据 (Szyper, 2002),这是一个 CBD 方法论的集合,这些方法论重点关注架构内的设置和软件组件的可重用性。虽然 CBD 没有表现出高深的理论方法,但它被归类在 SDP(软件开发过程)的一般演化之下,参见(Sommer,2010)作为其两个主导方向之一。 从结构的角度来看,一个软件系统由独立的、可互操作的架构单元组成——基于定义明确的接口的组件。经典的过程面向对象方法明显不使用组件元模型,然后基于该组件元模型形成目标组件系统。组件元模型描述组件的语法和语义。它们是组件、连接器和配置的规则系统。动态和移动架构的组件元模型还描述了配置更改规则(重新配置规则)的概念。现在考虑众所周知的元模型:Wright 用于静态架构,SOFA 和 Darvin 用于动态架构,SOFA 2.0 用于移动架构,参见 (Rych, Weis, 2008)。CBD 方法将基本术语口头定义为组件(原始/复合),接口,组件系统,配置,重新配置,逻辑(结构)视图,过程视图(行为),静态组件架构,动态架构,移动架构(完全动态架构),见(IEEE报告,2000)和(Crnk , Chaud, 2006。CBD 方法还提供了几种能够描述软件架构的 ADL 语言(架构描述语言)。已知的语言有整合 ACME 和 UML(Unified Modeling Language),见 (Garl, Mon, Wil, 2000) and (UNIFEM, 2005)。第二个 SWC/SWA 系统的方法是在 SOA 上形成的,但本文并没有始终如一地处理它。SOA 是一种架构哲学。 SOA 不是一种全面开发目标软件的方法论。尽管如此,SOA 成功地填补了软件设计哲学的角色,另一方面,也给出了一个重要的概念,将软件组件与其架构单元联系起来——业务服务。 SOA 将任何软件理解为业务服务的组件系统,并解决了其中的生命组件。组件的物理实现由 Web 服务平台提供。 SOA 的一定缺乏是它与业务流程的薄弱环节,而业务流程是公认的业务活动平台和创建企业服务的源泉。 本文涉及 CBD 中的一个特定活动,即概念的集成。将基于组件的系统转化为高级程序化、面向对象的方法 (Arlo, Neust, 2007), (Kan, Müller, 2005), (Krutch, 2003) 用于具有双层流程逻辑的问题域。提出了一种基于某种元模型(对象方法论中构件系统开发的应用)并导致构件系统形成的集成方法。提到的元模型分为部分工作流,这些工作流位于经典的基于对象过程的方法的不同阶段。考虑到元模型和所提到的对象方法的工作实践中输入和输出工件的一致性。本文侧重于开始探索动态和移动组件系统的静态组件系统。代数。

著录项

相似文献

  • 外文文献
  • 中文文献
  • 专利
代理获取

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号