三断笛

Architecture-Driven Modernization Knowledge Discovery Meta-Model (KDM) V1.3.pdf KDM is defined via Meta-Object Facility (MOF). KDM determines the interchange format via the XML Metadata Interchange (XMI) by applying the standard MOF to XMI mapping to the KDM MOF model. The interchange format defined by KDM is called the KDM XMI schema. The KDM XMI schema is provided as the normative part of this specification. KDM is a meta-model with a very broad scope that covers a large and diverse set of applications, platforms, and programming languages. Not all of its capabilities are equally applicable to all platforms, applications, or programming languages. The primary goal of KDM is to provide the capability to exchange models between tools and thus facilitate cooperation between tool suppliers to integrate multiple facts about a complex enterprise application, as the complexity of modern enterprise applications involves multiple platform technologies and programming languages. In order to achieve interoperability and especially the integration of information about different facets of an enterprise application from multiple analysis tools, this specification defines several compliance levels thereby increasing the likelihood that two or more compliant tools will support the same or compatible meta-model subsets. This suggests that the meta-model should be structured modularly, following the principle of separation of concerns, with the ability to select only those parts of the meta-model that are of direct interest to a particular tool vendor. Separation of concerns in the design of KDM is embodied in the concept of KDM domains.

目录 第一部分 法律法规 第l章 法律 1.1 大纲要求 1.2 要点详解 1.2.1 《合同法》 1.2.2 《招投标法》 1.2.3 《政府采购法》 1.2.4.《著作权法》 1.3 真题分析 1.4 本章练习 第2章 系统集成法规 2.1 大纲要求 2.2 要点详解 2.2.1 《系统集成企业资质等级评定条件》 2.2.2 《系统集成项目经理资质管理办法》 2.3 真题分析 2.4 本章练习 第3章 软件工程基础标准 3.1 大纲要求 3.2 要点详解 3.2.1 《软件工程术语》GB／T 11457－1995 3.2.2 《信息处理：数据流程图、程序流程图、系统流程图、程序网络图和系统资源图的文件编辑符号及约定》GB 1526--1989 3.2.3 《信息处理系统：计算机系统配置图符号及约定》GB／T 14085－1993 3.3 真题分析 3.4 本章练习 第4章 软件工程开发标准 4.1 大纲要求 4．2 要点详解 4.2.1 《信息技术：软件生存周期过程》GB／T 8566--2001 4.2.2 《软件支持环境》GB／T 15853--1995 4.2.3 《软件维护指南》GB／T14079--1993 4.3 真题分析 4.4 本章练习 第5章 软件工程文档标准 5.1 大纲要求 5.2 要点详解 5.2.1 《软件文档管理指南》GB／T 16680--1996 5.2 2《计算机软件产品开发文件编制指南》GB／T 8567－1988 5.2.3 《计算机软件需求说明编制指南》GB／T 9385--1988 5.3 真题分析 5.4 本章练习 第6章 软件工程管理标准 6.1 大纲要求 6.2 要点详解 6.2.1 《计算机软件配置管理计划规范》GB／T 12505－1990 6.2.2 《信息技术：软件产品评价、质量特性及其使用指南》GB／T 1626－2002 6.2 3 《计算机软件质量保证计划规范》GB／T 12504－1990 6.2.4 《计算机软件可靠性和可维护性管理》GB／T 14394－1993 6.3 真题分析 6.4 本章练习 第7章 信息系统工程监理 7.1 大纲要求 7.2 要点详解 7.3 真题分析 7.4 本章练习 附录A法律法规 A.1 合同法 A.2 招投标法 …… 第二部 案例分析 第三部 论文写作 参考文献

该文档包含PMBOK各阶段、过程、领域的完整视图。是对PMBOK学习的梳理和总结，对全面学习PMBOK十分有帮助。

[走向数学丛书（全18册）].冯克勤.扫描版\4 计算复杂性（王则柯）.pdf

一种SQL语法分析的策略和实现.pdf

主流内存数据库指南.pdf

数据库文件增长对主机性能的影响分析.pdf

sql server 数据集成建模指南.pdf

sql server 数据仓库最佳实践手册.pdf

sql server 时间数据类型 pdf

Sql Server 企业数据集成实践手册.pdf

SQL SERVER 导出专家手册.pdf

SQL Server虚拟化基础指南 pdf

SQL Server索引设计和调优技巧大全.pdf

SQL Server群集与非群集索引设计指南.pdf )

SQL Server第三方工具指南.pdf

SQL Server存储域网络技巧集锦.pdf

SQL Server存储过程调试指南.pdf

SQL Server XML基础指南.pdf

SQL Server 2008 R2中文教程 pdf

SQL Server CLR数据库对象开发指南 pdf

2011年度十大SQL Server技巧文章 pdf

ASP.net与VB.net从入门到精通

VB COm 列集 散集 序列化 持久化

WIM技术指南. 详细的WIM介绍,如WQL.

ASP与XML高级编程

VB6编写 模仿物体下落与反弹. 封装了物体的匀(加)速直线运动的一些方法,可以方便用于其他程序中.

VB设计的一款仿移动业务管理系统,功能比较简单,但基本功能都有,采取的Access数据库,数据库未经优化(使用前请先注册控件)<br>本程序仅供参考 三断笛保持所有权利

一个简单的数据库服务器调试工具,还没写完的<br>现在支持SQL和Oracle两类,SQL只用到一种连接方式,而Oracle用到了ADO和OO4O(部分功能尚未完成),<br>支持SQL语句执行(支持SQL Server和Oracle语法,并支持关键字高亮)支持导出数据库表结构为SQL脚本....<br>连接Oracle服务器需要安装OO40组件,这一组件可以去OTN免费得到

Unified Modeling Language® (OMG UML®) V2.51.pdf This specification defines the Unified Modeling Language (UML), revision 2. The objective of UML is to provide system architects, software engineers, and software developers with tools for analysis, design, and implementation of software-based systems as well as for modeling business and similar processes. The initial versions of UML (UML 1) originated with three leading object-oriented methods (Booch, OMT, and OOSE), and incorporated a number of best practices from modeling language design, object-oriented programming, and architectural description languages. Relative to UML 1, this revision of UML has been enhanced with significantly more precise definitions of its abstract syntax rules and semantics, a more modular language structure, and a greatly improved capability for modeling large-scale systems.

The LML specification’s purpose is to provide a reference for users of the language to understand its goals, concepts and structure and to provide vendors a reference for implementation of the language. The basis for the LML formulation is the classic entity, relationship, and attribute (ERA) meta - meta model. This formulation modifies the classical approach slightly by includ ing attributes on relationships, to provide the adverb, as well as the noun (entity), relationship (verb), and attribute (ad jective ) language elements. Since LML was designed to translate to object languages, such as UML/SysML, these language elements correspond to classes (entity), relations (relationship), and properti es (attribute). Current Systems Engineering languages tend to add complexity to already complex problems, thus making it more difficult to communicate the unde rlying issues and develop effective solutions. LML is designed to be a simpler language, both in terms of its ontology and visual expressions. This feature makes it easy to understand by the entire set of lifecycle stakeholders. Such a simplified language many not include all the “bins” for information a particular domain wants, hence, LML is extensible allowing for discipline and domain specific extensions to support the needs of a specific pro ject, organization or customer. The process for extension submission will be detailed on the lifecyclemodeling.org website. For example, UML and SysML use the term Actor to define a part of the system that performs actions . The DoDAF Metamodel 2 uses the word Performer for the same purpose. LML uses the term, Asset, but also allows the user to extend the language by defining Actors or Performers. However, we recommend modelers use the type attribute for Assets instead, as a means to differentiate between these different names. New entities or child entities are recommended only when new attributes and/or relationships are needed. Thus modelers using LML will know what entity to put something in immediately and can adjust the type as needed. We saw this problem in the DoDAF where modelers were often confused by the difference between an operational node and a systems node. When you have two “bins” to put the same kind of information into confusion often results. Further examples of this comparison appear in Appendix A and B. This specification of LML also defines common visualizations for information. For example, the Risk entity has a standard Risk Matrix as its basic diagram. Each entity has these kinds of common visualizations and they need to be as simple as possible to reduce the complexity of the language and make it more understandable by a broader set of stakeh olders. Other visualizations are allowed and encouraged as they aid in expressing the information, which is the real goal of any language visualizations. These can and should be proposed as extensions to the language as well so that others practitioners can benefit from these visualizations. Ontologies provide a set of defined terms and relationships between the terms to capture the information that describes the physical, functional, performance, and programmatic aspects of the system. By system, 1 we mean the entire set of processes, people and things which operate for the benefit of people. Common ways for describing such ontologies is entity, relationship, and attribute (ERA). ERA is often used to define database schemas. LML use s the ERA approach, but extends it by adding attribute s to relationships. The extension reduces the number of relationships needed, just as attributes reduce the number of entities needed. This section defines the ERAs for LML, thus providing the basic definitions of the data type s used to collect information about the system . In addition, we describe how inheritance, extensions, limitations and instantiation can be used by tool developers to remain within the guidelines of this standard. Entity, relationship and attribute have equivalent English language elements: noun, verb, and adjective. With the addition of attributes on the relationship, we also have the equivalent of the adverb. These equivalencies have been provided to aid in understanding the semantics of the language.

Architecture-driven Modernization Abstract Syntax Tree Metamodel (ASTM) V1.pdf The purpose of the ASTM is to provide a framework that allows tool vendors and tool clients to build and use tools that conform to commonly agreed upon modeling specifications for the interchange of abstract syntax models of software. Interoperability is achieved when models can be interchanged using modeling elements that conform to those specified in the ASTM specification. The internal proprietary models of tools need not conform the ASTM for a tool to be considered compliant with the ASTM. To be considered compliant a tool need only adhere to the ASTM as a model interchange specification. Tool conformance is concerned solely with the ability of tools to interchange models that conform to the ASTM. • For a GAST model to conform with the ASTM it must conform to the GAST Metamodel provided by this specification. • For a SAST model to conform to the ASTM it must conform to both the GASTM model provided with this specification as well as the SASTM model provided by some future SASTM specification. The ASTM is a bi-dimension multi-layered modeling specification. The two dimensions of the ASTM define both syntactic as well as the semantic properties of software. The layers of the ASTM define a core set of modeling elements, the GASTM, that are common to many programming languages as well as a set of extensions, the SASTMs, that extend from the core for and are used in concert with the GASTM for defining models specialized to particular programming languages. Table 2.1 illustrates the Compliance Points of the ASTM.

Ontology Definition Metamodel V1.1.pdf There are several compliance points distinguished for the Ontology Definition Metamodel. These include: 1. None or Not Compliant, meaning that the application in question is not compliant with a particular metamodel, as defined by the metamodel itself, the abstract syntax, well-formedness rules, semantics, and notation specified for a particular package or set of packages. 2. Compliant, meaning that the implementation fully complies with the abstract syntax, well-formedness rules, semantics and notation of a particular package or set of packages. 3. Interchange, indicating that the implementation provides compliance as specified in [2], and can exchange metamodel instances using ODM package conformant XMI. There are several possible entry points for implementations that want to provide/claim minimal compliance with the ODM. These require compliance with one of the following base metamodel packages: • RDFBase Metamodel Package (RDFBase is a sub package of the Resource Description Framework (RDF) Metamodel Package). • Topic Maps (TM) Metamodel Package. • Common Logic (CL) Metamodel Package. For a given implementation to claim ODM compliance, it must be Compliant, as defined in 2, above, with one of these three packages. There are several compliance options available to vendors for the RDF Metamodel Package. These include: • RDFBase Only - as implied above, this package contains the set of elements requ ired for core RDF support, such as is necessary to support a triple store implementation; the focu s here is on the set of constructs defined in the RDF Concepts and Abstract Syntax [RDF Concepts] document. • RDFBase + RDFWeb - provides core RDF support and fits these concepts to the World Wide Web. • RDFBase + RDFS - moves the implementation focus from core RDF to RDF Schema, as specified in [RDF Schema]. • RDF - meaning, the implementation supports all of the concepts defined in the three sub packages, which represents RDF Schema fitted to the Web. There are two possible compliance points for the OWL Metamodel Package. Each of these requires support for the entire RDF package, including the RDFWeb component. They include: • OWLBase + OWLDL - focus is on a description logics application that constrains an ontology in turn for DL decidability. • OWLBase + OWLFull - focus is on more expressive applications rather than on decidability of entailment. The complete set of ODM compliance options is summarized in Table 2.1.

Business Motivation Model V1.3.pdf Fundamental to the Business Motivation Model is the notion of ‘motivation.’ If an enterprise prescribes a certain approach for its business activity, it ought to be able to say ‘why ;’ that is, what result(s) the approach is meant to achieve. Sometimes it is difficult to uncover such motivation, especially in operations that have been going on for some time. All too often it turns out to be “...because we had to find a workaround for a system that didn’t do quite what was needed.” This may describe business work prac tice, information systems, or both. A cornerstone of any work addressing motivation has to be the enterprise’s aspirations (its Vision) and its action plans for how to realize them (its Mission). Refinements were intr oduced; Vision into Goals and Objectives, and Mission into Strategies for approaching Goals, and Tactics for achieving Objectives. The general term End was adopted to refer broadly to any of the ‘aspiration’ concepts (Vision, Goal, Objective) and the term Means to refer generally to any of the ‘action plan’ concepts (Mission, Strategy, Tactic). This conjunction of Ends and Means ‘being’ and ‘doing’ provides the core concepts of the Model 1 . An enterprise, however, cannot operate on this Model alone — the business needs to take into account the numerous Influencers that can hinder or assist its operation. These Influencers provide Oppor tunities that would help the enterprise operate, as well as Threats that would thwart it. Influencers also represent Strengths from within that the enterprise could exploit, or Weaknesses that it should compensate for. But is an Influencer inherently a Strength or Weakness — is it always a Threat or Opportunity? That determination comes from an Assessment of the impact of an Influencer on the st ated Ends and Means — an Assessment such as is developed in SWOT 2 analysis. In this commonly-used technique, Internal In fluencers (assessed to be Strengths and Weaknesses) and External Influencers (assessed to be O pportunities and Threats) are analyzed as a part of business plan development. Once an Assessment has identified relevant Influencers in terms of their impact on Ends and Means, Directives (Business Policies and Business Rules) can be put in place to govern and guide the enterprise Courses of Action. Directives keep the enterprise on course and moving toward its Desired Results. Because of their integr al role in guiding Courses of Action, Directives are included in the set of Means concepts. Business Rules are noteworthy in that regard. Business Rule s sharpen the Business Tactics be cause they make Courses of Action concrete at the operational level. Bu siness Rules can also provide specific remedies when a Course of Action fails, and specific resolutions to conflicts that inevitably arise amon g the Ends. In short, Business Rules provide the leverage needed for building effective, adaptable business solutions and systems.

Production Rule Representation (PRR) V1.pdf The Production Rule Representation (PRR) fulfills a number of requirements related to business rules, software systems, OMG standards, and other rule standards. • It provides a standard production rule representation that is compatible with rule engine vendors’ definitions of production rules. It can therefore be used for interchange of business rules amongst rule modeling tools (and other tools that support rule modeling as a function of some other task). • It provides a standard production rule representation that is readily mappable to business rules, as defined by business rule management tool vendors. • It provides a standard production rule definition that supports and encourages system vendors to support production rule execution. • It provides an OMG MDA PIM model with a high probability of support at the PSM level from the contributing rule engine vendors and others, and can be included to add production rule capabilities to other OMG metamodels. • It provides examples of how the OMG UML can be used to support production rules in a standardized and useful way. • It provides a standard production rule representation that can be used as the basis for other efforts such as the W3C Rule Interchange Format and a production rule version of RuleML.

Systems Modeling Language (OMG SysML™) 1.6.pdf The purpose of this International Standard is to specify the Systems Modeling Language (SysML), a general-purpose modeling language for systems engineering. Its intent is to specify the language so that systems engineering modelers may learn to apply and use SysML; modeling tool vendors may implement and support SysML; and both can provide feedback to improve future versions. Note that a definition of “system” and “systems engineering” can be found inISO/ IEC 15288. SysML reuses a subset of UML 2.5 and provides additional extensions to address the requirements in UML for SE. SysML uses the UML 2.5 extension mechanisms as further elaborated in Clause 17 as the primary mechanism to specify the extensions to UML 2.5. This revision of SysML relies on several new features incorporated into UML 2.5. Any use of the term “UML 2” or “UML” in this specification, unless otherwise noted, will refer to UML 2.5 in general and the UML 2.5 specification in particular. Since SysML uses UML 2.5 as its foundation, systems engineers modeling with SysML and software engineers modeling with UML 2.5 will be able to collaborate on models of software-intensive systems. This will improve communication among the various stakeholders who participate in the systems development process and promote interoperability among modeling tools. It is anticipated that SysML will be customized to model domain-specific applications, such as automotive, aerospace, communication, and information systems. SysML is designed to provide simple but powerful constructs for modeling a wide range of systems engineering problems. It is particularly effective in specifying requirements, structure, behavior, allocations, and constraints on system properties to support engineering analysis. The language is intended to support multiple processes and methods such as structured, object-oriented, and others, but each methodology may impose additional constraints

Unified Architecture Framework (UAF) V1 This Appendix describes the Unified Architecture Framework, the Domain Meta-Model (DMM) that captures the concepts, relationships, and viewpoints that specify the Unified Architecture Framework Profile &#40;UAFP&#41;. As well as providing the DMM for the UAFP, it is intended to provided a non-implementation specific metamodel for those non-UML or SysML tool vendors who may wish to implement the UAF, consequently it is not neccessary to generate XMI for the UAF.

Value Delivery Modeling Language (VDML) V1.1 The purpose of VDML is to provide a standard modeling language for analysis and design of the operation of an enterprise with particular focus on th e creation and exchange of value. It provides an abstraction of the operation of an enterprise that is appropriate for business executives, along with representation of supporting detail for business analysts to link strategy and business models to the activities, roles, and capabilities that run the enterprise. The target users are business people—executives, business architects, analysts and managers. Information systems analysts and designers may use VDML models as specifications for the design of supporting information systems.