1------------------------------------------------------------------------------ 2-- -- 3-- Matreshka Project -- 4-- -- 5-- Ada Modeling Framework -- 6-- -- 7-- Runtime Library Component -- 8-- -- 9------------------------------------------------------------------------------ 10-- -- 11-- Copyright © 2011-2012, Vadim Godunko <vgodunko@gmail.com> -- 12-- All rights reserved. -- 13-- -- 14-- Redistribution and use in source and binary forms, with or without -- 15-- modification, are permitted provided that the following conditions -- 16-- are met: -- 17-- -- 18-- * Redistributions of source code must retain the above copyright -- 19-- notice, this list of conditions and the following disclaimer. -- 20-- -- 21-- * Redistributions in binary form must reproduce the above copyright -- 22-- notice, this list of conditions and the following disclaimer in the -- 23-- documentation and/or other materials provided with the distribution. -- 24-- -- 25-- * Neither the name of the Vadim Godunko, IE nor the names of its -- 26-- contributors may be used to endorse or promote products derived from -- 27-- this software without specific prior written permission. -- 28-- -- 29-- THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS -- 30-- "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT -- 31-- LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR -- 32-- A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT -- 33-- HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, -- 34-- SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED -- 35-- TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR -- 36-- PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF -- 37-- LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING -- 38-- NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS -- 39-- SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. -- 40-- -- 41------------------------------------------------------------------------------ 42-- $Revision: 2714 $ $Date: 2012-03-24 10:29:08 +0400 (Sat, 24 Mar 2012) $ 43------------------------------------------------------------------------------ 44-- This file is generated, don't edit it. 45------------------------------------------------------------------------------ 46-- A dependency is a relationship that signifies that a single or a set of 47-- model elements requires other model elements for their specification or 48-- implementation. This means that the complete semantics of the depending 49-- elements is either semantically or structurally dependent on the 50-- definition of the supplier element(s). 51------------------------------------------------------------------------------ 52with AMF.UML.Directed_Relationships; 53limited with AMF.UML.Named_Elements.Collections; 54with AMF.UML.Packageable_Elements; 55 56package AMF.UML.Dependencies is 57 58 pragma Preelaborate; 59 60 type UML_Dependency is limited interface 61 and AMF.UML.Directed_Relationships.UML_Directed_Relationship 62 and AMF.UML.Packageable_Elements.UML_Packageable_Element; 63 64 type UML_Dependency_Access is 65 access all UML_Dependency'Class; 66 for UML_Dependency_Access'Storage_Size use 0; 67 68 not overriding function Get_Client 69 (Self : not null access constant UML_Dependency) 70 return AMF.UML.Named_Elements.Collections.Set_Of_UML_Named_Element is abstract; 71 -- Getter of Dependency::client. 72 -- 73 -- The element(s) dependent on the supplier element(s). In some cases 74 -- (such as a Trace Abstraction) the assignment of direction (that is, the 75 -- designation of the client element) is at the discretion of the modeler, 76 -- and is a stipulation. 77 78 not overriding function Get_Supplier 79 (Self : not null access constant UML_Dependency) 80 return AMF.UML.Named_Elements.Collections.Set_Of_UML_Named_Element is abstract; 81 -- Getter of Dependency::supplier. 82 -- 83 -- The element(s) independent of the client element(s), in the same 84 -- respect and the same dependency relationship. In some directed 85 -- dependency relationships (such as Refinement Abstractions), a common 86 -- convention in the domain of class-based OO software is to put the more 87 -- abstract element in this role. Despite this convention, users of UML 88 -- may stipulate a sense of dependency suitable for their domain, which 89 -- makes a more abstract element dependent on that which is more specific. 90 91end AMF.UML.Dependencies; 92