DOCSLIB.ORG

REQUIREMENTS ENGINEERING MANAGEMENT FINDINGS REPORT May 2009 6

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
REQUIREMENTS ENGINEERING MANAGEMENT FINDINGS REPORT May 2009 6 DOT/FAA/AR-08/34 Requirements Engineering Air Traffic Organization NextGen & Operations Planning Management Findings Report Office of Research and Technology Development Washington, DC 20591 May 2009 Final Report This document is available to the U.S. public through the National Technical Information Service (NTIS), Springfield, Virginia 22161. U.S. Department of Transportation Federal Aviation Administration NOTICE This document is disseminated under the sponsorship of the U.S. Department of Transportation in the interest of information exchange. The United States Government assumes no liability for the contents or use thereof. The United States Government does not endorse products or manufacturers. Trade or manufacturer's names appear herein solely because they are considered essential to the objective of this report. This document does not constitute FAA certification policy. Consult your local FAA aircraft certification office as to its use. This report is available at the Federal Aviation Administration William J. Hughes Technical Center’s Full-Text Technical Reports page: actlibrary.tc.faa.gov in Adobe Acrobat portable document format (PDF). Technical Report Documentation Page 1. Report No. 2. Government Accession No. 3. Recipient's Catalog No. DOT/FAA/AR-08/34 4. Title and Subtitle 5. Report Date REQUIREMENTS ENGINEERING MANAGEMENT FINDINGS REPORT May 2009 6. Performing Organization Code 7. Author(s) 8. Performing Organization Report No. David L. Lempia and Steven P. Miller 9. Performing Organization Name and Address 10. Work Unit No. (TRAIS) Rockwell Collins, Inc. 400 Collins Road NE 11. Contract or Grant No. Cedar Rapids, IA 52498 DTFACT-05-C-00004 12. Sponsoring Agency Name and Address 13. Type of Report and Period Covered U.S. Department of Transportation Final Report Federal Aviation Administration Air Traffic Organization NextGen & Operations Planning Office of Research and Technology Development Washington, DC 20591 14. Sponsoring Agency Code AIR-120 15. Supplementary Notes The Federal Aviation Administration Airport and Aircraft Safety R&D Division COTR was Charles Kilgore. 16. Abstract This report describes the results of a study conducted for the Federal Aviation Administration Airport and Aircraft Safety Research and Development Division to determine methods to enable successful management, control, integration, verification, and validation of system and software requirements that may be developed by multiple entities. In Phase 1 of the study, a survey of the literature was conducted to identify best practices in requirements engineering, and an industry survey was taken to determine current practices and the issues and concerns of practitioners. These sources were then combined to produce an overall list of safety and certification issues in requirements engineering management. In Phase 2 of the study, the findings of Phase 1 were further refined and used to guide the selection of several best practices from the literature. This final report included the results of Phases 1 and 2. The best practices were integrated into a complete set of 11 recommended practices and documented in a Handbook of Requirements Engineering Management. These practices can be incrementally added to an organization’s existing requirements engineering process to incorporate the best practices identified in the literature. 17. Key Words 18. Distribution Statement Requirements, Engineering, Avionics, Systems, Software This document is available to the U.S. public through the National Technical Information Service (NTIS) Springfield, Virginia 22161. 19. Security Classif. (of this report) 20. Security Classif. (of this page) 21. No. of Pages 22. Price Unclassified Unclassified 216 Form DOT F 1700.7 (8-72) Reproduction of completed page authorized TABLE OF CONTENTS Page EXECUTIVE SUMMARY xiii 1. INTRODUCTION 1 1.1 Background 1 1.2 Overview of the Main Study Findings 2 1.2.1 Findings From the Literature Search 2 1.2.2 Findings From the Industry Survey 2 1.2.3 Development of the Requirements Engineering Management Handbook 3 1.3 Organization of Report 4 2. BEST PRACTICES IDENTIFIED IN THE LITERATURE 4 2.1 DO-178B, DO-248B, and DO-278 4 2.2 Statecharts, StateMate, and Rhapsody 8 2.3 Software Cost Reduction and the Four-Variable Model 9 2.4 The RSML and the RSML-e 13 2.5 Specification Toolkit and Requirements Methodology and Intent Specifications 14 2.6 Unified Modeling Language 16 2.7 Synchronous Graphical Modeling Languages 18 2.8 Integrated Modular Avionics 19 3. INDUSTRY SURVEY 21 3.1 Approach 21 3.2 Findings 22 3.2.1 Background Information 22 3.2.2 Tools and Methods 23 3.2.3 Comments 27 iii 3.3 Survey Conclusions 31 4. SAFETY AND CERTIFICATION CONCERNS 32 4.1 General Issues 33 4.1.1 What is Requirements Engineering Management? 34 4.1.2 Clarification of DO-178B Terms and Guidance 34 4.1.3 Is More Guidance Needed on Requirements Engineering Management? 34 4.2 Safety Issues 34 4.2.1 What Should be Done Differently During Development Due to Safety Requirements? 35 4.2.2 Can ARP 4754 and DO-178B be Integrated Better? 35 4.2.3 What Techniques can be Used to Improve Software Safety? 35 4.2.4 How Should the Intent of Requirements be Specified? 35 4.2.5 How Should Environmental Assumptions be Specified? 36 4.2.6 How Should Human Factors Requirements be Specified? 36 4.3 Certification Issues 36 4.3.1 What is the Relationship of System and Software Requirements? 37 4.3.2 What is the Relationship of Software Requirements and Software Design? 37 4.3.3 What is the Relationship of Software and Hardware Requirements? 38 4.3.4 Should Requirements be Specified Differently in Different Domains? 38 4.3.5 How Should Traceability and Change of Requirements be Managed? 38 4.3.6 How Should Timing Requirements be Specified? 39 4.3.7 What Should the Certification Authorities do Differently? 39 4.3.8 Should Civil Standards for REM be Harmonized With Military Standards? 40 iv 4.4 Model-Based Development Issues 40 4.4.1 What is the Relationship of Systems and Software Requirements in MBD? 41 4.4.2 If Models will be Used as Requirements, How are They to be Validated? 42 4.4.3 What is the Relationship of Software Requirements and Software Design in MBD? 42 4.4.4 Which MBD Modeling Paradigms Should be Used for Which Problem Domains? 44 4.4.5 What Problems for Traceability and Change Management of Requirements are Posed by MBD? 44 4.4.6 What Problems are Posed for REM by the Use of MBD Tools? 45 4.4.7 How Should Intent of Requirements be Specified in MBD? 46 4.4.8 How Should Environmental Assumptions be Specified in MBD? 46 4.4.9 How Should Timing Requirements be Specified in MBD? 46 4.4.10 How Should Human Factors Requirements be Specified in MBD? 46 4.4.11 What Should the Certification Authorities do Differently to Support MBD? 46 4.4.12 How Should Legacy Requirements be Migrated to Support MBD? 47 4.4.13 Can Models be Used as Contracts? 47 4.5 Integrated Modular Avionics Issues 47 4.5.1 How Should Application Requirements be Specified? 48 4.5.2 How Should Platform Services be Specified? 49 4.5.3 How Should Requirements be Specified to Support Incremental Acceptance in Certification? 50 4.5.4 How Should Requirements be Specified to Support Reuse in IMA? 50 4.5.5 Increased Risk of Common Mode and Cascading Failures 51 4.5.6 Specifying and Meeting System Performance Requirements 51 v 4.5.7 Specifying and Meeting Dependencies Between Applications 51 4.5.8 Traceability and Configuration Management 52 4.5.9 What is the Role of the Certification Authorities? 52 4.5.10 Does the REM Process Change in IMA? 52 4.6 Object-Oriented Development Issues 52 4.6.1 What is the Relationship of Safety and Software Requirements in OOD? 53 4.6.2 What is the Relationship of System and Software Requirements in OOD? 53 4.6.3 What is the Relationship of Software Requirements and Software Design in OOD? 53 4.6.4 Which OOD Modeling Paradigms Should be Used in Which Problem Domains? 54 4.6.5 What Problems for Traceability and Change Management of Requirements are Posed by OOD? 54 4.6.6 How Should Intent be Specified in OOD? 55 4.6.7 How Should Environmental Assumptions be Specified in OOD? 55 4.6.8 How Should Timing Requirements be Specified in OOD? 55 4.6.9 How Should Human Factors Requirements be Specified in OOD? 55 4.6.10 How Should Legacy Requirements be Migrated to Support OOD? 55 5. PRIORITIZING THE SAFETY AND CERTIFICATION ISSUES 56 5.1 Summarizing the Industry Survey Issues 56 5.1.1 What is the Relationship of Software Requirements to Software Design? 57 5.1.2 What Problems for Traceability and Configuration Management are Posed by MBD/OOD? 57 5.1.3 What New Problems are Posed for REM by the Use of MBD Tools? 57 5.1.4 If Models are Used as Requirements, How are They to be Validated? 57 vi 5.1.5 How Should Traceability and Configuration Management be Managed? 57 5.1.6 What is the Relationship of System and Software Requirements? 58 5.2 Summarizing the Literature Search Issues 58 5.2.1 Defining the System Boundary 58 5.2.2 Documenting the Environmental Assumptions 58 5.2.3 Providing Intent and Rationale 59 5.2.4 Validation of Requirements 60 5.2.5 Verification of Requirements 60 5.2.6 Managing Change and Complexity 61 5.2.7 Development by Multiple Entities 61 5.2.8 Specifying Requirements for the Human Machine Interface 62 5.3 Prioritizing the Issues 62 6.
Load more

Recommended publications
  • 2006 FIRST Annual Report
    annual report For Inspiration & Recognition of Science & Technology 2006 F I R Dean Kamen, FIRST Founder John Abele, FIRST Chairman President, DEKA Research & Founder Chairman, Retired, Development Corporation Boston Scientific Corporation S Recently, we’ve noticed a shift in the national conversation about our People are beginning to take the science problem personally. society’s lack of support for science and technology. Part of the shift is in the amount of discussion — there is certainly an increase in media This shift is a strong signal for renewed commitment to the FIRST T coverage. There has also been a shift in the intensity of the vision. In the 17 years since FIRST was founded, nothing has been more conversation — there is clearly a heightened sense of urgency in the essential to our success than personal connection. The clearest example calls for solutions. Both these are positive developments. More is the personal commitment of you, our teams, mentors, teachers, parents, awareness and urgency around the “science problem” are central to sponsors, and volunteers. For you, this has been personal all along. As the FIRST vision, after all. However, we believe there is another shift more people make a personal connection, we will gain more energy, happening and it has enormous potential for FIRST. create more impact, and deliver more success in changing the way our culture views science and technology. If you listen closely, you can hear a shift in the nature of the conversation. People are not just talking about a science problem and how it affects This year’s Annual Report echoes the idea of personal connections and P02: FIRST Robotics Competition someone else; they are talking about a science problem that affects personal commitment.
    [Show full text]
  • Artifact-Centric Modeling of Business Processes Using UML Diagrams
    Proceedings of The 20th World Multi-Conference on Systemics, Cybernetics and Informatics (WMSCI 2016) Artifact-Centric Modeling of Business Processes Using UML Diagrams David Grünert, Thomas Keller, and Elke Brucker-Kley ZHAW School of Management and Law Institute of Business Information Technology 8401 Winterthur, Switzerland {grud, kell, brck}@zhaw.ch Abstract and hidden in the process model. Accordingly, the positioning of information at the center of modeling was termed data- or infor- The modeling of business processes to date has focused on an mation-centric process modeling [2], [3], [4], [5]. Information activity-based perspective while business artifacts associated with entities are modeled by state charts. Transitions are triggered by the process have been modeled on an abstract and informal level. activities. Associated roles are defined by means of use case Ad hoc, dynamic business processes have recently emerged as a diagrams. In [5], the term opportunistic BPM (oBPM) was intro- requirement. Subsequently, BPMN was extended with ad hoc duced for this kind of approach. The duality between activity- sub-processes and a new standard, Case Management Modeling and information-centric models was shown in [6]. and Notation (CMMN), has been created by the Object Manage- Many artifact-centric approaches defined new or extended model ment Group (OMG). CMMN has an information-centric ap- syntax [6]. However, a new or extended modeling syntax increas- proach, whereas the extension of BPMN adheres to an activity- es complexity for all parties involved in designing, reading, and based perspective. The focus on BPMN and on processes in gen- implementing the modeled process and requires adapted model- eral has caused UML to fade into the background.
    [Show full text]
  • Adaptive Health Management Information Systems Concepts, Cases, and Practical Applications
    56918_FMxx_Final_Tan 4/6/10 1:31 PM Page i Adaptive Health Management Information Systems Concepts, Cases, and Practical Applications Third Edition Edited by Joseph Tan, PhD Professor Business Department Wayne State University School of Business Administration Detroit, Michigan with Fay Cobb Payton, PhD Associate Professor Information Systems/Technology North Carolina State University College of Management Raleigh, North Carolina 56918_FMxx_Final_Tan 4/6/10 1:31 PM Page ii World Headquarters Jones and Bartlett Publishers Jones and Bartlett Publishers Jones and Bartlett Publishers 40 Tall Pine Drive Canada International Sudbury, MA 01776 6339 Ormindale Way Barb House, Barb Mews 978-443-5000 Mississauga, Ontario L5V 1J2 London W6 7PA [email protected] Canada United Kingdom www.jbpub.com Jones and Bartlett’s books and products are available through most bookstores and online booksellers. To contact Jones and Bartlett Publishers directly, call 800-832-0034, fax 978-443-8000, or visit our website www.jbpub.com. Substantial discounts on bulk quantities of Jones and Bartlett’s publications are available to corporations, professional associations, and other qualified organizations. For details and specific discount information, contact the special sales department at Jones and Bartlett via the above contact information or send an email to [email protected]. Copyright © 2010 by Jones and Bartlett Publishers, LLC All rights reserved. No part of the material protected by this copyright may be reproduced or utilized in any form, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without written permission from the copyright owner. This publication is designed to provide accurate and authoritative information in regard to the Subject Matter covered.
    [Show full text]
  • Aerospace, Defense, and Government Services Mergers & Acquisitions
    Aerospace, Defense, and Government Services Mergers & Acquisitions (January 1993 - April 2020) Huntington BAE Spirit Booz Allen L3Harris Precision Rolls- Airbus Boeing CACI Perspecta General Dynamics GE Honeywell Leidos SAIC Leonardo Technologies Lockheed Martin Ingalls Northrop Grumman Castparts Safran Textron Thales Raytheon Technologies Systems Aerosystems Hamilton Industries Royce Airborne tactical DHPC Technologies L3Harris airport Kopter Group PFW Aerospace to Aviolinx Raytheon Unisys Federal Airport security Hydroid radio business to Hutchinson airborne tactical security businesses Vector Launch Otis & Carrier businesses BAE Systems Dynetics businesses to Leidos Controls & Data Premiair Aviation radios business Fiber Materials Maintenance to Shareholders Linndustries Services to Valsef United Raytheon MTM Robotics Next Century Leidos Health to Distributed Energy GERAC test lab and Technologies Inventory Locator Service to Shielding Specialities Jet Aviation Vienna PK AirFinance to ettain group Night Vision business Solutions business to TRC Base2 Solutions engineering to Sopemea 2 Alestis Aerospace to CAMP Systems International Hamble aerostructure to Elbit Systems Stormscope product eAircraft to Belcan 2 GDI Simulation to MBDA Deep3 Software Apollo and Athene Collins Psibernetix ElectroMechanical Aciturri Aeronautica business to Aernnova IMX Medical line to TransDigm J&L Fiber Services to 0 Knight Point Aerospace TruTrak Flight Systems ElectroMechanical Systems to Safran 0 Pristmatic Solutions Next Generation 911 to Management
    [Show full text]
  • Xerox University Microfilms 300 North Zeeb Road Ann Arbor, Michigan 48106 74-2001
    CULTURAL FORMATION PROCESSES OF THE ARCHAEOLOGICAL RECORD: APPLICATIONS AT THE JOINT SITE, EAST-CENTRAL ARIZONA Item Type text; Dissertation-Reproduction (electronic) Authors Schiffer, Michael B. Publisher The University of Arizona. Rights Copyright © is held by the author. Digital access to this material is made possible by the University Libraries, University of Arizona. Further transmission, reproduction or presentation (such as public display or performance) of protected items is prohibited except with permission of the author. Download date 11/10/2021 00:04:31 Link to Item http://hdl.handle.net/10150/288122 INFORMATION TO USERS This material was produced from a microfilm copy of the original document. While the most advanced technological means to photograph and reproduce this document have been used, the quality is heavily dependent upon the quality of the original submitted. The following explanation of techniques is provided to help you understand markings or patterns which may appear on this reproduction. 1. The sign or "target" for pages apparently lacking from the document photographed is "Missing Page(s)". If it was possible to obtain the missing page(s) or section, they are spliced into the film along with adjacent pages. This may have necessitated cutting thru an image and duplicating adjacent pages to insure you complete continuity. 2. When an image on the film is obliterated with a large round black mark, it is an indication that the photographer suspected that the copy may have moved during exposure and thus cause a blurred image. You will find a good image of the page in the adjacent frame. 3.
    [Show full text]
  • Plantuml Language Reference Guide (Version 1.2021.2)
    Drawing UML with PlantUML PlantUML Language Reference Guide (Version 1.2021.2) PlantUML is a component that allows to quickly write : • Sequence diagram • Usecase diagram • Class diagram • Object diagram • Activity diagram • Component diagram • Deployment diagram • State diagram • Timing diagram The following non-UML diagrams are also supported: • JSON Data • YAML Data • Network diagram (nwdiag) • Wireframe graphical interface • Archimate diagram • Specification and Description Language (SDL) • Ditaa diagram • Gantt diagram • MindMap diagram • Work Breakdown Structure diagram • Mathematic with AsciiMath or JLaTeXMath notation • Entity Relationship diagram Diagrams are defined using a simple and intuitive language. 1 SEQUENCE DIAGRAM 1 Sequence Diagram 1.1 Basic examples The sequence -> is used to draw a message between two participants. Participants do not have to be explicitly declared. To have a dotted arrow, you use --> It is also possible to use <- and <--. That does not change the drawing, but may improve readability. Note that this is only true for sequence diagrams, rules are different for the other diagrams. @startuml Alice -> Bob: Authentication Request Bob --> Alice: Authentication Response Alice -> Bob: Another authentication Request Alice <-- Bob: Another authentication Response @enduml 1.2 Declaring participant If the keyword participant is used to declare a participant, more control on that participant is possible. The order of declaration will be the (default) order of display. Using these other keywords to declare participants
    [Show full text]
  • Lbex-Docid 146350 Lehman Brothers Holdings Inc
    Loan Portfolio Group LPG Weekly Review Private and Confidential July 27, 2007 Loan Portfolio - Gross & Net Exposure $40.2 Greg Smith $40.0 (212) 526-5347 [email protected] $36.0 $8.5 $31.7 A. Tucker Hackett, CFA $32.0 (212) 526-3164 $28.0 [email protected] $9.3 $24.0 Frank Turner $20.6 $20.9 (212) 526-1463 $20.0 $4.5 [email protected] $6.9 (billions) $16.0 $31.7 Daniel Haykin $12.0 $12.0 (212) 526-6050 $8.8 $22.4 [email protected] $7.4 $8.0 $16.1 $3.1 $14.0 Andrew Milanez $4.0 $5.7 (212) 526-3038 $4.7 [email protected] $0.0 Gross Net Gross Net Gross Net Binita Parmar (212) 526-7643 FYE 2005 FYE 2006 7/24/07 [email protected] High Grade High Yield * *Includes European deals that have closed but are still in syndication. Loan Portfolio Summary FYE 2005 FYE 2006 7/24/07 (mm) HG HY TOTAL HG HY TOTAL HG HY TOTAL Gross Exposure $16,144 $4,483 $20,627 $22,387 $9,313 $31,700 $31,698 $8,507 $40,205 Structured Participations (3,310) (250) (3,560) (4,172) (131) (4,303) (4,439) (137) (4,576) CDS/Bond Shorts (7,122) (1,110) (8,232) (13,554) (1,814) (15,368) (13,262) (1,424) (14,686) Net Exposure $5,712 $3,123 $8,835 $4,661 $7,368 $12,029 $13,997 $6,947 $20,943 Macro & Other Hedges 0 0 0 (683) (100) (783) (1,181) (125) (1,306) $5,712 $3,123 $8,835 $3,978 $7,268 $11,246 $12,816 $6,822 $19,637 Internal Use Only This is a product of the Loan Portfolio Group and is neither Lehman Brothers research nor a research report.
    [Show full text]
  • The Development of an Object-Oriented Software
    Object-Oriented Design Lecture 18 Implementation Workflow Sharif University of Technology 1 Department of Computer Engineering Implementation Workflow • Implementation is primarily about creating code. However, the OO analyst/designer may be called on to create an implementation model. • The implementation workflow is the main focus of the Construction phase. • Implementation is about transforming a design model into executable code. Sharif University of Technology 2 Implementation Modeling • Implementation modeling is important when: • you intend to forward-engineer from the model (generate code); • you are doing CBD in order to get reuse. • The implementation model is part of the design model. • Artifacts - represent the specifications of real-world things such as source files: • components are manifest by artifacts; • artifacts are deployed onto nodes. • Nodes - represent the specifications of hardware or execution environments. Sharif University of Technology 3 Implementation Model Sharif University of Technology 4 Implementation Workflow: Activities • The Implementation Workflow consists of the following activities: • Architectural Implementation • Integrate System • Implement a Component • Implement a Class • Perform Unit Test Sharif University of Technology 5 Architectural Implementation • The UP activity Architectural Implementation is about identifying architecturally significant components and mapping them to physical hardware. • The deployment diagram maps the software architecture to the hardware architecture. • Deployment
    [Show full text]
  • UASSC Participating Organizati
    Organizations participating in the UASSC 34 North Drones. LLC American Society of Agricultural and Biological ABSI Defense Engineers (ASABE) Academy of Model Aeronautics (AMA) American Society of Mechanical Engineers Advance Aerial Inspection Resources (ASME) Aer Tellus Aqua Unmanned Systems American Society of Safety Professionals (ASSP) Aerie Collective American Tower Corporation Aerial Innovation Analytical Graphics, Inc. Aerial Services, Inc. (ASI) Apellix Aerion Supersonic Apple Inc. Aeronyde Corporation Archangel Aero Aerospace Corporation, The Argos Unmanned Aerial Solutions Aerospace Industries Association (AIA) Ariascend Corporation Aerospace Vehicle Systems Institute (AVSI), Texas Aries Aero Systems, LLC A&M University ARINC Industry Activities, a Program of SAE ITC Aero Systems West Army National Guard Airavat, LCC ASIS International Air Line Pilots Association (ALPA) Association for Automatic Identification & Airborne International Response Team (AIRT) Mobility (AIM) Airborne Law Enforcement Association (ALEA) Association for Unmanned Vehicle Systems Airborne Public Safety Association International (AUVSI) Airbus Aerial ASTM International Aircraft Owners & Pilots Association (AOPA) AT&T AirMap Astronics AES Airobotics Inc. Aurora Flight Sciences (A Boeing Company) AirShark Aviation Systems Engineering Company (ASEC) AiRXOS, part of GE Aviation Bell Flight Airzus, Inc. BNSF Railway Akin Gump Strauss Hauer & Feld LLP Boeing Company, The Alaska Center for UAS Integration, University of Boeing Research & Technology (BR&T) Alaska
    [Show full text]
  • Insight MFR By
    Manufacturers, Publishers and Suppliers by Product Category 11/6/2017 10/100 Hubs & Switches ASCEND COMMUNICATIONS CIS SECURE COMPUTING INC DIGIUM GEAR HEAD 1 TRIPPLITE ASUS Cisco Press D‐LINK SYSTEMS GEFEN 1VISION SOFTWARE ATEN TECHNOLOGY CISCO SYSTEMS DUALCOMM TECHNOLOGY, INC. GEIST 3COM ATLAS SOUND CLEAR CUBE DYCONN GEOVISION INC. 4XEM CORP. ATLONA CLEARSOUNDS DYNEX PRODUCTS GIGAFAST 8E6 TECHNOLOGIES ATTO TECHNOLOGY CNET TECHNOLOGY EATON GIGAMON SYSTEMS LLC AAXEON TECHNOLOGIES LLC. AUDIOCODES, INC. CODE GREEN NETWORKS E‐CORPORATEGIFTS.COM, INC. GLOBAL MARKETING ACCELL AUDIOVOX CODI INC EDGECORE GOLDENRAM ACCELLION AVAYA COMMAND COMMUNICATIONS EDITSHARE LLC GREAT BAY SOFTWARE INC. ACER AMERICA AVENVIEW CORP COMMUNICATION DEVICES INC. EMC GRIFFIN TECHNOLOGY ACTI CORPORATION AVOCENT COMNET ENDACE USA H3C Technology ADAPTEC AVOCENT‐EMERSON COMPELLENT ENGENIUS HALL RESEARCH ADC KENTROX AVTECH CORPORATION COMPREHENSIVE CABLE ENTERASYS NETWORKS HAVIS SHIELD ADC TELECOMMUNICATIONS AXIOM MEMORY COMPU‐CALL, INC EPIPHAN SYSTEMS HAWKING TECHNOLOGY ADDERTECHNOLOGY AXIS COMMUNICATIONS COMPUTER LAB EQUINOX SYSTEMS HERITAGE TRAVELWARE ADD‐ON COMPUTER PERIPHERALS AZIO CORPORATION COMPUTERLINKS ETHERNET DIRECT HEWLETT PACKARD ENTERPRISE ADDON STORE B & B ELECTRONICS COMTROL ETHERWAN HIKVISION DIGITAL TECHNOLOGY CO. LT ADESSO BELDEN CONNECTGEAR EVANS CONSOLES HITACHI ADTRAN BELKIN COMPONENTS CONNECTPRO EVGA.COM HITACHI DATA SYSTEMS ADVANTECH AUTOMATION CORP. BIDUL & CO CONSTANT TECHNOLOGIES INC Exablaze HOO TOO INC AEROHIVE NETWORKS BLACK BOX COOL GEAR EXACQ TECHNOLOGIES INC HP AJA VIDEO SYSTEMS BLACKMAGIC DESIGN USA CP TECHNOLOGIES EXFO INC HP INC ALCATEL BLADE NETWORK TECHNOLOGIES CPS EXTREME NETWORKS HUAWEI ALCATEL LUCENT BLONDER TONGUE LABORATORIES CREATIVE LABS EXTRON HUAWEI SYMANTEC TECHNOLOGIES ALLIED TELESIS BLUE COAT SYSTEMS CRESTRON ELECTRONICS F5 NETWORKS IBM ALLOY COMPUTER PRODUCTS LLC BOSCH SECURITY CTC UNION TECHNOLOGIES CO FELLOWES ICOMTECH INC ALTINEX, INC.
    [Show full text]
  • A Model-Driven Methodology Approach for Developing a Repository of Models Brahim Hamid
    A Model-Driven Methodology Approach for Developing a Repository of Models Brahim Hamid To cite this version: Brahim Hamid. A Model-Driven Methodology Approach for Developing a Repository of Models. 4th International Conference On Model and Data Engineering (MEDI 2014), Sep 2014, Larnaca, Cyprus. pp.29-44, 10.1007/978-3-319-11587-0_5. hal-01387744 HAL Id: hal-01387744 https://hal.archives-ouvertes.fr/hal-01387744 Submitted on 26 Oct 2016 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Open Archive TOULOUSE Archive Ouverte ( OATAO ) OATAO is an open access repository that collects the work of Toulouse researchers and makes it freely available over the web where p ossible. This is an author-deposited version published in : http://oatao.univ-toulouse.fr/ Eprints ID : 15256 The contribution was presented at MEDI 2014: http://medi2014.cs.ucy.ac.cy/ To cite this version : Hamid, Brahim A Model-Driven Methodology Approach for Developing a Repository of Models. (2014) In: 4th International Conference On Model and Data Engineering (MEDI 2014), 24 September 2014 - 26 September 2014 (Larnaca, Cyprus). Any corresponde nce concerning this service should be sent to the repository administrator: staff -oatao@listes -diff.inp -toulouse.fr A Model-Driven Methodology Approach for Developing a Repository of Models Brahim Hamid IRIT, University of Toulouse 118 Route de Narbonne, 31062 Toulouse Cedex 9, France [email protected] Abstract.
    [Show full text]
  • Working with Deployment Diagram
    UNIVERSITY OF ENGINEERING AND TECHNOLOGY, TAXILA FACULTY OF TELECOMMUNICATION AND INFORMATION ENGINEERING SOFTWARE ENGINEERING DEPARTMENT Lab # 09 Working with Deployment Diagram You’ll learn in this Lab: What a deployment diagram is Applying deployment diagrams Deployment diagrams in the big picture of the UML A solid blueprint for setting up the hardware is essential to system design. The UML provides you with symbols for creating a clear picture of how the final hardware setup should look, along with the items that reside on the hardware What is a Deployment Diagram? A deployment diagram shows how artifacts are deployed on system hardware, and how the pieces of hardware connect to one another. The main hardware item is a node, a generic name for a computing resource. A deployment diagram in the Unified Modeling Language models the physical deployment of artifacts on nodes. To describe a web site, for example, a deployment diagram would show what hardware components ("nodes") exist (e.g., a web server, an application server, and a database server), what software components ("artifacts") run on each node (e.g., web application, database), and how the different pieces are connected (e.g. JDBC, REST, RMI). In UML 2.0 a cube represents a node (as was the case in UML 1.x). You supply a name for the node, and you can add the keyword «Device», although it's usually not necessary. Software Design and Architecture 4th Semester-SE UET Taxila Figure1. Representing a node in the UML A Node is either a hardware or software element. It is shown as a three-dimensional box shape, as shown below.
    [Show full text]