Formal Specification and Development

合集下载

实验室审核标准

Document Name:Global Outside Lab QualificationProcedureDate Revised:21-May-08© 20yy – 20yy Whirlpool Corporation. The subject matter shown hereon is disclosed in confidence to the extent it is original with Whirlpool.Disclosure to other parties except in filling Whirlpool orders is forbidden.Appendix to GES-0128:Outside Lab Capability AssessmentREQUIREMENTSREPORT FORMCOMMENTS CARDCOPYRIGHT © 2008 WHIRLPOOL CORPORATIONDocument Name:Global Outside Lab QualificationProcedureDate Revised:21-May-08© 20yy – 20yy Whirlpool Corporation. The subject matter shown hereon is disclosed in confidence to the extent it is original with Whirlpool.Disclosure to other parties except in filling Whirlpool orders is forbidden. TABLE OF CONTENTSPage Foreword ....................................................................................................................................... 11 Auditee Preparation Guidelines ...................................................................................................... 11-12Suggested Outside Lab Capability Assessment Agenda ................................................................. 13 Outside Lab Capability Assessment Topics .................................................................................... 13 Requirement Statements and Guidelines ........................................................................................ 14-15 Auditee Final Assessment Status ................................................................................................... 16 Outside Lab Capability Assessment Requirements ......................................................................... 17 L1 - Quality Systems (equipment & data integrity)................................................................. 18 L2 - Materials Testing .......................................................................................................... 19 L3 - Codes & Regulatory Requirements ............................................................................... 20 L4 - Test Specifications & Procedures .................................................................................. 21 L5 - Test Plans .................................................................................................................... 22-23 L6 - Reliability ………………………………………………………………24 L7 - Lab Product Approval Process ...................................................................................... 25-26L8 – Lab Personnel Experience ………………………………….…………..27-28 L9 – Product Experience and Market Experience (29)Glossary of Terms …………………………………………………...30-31 Outside Lab Assessment Report .................................................................................................... 33 Assessment Individual Key Scores and Findings ............................................................................ 33-35 Comments Card ............................................................................................................................ 36 Comments & Suggestions ..............................................................................................................37Document Name:Global Outside Lab QualificationProcedureDate Revised:21-May-08© 20yy – 20yy Whirlpool Corporation. The subject matter shown hereon is disclosed in confidence to the extent it is original with Whirlpool.Disclosure to other parties except in filling Whirlpool orders is forbidden.FOREWORDThe purpose of this document is to define the proper standard for the assessment of outside labs for potential data source(s) to support Whirlpool Corporation ’s product approval process. It is expected that any outside lab providing data will do so in a manner consistent with Whirlpool ’s Product Approval and Lab Operation process; thus, this Whirlpool ’s assessment is based upon the same “18 PALO Keys to Lab Improvement ” as is used internally at Whirlpool.This Outside Lab Assessment is to be used under the direction of a trained Product Approval representative.The contents of this document explain the necessary steps involved when going through a Whirlpool Outside Lab Assessment. The first section in this package is the “Outside Lab Audit Assessment Guidelines,” which are recommendations on how and what to prepare for the official assessment. Following that is the “Suggested Assessment Agenda .” This agenda is supplied to help the outside lab understand approximately how the time is allocated throughout the day while conducting the assessment. It is only a suggested agenda and does not take into account the size or complexity of the location beingassessed. The section “Guidelines for Use ” contains information about how to use this document. The biggest and most important section called “Assessment Requirements,” lists all the assessment requirements that will be used to evaluate the Outside Lab ’s Capabilities. This section is the core of the assessment process and the assessment team will evaluate the outside lab based upon this material. The sections have been organized to allow a natural flow or progression of questions while performing the Outside Lab Assessment. Finally, the last section called “Outside Lab Assessment Results &Comments Card ,” is a copy of the forms used to write the final assessment report. It includes a copy of a survey that may be filled out by the outside lab after the assessment is complete. It is through this feedback that we can continue to make the assessment process more valuable.This document shall provide all the necessary information to complete an Outside Lab Assessment and Final Report. If any more information is required, the outside lab shall contact the lead assessor. This person can answer any remaining questions.It is our intent that this process will provide Global Whirlpool Technology and Procurement personnel with a solidunderstanding of each Outside Lab ’s capabilities such that enlightened decisions can be made regarding potential testing outsourcing.AUDITEE PREPARATION GUIDELINESAUDITEE: This checklist is provided as an aid to help prepare you for your upcoming Outside Lab Capability Assessment . Basically, a Whirlpool team will be assessing your lab capabilities relative to specific Whirlpool needs and requirements. The key to a successful and efficient audit is preparation, both on the part of the auditee and the audit team. Your responsibility, as Auditee, is to make sure that the following items have been addressed and available as needed.A. Has the agenda for the day(s) of the audit been established and communicated? This is the responsibility ofWhirlpool Lead Assessor. If not complete, please contact the Lead Assessor.Document Name:Global Outside Lab QualificationProcedureDate Revised:21-May-08© 20yy – 20yy Whirlpool Corporation. The subject matter shown hereon is disclosed in confidence to the extent it is original with Whirlpool.Disclosure to other parties except in filling Whirlpool orders is forbidden.B. Have you reviewed the Outside Lab assessment standard, understand the requirements and used them toperform a self-evaluation prior to the official visit? Have you sent a copy of your self-assessment to the Whirlpool Lead assessor? C. Do you understand the scoring system?D. Is your documentation and supporting evidence readily available? Suppliers should prepare for the assessmentby gathering initial documentation & evidence by key, summarize it, organize it in a manner that the information can be rapidly selected for discussion, and prepare for additional background evidence should the Lead Assessor desire additional material.Key Point: The audit can be conducted in a much more efficient manner if the supporting documentation isarranged in a sequence corresponding to the Whirlpool requirements.The audit documentation can be flowcharted according to your design process. You may arrange the evidence in that order and notify the lead auditor of the desired flow and the lead auditor will follow your recommendations by re-arranging the assessment keys in the order you have recommended (note: all keys must be completed).E. Have you identified the key contact person (Lab Manager or equivalent) to represent your organization andinterface with the lab assessment team? F. Do you have lead people identified for specific sections of the audit (i.e. reliability, equipment calibration,personnel experience, document management, planning, etc.)? Are they “ready ” when called upon? G. Has a conference room been reserved for the audit team to use? H. Is a telephone available? I.Given the expected complexity of the audit and the size of the facility, has the overall time duration of the audit been estimated and consideration given to necessary breaks, including lunch arrangements, if needed? (Note: In the interest of time, a quick working lunch brought to the audit location is typically preferred.)J. Is any safety equipment required (i.e. safety glasses, steel toe shoes, hearing protection, etc.)?Finally, if you have any other questions or concerns they can and should be resolved with the Whirlpool Certified Lead Assessor prior to the actual audit day.Document Name:Global Outside Lab QualificationProcedureDate Revised:21-May-08© 20yy – 20yy Whirlpool Corporation. The subject matter shown hereon is disclosed in confidence to the extent it is original with Whirlpool.Disclosure to other parties except in filling Whirlpool orders is forbidden.SUGGESTED ASSESSMENT AGENDAACTIVITIES:EST. DURATIONIntroduction (Team members/Auditee representatives) .................................................................. 10 - 20 min. Auditee overview of Lab Operation & Facilities .............................................................................. 30 min. Lab Facility Tour ........................................................................................................................... 30 min - 1 Hr. Lab Capability Assessment ............................................................................................................ 4 - 6 Hrs. Scoring & Report Development (Whirlpool Team Only) ................................................................... 30 min – 1 Hr. Closure Meeting ............................................................................................................................ 30 - 45 min.Note: This suggested agenda does not take into account the size or complexity of the location being assessed. The estimated duration should be seen as a guideline only. A typical assessment can take anywhere from 5.0 hr. to 9.0 hrs .Outside Lab Capability Assessment TopicsKey No.KEY NAMEL1 QUALITY SYSTEMS (equipment & data integrity) L2 MATERIALS TESTINGL3 CODES & REGULATORY REQUIREMENTS L4 TEST SPECIFICATIONS & PROCEDURES L5 TEST PLANS L6 RELIABILITYL7 LAB PRODUCT APPROVAL PROCESS L8 LAB PERSONNAL EXPERIENCEL9PRODUCT EXPERIENCE AND MARKET EXPERIENCEDocument Name:Global Outside Lab QualificationProcedureDate Revised:21-May-08© 20yy – 20yy Whirlpool Corporation. The subject matter shown hereon is disclosed in confidence to the extent it is original with Whirlpool.Disclosure to other parties except in filling Whirlpool orders is forbidden.REQUIREMENT STATEMENTS AND GUIDELINESAs mentioned in the Foreword, this audit was designed to evaluate all three dimensions of a lab ’s capability; the Personnel , Equipment, and Documentation . To achieve this, each assessment page is laid out in the following manner: The “KEY ” statements are the first statements written in “Bold ” letters on top of every page in the assessment. The keyDocument Name:Global Outside Lab QualificationProcedureDate Revised:21-May-08© 20yy – 20yy Whirlpool Corporation. The subject matter shown hereon is disclosed in confidence to the extent it is original with Whirlpool.Disclosure to other parties except in filling Whirlpool orders is forbidden.Key ScoringAs indicated above, all keys have as a scoring technique a series of incremental points. Within each point are a number of ‘criteria statements ’ that correlate directly with increased compliance to the requirements of the key. From point-to-point these criteria build upon each other in a progressive manner toward excellence in the “Key ” subject matter.For the purposes of scoring, to achieve the “point being evaluated ” the auditee must, in the opinion of the Lead Assessor , meet or exceed all of the criteria based statements assigned to it . Only after meeting the current ‘point ’ requirements may the assessor look toward the next level of incremental criteria. Also, as noted above, to aid in scoring decisions, half-point scores (0.5, 1.5, or 2.5) are permissible.If all of the criteria are not met, the score shall be recorded at the previous “point ” level or, as appropriate, at the half-point score between the previous score and the next incremental score. Key ScoringPOINTSCRITERIA0 Non-Existent – System requirements have not been addressed; there is essentially no evidence of implementation or compliance.1 Traditional - System requirements may informally exist but they are unstructured and potentially inefficient. There is minimal compliance toward required standards.2 Learning - Adequate awareness and understanding of the preferred approach with basic proficiency and implementation levels, reasonable documentation.3 Leading – Full awareness and understanding of the preferred approach with effective and efficient implementation levels, solid documentation, an operational model.Lead Assessor QuestionsThe Lead Assessor Questions shown with each key are intended only as “thought provokers ” or “response generators ”. Their sole purpose is to stimulate supplier discussion on the key topic in a manner applicable to the key ’s scoring criteria. They are not meant to be “all inclusive ”; thus a supplier should focus their attention on the scoring criteria and not the lead assessor questions.Overlap of Key ContentFrom time-to-time it is fully expected that the content of various “Keys ” will overlap with the content of similar keys. To a degree, this is planned into the assessment. The repetition of seeing a topic in multiple areas of this assessment simply signifies the importance of its content.While this may spark some discussion regarding fairness of scoring if the auditee has a particular weakness in the duplicated area; it needs to be recognized as well that if the auditee has strength in this area, their strength will be likewise be multiplied throughout the assessment.Document Name:Global Outside Lab QualificationProcedureDate Revised:21-May-08© 20yy – 20yy Whirlpool Corporation. The subject matter shown hereon is disclosed in confidence to the extent it is original with Whirlpool.Disclosure to other parties except in filling Whirlpool orders is forbidden.None, No, Some, Occasional, Most, Majority, All and Always in Criteria Statements:Many of the Results Oriented criteria statements are specifically designed to probe the level of results that the design system should create. There are four levels of evaluation for these questions that contain results oriented requirements. These four levels can be recognized by the use of the words “None, Some, Most and All ” (and their synonyms) in the evaluation criteria. The meaning of these words can be reasonably quantified as shown in the following table:LEVEL RANGE None, no 0 – 5 % Some, occasional 6 - 50 % Most, majority 51 - 85 % All, always86 - 100 %Multiple Outside Lab OperationsIf an Outside Lab has multiple lab operations (i.e. an automotive lab, an appliance lab, a lab for all others, etc.) for the purpose of managing development, cost, and efficiency, the Whirlpool Outside Lab Assessment shall be applied to the section of the Outside Lab ’s business that would typically be utilized to test Whirlpool parts and product.ASSESSMENT STATUSAuditee Status:In addition to the assessment scores, auditees are classified under one of the four different status choices. This status is with regard only to the capability assessment. Additional reviews of specific facility, equipment, fixtures, and test procedure reviews are necessary for final determination of qualification level. These four status choices are Full Qualification , Conditional Qualification, Qualification in Process, and No Qualification . See matrix below:Assessment StatusCriteria(assumes all Keys are being assessed)Full Qualification Assessment that has a minimum score of 2 points or more for each key.Conditional Qualification Assessment that has less than a minimum score of 2 points for any key, but has documented an improvement plan that is acceptable to Whirlpool, with regard to quality and schedule.Qualification InProcessAssessment that is not complete, but plans are in place.No QualificationNo plans or desire to qualify currently.Document Name:Global Outside Lab QualificationProcedureDate Revised:21-May-08© 20yy – 20yy Whirlpool Corporation. The subject matter shown hereon is disclosed in confidence to the extent it is original with Whirlpool.Disclosure to other parties except in filling Whirlpool orders is forbidden.OUTSIDE LABASSESSMENTREQUIREMENTSDocument Name:Global Outside Lab QualificationProcedureDate Revised:21-May-08© 20yy – 20yy Whirlpool Corporation. The subject matter shown hereon is disclosed in confidence to the extent it is original with Whirlpool.Disclosure to other parties except in filling Whirlpool orders is forbidden.KEY #L1 - QUALITY SYSTEM (EQUIPMENT & DATA INTEGRITY)Description: This ‘Key ’ is designed to understand the process for maintaining integrity of their test equipment, test and equipment procedures (work instructions), and test records. Lead Assessor Questions:1. What is your process to calibrate & update laboratory test equipment?2. What is your process for updating test / equipment procedures or work instructions?3. What is your document control process for test records?4. What independent lab certifications or accreditations do you currently hold? (ie. ISO-17025, UL, etc.) 0 pts There is no evidence of test equipment calibrationNo evidence of a process to maintain control of test procedures (work instructions) andtest records.1 ptSome evidence of acceptable test equipment calibration; some examples of expiredcalibration tagsAn informal process to maintain control of test data & documentation exists (procedures,work instructions, etc.).Some test procedures are out-of-date or do not match actual practice2 ptsMost equipment has acceptable calibration and measurement systems analysis evidenceavailableA formal process to maintain control of test data & documentation exists (procedures,work instructions, etc.).Most test procedures are up-of-date and match actual practiceThere exists evidence that key test procedures are reviewed periodically3 ptsThe lab is currently ISO-17025 accredited OR meets the following requirements:All equipment has acceptable calibration and measurement systems analysisevidence availableAll test data (records) is stored in an easily accessible location, controlled through aformal document control system, and are kept for set periods of time (e.g. records retention)All test procedures are up-of-date and match actual practiceAll test procedures are reviewed per schedule or process trigger (evidence required) Equipment is calibrated based upon MSE / MSA needs or control chartingNotes* - calibratedbased upon factual, demonstrated evidence that ‘control ’ has been lost in the measurement device as opposed to calibration based upon a selected time interval.Document Name: Global Outside Lab QualificationProcedureDate Revised: 21-May-08© 20yy – 20yy Whirlpool Corporation. The subject matter shown hereon is disclosed in confidence to the extent it is original with Whirlpool.Disclosure to other parties except in filling Whirlpool orders is forbidden.KEY #L2 – MATERIALS TESTINGDescription: The Auditee may be expected to have a fully equipped materials testing lab to analyze and test materials for proper formulation and material properties analysis during design and development. Expected scope would be materials applicable to the industry of the products being tested.Lead Assessor Questions:1. What material testing capability do you have at this location?2. Do you have all the material testing equipment needed for your products?3. Do you have plans to update the materials testing lab? 0 pts There are no materials testing capabilities at this locationAll materials are contracted out for testing and/or analysis1 ptsSome material testing is completed at this locationThe more difficult material testing is contracted outMost auditee test personnel have less than (2) years of test experienceMost materials testing is done based upon informal, unapproved procedures2 pts Most materials testing is completed at this locationMost material testing is completed with formal, detailed test procedures and analysisreports.Most test result records are archived for future referenceSome auditee test personnel have greater than (5) years of test experienceSome test personnel have (2) or more years of formal college training3 pts All material testing is completed with formal, detailed test procedures and analysisreports.All test result records are archived for future referenceAll test result records are archived and easily retrieved for future referenceSome auditee test personnel have greater than (10) years of test experienceMost test personnel are degreed engineersNotesDocument Name: Global Outside Lab QualificationProcedureDate Revised: 21-May-08© 20yy – 20yy Whirlpool Corporation. The subject matter shown hereon is disclosed in confidence to the extent it is original with Whirlpool.Disclosure to other parties except in filling Whirlpool orders is forbidden.KEY #L3 – CODES & REGULATORY REQUIREMENTSDescription: This ‘Key ’ is intended to understand how codes and regulatory requirements are implemented and validated at the auditee ’s facility. It also is intended to assess the competency of personnel associated with the codes and regulatory operations.Lead Assessor Questions:1. Please describe the methods used in your product development group to ensure adherence to regulatory agency codesand product safety requirements.2. Please describe your level of certification (of lab and technicians) by appropriate codes agencies (e.g. UL, CSA, IEC,etc.).0 pts No identified codes function at this design locationNo codes agency certification of lab and/or technicians Auditee expects all codes & regulatory requirements to be their customer ’s responsibility 1 ptSome engineering change notice approvals include a sign-off from a codes/safety standpoint There is some evidence that outside codes houses are leveraged to minimize the risk that regulatory gaps may exist 2 ptsSome codes engineer(s) are in place at auditees design facility Some codes agency certification of auditees lab and/or technicians – or - some evidence that outside codes houses are leveraged Most engineering change notices are reviewed and signed-off by a codes/safety expert Most codes requirements are completed by product release Most code engineer test requirements are fully documented 3 ptsLead codes engineer has more than 5 years experience in the Product Approval and Lab Operations All engineering change notices AND temporary change authorizations have a codes/safety sign-off All appropriate labs and technicians are certified by regional appropriate codes agency All codes requirements are completed by product release All code engineer test requirements are fully documented NotesDocument Name: Global Outside Lab QualificationProcedure Date Revised: 21-May-08© 20yy – 20yy Whirlpool Corporation. The subject matter shown hereon is disclosed in confidence to the extent it is original with Whirlpool.Disclosure to other parties except in filling Whirlpool orders is forbidden.KEY #L4 - TEST SPECIFICATIONS & PROCEDURESDescription: Test specifications and procedures are the backbone of the testing and validation process. Their accuracy and use drive the verification and fitness for use decisions that must be made for new and revised products. This key investigates the auditee ’s test specification management system.Lead Assessor Questions:1.What is your process to develop and update test specifications? 1.Is there linkage of test specifications to customer needs? 2.How is data from the field used to create or improve specifications? 3.Who reviews newly created specifications prior to formal release? What is their authority? 4.How are specifications / test procedures reviewed over time? 5. What independent lab certifications or accreditations do you currently hold? (ie. ISO-17025, UL, etc.)0 ptsThere is no process to develop or update test specifications 1 pt There is limited input from design, customer, and field test results into test specificationcreationTest specifications are informally written by individuals who individually put them to useProcedures / test specifications are informally reviewed2 pts A formal process exists for the development and updating of test specifications; however, itmay not always be used as individually generated test specifications still occasionally existThere is some input from ‘the customer ’ and ‘field test results ’ into test specificationdevelopmentThere is some collaboration between design and the lab organizations in test specificationcreationReleased procedures / test specifications are formally reviewed to ensure correctness;review schedule is variable3 pts The lab is currently ISO-17025 accredited OR meets the following requirements:A formal, approved process for the development and updating of specifications existsand its use is a business requirement.Most specifications are developed based upon customer intended functions and are tiedto customer needs / benefits with historical data from the fieldA great deal of collaboration exists between design and lab organizations in testspecification creationReleased procedures / test specifications are regularly reviewed by a cross-functionaltechnical team according to a developed scheduleNotesDocument Name: Global Outside Lab QualificationProcedureDate Revised: 21-May-08© 20yy – 20yy Whirlpool Corporation. The subject matter shown hereon is disclosed in confidence to the extent it is original with Whirlpool.Disclosure to other parties except in filling Whirlpool orders is forbidden.KEY #L5 – TEST PLANSDescription: This ‘Key ’ evaluates the process used to develop and implement test plans for testing and approving products that meet customer requirements. It includes how test plans are continuously improved with new requirements such that results achieved from approved product lead to better products.Lead Assessor Questions:1.How are test plans for new features / products developed? Who has input to their creation? 2.Please describe how DFMEA ’s provide directional content to the creation of your test plans. 3.Is there a standardized template used for test plan development? 4.When in the development cycle are test plans created and how are they linked to the customer specifications? 5.Are new tests developed when new specifications are created? 0 ptsAuditee has no formal test plans - they do minimal testing Auditee does not create their own test plans (customer assumes this responsibility) 1 pt Evidence shows only standard tests are used and minimal or no critical thought is given for newtests.Tests plans are typically created close to product launch (reacting to the timetable)The Product Approval Group & Design Engineering only occasionally interact in test plandevelopmentThere is evidence that DFMEA ’s are used in some test plan creation.2 pts Test plans are based on prior test documents; no specific regional /global template is usedNew, unique tests are developed for unique features or new product based upon customerinsightsSome test plans are developed early in the process.Test plans are jointly developed between the Product Approval Group and Design EngineeringGroup with the Product Approval Group having the overall authority on most test plan content.There is some test plan coordination / interaction with customers (i.e. effect on other customerparts).There is evidence that DFMEA ’s are used in most test plan creation.3 ptsTest plan development template (w/standard tests) used to drive critical thought for all projecttest plans.There is clear evidence of new tests proactively developed and based upon customer insights.These tests are shown to be linked to newly developed product specificationsTest plans are jointly developed with the Product Approval Group and Design Engineering, andit is clearly documented that the Product Approval engineer has the final authority on all test plan content.There is considerable test plan coordination / interaction with customers (i.e. effect on othercustomer parts).There is evidence that DFMEA ’s are used in all test plan creation.Most test plans are developed early in the process.。

HSD070IDW1-E13 Formal Specification v1.0 for Golden Supreme

2.1.2
Back-Light Unit Item LED current LED voltage
Symbol IL VL
Typ. 180 10.5
Max.

Unit mA V
Note (1) (2)(3) (1) (2)(3)
Note (1) Permanent damage may occur to the LCD module if beyond this specification. Functional operation should be restricted to the conditions described under normal operating conditions. (2) Ta =25±2℃ (3) Test Condition: LED current 180 mA. The LED lifetime could be decreased if operating IL is larger than 180mA.
Contents
1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 General description ……………………………….… Absolute maximum ratings …………………………. p.4 p.5 p.6 p.10 p.11 p.13 p.23 p.24 p.26 p.27 p.28
2.2 Environment Absolute Rating
Item Operating Temperature Storage Temperature Symbol Topa Tstg Min. -20 -30 Max. 70 80 Unit ℃ ℃ Note

最准确银行常用单词中英文对照

最准确银行常用单词中英文对照第一篇：最准确银行常用单词中英文对照本外币活期存款 RMB/foreign currency current deposit、本外币定期存款RMB/foreign currency time deposit 本外币通知存款RMB/foreign currency call deposit 协定存款 agreement deposit 固定资产贷款fixed asset loan 房地产开发贷款housing developing loan 单位流动资金贷款 working capitals loan 转贷款 transfers loan 银团贷款syndicated loan 委托贷款entrusted loan 票据贴现bill discount 证券公司股票质押贷款stock mortage loan 进口押汇import finance 出口押汇 export finance 打包贷款 packaging loan 外币存单质押贷款foreign exchange deposit certificate mortage loan 现金收付业务 cash/non-cash receiving and paying 银行汇票banks bill of exchange 银行本票banks promissory note 支票check 商业汇票commercial bill of exchange 汇兑（信汇、电汇）transfers（mail transfers、telegraphic transfers）票据承兑acceptance of bill 资信证明业务credit proof 代发工资wages paying 代理发行 agency of issuing 兑付债券 redeeming bond 代收公用事业费public utility charge collection 网上银行业务online banking 进口开证import letter of credit 进口代收import collection 出口信用证通知 advice of export letter of credit 出口信用证议付negotiation of export letter of credit 出口托收export collection 外汇光票托收 foreign exchange bill collection 外汇汇入汇款 foreign exchange outgoing remittance 外汇汇出汇款 foreign exchange incoming remittance 提货担保 shipping guarantee 银行保函 letter of guarantee 备用信用证standly letter of credit 结售汇money exchange 活期储蓄 current saving 定期储蓄 time saving 个人通知存款 individual call deposit 定期一本通 fixed time book 兴业卡存取款 depositing/drawing though XINGYE card POS消费转帐业务 POS consumptive transfers 银证通 transfer between bankand security company 银期通 transfer between bank and futures company 个人外汇买卖 personal money exchange 个人存款证明业务personal deposit proof 个人住房按揭贷款Personal housing mortgage loan 住房装修贷款 house renovation loan 个人有价单证质押贷款 personal valued certificate mortgage loan 汽车消费贷款automobile consumptive loan 个人旅游贷款personal travelling loan 个人商用房贷款 personal commercial housing loan 个人授信额度贷款 personal credit facility第二篇：管理学中英文单词对照[范文]第一章管理总论 Manager 管理者First-line managers 基层管理者 Middle managers 中层管理者Top managers 高层管理者Management 管理Efficiency 效率Effectiveness 效果Planning 计划Organizing 组织Leading 领导Controlling 控制Management process 管理过程 Management roles 管理角色Interpersonal roles 人际关系角色 Informational roles 信息传递角色Decisional roles 决策制定角色Technical skills 技术技能Human skills 人事技能 Conceptual skills 概念技能 System 系统Closed systems 封闭系统Open systems 开放系统Environment 环境Special environment 具体环境 General environment 一般环境Contingency perspective 权变观 Organization 组织 Universality of management 管理的普遍性Nonmanagerial employees / Operatives 操作者第二章管理的历史Division of labor 劳动分工Industrial revolution 产业革命Scientific management 科学管理Therbligs 基本动作元素General administrative theorists 一般行政管理理论家Principles of management 管理原则 Bureaucracy 官僚行政组织、层级组织Quantitative approach 定量方法Organizational behavior(OB)组织行为Hawthorne Studies 霍桑研究Workforcediversity 员工多样化 Entrepreneurship 企业家e-business(electronic business)电子商务e-commerce(electronic commerce)电子贸易、电子商务Intranet 内部互联网Total quality management(TQM)全面质量管理Learning organization 学习型组织Knowledge management 知识管理Workplace spirituality 团队精神第三章计划 Decision 决策Decision-making process 决策过程 Problem 问题Decision criteria 决策标准Implementation 实施Rational decision making 理性决策Bounded rationality 有限理性Satisficing 满意Escalation of commitment 承诺升级 Intuitive decision making 直觉决策Well-structured problems 结构良好问题Programmed decision 程序化决策 Procedure 程序 Rule 规则 Policy 政策Poorly structured problems 结构不良问题Nonprogrammed decisions 非程序化决策 Certainty 确定性 Risk 风险性Uncertainty 不确定性 Directive style 指导性风格 Analytic style 分析性风格 Conceptual style 概念性风格 Behavioral style 行为性风格 Planning 计划 Goals 目标 Plans 计划Strategic plans 战略计划Operational plans 作业计划Long-term plans 长期计划 Short-term plans 短期计划 Specific plans 具体性计划 Directional plans 指导性计划 Single-use plan 单一目标计划 Standing plans 标准计划Traditional goal setting 传统目标设定 Means-ends chain 手段－结果链Management by objectives(MBO)目标管理 Mission 使命Commitment concept 承诺概念Formal planning department 正式计划部门Strategic management 战略管理Strategic management process 战略管理过程Opportunities机会 Threats 威胁Core competencies 核心能力 Strengths 优势 Weaknesses 劣势SWOT analysis SWOT分析Corporate-level strategy 公司层战略 Stability strategy 稳定战略 Growth strategy 增长战略Related diversification 相关领域多元化经营Unrelated diversification 不相关领域多元化经营 Retrenchment strategy 收缩战略BCG matrix BCG矩阵波士顿咨询集团矩阵Business-level strategy 事业层战略Strategic business units 战略经营单位Competitive advantage 竞争优势 Cost leadership strategy 成本领先战略 Differentiation strategy 差异化战略 Focus strategy 集中化战略Functional-level strategy 职能层战略 Environmental Scanning 环境扫描Competitor intelligence 竞争者情报、竞争者信息 Forecasts 预测Quantitative forecasting 定量预测 Qualitative forecasting 定性预测 Forecasting Techniques 预测技术 Benchmarking 基准化、标杆 Resources 资源 Budget 预算Revenue Budgets 收入预算 Expense Budgets 费用预算 Profit Budgets 利润预算 Cash Budgets 现金预算 Scheduling 进度计划、规划 Gantt Charts 甘特图 Load Charts 负荷图PERT network 计划评审技术网络Events 事件Activities 活动Slack time 松弛时间 Critical path 关键线路Breakeven analysis 盈亏平衡分析 Linear programming 线性规划 Project 项目Project Management 项目管理 Scenario 设想方案第四章组织Organizing 组织Organizational structure 组织结构 Organizational design 组织设计 Work specialization 劳动分工 Departmentalization 部门化Functional departmentalization 职能部门化Product departmentalization 产品部门化Geographical departmentalization 地区部门化Process departmentalization 过程部门化Customer departmentalization 顾客部门化Cross-functional teams 跨职能团队 Chain of command 指挥链 Authority 职权Responsibility 职责Unity of command 统一指挥Span of control 管理幅度Centralization 集权化Decentralization 分权化Formalization 正规化Mechanistic organization 机械式组织 Organic organization 有机式组织Unit production 单件生产Mass production 大量生产Process production 连续生产 Simple structure 简单结构 Functional structure 职能型结构 Divisional structure 分部型结构 Team-based structure 团队结构 Matrix structure 矩阵结构 Project structure 项目结构Autonomous internal units 内部自治单位Boundaryless organization 无边界组织 Learning organization 学习型组织High-performance work practice 高绩效的工作实践Human resource management process 人力资源管理过程 Labor union 工会Human resource planning 人力资源规划 Job analysis 职务分析Job description 职务说明书Job specification 职务规范Recruitment 招聘 Decruitment 解聘Selection process 甄选过程 Validity 效度 Reliability 信度 Work sampling 工作抽样 Assessment centers 测评中心 Orientation 定向、导向Performance management system 绩效管理系统Written essay 书面描述法Critical incidents 关键事件法Graphic rating scales 评分表法Behaviorally anchored rating scales(BARS)行为定位评分法Multiperson comparisons 多人比较法 Group order ranking 分组排序法 Individual ranking 个体排序法 Paired comparison 配对比较法360 degree feedback 360度反馈skill-based pay 按技能付酬Career 职业生涯、职业Organizational change 组织变革Change agents 变革推动者Organizational development(OD)组织发展Stress 压力Creativity 创造 Innovation 创新第五章领导 Behavior 行为Organizational behavior 组织行为学 Attitudes 态度Cognitive component 认知成分 Affective component 情感成分Behavioral component 行为成分Job satisfaction 工作满意度Job involvement 工作投入Organizational commitment 组织承诺Organizational citizenship behavior(OCB)组织公民行为Cognitive dissonance 认知失调Attitude surveys 态度调查Personality 人性Big-five model 重要的五大模型 Emotional intelligence(EI)情感智商 Locus of control 控制点Machiavellianism 马基雅维里主义Self-esteem 自尊Self-monitoring 自我监控 Perception 知觉Attribution theory 归因理论Fundamental attribution error 基本归因错误 Self-serving bias 自我服务偏见 Selectivity 有选择地接受、选择性 Assumed similarity 假设相似性 Stereotyping 刻板印象 Learning 学习Operant conditioning 操作性条件反射 Social learning theory 社会学习理论 Shaping behavior 行为塑造 Motivation 动机 Need 需要Hierarchy of needs theory 需要层次理论 Physiological needs 生理需要Safety needs 安全需要Social needs 社会需要Esteem needs 尊重需要Self-actualization needs 自我实现需要 Theory X X理论 Theory Y Y理论Motivation-hygiene theory 激励－保健理论Hygiene factors 保健因素 Motivators 激励因素Three-needs theory 三种需要理论Need for achievement(nAch)成就需要Need for power(nPow)权力需要Need for affiliation(nAff)归属需要 Goal-setting theory 目标设定理论 Reinforcement theory 强化理论 Reinforcers 强化物 Job design 职务设计Job scope 职务范围Job enlargement 职务扩大化Job enrichment 工作丰富化 Job depth 职务深度Job characteristic model(JCM)职务特征模型 Skill variety 技能多样性Task identity 任务同一性Task significance 任务重要性Autonomy 自主性 Feedback 反馈Equity theory 公平理论 Referents 参照对象 Expectancy theory 期望理论 Compressed workweek 压缩工作周 Flexible work hours 弹性工作制Job sharing 职务分担Contingent workers 应急工Telecommuting 电子通信，远程办公Pay-for performance programs 基于绩效的薪酬管理Open-book management 公开帐簿管理 Leader 领导者 Leadership 领导Behavioral theories 行为理论Autocratic style 权威式Democratic style 民主式Laissez-faire style 放任式Initiating structure 定规维度 Consideration 关怀维度High-high leader 高－高型领导者 Managerial grid 管理方格论Fiedler contingency model 菲德勒权变模型Least-preferred co-worker(LPC)questionnaire 最难共事者问卷Leader-member relations 领导者－成员关系，上下级关系Task structure 任务结构 Position power 职位权力Situational leadership theory(SLT)情景领导理论 Readiness 准备状态 Maturity 成熟度Leader participation model 领导者参与模型 Path-goal theory 路径－目标理论Transactional leaders 事务型领导者Transformational leaders 变革型领导者 Charismatic leader 超凡魅力的领导者 Visionary leadership 愿景领导者 Legitimate power 法定权 Coercive power 强制权 Reward power 奖赏权 Expert power 专长权 Referent power 模范权 Credibility 可信度 Trust 诚信、信任Empowerment 授权 Communication 沟通Interpersonal communication 人际沟通Organizational communication 组织沟通 Message 信息 Encoding 编码 Channel 通道、渠道 Decoding 解码Communication process 沟通过程 Noise 噪音Nonverbal communication 非言语沟通 Body language 体态语言 Verbal intonation 语调 Filtering 过滤Selective perception 选择性知觉 Information overload 信息超载 Jargon 行话Active listening 积极倾听Formal communication 正式沟通Informal communication 非正式沟通 Downward communication 下行沟通、向下交流Upward communication 上行沟通、向上交流Lateral communication平行沟通、横向交流Diagonal communication 斜行沟通、越级交流 Communication networks 沟通网络 Grapevine 小道信息、谣言 E-mail 电子邮件Instant messaging(IM)即时信息 Voice mail 声音邮件 Fax 传真Electronic data interchange(EDI)电子数据交换Teleconferencing 电信会议Videoconferencing 视频会议Intranet 内部互联网 Extranet 外部互联网第六章控制 Control 控制Market control 市场控制Bureaucratic control 官僚组织控制、层级控制 Control process 控制过程Management by walking around(MBWA)走动式管理 Range of variation 偏差范围Immediate corrective action 立即纠正行动Basic corrective action 彻底纠正行动 Feedforward control 前馈控制Concurrent control 同期控制、现场控制 Feedback control 反第三篇：银行常用语中英文对照中国民生银行新街口支行China Minsheng Banking.Cop., LTD 网银体验区E-Banking Experience Zone 暂停服务，请稍后Out of Service, Please Wait 自动存取款机Automatic Withdraw/Deposit Machine 请刷卡 Please Swipe Card 营业时间 Business Hour 对公 For Corporate 储蓄 Saving 24小时自助服务Hour Self Service中国银行 Bank of China 新街口对公业务CORPRATE BANKING（拼写错误）节假日不办理Public Holiday Closed 个人业务 PRIVATE BANKING 节假日营业时间 Public Holiday Opening Hours 理财服务 Wealth Management 私人金融业务 Personal Banking 领取汇票 To draw the draft here 汇兑 EXCHANGE & TRANSFER 印鉴挂失 Report of lost seal 密码挂失Report of lost password 存款证明 Certificate of Deposit 10元/笔/份/张RMB 10 per item 退汇Refunding 挂失止付（汇票）Loss reporting and payment stopping(draft)存入收款人现汇账户Credit the payee’s amount of spot exchange 代售Agency sale 买汇Exchange purchase 光票托收Clean collection 现钞托收Banknote collection 退票Dishonor 年费Annual Fee 工本费（包括开卡和补发）Service Charge(card issue and replacement)个人人民币汇款Personal RMB remittance(CASH)人民币对公结算The Corporate settlement of RMB 外币对公结算The Corporate settlement of Foreign Exchanges 银行卡服务业务The custom service of bank card 服务星级SERVICE LEVEL 您对本次服务的评价PLEASE LEAVE YOUR VALUABLE OPINIONS 满意SATISFACTORY 基本满意AVERAGE 不满意DISSATISFIED 代保管业务SAFE DEPOSIT DEPT.货币兑换EXCHANGE 24小时自助服务hour self-service banking 理财Wealth Management 兑换机EXCHANGE MACHINE 自动取款机AUTOMATIC TELLER MACHINE 请将银行卡正确插入插卡处Insert your card into the slot correctly 输入正确密码（请注意安全防止他人窃取）Input your correct password(watch out to avoid being peeped)按屏幕提示进行转账、存折补登、代缴费、查询业务Make transfer, entry account to passbook, payment, and query according to the direction on the screen.出门请按钮（一按即放）PLEASE PRESS THE BUTTON(PRESS THEN REALASE)灭火器箱FIRE EXTINGGUISHER BOX东亚银行 The Bank of East Asia（China）Ltd.新街口 24小时自助服务Hour Banking Services 南京分行 Nanjing branch 营业时间Banking Hour 投诉箱 Complain Box 小心地滑Slippery Floor 请在此排队Please Queue Here 个人理财服务 Personal Financial Services 企业银行服务Corporate Banking 企业及银团贷款部Corporate Lending and Syndication Department 房地产贷款部Property Lending Department 贸易融资部Trade Finance Department 柜台服务Counter Services 小心地滑CAUTION WET FLOOR交通银行 Bank of Communications新街口 24小时自助服务Self Service Banking进门请刷卡，无需输密码Please Insert Your Card For Entry 营业时间Business Hour星期六、日休息Closed on Saturday and Sunday 储蓄时间Business Hours for Savings Deposits 存取款一体机Cash Recycling Machine 金融快线BOCOM EXPRESS 自动终端Multimedia Self Banking 现金服务Cash-related Services 对公服务Corporate Banking 交行理财BOCOM Fortune 交通银行湖南路对私服务Private Banking 理财服务Financing Service 外汇兑换Foreign Exchange 注意自动门Caution Automatic Door 中国建设银行China Construction Bank 新街口外汇储蓄营业点Foreign Currency Deposit Taking Office 24小时自助服务Hour Self Banking 中山路支行Zhongshan Road Sub-branch 对公服务Corporate Banking 节假日不办理Public Holiday Close 个人业务Private Banking 周一至周五Monday to Friday 节假日营业时间Public Holiday Operate Hours 个人理财中心Personal Finance Center 现役军人优先Servicemen Priority 大堂经理Lobby Leader 客户服务电话Customer Service Hotline 残疾人优先窗口Particular Counter for the Disabled 个人业务顾问Personal Banker 叫号机Queuing Machine 存款机Cash Deposit Machine 自动门Automatic江苏银行Bank of Jiangsu 总行营业部Headquarters Business Dept.广东发展银行玄武支行Guangdong Development Bank对公业务CORPORAT SERVICE拼写错误储蓄业务PRIVATE SERVICE 营业时间BUSINESS HOURS 24小时自助服务HOURS SELF-SERVICE 银行提示REMINDER请妥善保管银行卡和密码Please Safeguard Your Bank Cards and PIN 安全提示 SafetyHints 个人服务 Personal Banking 对公服务 Corporate Banking VIP服务VIP Banking 等候区Waiting Area上海浦东发展银行Shanghai Pudong Development Bank新街口对公业务Corporate Banking 个人业务Personal Banking 营业时间Business Hour 理财经理Financial Planner 叫号机Cueing Machine 24小时自助服务 Self Service Banking 现金业务Teller Counter 公司业务Corporate Account 等待区Waiting Area 理财专区Wealth Management Service 自助银行Self-service Banking 大堂经理Duty Manager中国工商银行Industrial and Commercial Bank of China 自助服务银行Self-service Banking 大堂经理CLIENT MANEGER 现金服务 CASH SERVICE华夏银行Huaxia Bank 新街口对公业务Wholesale Banking Service 对私业务Retail Banking Service 等待区Waiting Areas 保管箱Safe Deposit Box 自助银行区Self-service Areas长江路支行储蓄*出纳Savings 出纳Cash 涉外服务For Foreigners 保管箱Safe keeping box 收费项目Items 开卡工本费Administrative charge for card activation 补卡工本费Administrative charge for card replacement 卡挂失手续费Administrative charge for card loss reporting.免费Free of charge 每笔十元The charge is 10 yuan per transaction 外汇业务Foreign Exchange Business 汇入/汇出汇款Inward/Outward Remittance 多币种汇款Multiple currency remittance 电子邮件通知Email Notification 强行改密（密码挂失）Overriding change of password(loss of password)异地柜台存款Exterritorial counter deposit 取款Withdrawal 卡卡转账Card-Card Transfer 跨行取款Inter-bank withdrawal 跨行查询Inter-bank enquiry 退汇Rejected Remittance 止付Payment termination 自动取款机Self-Drawing 自动存款机Self-Saving 服务流程图Service Flow Chart 华夏银行湖南路营业时间Opening Time 节假日不营业Weekend/Holiday Closed渣打银行Standard Charted Bank 新街口业务办理时间Banking Hours 理财咨询时间Financial Consultancy Hours 投诉热线Complaint Hotline 电话银行服务Phone Bank Service中国邮政储蓄China Postal Savings浮桥外币储蓄点Foreign Deposit Service Available 意见箱Suggestion Box 业务办理Postal Service深圳发展银行Shenzhen Development Bank新街口自动查询缴费机Automatic Inquiry Payment Machine 营业时间Business Hours 存取款一体机CRS 大堂经理Lobby Manage 填单处Form Filling Area 业务咨询处Information 个人柜台Personal Banking Counter 本行网址Bank Web Address 网点咨询电话Network Information 非本行人员莫入Only Stuff自动取款机操作指引ATM Operational Guide 服务热线Service Line 存取款机操作指引CRS Operation Guide招商银行China Merchants Bank 营业时间Business Hours 个人营业时间Personal Business Hours 对公营业时间Corporate Business Hours 节假日照常营业Holiday Business as Usual 自助服务区Self Service Area 监督Oversight 理财中心Premier Customers 投诉Complaints 全国统一客户服务电话China Client Service Telephone 综合业务Integrated Services 代发业务Salary Release Service 现金快速通道Fast Track Deposit and Withdrawal 接待区Reception 理财服务区Financial Services 个人贷款业务咨询Personal Loan Business Consultant 会计结算Accounting Settlement 个人理财专柜Wealth Management Area 一卡通金卡业务All-in-one-card gold card service.储蓄专柜Cashier Service 因您而变We are here just for you光大银行China Everbright Bank新街口营业时间Customer Service 个人业务Retail Service 出纳Cashier 会计结算Accounting 理财缴费机Self Help Machine for Paying Bill 现金存取款机Cash Deposit & Drawing Machine 现金取款机Cash Drawing Machine 多媒体查询机Multi-media Checking Machine 取款机操作提示Note for ATM Operation南京银行Bank of Nanjing 新街口综合业务General Services 私人业务Personal Banking 公司业务Corporate Banking 国际业务International Banking 大堂经理Reception Manager 现金取款机Cash Drawing Machine 现金存取款机Cash Deposit & Drawing Machine 自助服务终端Self-help Service Terminal 操作说明Operating Instruction中信银行China Citic Bank湖南路营业时间Business Time 储蓄时间Deposit Time 大堂经理HALL MANAGER 对公业务Corporating Banking Business 对私业务Retail Banking Business 现金结算Cash Settlement 24小时服务热线Hour Hotline 紧急按钮Emergency Button中国农业银行Agricultural Bank of China 现金服务区Cash Service 自助服务区Self-Service Area 客户等候区Customer Waiting Area 咨询引导区Consulting Area 保管箱Lock Box 24小时自助服务Hours Banking 自助服务终端Self-service Terminal 操作指南Operation Instructions 插卡Insert card 输入密码Key in PIN湖南路查询Inquiry 转账Account Transfer 改密Modify PIN 挂失Reporting a loss 理财卡Wealth Management Card 查询子帐户Inquiry Subaccount 通知存款Call Deposit 外汇查询Foreign Exchange Inquiry 市价交易Market price transaction 委托Request 银证Banxecurity第三方存款The third partysafe keeping 银期转账Bank-option account transfer 银行转期货Bank-to-futures 查期方余额Inquiry the balance of the future 输入账号、密码Input account number, password 代缴费Charging service as agents 存折补登The passbook renewed 交易结束Transaction end 退出、取卡或存折Exit, take card or passbook 无卡存折Non-card deposit 核对户名Check Username 放入现金Put in Banknote 核对张数、金额Check up number of sheets, account 确认存款Confirm the deposit 活期存折Demand account for passbook 活期/定期Demand account/Time account 自动存取款机Automatic Deposit and Withdrawal Machine 自动取款机Automatic Teller Machine 自助服务终端使用说明User’s guides for Self-service Terminal 本机只受理农行金穗系列卡和存折等业务Kin card series and passbook of Agriculture Bank of China only 本机不能办理存取款业务Non-cash Business 客户热线Custom Service Hot-line 本机可受理加入“银联”的其他银联卡This machine can handle any “union pay” card 请妥善保管好银行卡和密码，在使用时请用时候身体挡住他人视线，谨防他人窥视您的密码Please take of your bank card and PIN, guide against others peeping your PIN while using the card 每次取款上限2000元，每日累计最多取款十次，每日累计取款限额20000元Ceiling of 2000 yuan per withdrawal, with 10 times at most, for amount of 20000 limit per day 存款现钞面额仅限100元Deposit domination: 100 yuan only 请不要将残币、不平整的钞票或其他异物放入本机Please do not put the damaged, untidy banknotes or things other banknotes into this machine.如遇机器吞卡，请于次日持本人有效证件到营业厅柜台领取In case of card-swallowing, please go to the business hall with your own identity documents to take back your card the next day恒丰银行Evergrowing Bank湖南路中国人寿保险股份有限公司China Life Insurance Company Limited第四篇：各类茶叶品种中英文单词翻译对照(音标)茶学专业英语词汇茶叶品种 Tea varietiesTea 茶Green tea 绿茶 Black tea 红茶White tea 白茶Scented tea花茶Pu'er tea；Pu Erh tea；Puu Eel tea普洱茶 Yellow tea 黄茶Dark tea黑茶 Sincha 新茶Yü-chien tea 雨前茶 Teabag 袋泡茶Mugi-cha 大麦茶 Herbal tea [ˈɜ:rbl]花草茶Jasmine tea 茉莉花茶 Chrysanthemum tea [krɪˈsænθəməm,-ˈzæn-]菊花茶Block Puer tea 普洱（砖）Aged Pu'er tea 陈年普洱Oolong tea；Oulung tea 乌龙茶 Bohea tea [boʊ'hi:] 武夷茶Hyson Tea 熙春茶 Kungfu Tea；Gongfu Tea 功夫茶Twankay Tea [ˈtwæŋkei]屯溪茶 Keemun Tea;Qimen tea 祁门茶Loungjing Tea； Longjing Tea；Lung Ching tea 龙井茶Drogon Well 是对“龙井”这一名词的非正规翻译，不建议使用。

Agile specification-driven development

Agile Speciﬁcation-Driven DevelopmentJonathan S.Ostroff1,David Makalsky1,and Richard F.Paige21Department of Computer Science,York University,Canada.{jonathan,dm}@cs.yorku.ca2Department of Computer Science,University of York,UK.paige@Abstract.We present an agile approach to Speciﬁcation-Driven Development,which combines features of Test-Driven Development and the plan-based ap-proach of Design-by-Contract.We argue that both tests and contracts are differenttypes of speciﬁcations,and both are useful and complementary for building highquality software.We conclude that it is useful for being able to switch betweenwriting tests and writing contracts,and explain how Speciﬁcation-Driven Devel-opment supports this capability.1IntroductionTraditional software development methods stress the elicitation and documentation of a “complete”set of requirements,followed by architectural and high-level design,coding, inspection and testing.This general approach is sometimes described as plan-driven de-velopment.Agile methods were a reaction to these traditional“documentation driven, heavyweight software development processes”[2],focusing on an iterative design pro-cess with rapid feedback in which code appears early[15].In this paper,we describe an integrated approach,Speciﬁcation-Driven Develop-ment(SDD),which combines the best features of the agile Test-Driven Development (TDD)methodology with the best features of the plan-driven approach of quality-ﬁrst Design-by-Contract(DbC)[11].The emphasis in TDD is the production of executable tests that act as restricted emergent speciﬁcations of collaborative behaviour.DbC em-phasises a concept of contract,which can be represented using constructs such as pre-conditions,postconditions,and class invariants for explicitly specifying expected be-haviour.Atﬁrst glance,TDD and DbC conﬂict,or,as one authority put it: If it’s a matter of gut feeling,then mine is that the two approaches,testﬁrst and Design by Contract,are the absolute extreme opposites with no combina-tion possible or desirable.It’s nice once in a while to see a real irreconcilable opposition[13].We attempt to show that not only are TDD and DbC compatible,but that each can enhance the other.In SDD,both unit tests and contracts are speciﬁcations,and there are advantages to using each type of speciﬁcation in producing reliable systems.TDD is superior for capturing complex emergent behaviour(e.g.,trace behaviour)that cannot easily be expressed statically with contracts;DbC is superior for completely specifyingbehaviour.The two approaches are compatible:both TDD and DbC are iterative and are based on the view that it is important to produce working code as soon as possible.We make our arguments in the context of the Eiffel language which has DbC built-in.But,DbC works in other languages such as Java as well[7].2Plan-Driven DevelopmentThe conventional,systematic plan-driven approach to software development is inherited from systems engineering.Plan-driven development approaches,such as DbC,stress the elicitation and documentation of a complete set of requirements,followed by archi-tectural and high-level design.Code and tests often appear at the tail end of the pro-cess.The gap between requirements and code is thus bridged by speciﬁcations,which describe constraints on behaviour shared between the physical world and the system. Iterations between writing speciﬁcations and coding are often encouraged.Incremen-tal approaches to plan-driven development have been adopted,but all still emphasise documentation and traceability between requirements,speciﬁcation,and code.Plans can be written in a variety of ways,including structured natural language, UML class and sequence diagrams,and formal methods.There is an associated cost with applying mathematical techniques;in general,it is much more than testing with the beneﬁt of obtaining higher quality[3].The economic reality is that for most software development,testing and inspections trump formal speciﬁcations.In plan-driven approaches,complete documentation brings with it two main prob-lems.First,there is the problem of keeping the documentation consistent with changes in the design and code.And second,there is the sheer volume of documentation that must be produced.Analysts must document the requirements,designers must create the design speciﬁcations,and programmers must document their code.At each stage,addi-tional detail must be added as we do not know who will be reading the documentation; it may therefore be safer to err on the side of caution.2.1Design by ContractDbC is a form of plan-driven development that naturally lends itself to agile develop-ment because of the way in which its documentation is expressed.It also has almost all the beneﬁts of mathematical methods–and these are formidable for emphasising software qualityﬁrst–without the associated cost.Contracts on software are written using preconditions,postconditions and class invariants,providing mathematical spec-iﬁcations.These contracts are written in the assertion language of the programming language itself,and are therefore executable;contracts are thus a form of the best kind of documentation,that which executes with the code,and which is always guaranteed to be consistent with the code(otherwise an assertion violation would arise at run-time).Suppose we need to calculate the square root of a real number to four decimal places.Fig.1provides an example illustrating how this might be done using contracts.There are many beneﬁts to using contracts to document software:contracts are checked every time the code is executed(and violations are immediatelyﬂagged);com-ponents are self-documenting because the contracts are part the documentation(andclass MATH featuresquare_root(x:DOUBLE):DOUBLE isrequire x>=0do--your algorithm goes here, e.g.,Newton’s methodensure(Result*Result-x).abs<=epsilon;epsilon=old epsilonendepsilon:DOUBLE--accuracyinvariant0<epsilon and epsilon<=0.001end--MATHFig.1.Example of a contract for class MATHinconsistency between code and contracts is impossible).And The beneﬁts of using contracts to document software are as follows:contracts provide design rules for main-taining and modifying the behaviour of components,cf.,behavioural subtyping,and a basis for formal veriﬁcation.In[11]Meyer describes the“quality-ﬁrst”DbC design method.Meyer implements quality-ﬁrst DbC using Eiffel and the BON visual modelling language,both of which support contracts,and for which integrated tool support exists.A brief summary of quality-ﬁrst DbC in BON/Eiffel follows.1.Write Eiffel code or produce BON diagrams as soon as possible,because thensupporting tools immediately do syntax,type,and consistency checking.2.Get the current unit of functionality working before starting the next.Deal withabnormal cases,e.g.,violated preconditions,right away.3.Intertwine analysis,design,and implementation.4.Always have a working system.5.Get cosmetics and style right.DbC can be seen as an instance of plan-driven development,but unlike some ap-proaches it does not suffer from the“big design up front”problem,in part because the plans in DbC are validated code.There are two vague steps in the quality-ﬁrst DbC approach:(a)in step(2)we must get the current unit of functionality working,but how do we progress from informal requirements to a contract or a BON diagram?(b)in step (4)we are told to constantly compile,execute,and test the system but how the testing is to be performed is not explained.These two problems can at least partially be alleviated with the use of TDD techniques.3Test-Driven DevelopmentTest Driven Development(TDD)is one of the popular evolving agile methods[1];it emphasises testingﬁrst as a replacement for up-front design.Like all agile methods,TDD stresses the development of working code over documentation,models and plans. The TDD cycle proceeds as follows:(1)write the testﬁrst(without worrying if it does not compile);(2)write enough code to make the test pass;(3)refactor the code to eliminate redundancies and other designﬂaws introduced by making the test pass.A striking aspects of this approach is the idea that the code that is implemented may not be behaviorally correct:it just has to pass the test.Correctness means passing all the tests.The test is therefore the speciﬁcation.Another striking aspect is refactoring as a replacement for up-front design(sometimes pejoratively called a“big up front design”)[5].Testing,with tool support,occurs all the time:before and after refactoring,and whenever new functionality is implemented.Tests are a form of speciﬁcation,typically(though not exclusively)dealing with normal and expected behaviour.Tests do not provide precise documentation of class interfaces.Thus,they are useful in capturing traces of valid behaviour for scenarios of the system,but may miss the big picture,i.e.,the architecture and component views. Thus tests cannot be described as complete requirements.Tests encompass both unit and regression tests,and also what we call collaborative tests.These latter tests are related to UML sequence and collaboration diagrams in that they show the messages (method calls)sent between a number of speciﬁc objects within a use case.A good example of a collaborative test is shown below,in Fig.2,for a simple banking system. An account is initialised and withdrawal is made,with the expected result of the account checked for correctness.test_teller_withdrawal_request:BOOLEAN islocal a:ACCOUNT;t:TELLER_TRANSACTIONdo--initial balance$900in John’s accountcreate a.make("John Doe",900)check a.balance=900endcreate t--test scenariot.request(a,500)t.withdrawal_requestresult:= a.balance=400and t.succeededendFig.2.Collaborative test for banking systemThe beneﬁts of TDD are many.For one,the cost of veriﬁcation is spread across the development process.The TDD process also provides low-level information about test failures,on the operation or even statement level,thus making debugging easier. Experience has shown that designs driven by tests tend to exhibit high cohesion and loose coupling,perhaps possibly due to the frequent refactoring and the requirement to keep the design as simple as possible.TDD also allows predictive speciﬁcation of what code will do,independent of the existence of the code itself.Finally,the tests producedusing TDD provide documentation of the design and the design process.The latter,in particular,will be essential for any requisite auditing and review.The limitations of TDD come in part from the incompleteness of tests:requirements cannot be completely captured by tests in general without enumerating all scenarios. Further,tests cannot deal with phenomena that are in the environment of the system, whereas contracts can express constraints on such constructs.3.1Collaborative vs Contractual SpeciﬁcationsTest-based unit and collaborative speciﬁcations are incomplete,because they consider only speciﬁc scenarios.Consider the following unit test,written in Eiffel.test_integers_sorted:BOOLEAN islocal sa1,sa2:SORTABLE_ARRAY[INTEGER]dosa1:=<<4,1,3>>;sa2:=<<1,3,4>>;sa1.sort;Result:=equal(sa1,sa2)endin which we create an unsorted array sa1,execute routine sort,and then assert that the array is equal to the expected sorted array sa2.The unit test does three things for us.The test is a precise speciﬁcation of a unit of functionality(the sort function in the special case of array<<4,1,3>>).The test also drives the design.It induces the public interface of class SORTABLEARRAY is constrained to inherit from COMPARABLE.This allows us to compare any two elements in the array,e.g.,the expre-sion item(i)<=item(i+1)is legal whether the array holds instances of integers or poeple,provided the instances are from classes that inherit from COMPARABLE.Routine sort is speciﬁed via preconditions and postconditions.The preconditions state that there must be at least one non-void element to sort.The unit test did not specify this,nor is it generally easy for unit tests to specify preconditions.The postcondition states that the array must be sorted and is unchanged.This postcondition speciﬁes this property for all possible arrays,holding elements of any type.Again,only an inﬁnite number of unit tests could capture this property.SORTABLEpositive:count>0elements void:∀i|lower≤i≤upper•item(i)=Void···sorted:∀i|lower≤i≤upper•item(i)≤item(i+1)countARRAYSince contracts and tests are both speciﬁcations(the contract being more general), they can both serve to drive development of the code.Unit tests can be used to automatically check that the code satisﬁes its speciﬁcation –just run the tests.Can code be checked against the contracts?One approach would be program veriﬁcation which provides strong assurance but requires qualitatively more time and effort than testing.The simpler approach is to turn assertion checking on in the programming language.But,unit tests will now be required to execute the code so that contracts can be checked.However,there is a test ampliﬁcation effect,which we discuss in the next section.While contractual speciﬁcations are detailed and complete,they have disadvantages. Consider a class STACK[G]with routines given by push(x:G)and pop.While contracts can fully specify the effects of push and pop individually,they cannot directly describe the last-in-ﬁrst-out(LIFO)property of stacks which asserts that∀s:STACK,x:G•pop(push(x,s))=sBy contrast,the LIFO behaviour can easily be captured using test-based collaborative speciﬁcations.4Speciﬁcation-Driven DevelopmentClearly there are beneﬁts to plan-driven development based on DbC,and test-driven de-velopment.Choosing between the value offered by the approaches will equally clearly depend on the project at hand.There are surprising commonalities between TDD and DbC,particularly:both contracts and tests are speciﬁcations;both TDD and DbC seek to transform requirements to compilable constructs as soon as possible;both TDD and DbC are lightweight veriﬁcation methods;both methods are incremental;and both em-phasise qualityﬁrst in terms of units of functionality.We claim that it is not necessary to choose between the two approaches a priori,and that there are substantial beneﬁts to using TDD and DbC together in a project.Speciﬁcation-Driven Development(SDD)provides the ability to use TDD and DbC techniques in the same development.It assumes(a)the availability of a contract-aware programming language(e.g.,Eiffel,or Java with a suitable pre-processor),and(b)a suitable testing framework(e.g.,JUnit or ETester).The statechart of Fig.4describes the approach.It does not dictate where to start–it is the developer’s choice whether to start with TDD or DbC based on project context.However,the emphasis is always on transforming customer requirements into compilable and executable code.Fig.4.SDD:Speciﬁcation-Driven DevelopmentSDD provides more than TDD or DbC individually,as it eliminates some of the limitations with each approach.But SDD is more than the sum of TDD and DbC,as there are synergies between the approaches.In particular,contracts act as test ampliﬁers. When writing a contract,it is easy to make mistakes,or write a contract that is simply too weak and which underconstrains the system.Some of theseﬂaws will be caught by executing the system;but this is not sufﬁcient in general.Writing tests to exercise the contracts(i.e.,which validate and invalidate each pre-and postcondition)can help validate the tests,and can also help drive the production of tests.4.1Some observationsSDD can start with writing tests(as illustrated by the left-most state in the statechart), or with writing contracts.However,there are two reasons to prefer writing unit tests before contracts:Closure:A unit test provides a precise description of a unit of functionality and hence also a clear stopping point–you write just enough clean code to get the test to pass.Contracts do not provide clear stopping points for units of functionality in quite the same way,thus allowing for the possibility of unnecessary design.Collaborative speciﬁcation friendly:tests can formalize instances of collaborative spec-iﬁcations more easily than contracts,as illustrated by the last-in-ﬁrst-out property of stacks.Contracts,of course,can provide precise documentation of the complete behaviour of code in a way that tests cannot(as illustrated in Fig.3).Contracts also provide preconditions;tests cannot document or check for preconditions.Finally,contracts can supply a qualitative level of assurance for code beyond that of testing in the case of program veriﬁcation,and can act as an automatic test ampliﬁer in the case that assertion checking is turned on.In summary:1.Contracts are good forﬂeshing out the design while making underlying assump-tions explicit.2.Contracts spell out the logical assumptions underlying a design more completelyand concisely than unit tests.3.Tests are good for writing collaborative speciﬁcations;as such,they are likely tobe more appropriate early in the development process when scenarios are being reﬁned to executable constructs.Contracts are good for constraining the design to meet the requirements.5ConclusionsWe have investigated the compatibility and complementarity of TDD and DbC,in pro-ducing a new agile approach called Speciﬁcation-Driven Development.Our conclusion is that TDD and DbC are complementary technologies and can be used synergistically, but also to supplement limitations:contracts make design decisions explicit that may only be implicit in tests;and tests can better capture requirements(such as the LIFO property on stacks)than contracts.We are providing tool support for the Eiffel language that allows TDD and DbC to be used together.This support comes via the ETester framework,documented else-where[8].ETester is speciﬁcally designed to make it easy to write unit tests and tests involving contracts.Additional work on an Eiffel plug-in for Eclipse will also make use of ETester.Our work has similarities to that of Feldman[4];his work focused particularly on the relationship between contracts and refactoring,whereas we have focused on the assistance that contracts provide to the TDD process.Feldman in particular makes the point that using contracts can reduce the amount of tests that need to be written because contracts cover the correctness of methods.We disagree on this point as tests must still be written to exercise the contracts,and to particularly deal with contracts that underspecify behaviour.However,we do agree with Feldman’sﬁndings that contracts work synergistically with refactoring.The table below summarises our conclusions.TDD lacks:Self-Documenting Design(automated usingseamless and reversible BON)Contracts and contractual speciﬁcationsTDD has:Units of functionality for Quality FirstSystematic regression tools for exercising con-tractsSynergies:Contracts are test ampliﬁersContractual and collaborative speciﬁcations provide lightweight veriﬁcation of the designTable1.SDD synergies–SDD>max(TDD,DbC)References1.Beck,K.Test-driven Development:by example,Addison-Wesley,2003.2.Beck,K., A.Cockburn,R.Jeffries,and J.Highsmith.Agile Manifesto/history.html.2001.3.Berry,D.M.Formal methods:the very idea—Some thoughts about why they work whenthey work.Science of Computer Programming,42(1):p11–27,2002.4.Feldman,Y.Extreme Design by Contract.In Proc.XP2003,LNCS,Springer-Verlag,2003.5.Fowler,M.and K.Beck.Refactoring,Addison-Wesley,1999.6.Gamma,E.and K.Beck.JUnit:A cook’s tour.Java Report,p27-38,1999.7.Leavens,G.T.,K.R.M.Leino,E.Poll,C.Ruby,and B.Jacobs.JML:notations and toolssupporting detailed design in Java.In OOPSLA2000Companion,ACM,2000.8.Makalsky,D.ETester Unit Testing Framework.Available at /projects/etester,2003.9.Martin,R.C.Agile software development,Pearson Education,2003.10.Meyer,B.Object-Oriented Software Construction.Prentice Hall,1997.11.Meyer,B.Practice to Perfect:the Quality-First Model.IEEE Computer30(5),1997.12.Meyer,B.Towards practical proofs of class correctness.In Proc.ZB2003,Springer-Verlag,,LNCS2651,p359-387,2003.13.Meyer,B.Personal communication,June2003.14.Paige,R.and J.S.Ostroff.The Single Model Principle.Journal of Object Oriented Technol-ogy,1(5):2002.15.Williams,L.and A.Cockburn.Agile Software Development:It’s about puter,36(6):p39-43,2003.。

Formal_Derivation_of_the_Combinatorics_Problems_wi

J. Software Engineering & Applications, 2009, 2: 195-199doi:10.4236/jsea.2009.23026 Published Online October 2009 (/journal/jsea)195Formal Derivation of the Combinatorics Problems with PAR MethodLingyu SUN1, Yatian SUN21Department of Computer Science, Jinggangshan University, Ji’an, China; 2School of Chemistry and Materials Science, University of Science and Technology of China, Hefei, China.Received May 12th, 2009; revised June 13th, 2009; accepted June 17th, 2009.ABSTRACTPartition-and-Recur (PAR) method is a simple and useful formal method. It can be used to design and testify algo-rithmic programs. In this paper, we propose that PAR method is an effective formal method on solving combinatorics problems. Furthermore, we formally derive combinatorics problems by PAR method, which cannot only simplify the process of algorithmic program's designing, but also improve its automatization, standardization and correctness. We develop algorithms for two typical combinatorics problems, the number of string scheme and the number of error per-mutation scheme. Lastly, we obtain accurate C++ programs which are transformed by automatic transforming system of PAR platform.Keywords: PAR Method, Formal Derivation, Combinatorics, Algorithmic Programs1. IntroductionComputer Science is a science of developing correct and efficient algorithms. Its main research object is discrete data handled by computer. As long as the algorithm in-volves iterant calculation, each traditional strategy of algorithm design can embody the principle of partition and recurrence. Partition is a general approach for deal-ing with complicated objects and is typically used in di-vide-and-conquer approach. Recurrence is used in algo-rithm analysis and dynamic programming approach. PAR method is a unified approach of developing efficient al-gorithmic programs and its key idea is partition and re-currence. Using PAR method, we begin from the formal specification of a specified problem, partition the prob-lem into a couple of sub problems, and develop an effi-cient and correct algorithm represented by recurrence and initiation [1-3].Combinatorics is a science of studying discrete objects. In general, it includes basic theories, counting methods and algorithms widely used in combination. Combina-torics algorithms are based on combinatorics and make people feel that computer may have its own thought.However, many programming teaching materials can only present combinatorics algorithms but cannot pro-vide the formal derived procedures that design the spe-cific algorithms from the unresolved combinatorics problems. So algorithm designers cannot understand the essence of algorithms and cannot improve their capabil-ity of algorithm design [4].PAR method embodies rich mathematic ideology, it provides many powerful tools and appropriate develop-ing environment. We can avoid making a choice among various design methods by adopting PAR method to de-velop combinatory algorithms. It can also change many creative labor to mechanized labor, and can finally im-prove algorithmic programs design’s automatization, standardization and correctness [5,6].In this paper, we propose that PAR method is an effec-tive formal method on solving combinatorics problems. We formally derive several typical algorithms of combi-natorics problems by PAR method, which cannot only solve the above problems, but also can assure their cor-rectness on logic. These combinatorics problem instances include the number of string scheme, the number of error permutation scheme, maximum summary [4], the longest common subsequence [4], minimum spanning tree [4,7] and the Knapsack problem [4], etc. Because of the lim-ited space, we only describe the whole developing proc-ess of two specific combinatorics problem instances, the number of string scheme and the number of error permu-tation scheme, which are derived by PAR methods.2. The Developing Steps of the Number of String Scheme Derived by PAR Methods Suppose that A={},,,a b c d, n is given, and we want toFormal Derivation of the Combinatorics Problems with PAR Method196 select n elements to compose string, in which element a and b cannot be adjacent elements. How many schemes are there in a string with n elements? [4]2.1 The Formal Function Specification of theNumber of String SchemePQ: Given integer n , set A ={},,,a b c d , string S stores n elements of set A .PR: Let ()[][][]{String n =S S k =a S k =b S k ∨∨[]}1c S k d k n =∨=∧≤< and ()(,:F S i j i j =∀≤)1ba +≠, then[]:..1n S j j ab S j <+≠∧[]..j (:():Z N S S String n n =∈(:1:[1][1]))j j n S j j ab S j j ba ∀≤<+≠∧+≠ = {According to the definition of } (),F S i (:():(,1))N S S String n F S ∈= {equivalent transformation of quantifier }(:()(,1):1)S S String n F S ∈∧∑ (1)2.2 Partition the Problem Based on thePost-AssertionWe partition computing Z n into computing X n and Y n , each of that has the same structure with Z n .(:()(,1)X S S String n F S n =∈∧∑([1][1]):1)S a S b ∧=∨= (2)In Equation (2), X n denote the number of n elements’ string scheme that element a and b cannot be adjacent elements and the initial element is a or b .(:()(,1)Y S S String n F S n =∈∧∑([1][1]):1)S c S d ∧=∨= (3)In Equation (3), Y n denote the number of n elements’ string scheme that element a and b cannot be adjacent elements and the initial element is c or d .(:()(,1):1)Z S S String n F S n =∈∧∑ (:()(,1)S S String n F S =∈∧∑([1][1][1][1]):1)S a S b S c S d ∧=∨=∨=∨=={Range Disjunction }(:()(,1)([1][1]):1)S S String n F S S a S b ∈∧∧=∨=∑(:()(,1)([1][1]):1)S S String n F S S c S d ∈∧∧=∨=∑+= {According to the definition of X n and Y n }X Y n n + (4)According to the equation (4), we can partition com-puting Z n into computing X n and Y n .2.3 Construct the Recurrence RelationSuppose X n-1 denotes the number of n-1 elements’ string scheme that satisfy the condition and the initial element is a or b . Y n-1 denotes the number of n-1 elements’ string scheme that satisfy the condition and the initial element is c or d .(:()(,1)X S S String n F S n =∈∧∑([1][1]):1)S a S b ∧=∨=(:()(,1)([1]S S String n F S S =∈∧∧∑ [1])([2]a S b S =∨=∧[2][2][2]):1)a S b S c S d =∨=∨=∨== {Range Disjunction }(:()(,1)([1][2])S S String n F S S S ∈∧∧=∑ ([2][2]):1)S a S b ∧=∨=+(:()(,1)([1])S S String n F S S a ∈∧∧=∑([2][2]):1)S c S d ∧=∨=+(:()(,1)([1])S S String n F S S b ∈∧∧=∑ ([2][2]):1)S c S d ∧=∨== {According to the definition of}(),F S i (:()([1][2])(,2)S S String n S S F S ∈∧=∧∑([2][2]):1)S a S b ∧=∨=+(:()([1])(,2)S S String n S a F S ∈∧=∧∑ ([2][2]):1)S c S d ∧=∨=+(:()([1])(,2)S S String n S b F S ∈∧=∧∑ ([2][2]):1)S c S d ∧=∨== {According to the definition of X n-1 and Y n-1 }21X Y n +⨯1n -- (5)According to the equation (5), we can partition com-puting X n into computing X n-1 and 2×Y n-1. (:()(,1)Y S S String n F S n =∈∧∑([1][1]):1)S c S d ∧=∨=(:()(,1)([1]S S String n F S S =∈∧∧∑ [1])([2][2]c S d S a S =∨=∧=∨ [2][2]):1)b S c S d =∨=∨=Formal Derivation of the Combinatorics Problems with PAR Method 197=+==+=+=+== {Range Disjunction }(:()(,1)([1][2])S S String n F S S c S d ∈∧∧=∨∑([2][2]):1)S a S b ∧=∨=(:()(,1)([1][2])S S String n F S S c S d ∈∧∧=∨∑ ([2][2]):1)S c S d ∧=∨== {Range Disjunction }(:()(,1)([1])S S String n F S S c ∈∧∧∑ ([2][2]):1)S a S b ∧=∨=(:()(,1)([1])S S String n F S S d ∈∧∧∑ ([2][2]):1)S a S b ∧=∨=(:()(,1)([1])S S String n F S S c ∈∧∧∑([2][2]):1)S c S d ∧=∨=(:()(,1)([1])S S String n F S S d ∈∧∧∑ ([2][2]):1)S c S d ∧=∨== {According to the definition of (),F S i } (:()([1])(,2)S S String n S c F S ∈∧=∧∑ ([2][2]):1)S a S b ∧=∨=+++1n -(:()([1])(,2)S S String n S d F S ∈∧=∧∑ ([2][2]):1)S a S b ∧=∨=(:()([1])(,2)S S String n S c F S ∈∧=∧∑([2][2]):1)S c S d ∧=∨=(:()([1])(,2)S S String n S d F S ∈∧=∧∑ ([2][2]):1)S c S d ∧=∨== {According to the definition of X n-1 and Y n-1 }221X Y n ⨯+⨯- (6)According to the equation (6), we can also partition computing Y n into computing 2×X n-1 and 2×Y n-1.2.4 Developing Loop InvariantSuppose variant x stores the value of X i , variant u stores the value of X i+1, variant y stores the value of Y i , variant v stores the value of Y i+1, variant z stores the value of Z i , where X 1=2, Y 1=2, Z 1=4.LI: 11x X u X y Y v Y z Z i i i i =∧=∧=∧=∧=++(1)i n ∧≤≤i2.5 Developing Corresponding RADL ProgramThe Recurrence-based Algorithm Design Language(RADL ) program of the number of string scheme, derived by PAR methods, is shown in Algorithm 1. By the auto-matic program transforming system of PAR platform, we can get the Abstract Programming Language (APLA ) program of the number of string scheme which is trans-formed from the RADL program and is shown in Algo-rithm 2. Finally, we transform the APLA program of the number of string scheme to C++ program, which can get accurate running result.Algorithm 1 (The RADL program of string scheme ) |[in n:integer; i:integer; x,y,u,v: integer; out z:integer;]| {PQ ∧PR }Begin : i=1++1; x=2; y=2; z=4;A_I: ()()(1)x x i u x i y y i =∧=+∧=∧()()(11v y i z z i i n )=+∧=∧≤≤Termination : i=n;Recur : u=x+2*y; v=2*x+2*y; z=u+v; x=u; y=v; End .Algorithm 2 (The APLA program of string scheme ) var: n:integer; i:integer; x,y,u,v: integer; z:integer; begin :write(“Please input integer n value”); read(n);i:=1;x:=2;y:=2;z:=4; do (﹁(i=n)) →u:=x+2*y; v:=2*x+2*y; z:=u+v x:=u; y:=v; i:=i+1; odwrite(“The Number of string scheme:”, z); end .3. The Developing Steps of the Number of Error Permutation Scheme Derived by PAR MethodsSuppose that the original arrange scheme is A =[a 1…a i …a n ], which is satisfied with each element is different. We want to interlace n elements of original permutation scheme A to compose new permutation scheme B , in which each element cannot be the same position in A . How many schemes are there in error per-mutation with n elements? [4]3.1 The Formal Function Specification of theNumber of Error Permutation SchemePQ: Given the original permutation scheme A =[a 1…a i …a n ] , which is satisfied with (,:i j ∀Formal Derivation of the Combinatorics Problems with PAR Method198 (1):([][]))i j n A i A j ≤<≤≠(){|Perm A B B 1,,}i j k n j k ∧≤≤∧≠(.PR: Let [][][][]j A i B j B k ==∧≠, then)[][]()()::1:D N B B Perm A n =∈∧(j j n B j A j ∀≤≤≠= {equivalent transformation of quantifier })[][]()()::B B Perm A j ∈∧∀∑[1:j n B j A j ≤≤≠:1=][](){}:1:i i n B n '∃≤<()A i true ==[][]()1:j n B j A j ≤≤≠(::B B Perm A j ∈∧∀∑[]':1:i i n B ∧∃≤≤([]()):1n A i = (7)3.2 Partition the Problem Based on thePost-AssertionWe partition computing D n into computing U n and V n , each of that has the same structure with D n .)[][]()(U B B Perm A n =∈∑[]':1:i i n B n ∧∃≤<=In Equation (8), U n denotes the err ::1:j j n B j A ∧∀≤≤≠j (8)number of n elements’ [][][]()):1A i B i A n ∧=or permutation scheme in which a n must be the i th element in new permutation B .()[][]()(:V B B Perm A j =∈∧∀∑:1:j n B j A ≤≤≠j (9)e number of n elements’ n [](':1:i i n B n ∧∃≤<=In Equation (9), V n denotes th err [][][]):1A i B i A n ∧≠)or permutation scheme in which a n cannot be the i th element in new permutation B .()[][]()(::1:D B B Perm A j =∈∧∀∑j n B j A j ≤≤≠n []':1:i i n B n ∧∃≤<== {Range Disjunction }[]()):1A i()[][]((:B B Perm A ∈∧∀):1:j n B j A j ≤≤≠j ∑[]':1:i i n B n ∧∃≤<=()[][][]()):1A i B i A n ∧=+ [][]()1:j n B j A j ≤≤≠(::B B Perm A j ∈∧∀∑[]':1:i i n B n ∧∃≤<== {According to the definition of According to the equation (1puting D n into computing U n and[][][]()):1A i B i A n ∧≠U n and V n }(10)V n .3.n-1 elements’ er-ber of n-2 U V n n + 0), we can partition com- 3 Construct the Recurrence RelationSuppose D n-1 denotes the number of ror permutation scheme, D n-2 denotes the num elements’ error permutation scheme.()[][]()(::1:U B B Perm A j j n B j A j n =∈∧∀≤≤≠∑[][][][]())':1::1i i n B n A i B i A n ∧∃≤<=∧== {Generalized Range Disjunction }()(((:1:::1i i n B B Perm A j j n ≤<∈∧∀≤∑∑ ≤[][]))[]:1A n :)[][][]B j A j B n A i B i ≠∧=∧=()((:1::i i n B B Perm A =≤<∈∧∑∑[][]()):1::1j j i i j n B j A j ∀≤<∨<≤≠)= {According to the initial definition of D }n (:1:)2i i n D n ≤<∑-(1)2n D n =-⨯- (11)According to the equation 1), we can partition com-puting U n into computing (n-1)× D n-2.(1()[][]()(::1V B B Perm A j n =∈∧∀≤∑:j n B j A j ≤≠[][][][]())':1:i i n B n A i B ∧∃≤<=∧:1i A n ≠= {Generalized Range Disjunction }()(((:1:::1i i n B B Perm A j j n ≤<∈∧∀≤∑∑ ≤[][]))[]:1A n ≠ :)[][][]B j A j B n A i B i ≠∧=∧()((:1::i i n B B Perm A =≤<∈∧∑∑())):1:[][]:1j j n B j A j ∀≤<≠ = {According to the initial definition of D n }(:1:)1i i n D n ≤<∑-(1)1n D n =-⨯- (12)According to the equation (12), we can partition com-puting V n into computing (n-1) × D n-1.According to the equation (10)recurrence: D =U + V = (n-1) × (D +D ), where Suppose variant s1 stores the value of d (i-2), variant s2, (11), (12), we have the n n n n-1n-2D 1=0, D 2=1. That is to say, we can partition computing D n into computing (n-1) × D and (n-1n-1) × D n-2.3.4 Developing Loop InvariantFormal Derivation of the Combinatorics Problems with PAR Method 199)scheme which are typical combinatorics problems. It is revealed that PAR method has particular merit. It is apt to understand and demonstrate the ingenuity and cor-rectness of an algorithm by formula deduction. Com-pared with other derivation, our algorithmic programs are more precise and simple than the representation of algo-rithm in natural language, flowchart and program. It also shows that using PAR method in developing combina-torics problem is a very natural meaningful research work. This can not only expand the application of PAR method, but also prove that the PAR method is a unified and effective approach on solving combinatorics prob-lems.5. Acknowledgmentstores the value of d (i-1), variant d stores the value of d (i ), where D 1 =0, D 2=1.LI: 1(2)2(1)s d i s d i =-∧=-∧(1)i n ∧≤≤(d d i = 3.5 Developing Corresponding RADL ProgramTh DL program of the n e RA heme n umber of error permutation sc , derived by the PAR methods, is show in Algo-rithm 3. By the automatic program transforming system of PAR platform, we can get the APLA program of the number of error permutation scheme which is trans-formed from the RADL program and is shown in Algo-rithm 4. Finally, we transform the APLA program of the number of error permutation scheme to C++ program, which can get accurate running result.Algorithm 3 (The RADL program of error permutation scheme )|[in n:integer; i,s1,s2: integer ; out d:integer ;]| {PQ ∧PR }Begin : i=3++1; s1=0; s2=1;A_I: ()()()1221s d i s d i d d i =-∧=-∧=∧()3i n ≤≤=n+1; Termination : i Recur : d= (i-1)*(s1+s2;s2=d; ); Algorithm The APLA program of error permu sc nteger; d:integer; ase input integer n value”); d= (i-1)*(s1+s2); rrange Scheme:”, z); 4.c We oped algorithmic programs for the number st the international cooperation ience and Technology of PR [1] J. Y. Xue, “A ing efficientalgorithmic pr computer Science om-orithmic programs [C],” The Proceedings of rmal University, program [J],” Journal of Yunnan University Vo1. 27, rithm with PAR Method [J],” This paper is supported by project of Ministry of Sc China, grant No. CB 7-2-01, and by Science and Tech-nology research project of Jiangxi Municipal Education Commission under Grant No. GJJ09590.REFERENCESunified approach for develop ograms [J],” Journal of s1=s2End .4 (tation puter Sciences and Technology, Vol. 13, No. 6, pp. 95– 102, 1998. [3] J. Y. Xue, “A practicable approach for formal develop-ment of alg and Technology, Vol. 12, No. 4, pp. 103–118, 1997. [2] J. Y. Xue, “Formal derivation of graph algorithmic pro-grams using Partition-and-Recur [J],” Journal of C heme )var: n:integer; i:integer; s1,s2: i begin :te(“Ple The international Symposium on Future software Tech-nology (ISFS'99), Published by Software Engineers As-sociations of Japan, pp. 212–217, 1999. [4] L. Y. Sun, “The applied research of PAR method oncombinatorics problems [D],” Jiangxi No wri read(n);i:=2;s1:=0;s2:=1; do (﹁(i=n)) → 2007. [5] J. Y. Xue, “Research on formal development of algo-rithmic s1:=s2; s2:=d; i:=i+1; (natural sciences), Vol. 19, pp. 283–288, 1997. [6] Y. Q. Li, “Partition-and-recur method and its applications[J],” Computer Engineering and Applications, odwrite(“The Interlaced A end .Con lusionsdevel of C No. 11, pp. 77–79, 2000. [7] L. Y. Sun and J. Y. Xue, “Formal derivation of the mini-mum spanning tree algo omputer Engineering, Vo1. 32, No. 21, pp. 85–87, 2007.ring scheme and the number of error permutation。

7 User Requirement Specification and Design Qualification

11
13-01-2010
Design Specification (s) 设计确认
A detailed description from which the system or equipment can be built or the process developed. 一个使系统和设备得以建立，工艺得到发展的详细说明 It is a technical document. 这是一份技术性文件 It is the basis for Installation Qualification. 这是安装确认的基础 It should map directly to the Functional, Requirements via the clause numbering system (often not practical) 通过条款编码系统可以直接映射到功能需求（通常不实用）

3
13-01-2010
“V Model” for Validation-Relationship 确认关系的“V模型”
User specification 用户说明书
Is based on 基于
PQ
Design qualification
设计确认
Is based on 基于
9
13-01-2010
Exercise Number 1 练习1
Using the notes to assist you compile a URS for a powderliquid blender
用这些注解来帮助你为一个粉末液体搅拌机编译一个USR
10
13-01-2010
Functional Specification 功能确认

8.3.4 设计和开发控制-IATF16949条款解读

8 运行8.3产品和服务的设计和开发8.3.4设计和开发控制（ISO 9001:2015质量管理体系的要求）组织应对设计和开发过程进行控制，以确保：a)规定拟获得的结果；b)实施评审活动，以评价设计和开发的结果满足要求的能力；c)实施验证活动，以确保设计和开输出满足输入的要求；d)实施确认活动，以确保产品和服务能够满足规定的使用要求或者预期用途；e)针对评审、验证和确认过程中确定的问题采取必要措施；f)保留这些活动的成文信息。

注：设计和开发的评审、验证和确认具有不同的目的。

根据组织的产品和服务的具体情况，可单独或以任意组合的方式进行。

8 Operation8. 3 Design and development of products and services8. 3. 4 Design and development controls（ISO 9001:2015requirements）The organization shall apply controls to the design and development process to ensure that:a)The results to be achieved are defined;b)Reviews are conducted to evaluate the ability of theresults of design and development to meetrequirements;c)Verification activities are conducted to ensure that thedesign and development outputs meet the inputrequirements;d)Validation activities are conducted to ensure that theresulting products and services meet the requirementsfor the specified application or intended use;e)Any necessary actions are taken on problemsdetermined during the reviews, or verification andvalidation activities;f)Documented information of these activities is retained.Note: Design and development reviews, verification and validation have distinct purposes. They can beconducted separately or in any combination, as is suitable for the products and services of the organization.术语评审review对客体实现所规定目标的适宜性、充分性或有效性的确定示例：管理评审、设计和开发评审、顾客要求评审、纠正措施评审和同行评审。

专利翻译中的常用的英语词汇

专利翻译中的常用的英语词汇(最新收集)来源：作者：发布时间：2008-10-29 查看本文[繁體版]最近收集了一部分专利翻译中的常用的英语词汇,仅供参考abandonment of a patent application 放弃专利申请abandonment of a patent 放弃专利权abridgment 文摘abstract 文摘(摘要)abuse of patent 滥用专利权action for infringement of patent 专利侵权诉讼action of a patent 专利诉讼additional features don't work to resolve question 附加的特征也不能解决问题address for service 文件送达地址affidavit 誓书allowance 准许amendment 修改annual fee 年费annuity 年费anticipation 占先appeal 上诉appellation of origin 原产地名称applicant for patent 专利申请人application date 申请日期application documents 申请案文件application fee 申请费application for patent 专利申请(案)application laying open for public inspection 公开供公众审查的申请application number 申请号application papers 申请案文件arbitration 仲裁art 技术article of manufacture 制品assignee 受让人assignment 转让assignor 转让人author of the invention 发明人author's certificate 发明人证书basic patent 基本专利be paid in advance 预先交Berne Convention 伯尔尼公约Berne Union 伯尔尼联盟best mode 最佳方式bibliographic data 著录资料BIRPI 保护知识产权联合国国际局board of appeals 申诉委员会breach of confidence 泄密Budapest Treaty on the International Recognition of the Deposit of Microorganisms for the Purposes of Patent Procedure 国际承认用于专利程序的微生物保存布达佩斯条约burden of proof 举证责任by the Secretary of Labor 消费价格指数的波动case law 判例法caveat 预告certificate of addition 增补证书certificate of correction 更正证明书certificate of patent 专利证书certified copy 经认证的副本Chemical Abstracts 化学文摘citation 引证claim 1 is rejected on the basis that 根据…驳回权利要求1claim to a method 方法权利要求claim to a product 产品权利要求claim 权项claim1 was refected as being predictable 可以预料权利要求1可以恢复claimed features 要求保护的特征claimed subject matter 要求保护的主题claims 1and 2 have novelty under PCT Article 33(2) respectively 根据33条第二款权利要classifier 分类员co-applicants 共同申请人co-inventors 共同发明人color coding 色码制commissioner 专利局长common sense, known technical solution 公知，已知的技术方案Community Patent Convention 共同体专利公约complete application 完整的申请案complete description 完整的叙述complete specification 完整的说明书comptroller 专利局长compulsory license 强制许可证conception date 概念日期conception 概念concerned had to be regarded as essential features )confidential application 机密申请confidential information 保密情报conflict award 冲突裁定conflict procedure 冲突程序conflicting applications 冲突申请案content of the application as originally filed 原始申请的内容continuation application 继续申请continuation-in-part application 部分继续申请案contractual license 契约性许可证contributory infringement 简介侵犯convention application 公约申请convention country 公约国convention date 公约日期Convention Establishing the World Intellectual Property Organization 建立世界知识产权组织公约convention period 公约期限convention priority 公约优先权copyright 版权correction slip 勘误表counter pleadings 反诉状counterclaim 反诉country code 国家代号cross license 交叉许可证data exchange agreement 资料交换协议data of application 申请日期data 资料date of grant 授予日期date of issue 颁发日期date of patent 专利日期date of publication 公布日期dedication to the public 捐献于公众defendant 被告人defenses 辩护defensive publication 防卫性公告deferred examination 延迟审查dependent claim 从属权项dependent patent 从属专利Derwent Publications Ltd. 德温特出版有限公司(来源：专业英语学习网站)design patent 外观设计专利development 发展disclaimer 放弃权项disclosure 公开披露division 分案divisional application 分案申请domination patent 支配专利drawing 附图duration of patent 专利有效期economic patent 经济专利effective filing date 实际申请日期electronic funds transfer (EFT), credit card or deposit account 电子信贷转移，信用employee’s invention 雇员发明enable st shape to vary as a function of position 使某物的形状作为位置函数变化EPO 欧洲专利局ESARIPO 英语非洲工业产权组织essential features (all features which were necessary for solving 必要技术特征（解European Patent Convention 欧洲专利公约European Patent Office 欧洲专利局even remotely suggest that 即使间接的建议evidence 证据examination countries 审查制国家examination for novelty 新颖性审查examination 审查examiner 审查员examiner’s report 审查员报告exclusive license 独占性许可证exclusive right 专有权experimental use 实验性使用expired patent 期满专利exploitation of a patent 实施专利exposition priority 展览优先权expropriation 征用extension of term of a patent 延长专利期限fall under (doing business ) 落入（商业方法）fee 费用FICPI 国际工业产权律师联合会file copy 存档原件filing date 申请日期filing fee 申请费filing of an application 提出申请final action 终局决定书first please refer to claim 2 which states 先参照权利要求2，其表明first-to-file principle 先申请原则first-to-invention principle 先发明原则for claim 1, I would suggest adding... 建议在权利要求1加入force majeure 不可抗力foreign patent application 外国专利申请formal examination 形式审查fully complied with 完全遵守gazette 公报Geneva Treaty on the International Recording of Scientific Discoveries 关于科学发现国际注册日内瓦条约grace period 宽限期grant of a patent 授予专利权holder of a patent 专利持有人ICIREPAT 专利局间情报检索国际合作巴黎联盟委员会if the benefits thereof are desired. 得到其中的便利IFIA 国际发明人协会联合会in the claims by technical features 利用技术特征来表示in the initial specification and claims 在原说明书和权力要求中Maintenance fee 年费may not go beyond the scope of the disclosure contained 不得超出原说明书和权利要求书none of the prior art of record anticipates … 记录在案的现有技术并没有预见到... omnibus claims 多项权利要求on the basic of document1 在文件1的基础上，基于文件1or 11 years and 6 months after grant of the patent. 和11年零6个月的授权当月的同一日over D1 in view of D2 对比D1并结合D2Paris Union Committee for International Cooperation in Information Retrieval among Patent Offices 专利局间情报检索国际合作巴黎联盟委员会payments by credit card and payments by deposit account 信用卡或存储账户支付permits maintenance fees to be adjusted 允许年费调整pertaining to （payment method）关于please note none of these teachings in D1 请注意在对比文件1中没有该提示reference signs 标号reference was made to Article 1 引用第一条referred to generally as the "window period," 一般称为“窗口期”regarding claim 2 as not being supported by 关于权利要求2不被…支持regarding something , please refer to … 关于…请参考set forth the time periods 指定时间期限so that the infringer would only have to 侵权者只须subject matter claimed 要求保护的主题take the view of (that) 采取…观点technical contribution to the state of the art 对现有技术的贡献the difference over D1 is quite clear 相对于D1的不同是很明显的the point of this discussion is that 此次讨论的要点是….the protection sought should be indicated 要求保护的内容应当在权利要求中-the question is we must add st. in sb 问题是我们必须在…中加入…the reason we prefer to … 我们提到的理由the technical problem with which the application was 的技术问题必须的所有的技术特征）thereby providing a st. 因此，提供一个…this is particularly relevant to D1 which teaches us st. 这一点与对比文件尤其相关，它告诉我们...to avoid narrowing or widening claim 1 避免缩小或扩大权利要求1to be adjusted every year on October 1 每年的10月一日调整to be fulfill the requirement of clarity 满足清晰的要求to delimit (defined) the scope of protection 限定了保护范围to enlarge the scope of protection 扩大了保护范围to narrow the scope of protection 缩小了保护范围to optimize our protection for the application 使对申请的保护合理vague generalized discussion in D1 含混的，泛泛的讨论was granted 3 years and 6 months, 7 years and 6 months, 3年零6个月，7年零6个月Would you please advise how we can process in this question 请指示我们怎样处理该问Basic Issues on the Priority 优先权基本问题。

trial_lecture

Requirements for the Success of Formal Methods in Practical Software Engineering
Trial Lecture
Demissie B. Aredo
March 3, 2005
Introduction to Formal Methods
State-of-the-Art FMs are not in the mainstream SW engineering Limitations of FMs in industrial settings Introducing FMs into SW Engineering Practice Success Criteria for Formal Methods
Taken from: [2] Richard Sharpe, Formal methods start to add up once again, Computing, January 8, 2004.
Demissie B. Aredo March 3, 2005, Oslo 6
Main Concepts of FMs
Demissie B. Aredo March 3, 2005, Oslo 4
Historical Timeline
1947-48: Von Neumann and Goldstine propose six-step programming process, starting with conceptualization of the problem mathematically 1959: Backus-Naur Form (BNF) for languages 1960: Hoare's Algol 60 compiler 1962: PetriNets 1969: Hoare's 'axiomatic basis’ 1973: IBM's VDM (Vienna Development Method), Cliff Jones 1978: Hoare's CSP (communicating Sequential Processes)

2018-2019-设备作业指导书英文-范文word版 (15页)

本文部分内容来自网络整理，本司不为其真实性负责，如有异议或侵权请及时联系，本司将立即删除！== 本文为word格式，下载后可方便编辑和修改！ ==设备作业指导书英文篇一：设备确认操作规程(英文)PURPOSE:To provide a formal methodology to be followed during qualificationof equipment. SCOPE:Applicable to qualification of new equipment, re-qualification of equipment, which has undergone major modification, relocation of equipment and Periodic Qualification as per schedule in Pharma manufacturing department.RESPONSIBILITY:Production, Engineering, Safety, Quality Control and Quality Assurance staff.DEFINITION:Qualification: Documented verification that the environment and equipment are appropriate for the designated function.User Requirement Specification (URS): A Requirement specificationthat describes what the equipment or system is suppose to do, thus containing at least set of criteria or conditions that have to be met.Functional Design Specification (FDS): Functional designspecification is a document that specifies in a complete, precise, variable manner, the requirement design,behaviour or other characteristics of a system or component and often the procedures for determining whether these provisions have been satisfied.Specification that is offered by manufacturing based on URS and are agreed mutually.Design Qualification (DQ): Formal and systematic verification that the requirements defined in the specification phase are completely covered by the succeeding specification or implementation phase.Factory Acceptance Test (FAT): Testing conducted at the suppliers factory todetermine whether or not a system specifies it?s acceptance criteria and to enable the user to determine whether or not to accept the system.Installation Qualification (IQ): Documented verification that a system is installed according to written and pre-approved specifications.Site Acceptance Test (SAT): An acceptance test at the users site, usually involve the supplier.Operation Qualification (OQ): Documented verification that a system operatesaccording to written and pre-approved specification throughout all specified operating ranges.PLC Validation: Documented verification that PLC Hardware are as per original drawing, Digital and Analog Input and Output are connected as per PLC Architecture and functioning according to written and pre-approved specification throughout all specified operating ranges.Performance Qualification (PQ): Documented verification that a system is capable of performing or controlling the activities of the processes, it is required to perform or control, according to written and pre-approved specifications, while operating in its specified operating environment.User (s): The person, or persons, who operate or interact directly with the system.Supplier: Any organisation or individual contacted directly by the user to supply a product or service.Critical Equipment: The machine within a system where the malfunctioning or failure of equipment will have direct impact on product quality. Where product is in direct contact with machine body parts.Non-critical Equipment: The machine within a system where the malfunctioning or failure of equipment will not have direct impact on product quality. Where product is not in direct contact with machine body parts.1.0 HEALTH, SAFETY AND ENVIRONMENT: (对验证实施人员的HES要求)1.1 Personnel involved in qualification / re-qualification / periodic qualificationshould use appropriate personal protective equipment.1.2 Do not touch the moving parts.1.3 Electrical isolation should be done before any electric control panelverification.1.4 Read the safety instructions specified in the operation Manual of themachine to be qualified.2.0PROCEDURE:2.1 Equipment qualification should be based on the following documents2.1.1 User Requirement Specification (URS)2.1.2 2.1.3 2.1.4 2.1.5 2.1.6 2.1.7 2.1.8 2.1.9Functional Design Specification (FDS) Design Qualification (DQ) Factory Acceptance Test (FAT) Checklist on Receipt Installation Qualification (IQ) Operation Qualification (OQ) PLC Validation ( If applicable) Provisional Handover Certificate2.1.10 Performance Qualification (PQ) 2.1.11 Handover CertificateThe flow of the equipment qualification is as followsURS ? FDS ? DQ ? FAT ? IQ ? OQ ? PLC Validation (if applicable) SAT? PQ2.1.1 User Requirement Specification (URS):2.1.1.1 URS protocol should be approved by the project team(Users) members and Quality Assurance with Name, Sign and Date.2.1.1.2 Following points should be considered during thedevelopment of URS. ? Introduction ? Over view? Operation requirements ? Constraints? Life cycle ? Glossary ? References ? Approval2.1.1.3 Each URS protocol should be allotted with a protocol no. inthe format specified below “URS/P”Where,“URS” stands for User requirement specification.“P” stands for equipment / instrument / balance / area abbreviated code.2.1.1.4 The protocol should also identify with a Version No. Wherethe version no. changes with every change in the URS.2.1.1.5 The URS protocol header should consist of the following detailsas mentioned below:? Title of the URS ?Protocol No. ? Version No. ? Date? Cipla Patalganga ? Unit? Page No.A specimen of the header is given below:2.1.2 Functional Design Specification (FDS):2.1.2.1。

1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

Formal Specification and Development of aSafety-Critical Train Management SystemA. Chiappini1, A. Cimatti2, C. Porzia1, G. Rotondo1, R. Sebastiani2,P. Traverso2, and A. Villafiorita21 Ansaldo Segnalamento Ferroviario, Via dei Pescatori, 16100 Genova, Italy2 IRST, Istituto per la Ricerca Scientiflca e Tecnologica, Povo, 38050, Trento, ItalyAbstract. In this paper we describe the on-going specification and de-velopment of Ansaldo's Radio Block Center (RBC), a component of thenext-generation European Rail Traffic Management System (ERTMS).The RBC will be responsible of managing the movement of trains equippedwith radio communication. Its development process is critical: the RBCis a large-scale and complex system, it must provide several novel servicesat different levels of functionality, it must guarantee interoperability ac-cording to European standards, and, last but not least, a high level ofsafety. We have addressed these issues by devising a development basedon formal specifications. ERTMS scenarios have been formalized in orderto provide a better understanding of the interoperability requirements.The architecture of the RBC has been formally specified such that thesystem can be incrementally built as an overlay system (compatible withthe existing train detection and interlocking systems) and modularly ex-panded to control different kinds of trains. The formal specifications ofthe behaviour of each RBC module have been structured hierarchically:they provide an easy-to-understand documentation for customers and de-velopers; moreover, they can be simulated and validated automaticallyat the early stage of the development process, thus providing a high levelof confidence in their safety in a cost-effective way.1 IntroductionThe next-generation European railway control systems will have to address a set of novel safety, performance, interoperability, and compatibility requirements. One of the goals is to build a safety critical system which improves railway system performances while reducing investment and operating costs. Another goal is to build systems interoperable among different European nations: in practice, a train working for a given railway (e.g. the Italian one) should be able to work in neighboring countries (e.g. in the Austrian, French and German railway's networks). Moreover, the system should be compatible with the existing ones. Finally, it should provide new functionalities incrementally, allowing thus for different levels of increasing sophistication.The achievement of all these novel and different requirements is a crucial issue for the future of the European railway system. This has led to the set M. Felici, K. Kanoun, A. Pasquini (Eds.): SAFECOMP'99, LNCS 1698, pp. 410-419, 1999© Springer-Verlag Berlin Heidelberg 1999Formal Specification and Development of a Safety-Critical Train Management System 411 up of a project at the European (rather than national) level, called the Euro-pean Rail Traffic Management System (ERTMS). In the ERTMS project, the performance requirement has been addressed by conceiving a completely new communication system between trains and signalling systems on the ground, based on GSM mobile radio data transmission and on high-rate balises (Eu-roBalises). The interoperability requirement has been addressed by designing a European standard communication protocol between the train and the ground system, that has been described by a set of uses cases, called ERTMS scenarios. The system is described in [3] and [2].The goal of the project described in this paper is the Ansaldo's specification and development of the Radio Block Center (RBC), the ERTMS component responsible for the management of the movement of trains equipped with radio communication. The RBC is a large-scale and complex system: it must interact with several systems beyond trains, e.g. with existing interlocking systems, with the RBC's controlling neighboring parts of the railways line, with a man-machine interface for monitoring and control. It must provide several novel services and guarantee interoperability according to the ERTMS standards, and, last but not least, a high level of safety. It is clear that its specification and development are critical.We have addressed these issues by devising a development based on formal specifications. One of the main motivations for this choice is the fact that an approach based on formal methods allows for unambiguous specifications which can be validated at the early stage of the development process. Unambiguous specifications are extremely important for the interoperability and compatibility requirements. Their "early validation" is a must in practice for the safety require-ments and for the development of a large-scale system. One of the main goals of the project is to devise a development process based on formal techniques which can be cost-effective and really usable by the experts in the signalling field. This has been achieved through some main steps where we have managed to adopt formal notations and formal verification techniques which can be smoothly in-troduced into the Company's development process. An overview of these main steps is presented in Section 2. The rest of the paper (after a brief description of the application domain in Section 3) describes in detail these steps: the formal-ization of ERTMS scenarios (Section 4), the formal input/output specification of RBC's software modules (Section 5), the hierarchical formal specification of their behaviour (Section 6) and their early validation (Section 7). In order to keep the paper short and readable, these steps are described through a simple example, which is discussed all through the paper. The whole formal specifica-tion and design at the current stage of the project is presented in a detailed project report [1].2 Overview of the ApproachCost-effectiveness and real usability of formal methods within the project has been achieved through a specification process based on the following main steps.412 A. Chiappini et al.First, ERTMS scenarios describing the RBC-train communication have been formalized in order to provide a better understanding of the interoperability requirements. At this stage, it is important to use a language which is easy to understand by signalling experts. Scenarios have been formalized in the "Message Sequence Chart" (MSC) format [6]. MSC's have been designed to represent the dynamic behaviour of protocols. In spite of the fact they are formal and thus provide unambiguous descriptions, their graphical notation is extremely intuitive and easy to read. MSC's have allowed experts in signalling and experts in formal methods to share their respective know-how. As a result, they have allowed us to disambiguate several scenarios and to state clearly the hypotheses under which the scenarios are applicable.Second, we have designed the high level architecture of the RBC through "Structured Description Language (SDL) block (interconnection) diagrams" [5]. SDL diagrams allow for the definition of software modules and the information exchanged between modules. We have first defined the interconnection diagram between the RBC as a black box and the other systems it interacts with (e.g. the interlocking, the other RBC's, the interface to the operator and the train). We have then decomposed the RBC module into more "elementary" functionalities.Third, starting from the formalized scenarios (MSC's) and the architectural decomposition in different software modules (SDL block diagrams) we have for-mally specified the dynamic behaviour of each module. We have used "State Charts" [4] for this purpose. State Charts are a well-known formalism which is used to describe systems components as automata. Automata are a well known technique used in Ansaldo—engineers can easily understand them and use them to describe the system behaviour. The main problem in this task is due to the fact that the system is quite large. A mere one-level and flatten description of the system in terms of state charts would be unpractical and very difficult to maintain. For this reason, state charts have been structured hierarchically: we have developed state charts which describe the behaviour of the system at a high level, abstracting away several details. These state charts are simple (i.e. with a reasonable number of states) and highly non-deterministic: given a state of the system, the system can evolve into more than one next state. In other words, the state chart is not detailed enough to specify the exact conditions under which the system evolves in one of the possibly many behaviours. These automata provide a high level view of the system, are extremely important for the documentation (both for developers and customers), and can be easily validated by railways experts by means of simple inspections.Then high level state charts are refined in detailed ones. We have specified the detailed behaviour of the system through "SDL processes". SDL processes describe in detail how the system evolves from one state to the next. SDL [5] is a language which has been extensively used in industry. Its notation is not difficult for an engineer which is used to traditional programming and software engineering notations, like data flow diagrams and flowcharts. The signalling expert can still read the detailed specification easily, but a manual validation by inspection is unpractical, since at this level of detail the specification is large.Formal Specification and Development of a Safety-Critical Train Management System 413 As a consequence, we have exploited existing tools to automatically simulate the specifications. This is the immediate advantage of having developed formal specifications: they can be simulated far before the code implementation phase. Moreover, we have used "Model Checking" techniques to explore all the possible behaviours of the system exhaustively. The significant added value of Model Checking w.r.t. simulation is that it can guarantee that a safety property is satisfied for all possible behaviours of the system. Indeed, Model Checking has revealed unexpected behaviours of the system as initially specified: specifications errors have been corrected until the specifications have been validated by model checking.In this project, we have used the ObjectGeode tool [7], which among other languages and features, allows for the use of MSC's, SDL bock diagrams, State Charts, SDL processes, and a simulator and a model checker for SDL processes.3 Overview of the ApplicationThe main functionality of the RBC is the allocation of Movement Authority (MA) to trains, that is, permission to move for a certain distance. In order to safely allocate MA, the RBC collects information about (but not limited to) the position of trains on the line, emergency situations, and pending orders from human operator (s).CHEURORADIOFig. 1. The ERTMS System.Figure 1 depicts the situation. The line is logically divided into block sections; the signalling system must guarantee that any block section is occupied at the most by one train. In order to do so, the entrance into a block section is protected by a signal. A train detection system senses the status of occupation of the blocks and sets the signals accordingly. In the station the situation is more complex: an interlocking system is responsible of setting/releasing itineraries, by safely414 A. Chiappini et al.controlling switches and signals. The RBC is connected to all the interlockings installed in the zone it controls. The RBC collects information about the position of trains, the status of occupation of blocks on the line and the itineraries set in the stations, computes MA's based on the information it has collected, and sends them to the trains.4 Scenarios (via Message Sequence Charts)The least restrictive way of guaranteeing interoperability is to impose a standard-ization of the messages and the protocol between RBC and train. The ERTMS project has thus defined a list of correct RBC-train messages, called telegrams, and a set of use cases, called scenarios, that provide examples of the commu-nication protocol. Scenarios are composed of a description in natural language, that explains the rationale of the scenario (e.g. the applicability) and a tab-ular description of the protocol, that provides examples of how telegrams are exchanged.Scenarios leave several options open: we must choose among all the options provided by the scenarios the ones that are most suitable, e.g., with the system in which the RBC is going to operate. For instance, the Scenario describing MA allocation to trains does not fix the criteria according to which the RBC decides to allocate MA's: such criteria indeed depend upon the rules governing the signalling system in which the RBC operates (e.g. they are decided on a national basis). This information, however, is essential to provide an executable specification of the RBC.More to the point, the tabular form used in [2] is kind of ambiguous. The succession of rows does not necessarily correspond to progression of time. Alter-natives are difficult to represent.MA_AckRBCma req+pos\M A R e q-M° A /{ WaitAc _ma_ack k_M o d A \ack_of_ma_Fig. 2. MSC of MA Allocation with acknowledgement.The above considerations suggest the need for a more precise notation, with clear syntax and semantics, and easily understandable by experts of the railwayFormal Specification and Development of a Safety-Critical Train Management System 415 system. We adopted the Message Sequence Charts (MSC) notation, as it meets all these requirements. Figure 2 shows an MSC that rationalizes part of the Sce-nario describing MA allocation to trains. We distinguish an entity, called R B C, that communicates with the environment (framing rectangle). The environment comprehends everything external to the R B C: in our case, trains. The R B C and the environment exchange messages, represented in the MSC by labelled arrows. Time progresses from the top to the bottom. The MSC represents the recep-tion of a request for a MA (ma_req+pos), to which the RBC answers with a MA requiring an acknowledgement (ma_ack). Upon receiving the MA, the train acknowledges the reception (ack_of _ma). The MSC is also marked with "con-ditions" (e.g. Normal_ModA), that fix the states of the communication between track and train.Fig. 3. Abstract MSC of MA Allocation.In ObjectGeode, MSC's can be combined to form more complex MSC's, using operators like sequence, alternative, and iteration. The composition of MSC's is represented by a tree (called hierarchy), in which the nodes are operators and the leaves are MSC's. Figure 3 shows a hierarchy of MSC's that rationalizes the behaviours of the Scenario describing MA allocation to trains. We individuate two different operating modes, called Mode A and Mode B. In Mode A (leftmost subtree), trains always ask for MA's, whereas in Mode B (rightmost subtree) the RBC allocates MA to trains when it decides to do so. The RBC may request a a change in the operating mode (subtrees marked OMC—Operating Mode Change) and, finally, MA's may require an acknowledgement or not (leaves of the tree). The MSC in Figure 2 is the leaf M A_A c k in the hierarchy in Figure 3.5 Architectural Description (via SDL InterconnectionDiagrams)MSC's help understand and formally define the way in which the RBC interacts with trains. This is not the whole story, however, as the RBC interacts with several other actors. The second step in the specification of the RBC, thus, is the definition of the environment in which the RBC operates (what we call the "context diagram") and the definition of the constituent blocks of the RBC (architectural decomposition).Figure 4 shows the context diagram for the RBC. The RBC interacts with actors, that range from devices for the configuration of the RBC at startup416 A. Chiappini et al.s y s t e m Environment L2ConiiguratorDeviceOperatorDeviceAnomalies D etectorInterlockingLoggerLevelCrossingAnnouncing D eviceFig. 4. Context Diagram of the RBC.(Configurator Device), through devices for collecting the status of the line (Op-erator, Anomalies Detector, Interlocking, Line TDS, External RBC), to trackside devices directly operated by the RBC (Level Crossing and Announcing Device).6 Dynamic Behaviour Specification (via State Charts andSDL processes)We can now start filling the blocks of the interconnection diagram, using the MSC's as a constraint for the I/O behaviour of the RBC. To simplify the process of specification of the blocks, and increase our confidence on the specifications, we start with abstract specifications—using State Charts—that we later refine into SDL code. The abstract specifications hide several details of the behaviour of the RBC (like, for instance, what decisions trigger a transition to a state rather than another): the goal here is providing "high level" specifications that can be validated "by hand".Figure 5 shows the abstract specification of the communication protocol described in the Scenario describing MA allocation to trains. The left hand side implements the allocation of MA in Mode A. We distinguish three states: Normal_ModA, MAReq.ModA, and WaitAck.ModA. In Normal.ModA the RBC waits for a MA request from the train (ma_req), that causes a transition into M A R e q_M o d A. From M A R e q_M o d A the RBC sends a MA to the train and non-deterministicallyFormal Specification and Development of a Safety-Critical Train Management System 417Fig. 5. Abstract State Chart for MA Allocation.goes into one of the following four states, depending on the MA the RBC decides to send: Normal_ModA (MA that does not require acknowledgement nor operat-ing mode change), WaitAck_ModA (MA that requires acknowledgement but does not require to change operating mode), Normal_ModB (MA that does not require acknowledgement, but that requires an operating mode change), WaitAck_ModB (MA that requires both acknowledgement and to change operating mode). The state chart we just presented does not describe the internal mechanisms and strategies according to which the RBC chooses what MA to send, and, there-fore, its next state: our goal, here, is the specification of the generic behaviour of the RBC (e.g., the fact that from M A R e q_M o d A, the RBC has four possible next states, corresponding to four logically different states of the communication).State Charts can be automatically translated by ObjectGeode into SDL code. In our case, (a slightly modified version of) the chart of Figure 5 has been auto-matically translated into SDL code, that has later been refined by hand, adding the details to make its behaviour deterministic. Figure 6 shows the portion start-ing from M A R e q_M o d A: the RBC gets information about the occupation of the line (track_path), computes the MA (cma), then decides the next state. Now the transition onto the next state is deterministic and depends upon a call to the function omc (that determines whether to change operating mode) and a parame-ter cf g_ack (that determines whether to ask for acknowledgements). Depending on which of the four branches is chosen, the RBC sends a different message to the train (one of ma_ack_omc, noma_ack_omc, ma_ack, and ma_noack).418 A. Chiappini et al.(fma\ ma_ack(tid,ma) \ ma_noack(ti4ma) \WaitAck_ModB I I Normal_ModB 1 I WaitAck_ModA ) ( Normal_ModAJ I WaitAck_ModA J IFig. 6. SDL representation of the State Chart.7 Early Validation (via Simulation and Model Checking)The last step is the validation of the specifications. In this step we exploit the executability of the specifications, by running them inside ObjectGeode's sim-ulator and model checker (exhaustive simulator). The goal of this activity is verifying that certain properties hold of the specifications of the RBC. It is im-portant here to observe that, short of a few properties that can be proven with the RBC in isolation (like the absence of deadlocks), in order to verify whether the RBC behaves correctly, we must immerse the RBC into an environment. The environment is composed of, for instance, interlocking and the train detection systems, that provide inputs to the RBC, and trains, that communicate with the RBC and move according to the MA's they receive from the RBC. Thus, by monitoring how trains move, we can check whether the RBC behaves as it should. We can arbitrarily degrade the performances of the environment, by al-lowing, for instance, telegrams to be lost or corrupted by the radio channel. This allows to test the behaviour of the RBC in a wide range of (critical) situations.Properties are verified by running simulations (either random or exhaustive) with watches that monitors the behaviour of the system. Such watches can either express properties holding of a state or properties holding along a sequence of states. For instance, we can verify that no block section is occupied by more than one train or that a certain train has reached a certain position.8 ConclusionsIn this paper we have described an on-going project whose aim is the formal specification of a system (the implementation of RBC done by Ansaldo) for the management of trains according to the ERTMS requirements. We have adoptedFormal Specification and Development of a Safety-Critical Train Management System 419 formal methods in order to cope with the safety and interoperability require-ments. One of the main issues of the project is the provision of formal spec-ification techniques which can be easily understood and used cost-effectively within the Company's development process. This issue has been addressed by providing formal specifications which are unambiguous and, at the same time, can be easily inspected by the development team; by devising an hierarchical specification of the system which provides an highly structured documentation for customers and developers; by an early validation phase which is performed during the specification and design phase and in which (detailed) formal specifi-cations can be simulated (either interactively or exhaustively) to detect possible expensive specification errors at the early stage of the project.We have approached the problem of the specification of a quite large and complex system, interacting with several external actors, in a selective and in-cremental way. At this stage of the project we have formally specified and vali-dated a significant subset of the functionalities. Some of them are (part of) the management of trains inside the area controlled by the RBC, the entry /exit of a train from/to areas controlled/not-controlled by other RBC's, some cases of anomalies handling. These specifications and the methodology used to provide them are now taken as examples and guidelines to complete the specifications and design in the current continuation of the project.AcknowledgementsThe work described in this paper was founded under contract 1607/250000(NA). The authors would like to thank all the people at Ansaldo and IRST involved in the project.References1. A. Chiappini, A. Cimatti, F. Giunchiglia, G. Rotondo, R. Sebastiani, P. Traverso,and A. Villafiorita. Formal Specification of the Radio Block Centre (RBC): First Part. RBC I: Ansaldo-IRST Project Report, December 1998.2. EEIG-ERTMS Users Group, 25 Avenue De Beaulieu 1160 Brussels, Belgium. Sce-narios.3. EEIG-ERTMS Users Group, 25 Avenue De Beaulieu 1160 Brussels, Belgium. SystemRequirements S pecification.4. David Harel. Statecharts: A Visual Formalism for Complex Systems. Science ofComputer Programming, 8(3):231-274, June 1987.5. ITU-T. CCITT specification and description language (SDL), March 1993. ITU-TRecommendation Z.100.6. ITU-T. Message Sequence Chart (MSC), October 1996. ITU-T RecommendationZ.120.7. VERILOG. ObjectGeode Documentation. Available at .。