首页 考试吧论坛 Exam8视线 考试商城 网络课程 模拟考试 考友录 实用文档 求职招聘 论文下载 | ||
2011中考 | 2011高考 | 2012考研 | 考研培训 | 在职研 | 自学考试 | 成人高考 | 法律硕士 | MBA考试 MPA考试 | 中科院 |
||
四六级 | 职称英语 | 商务英语 | 公共英语 | 托福 | 雅思 | 专四专八 | 口译笔译 | 博思 | GRE GMAT 新概念英语 | 成人英语三级 | 申硕英语 | 攻硕英语 | 职称日语 | 日语学习 | 法语 | 德语 | 韩语 |
||
计算机等级考试 | 软件水平考试 | 职称计算机 | 微软认证 | 思科认证 | Oracle认证 | Linux认证 华为认证 | Java认证 |
||
公务员 | 报关员 | 银行从业资格 | 证券从业资格 | 期货从业资格 | 司法考试 | 法律顾问 | 导游资格 报检员 | 教师资格 | 社会工作者 | 外销员 | 国际商务师 | 跟单员 | 单证员 | 物流师 | 价格鉴证师 人力资源 | 管理咨询师考试 | 秘书资格 | 心理咨询师考试 | 出版专业资格 | 广告师职业水平 驾驶员 | 网络编辑 |
||
卫生资格 | 执业医师 | 执业药师 | 执业护士 | ||
会计从业资格考试(会计证) | 经济师 | 会计职称 | 注册会计师 | 审计师 | 注册税务师 注册资产评估师 | 高级会计师 | ACCA | 统计师 | 精算师 | 理财规划师 | 国际内审师 |
||
一级建造师 | 二级建造师 | 造价工程师 | 造价员 | 咨询工程师 | 监理工程师 | 安全工程师 质量工程师 | 物业管理师 | 招标师 | 结构工程师 | 建筑师 | 房地产估价师 | 土地估价师 | 岩土师 设备监理师 | 房地产经纪人 | 投资项目管理师 | 土地登记代理人 | 环境影响评价师 | 环保工程师 城市规划师 | 公路监理师 | 公路造价师 | 安全评价师 | 电气工程师 | 注册测绘师 | 注册计量师 |
||
缤纷校园 | 实用文档 | 英语学习 | 作文大全 | 求职招聘 | 论文下载 | 访谈 | 游戏 |
Web Evolution
We all experience that web application undergo very fast evolution, driven by the requirements to continously update content, and to take up latest technological options. Unfortunately, resources are a poor abstraction in the course of evolution, as modifications are seldomly localized in single resources. Rather, evolution effects concepts as described in the sections above, for example structural concepts composed of fragments that are embedded in a number of resources, or general concepts mapped to a range of specific code fragments.
In the following section we describe an object-oriented model, WebComposition[6], for engineering webs, addressing issues of maintainability in general and hypertext structures in particular. After introduction of the model, we briefly describe its implementation in the WebComposition system which maintains the model throughout the life cycle and links it to the actual web by means of automatic and incremental resource generation.
The WebComposition Model
In WebComposition, web entities are modeled as component objects with a state and a set of operations specifying the component behavior. Components can model web entities of arbitrary granularity. A component may for example model entities as small as individual links, anchors or other resource fragments. Of course, a component may also be associated with a complete resource, for instance an HTML page or a Perl Script generating an HTML page. A component may even model a group of resources, for example modelling a dialog sequence implemented in a number of interlinked forms.
Components can reference other components to model aggregation (has-part) or specialization (inherits-from). For example, a component modeling a page could reference components modelling parts of the page; a component modeling a navigation structure could reference components modeling involved links and anchors. By means of a dedicated reference type, components can reference prototype components from which they inherit state and behavior (WebComposition is based on a prototype-instance OO model, cf. [7], as opposed to a class-oriented OO model which we considered too heavy). Components may be abstract, i.e. function only as prototype for specific components. Abstract components are one means to realize code sharing among objects. Another means for code sharing is to allow multiple references on the same component, e.g. for a component modeling an HTML fragment that is replicated in multiple HTML pages. Sharing is fundamental not only for reuse but also for maintainability as it helps keeping modifications local.
Components are defined by state and behavior. The state is defined by a list of typed properties (name-value-pairs). For example, a component modeling an HTML element would have properties relating to that element's attributes. The behavior is defined by a set of operations. All components have to provide operations getProperties, setProperties and generateCode.
The first two operations realize read respectively write access for manipulation of component state. Together, they implement the persistence service of a component, serialising/deserialising component state for persistent storage in the Component Store (cf. next section).
The generateCode operation implements the presentation service of a component, mapping its state to a representation in the web, for instance a mapping to HTML code. The relationship between component and its web representations is a model-view-relationship. For primitive components, for instance a chunk of text, this mapping is straightforward, and the operation can be thought of as consisting of a simple print statement. For composite components the mapping involves delegation of mapping to its children components. For simple composites such as a list, generateCode could simply iterate over its children, invoking their respective operations. In more complex cases, for instance tables, the composite has to generate its own code in addition to the code of its children.
WebComposition System
The WebComposition system implements the model in a persistent database, the Component Store, maintains controlled access for component manipulation throughout the life cycle through a Component Server, and facilitates the incremental mapping of stored component models to a web implementation by means of a Resource Generator. The system is transparent for the existing web, i.e. it does not require server modifications or the like.
The component store is based on a standard RDBMS, as the prototype-instance model (in contrast to class-oriented OO models) can be mapped in a straightforward way to tables and relationships. Our current implementation is based on Microsoft SQL Server but database-specific code has been kept at a minimum for the sake of portability.
The component server provides access to components through a component access protocol. This protocol is transaction-oriented and supports check-in, checkout, unlock and get operations. Components are uniquely identified through a UUID and a version number. The component server can serve components to any kind of application, for instance to tools for explicit editing of components, to management tools monitoring web applications, or even to the application to which the component belongs. The last case is important as it facilitates application-driven evolution of itself which can for instance be used for customisation of applications.
The component server does not distinguish between instances and prototypes (in fact, there is no such distinction in the model anyway, cf. previous section). The component server though distinguishes between the properties a component defines itself and those properties inherited from other components. It grants read access to all properties but restricts write access to the instance-specific properties. Not yet implemented in the component access protocol but considered is a mutation operations extending write access to inherited properties which after modification become instance properties no longer subject to inheritance.
更多软考资料请访问:考试吧软件水平考试栏目
希望与更多网友交流,请进入考试吧软件水平考试论坛
北京 | 天津 | 上海 | 江苏 | 山东 |
安徽 | 浙江 | 江西 | 福建 | 深圳 |
广东 | 河北 | 湖南 | 广西 | 河南 |
海南 | 湖北 | 四川 | 重庆 | 云南 |
贵州 | 西藏 | 新疆 | 陕西 | 山西 |
宁夏 | 甘肃 | 青海 | 辽宁 | 吉林 |
黑龙江 | 内蒙古 |