An Object Oriented Collaboration Flow Management System for Virtual Team Support

category种类CDMA Code Division Multiple access,码分多址Challeng挑战Class类Class diagram类图Cloud Computing云计算Collaboration diagram协作图Communication消息通信Component构件Component diagram构件图Composite组合Confidentiality机密性consolidation,合并,constructe构造Containe容器coordinated调节,协调CORBa Common Object Request Broker Architecture,公共对象请求代理体系结构corresponding相应的CRM Customer Relationship Management,客户关系管理DAS Direct-Attached Storage,直接连接存储Data mart数据集市Data Mining数据挖掘Data Warehouse数据仓库Database数据库Datalink layer数据链路层DCF Discounted cash flow折现现金流DCOM Distributed Component object Model,分布式构件对象模型DD Data Dictionary,数据字典DDN Digital Data Network,数字数据网decomposed腐烂definite明确的Dependency依赖Deployment diagran部署图derived from来源于DEs Data Encryption Standard,数据加密标准Development view开发视图DFD Data Flow Diagran,数据流图DHCP Dynamic Host Configuration Protocol,动态主机设置协议Directory structure目录结构Distributed Computing分布式计算Dss Decision Support Systen,决策支持系统EC Electronic commerce,电子商务ED| Electronic data interchange,电子数据交换enactment颁布,扮演Enhance igate提高Equipment Room Subsystem设备间子系统Entity Relationship Diagram, E-R EERP Enterprise Resource Planning,企业资源计划ERP Enterprise Resource Planning企业资源规划especial!y特别,尤其essentia基本的Ethernet以太网evolutionary mode演变型Exploit开发Extendibility可扩展性FDMA Frequency Division Multiple Access,频分多址feasibility可行性Firewall防火墙forecast预测,预报FTP File transfer protoco,文件传输协议FTTB Fiber to The Building,光纤到楼FTTC Fiber to the curb,光纤到路边FTTHFiber to the home,光纤到户FttR Fiber to the remote module,光纤到远端接入点FTtz Fiber to the zone,光纤到小区function-函数Functionality功能性fundamental基本(础)的funding基金;储备,存款G2 B Government to business,政府对企业G2 c Government to citizen,政府对公众G2 Government to Employee,政府对公务员G2 g Government to government,政府部门之间Gateway网关Generalization泛化G| s Geographic Information System,地理信息系统Graphical User Interface图形用户界面Grid Computing网格计算HDSL High- speed Digital Subscriber Line,高速率数字用户线路HFC Hybrid Fiber- Coaxial,混合光纤同轴电缆网Horizontal Backbone Subsystem水平干线子系统HTML Hypertext Markup Language,超文本标记语言IDEa International Data Encryption Algorithm,国际加密数据算法identifying认同lEc International electro technical commission,国际电工委员会EEe Institute of Electrical and electronics engineers,电气电子工程师协会impact影响individuals个别地nformation Security信息安全Inheritance继承inspected in检查ntegrity完整性investigation调查involves涉及OT Internet of Things,物联网IPSec The Internet Protocol Security, Internet协议安全性s Information System,信息系统so International Organization for Standardization,国际标准化组织ITIL Information Technology Infrastructure Library,信息技术基础架构库ITSM IT Service Management,∏T服务管理TU International Telecommunications Union,国际电信联盟Lan Local Area network,局域网LogicⅥeW逻辑视图Maintainability可维护性Message消息Middleware中间件M| s Management Information System,管理信息系统Modifiability可修改性Module view模块视图MrP Material Requirement planning,物料需求计划MRPll Manufacturing Resource Planning,制造资源计划NAS Network Attached Storage,网络连接存储Network Layer网络层Non-Repudiation不可否认性numerical数值的Object对象object diagram对象图OCR -Optical Character Recognition,光学字符识别OLAP On-Line Analytical Processing,在线联机分析处理OLTP On- Line Transaction Processing,联机事务处理系统OMG Object Management Group,对象管理组织ooa object-Oriented Analysis,面向对象分析方法ood Object-Oriented design,面向对象设计oop object Oriented programming,面向对象编程oS| Open System Interconnect,开放式互联系统PDH Plesiochronous Digital Hierarchy,异步光网络PDs Premises Distribution System,综合布线系统Performance性能Physical layer物理层Physical view物理视图PKi Public Key Infrastructure,公钥基础设施PMI Privilege Management Infrastructure,授权管理基础设施PON Passive Optical Network,无源光网络Portability可移植性PPTP Point to Point Tunneling Protocol,,点对点协议predecessor activitypreliminary初步的Presentation Layer-表示层priority重点probability of occurring发生可能性proceedings进程Process view进程视图procurement获得property财产,性能prototype原型Proxy代理RAId Redundant array of independent disk,独立冗余磁盘阵列Reassemble结构重组recession衰退reconciliation和解Reliabilit可靠性reliable可靠的responsibilities职责revised修订F| d Radio Frequency Identification,射频识别Router路由器RPC Remote Procedure call.,远程过程调用RSA由Ron rivest、Adi shamir和LenAdleman三人创建,著名非对称加密算法Sa Structured Analisys,结构化分析方法SANStorage area Network,存储区域网络Scenarios场景SCM Supply Chain Management,供应链管理SDH Synchronous Digital Hierarchy,同步光网络Security安全性Sequence diagran序列图Server服务器Session Layer会话层soa Service oriented architecture,面向服务的体系结构SoAP Simple object Access Protocol,简单对象访问协议specification规范;明确说明;说明书spiral model螺旋型sQa Software Quality Assurance,软件质量保证State diagram状态图successor activitySwitch交换机TCP Transmission Control Protocol,传输控制协议。

Using Aspects to Design a Secure SystemGeri Georg Agilent TechnologiesFort Collins, CO geri_georg@Indrakshi RayColorado State UniversityFort Collins, COiray@Robert FranceColorado State UniversityFort Collins, COfrance@AbstractDevelopers of complex systems have to address concerns such as security, availability of services, and timeliness that often are non-orthogonal to traditional design structures, that is, the concerns cross-cut traditional design units. In this paper we illustrate how an aspect-oriented approach to modeling allows developers to encapsulate such design concerns so that they can be woven into a design in a systematic and consistent manner. The paper focuses on the use of aspects for modeling and weaving in security concerns.1. IntroductionThe increasing dependency on software systems that (1) are pervasive (e.g., Internet based systems) (2) maintain sensitive information and (3) carry out critical activities has resulted in increasing attention being paid to security concerns during software development. There is a growing awareness that the manner in which software is designed can have a significant impact on the security of the system [8]. Software developers need to consider security concerns when making architectural, logical, and physical (including technology-related) design decisions. Addressing a security concern during design requires considering the impact of the security concern on each design unit and modifying the affected design units accordingly. This can be a tedious and error prone task and can result in inconsistent and incomplete implementation of the concern. A design technique that allows developers to encapsulate security concerns and systematically and consistently integrate the encapsulated properties across a design can ease the task of developing complex systems.In this paper we propose and illustrate an aspect-oriented design (AOD) technique for designing a secure system. An aspect-oriented design consists of a primary model, and one or more aspects that capture design concerns that cross-cut the design units of the primary model. Incorporating the aspects into the primary model is called weaving. Weaving results in a model in which the design units impacted by the concern represented by the aspect are modified accordingly.In our work, aspects are treated as design patterns. Treating security concerns as aspects (patterns) during design modeling has the following advantages: (1) Aspects allow one to understand and communicate security concerns in their essential forms, rather than in terms of a specific application’s behavior. (2) An aspect focuses on one concern, hence it is easier to model and understand its behavior. (3) The security aspects are potentially reusable across different systems. (4) Changes to security concerns are made in one place (aspects), and effected by weaving the aspects into the primary model.(5) The impact of security concerns on design units can be analyzed by weaving security aspects into primary models and evaluating the resulting models. Analysis can reveal undesirable emergent behaviors and interference across the woven aspects at the design level. System designers are able to identify problems with the design of security mechanisms even before they are implemented – this saves development cost and effort.In our AOD approach an aspect is defined in terms of structures of roles called Role Models [11,12]. Role Models are used because they allow one to express aspects as patterns. Aspect properties are defined in terms of roles that can be played by model elements representing application-specific concepts. In our approach, the model elements are UML constructs. Ourwork is based on the UML because it is emerging as a de facto modeling standard in industry.The manner in which multiple aspects are woven into a primary model is determined by weaving strategies. A weaving strategy identifies security aspects based on the kinds of attacks that are possible in a system and the mechanisms that can be used to detect, prevent, and recover from such attacks. A system designer can use a table that relates security-related characteristics, expressed in terms of the kinds of attacks that are possible on systems, and weaving strategies to determine the aspects to be woven into a primary model and the manner in which the aspects are to be woven.The rest of the paper is organized as follows. Section 2 gives background information pertaining to this work. Section 3 shows how security aspects can be specified using Role Models. Section 4 illustrates how security aspects can be woven with models of the essential functionality of a system. Section 5 concludes the paper. 2. Background2.1 Role ModelsRole Models (see [11,12]) are used to define aspects as design patterns. A Role Model is a structure of roles, where a (meta-)role defines properties that must be satisfied by conforming UML model elements. An UML model element (e.g., a class or an association) that has the properties specified in a role can play the role, that is, it conforms to (or realizes) the role. A UML model conforms to a Role Model if (1) it contains model elements that conform to the roles in the Role Model and (2) the structure of the UML model is consistent with the structure characterized by the Role Model. Weaving an aspect defined by Role Models into a primary model is essentially a model transformation process in which the non-conforming primary model is transformed to a conforming model (i.e., a model that incorporates the aspect).A design aspect (e.g., a security concern) can be modeled from a variety of perspectives. In this paper we focus on two aspect views: static and interaction views. An aspect’s static view defines the structural properties of the aspect. The interaction view specifies the interaction patterns associated with the aspect. We use specialized forms of two Role Model types to model aspects from these views : Static Role Models (SRMs) and Interaction Role Models (IRMs) [12]. SRMs define patterns of UML static structural models (e.g. Class Diagram patterns) while IRMs define UML interaction diagram patterns (e.g. Collaboration Diagram patterns). An aspect definition typically consists of a single SRM and one or more IRMs.An Overview of SRMsAn SRM consists of classifier and relationship roles. Each SRM role has a base that restricts the type of UML construct that can play the role. An example of an SRM for an authentication security concern is shown in Figure 1 (details of the properties expressed in the roles are suppressed in this SRM). This SRM consists of four class roles: Initiator, Target, IdentityRepository, and IdentityEntity. The base of these roles is Class (as indicated by the Class Role stereotype), thus only UMLclass constructs can play these roles. The SRM also Figure 1. Static view of an authentication aspect.consists of three relationship roles (each with base Association) that characterize associations between classes playing the connected roles. In the specialized form of SRMs used in this work association roles have multiplicity constraints expressed in template form (e.g., [[n]] where n is a range) or as an explicit set of ranges (i.e., a UML multiplicity such as *, 1, 2..4). If a multiplicity (an explicit set of ranges) is shown on an association role end, then the multiplicity must appear on the ends of the realizing associations. Multiplicities in a realization of an association role containing template multiplicities can be obtained by substituting values of n that satisfy the constraints associated with n (expressed using the OCL).Each role defines properties that conforming constructs must possess. Two types of properties can be specified in a SRM role: Metamodel-level constraints are well-formedness rules that constrain the form of UML constructs that can realize the role, and Feature roles characterize properties that must be expressed in the conforming model elements. Metamodel-level constraints are constraints over the UML metamodel expressed in the Object Constraint Language (OCL) [23, 32]). For example, a metamodel-level constraint in a class role can constrain conforming classes to be concrete with a class multiplicity that cannot exceed a value m. In this paper, we do not show the metamodel-level constraints in the diagrams.Feature roles are associated only with classifier roles. There are two types of feature roles: Structural roles specify state-related properties that are realized by attributes or value-returning operations in a SRM role realization, and behavioral roles specify behaviors that can be realized by a single operation or method. A feature role consists of a name, and an optional property specification expressed as a constraint template (omitted in the examples given in this paper). For example, each behavioral role (see [13]) is associated with pre- and post- constraint templates that, when instantiated, produce pre- and post-conditions for realizing operations.An Overview of IRMsUML interaction models (e.g., Collaboration and Sequence Diagrams) are used to specify or describe interactions between system parts. Interactions characterized by an aspect are defined using a template form of interaction models called Interaction Role Models (IRMs) [12]. An IRM consists of template forms of UML collaboration roles [23], and messages. Instantiating these templates results in an Interaction Diagram. In this paper we use only the Collaboration Diagram template form of IRMs to describe the interaction pattern defined in an aspect. An example of an IRM for an authentication security aspect is shown in Figure 2. This IRM is described in Section 3.Generating Models Elements from Role Models During aspect weaving new model elements may need to be created in order to incorporate the aspect into the original model. Conforming constructs are generated from an aspect’s SRM as follows:•Create an instance of the role base that satisfies the metamodel-level constraints.•For each structural role, generate an attribute and associated constraints by substituting aname for the role name, and substitutingconforming values for the templateparameters of the constraint templates.•For each behavioral role, generate an operation and associated constraints bysubstituting a name for the role name, andby substituting conforming values for thetemplate parameters for the pre- and post-condition constraint templates.•When multiplicity templates are given on association roles, association multiplicitiescan be obtained by substituting values thatsatisfy the constraints on the templateparameters.Interaction models can be produced from IRMs by substituting values for the template parameters that satisfy any constraints associated with the parameters.2.2 Security DefinitionsIn this section we present some security definitions that we use in the rest of this paper. For more details we refer the interested reader to [26]. The three main security objectives are: (1) Confidentiality (sometimes termed privacy or secrecy) - protecting against unauthorized disclosure of information. (2) Integrity - protecting against unauthorized modification of information. (3) Availability - protecting against unauthorized withholding of information or resources.In the security domain, user refers to the human user interacting with the computer system, s ubject is acomputation entity, or executing thread, that performs actions on other entities, and o bject is an entity acted upon by a subject (not to be confused with the OO notion of an object). Typically not all subjects or users in a system can be trusted to maintain the security objectives.A trusted subjects/users is a subject/user that will not cause any security violations. A subject/user that may cause security violations is said to be un-trusted. Some objects contain critical information and others do not. The ones that contain critical information often need additional protection. A sensitive object is one that contains sensitive information that should be protected from unauthorized access.Finally, we define what we mean by security attacks, threats, vulnerabilities, and security mechanisms. A security attack is any action that compromises the security of information/resources owned by an organization. A security threat is a circumstance that has the potential to cause harm to a system. A security vulnerability is a weakness in the system that might be exploited to cause harm. A problem is an error or failure in the system. Problems can also be exploited to cause harm. A security mechanism is a set of techniques that describe how the information/resources can be protected. Mechanisms can be grouped into those that detect, prevent, or recover from attacks. Authentication, access control, and encryption are examples of preventive mechanisms, auditing and intrusion tracking are detection mechanisms, and intrusion response is a recovery mechanism. In this paper we illustrate our design approach using an authentication example. Authentication is the process of verifying that the identity a user claims is indeed his true identity.2.3 Security MechanismsThe first step in designing a secure system is to identify the kinds of threats and the mechanisms that can be used to protect the system against such threats. Table 1 gives examples of attacks and problems, and the mechanisms that are commonly used to protect against them (this list is by no means exhaustive). For example, row 3 of the table states that for un-trusted communication links, the problem of lost communications can be solved by a handshaking protocol. Note that, in a real world scenario, these entities will not be acting alone but will act as a group. A group of entities will require a combination of the respective mechanisms. For example, a sensitive object requires encryption, authentication and access control to protect against unauthorized modification. When this sensitive object passes over an un-trusted communication link we must incorporate the additional mechanisms needed for lost, spurious and corrupted communications.In our AOD approach, a weaving strategy determines the aspects and constrains the manner in which they will be woven. Weaving strategies need to be developed from the kinds of threats or problems that can be expected in a system. For example, if the data passing over communication links in the user management system is not sensitive, eavesdropping may not be of concern. In Table 1. Attacks, Problems, and SolutionsEntityType ofAttack/ProblemPrevention,Detection,RecoveryMechanisms Trusted comm.linksLink errorChecksums Trusted subject User error AuditingUn-trustedcommunicationlinkLostcommunicationsHandshakingprotocol fordetecting loss,message re-transmissionSpurious orreplayedcommunicationsAuthentication,use nonce foreach message,auditing, non-repudiationCorruptedcommunicationsChecksums,encryptionEavesdropping EncryptionUn-trustedsubjectUn-authorizedaccessAuthentication,access-control,auditing Sensitive objectUn-authorizeddisclosureEncryption,authentication,access-control,auditingUn-authorizedmodificationAuthentication,access-control,checksums,auditingUn-authorizedexecutionAuthenticationaccess-control,auditingthis case, even if a communication link is un-trusted, encryptions are not needed and can be omitted from the weaving strategies.2.4 Related WorkThere has been much work on aspect-oriented programming [4, 5, 19, 20, 24, 29] and a number of authors have tackled the problem of defining and weaving aspects above the programming language level (e.g., see [3, 7, 10, 13, 15, 22, 25, 28]). In the latter cases, aspect specifications can be viewed as template models, and they are generally woven by using regular expression to match existing model elements and aspect elements. Many aspect compositions essentially result in wrapping additional functionality around an existing model. The proper model factoring must already exist to apply the aspect, so it is conceivable that effort must be applied to re-factor existing models to correctly compose them with aspect models. The technique proposed in this paper supports a more flexible and rigorous approach to aspect definition and weaving in aspect-oriented design (AOD).There has been some work on using the UML to model security concerns (e.g., see [1, 2, 6, 9, 12, 14, 16, 17, 18, 21, 31, 33]). Chan and Kwok [6] model a design pattern for security that addresses asset and functional distribution, vulnerability, threat, and impact of loss. UML stereotypes identify classes that have particular security needs due to their vulnerability either as assets or as a result of functional distribution. Jurjens [17, 18] models security mechanisms based on the multi-level classification of data in a system using an extended form of the UML called UMLsec. The UML tag extension mechanism is used to denote sensitive data. Statechart diagrams model the dynamic behavior of objects, and sequence diagrams are used to model protocols. Deployment diagrams are also used to model links between components across servers. UMLsec is fully described in a UML profile.Our works differs from the above in that the focus is not on extending modeling notations such as the UML but on how security concerns can be encapsulated and then woven into primary design models. By providing good support for separation of concerns during the design phase, the complexity of designing large systems can be better managed. Our work can also take advantage of UML security extensions: the weaving process can be designed to produce extended forms of the UML that reflect the properties expressed in the aspects in a more direct manner.3. Modeling Security Aspects Using Role ModelsDifferent security mechanisms can be modeled as aspects (e.g., auditing aspect, authentication aspect, data sensitivity aspect). In this paper we focus on the authentication aspect. Recall that authentication is the process of verifying that the identity claimed by a user is his true identity. Note that, different organizations mighthave different policies about when and how to perform Figure 2: IRM for the authentication aspectauthentication. For example, an organization might impose a duration when the authentication is valid. If the duration has expired, a user is required to re-authenticate himself/herself before performing any other operations. At this stage, we do not focus on such concerns.3.1 Modeling Security Aspects: Structural ViewThe authentication aspect from a structural perspective is shown in Figure 1. In this aspect, Initiator is to be played by classes whose instances will initiate the authentication request, Target is to be played by classes whose instances will receive authentication request, IdentityRepository is to be played by classes whose instances represent the repository of user identities, and IdentityEntity is to be played by classes representing user identities. Some of the SRM features and constraints are listed below: •There can be only one class that plays the IdentityRepository . The behavioral role lookUp , characterizes behaviors that look up an identity in the repository.•Target has behavioral roles verifyId (verifieswhether the identity is valid), lockOut (locksout the identity), and startConvs (initiates a conversation using the claimed identity of the Initiator ).3.2 Modeling Security Aspects: Interaction ViewWe use IRMs to describe the interaction pattern defined by an aspect. Constraints on the ordering ofmessages are expressed in terms of message sequence templates . A particular ordering can be obtained by substituting values for the template parameters that satisfy the parameter constraints.One can define the interactions that take place when a user needs to authenticate itself as shown in Figure 2. In Figure 2 there is one template parameter, the natural number n , and the constraint associated with it is n>0. The authentication process starts (message [[n]]) with the client (an instance of a class that conforms to Initiator ) sending a message containing the claimed identity to the server (an instance of a class that conforms to Target ). The server then sends a message to the identity repository to look up the claimed identity (message [[n]].1). If the identity does not exist (message [[n]].2A ), then the client is locked out (message [[n]].2A.1) and receives an error message (message [[n]].2A.2). If the identity does exist (message [[n]].2B ), the server decides whether the claimed identity is the true identity (message [[n]].2B.1). If not (message [[n]].2B.2A ), the client is locked out (message [[n]].2B.2A.1 ) and it receives an error message (message [[n]].2B.2A.2). If the claimed identity is the true identity (message [[n]].2B.2B ), then control returns to the initiatorbut with a continue message.4. Weaving Aspects into a Design ModelWeaving of an aspect into a primary model involves:Figure 3. Class Diagram for a User Management System it.(1) Mapping primary model elements to the roles they are intended to play : Before the weaver can incorporate the aspect into a primary model the modeler must first indicate the parts of the model the aspect is to be woven into. This can be accomplished by the modeler explicitly indicating the model elements that are intended to play the roles. Alternatively, the aspect can characterize the points into which it will be woven (as is done with pointcuts in AspectJ). In this paper the former approach is used. We are currently developing support for the second approach. Note that not all model elements need be mapped to roles. Also, not all roles need be associated with a primary model element. Roles not associated with primary model elements indicate that new model elements must be created and added to the primary model asdescribed later.(2) Merging roles with primary model elements : Each model element that is mapped to a role has its properties matched with the properties contained in the aspect, and additional properties are generated from the role if deficiencies in the model element are found. For example, a class that is mapped to a class role that does not have the attributes or operations that play structural and behavioral roles defined in the mapped class role is extended with attributes and operations generated from the role.(3) Adding new elements to the primary model : Each role that is not mapped to a model element is used to generate a model element that is then added to the model.(4) Deleting existing elements from the primary model : If a model element is mapped to a <<delete>> role (a <<delete>> role indicates that conforming elements mustnot exist in the model), then the model element is removed from the primary model.4.1 Weaving Aspect into Static Models using SRMsThe static structure of a user management system is modeled by the Class Diagram shown in Figure 3. The user management system consists of (1) Manager instances that direct actions on user information, (2) SystemMgmt instances that carries out the action, (3) userList instances that contain information about users and (4) userInfo instances that contains information aboutindividual users. We assume that there is a single SystemMgmt instance and a single userList instance. Figure 4 shows the result of weaving the static view of the Authentication aspect into the original User Management Class Diagram. Manager is mapped to Initiator and SystemMgmt is mapped to Target. IdentityRepository will be played by userList and IdentityEntity will be played by userInfo . Merging of roles to mapped primary model elements can result in modification to primary model elements. For example, the SystemMgmt class must be augmented to play the role of Target by adding operations of verifyID(), lockOut(), startConvs(). The userList class is augmented to play the IdentityRepository role by adding a lookUp() operation. The multiplicity of the association between Manager class (playing the Initiator role) and SystemMgmt class (playing the Target role) must be changed from * to 1..*, that is, the aspect template n must be substituted with 1..*. Other multiplicity substitutions are 1..1 for m . The aspectFigure 4.Static diagram with authentication wovenintoroles played by model elements are shown in the woven static diagram using stereotypes (see Figure 4).4.2 Weaving Aspects into Interaction Models using IRMsThe collaboration diagram describing the Add User behavior is shown in Figure 5. The collaboration starts with the manager sending a request to add a user (message 1). The system management then sends a look up request to the user list. After the user list has completed this request, control returns to the system management. If the user exists, an error message (message 1.2B) is sent to the manager. If the user does not exist two steps are performed in sequence – the add information request is generated (message 1.2A.1) and the operation complete signal is generated (message 1.2A.2). Figure 6 shows the result of weaving the authentication aspect interaction view into this model of user management system. The weaving is accomplished as follows:•The id parameter is substituted with cid and the iden parameter is substituted with uID1.•The template parameter n in the IRM is set to 1 because authentication must be carried out before anyoperation is performed. Consequently, all the interactions shown in the primary model (shown in Figure 5) must be renumbered. This is done by adding one to the outermost sequence number, thus the interactions in Figure 6 are now represented by interactions 2, 2.1, 2.2A, … in the woven model (seeFigure 6).5. ConclusionsFigure 5. Collaboration diagram for adding a user to a management system.Designing secure systems is difficult. In this paper we propose a technique to model and integrate security concerns into designs. The approach is aspect-oriented in that security concerns are modeled independently as aspects that can then be woven into models of essential functionality. In our approach, a listing of the different kinds of attacks that are prevalent and the mechanisms required to protect against such attacks is used to identify needed aspects and the strategy for weaving them into a design. Thus, two levels of weaving rules are needed in our approach. The first are the weaving strategies that identify the security aspects needed for particular situations and that constrain how the aspects are woven into models of essential functionality (e.g. weaving order). The second level of weaving deals with the mechanics of the weaving process.The weaving strategies are intended to be reusable forms of experiences that can be used to assess the threats to a particular system and propose techniques (i.e. a combination of mechanisms) to prevent or detect the related attacks. An interesting by-product of the weaving strategies is that we can change them (i.e., re-weave mechanisms), and see the impact on the system of these proposed changes. Note that the security provided by mechanisms in the model is only as good as the weaving strategies.Our experience indicates that flexible tool support for weaving will greatly enhance the practicality of our approach. Flexibility in the weaving process is necessary because the manner in which the aspects are woven is highly dependent on the form of source models and the type of aspects being woven. We are currently developing a prototype tool that will support flexible weaving, by providing users with a language for describing reusable weaving strategies and weaving procedures. References[1] G. J. Ahn and M. E. Shin 2001. Role-based authorization constraints specification using object constraint language. Proc. of the 10th Int’l. Workshop on Enabling Technologies: 157-162, Cambridge, MA, June.[2] H. A. Ali 2002. A new model for monitoring intrusion based on Petri nets. Information Management and Computer Security 9(4):175-182.[3] L. F. Andrade and J. L. Fiadeiro 2001. Coordination technologies for managing information system evolution. Proceedings of the CAISE’01.[4] F. Bergenti and A. Poggi 1999. Promoting reuse in aspect-oriented languages by means of aspect views. Tech. Report DII-CE-TR005-99, DII – Universita di Parma, Parma.[5] L. Bergmans and M. Aksit 2001. Composing crosscutting concerns using composition filters. Comm. of the ACM 44(10): Oct. 51-57.[6] M. T. Chan and L. F. Kwok2001. Integrating security design into the software development process for e-commerce systems. Information Management and Computer Security 9(2-3): 112-122.Figure 6. Collaboration diagram with authentication woven into it.。

政府回购工程项目资产转移流程1.政府回购工程项目的资产转移流程需要严格遵守相关法律法规。

The asset transfer process of government repurchased engineering projects needs to strictly comply with relevant laws and regulations.2.首先，政府回购部门需要向相关部门提交资产转移申请。

Firstly, the government repurchase department needs to submit an asset transfer application to the relevant department.3.资产转移申请需要包括原始资产的清单、数量、估值等相关信息。

The asset transfer application needs to include a list of original assets, quantity, valuation, and other relevant information.4.相关部门收到申请后，将进行资产审核和评估工作。

After receiving the application, the relevant department will conduct asset review and evaluation.5.审核和评估结果将用于确定资产转移的合理性和适当的补偿标准。

The results of the review and evaluation will be used to determine the reasonableness of the asset transfer and the appropriate compensation standards.6.一旦资产转移获得批准，相关部门将制定详细的转移方案。

价值工程0引言1985年《中共中央关于科学技术体制改革的决定》首次提出产学研合作，近年来我国产学研工作得到了快速发展，建立以企业为主体、市场为导向、产学研相结合的产业技术创新联盟成为新形势下产学研合作的有效模式。

产业技术创新联盟成员之间通过契约关系建立共同投入、联合开发、利益共享、风险共担的机制，更能形成长期、稳定和紧密的合作关系[1]。

产业技术创新联盟遍布诸多行业，组织模式各有不同。

这种由校、企、科研院所共建的创新联盟，在组织上分散而又被技术紧密连接，项目管理作为联盟组织创新和竞争活动的基本组织形式和运行管理模式，如何围绕产品开发与创新活动完善和优化项目管理方法，实现多利益主体协同环境下项目管理过程的开放性与柔性，是产业技术创新联盟持续发展的基础和重要保证。

1面向产业技术创新联盟的项目管理产业技术创新联盟是由区域内的行业骨干企业、核心企业与国内相关领域优势高校、科研机构等按市场经济规则联合组建的虚拟性组织，旨在实现持续性的产业技术创新的成果转化，推动产业结构优化升级，提升产业核心竞争力。

作为一种全新的产学研合作模式，产业技术创新联盟是以企业为主体，通过产学研联盟成员的优势互补和协同创新形成的一种长效、稳定的利益共同体，并通过契约关系建立共同投入、联合开发、利益共享、风险共担的机制[2]。

产品研发是技术创新联盟的重要任务，不同于传统的实体组织，技术创新联盟构建一种虚拟化的研发团队，拥有更丰富的资源，可以在更大范围内进行优化组合，围绕特定的研究目标和内容而产生一种基于信息技术的合作联盟，即综合关键技术来解决问题，但物理上不是在同一地点集中式工作[3]。

以虚拟研发为特征的跨组织产学研合作为产品研发项目管理赋予新的特点和要求：①组织虚拟化使得研发活动具有高度的分散性，相应的，权利也分散开来[4]。

②项目是各利益主体相互联系的桥梁和纽带，跨组织的产学研合作既要强调组织管理的集中性，又要保证各利益主体的自主性。

Documentum内容管理平台技术介绍AUG, 2008© Copyright 2008 EMC Corporation. All rights reserved. 1议程Ÿ 今天的EMC公司Ÿ EMC Documentum系统体系结构 Ÿ EMC Documentum服务体系结构 Ÿ EMC Documentum解决方案介绍 Ÿ 问题与交流© Copyright 2008 EMC Corporation. All rights reserved.2今天的EMCEMC 信息基础架构利用优化2003JAN.2004JAN.2005JAN.2006JAN.2007JAN.保护存储© Copyright 2008 EMC Corporation. All rights reserved.3议程Ÿ 今天的EMC公司Ÿ EMC Documentum系统体系结构Ÿ EMC Documentum服务体系结构 Ÿ EMC Documentum解决方案介绍 Ÿ 问题与交流© Copyright 2008 EMC Corporation. All rights reserved.4非结构化信息的挑战1 非结构化的知识型信息web Information white papers Ÿ 日常工作 SOPs product requirements – 只有工作时间的40%是用来处理与工作相关的 video emails competitive analysis 信息 meeting notes NDA project plans Ÿ 85%的企业信息是非结构化的 MRP – Source: Fulcrum Research animation 非结构化 Order letters Mgmt. Ÿ 90% 的非结构化信息未实现管理 invoices ERP photos 结构化 CRM fingerprints resumes Policy proposals Mgmt. SOWs contracts research detailed designs market requirements specifications presentations scanned documents forms POs illustrations data sheets© Copyright 2008 EMC Corporation. All rights reserved. 5非结构化信息的挑战2 非结构化的工作流程Ÿ 工作流程不适应快速变化的业务模型 Ÿ 全球范围的知识型协作 Ÿ 未实现管理的协作不具备推广能力 Ÿ Email无法成为协作工具approve review develop协同型 事务型plandiscussnegotiate design© Copyright 2008 EMC Corporation. All rights reserved.respond6非结构化信息的挑战3 失去控制的非结构化数据Ÿ 失去可控性的非结构化信息以36％年的 速率增长 Ÿ 所有内容，即使e-mail和IM也存在法规 要求 Ÿ 遍布全球－约16,000 个法规 可管理的 不可管理的© Copyright 2008 EMC Corporation. All rights reserved.7内容管理平台部署关键一：统一性业务影响 Ÿ 更高 TCO数据库 安全整合的视图Ÿ 多重技能要求 Ÿ 管理成本增加成性能 员 Ÿ 低下应用代码 对象模型 仓库Ÿ 系统故障风险增加 Ÿ 无能力响应审计Imaging BPM Reports Collaboration Messages RM审计跟踪Ÿ 可怜的信息利用 – 冗余, 缺乏再利 用, 等等.DMDAMWCM© Copyright 2008 EMC Corporation. All rights reserved.8内容管理平台部署关键一：统一性业务好处：门户/桌面/工作室Ÿ 更低的开发和管理成本 Ÿ 对最终用户及管理者更低的技能培训 要求 Ÿ 更好的性能和可靠性 Ÿ 统一的审核机制获得更高的安全性和 责任性 Ÿ 一个管理界面流程 内容 存储池ECI1Legacy WWWŸ 现有系统和外部资源的不同种类资源 存储池的内容管理Federated Repositories© Copyright 2008 EMC Corporation. All rights reserved.9体系结构 – 存储池结构内容服务器内容文件属性表 In RDBMSFull-text Indexes© Copyright 2008 EMC Corporation. All rights reserved.10Content Services §Search and Full text index retrieval§Check in / Check out§Major, minor, branch version control§Inherent server based workflow§E-Mail event notification on routed objects§Complete XML handlingFileSystem RDBMSŸ通用性–任意内容形式–管理，而不仅仅是存储Ÿ可升级–适用于任意硬件配置Ÿ灵活性–面向对象–文件系统和数据库相结合Ÿ开放性–开放的API, WebDAV, FTP, ODBC, JDBCRelationshipsVersionReferenced-by LocationDisplayPrintCheck-in/Check-outRoute/NotifyTransformUser AttributesFormat StatusDefault AttributesAttributesMethodsUser Session Type StoreContent ServerUnstructured Data Repository And ServicesLegacyMajor Packaged ApplicationsFile Store Records ManagerCaptivaCASNASSANŸ可扩展能力源于体系架构–服务器多CPU支持–群集的体系架构Ÿ无以伦比的库扩展能力–一个内容库可以支持超过10十亿以上的对象–一个内容库可以支持超过1万并发用户数访问DocbrokerDocbrokerContent ServerContent ServerContent ServerDatabase ClusterFile Server ClusterClustered Storage ArrayClient/ApplicationRequestsClustered Storage ArrayChicago Beijing商业联系性ŸBackup & RestoreŸRedundancy & FailoverŸHigh Availability (Clustering)分布式体系结构ŸDistributed repositories ŸReplicationŸFederated management内容管理平台部署关键三：统一的安全保证Ÿ 需求：内容经过集成和整合后，如何保证其安全性，如何让“合适”的人看 到“合适”的内容？标准的访问控制组 用户 角色属性 功能 内容User Group RoleACLPermission Set Permission Set Permission Set扩展的安全控制属性 功能 内容 改变地点 属性 功能 内容 改变所属人© Copyright 2008 EMC Corporation. All rights reserved.改变权限Author Reviewer执行应用改变状态21内容管理平台部署关键三：统一的安全保证Ÿ 在信息的整个生命周期内， 永久保护和控制文档及电子 邮件的权限。