Extending the UML Standards to Model Tree-Structured Data and Their Access Control Requirements

  • Alberto De la Rosa Algarín
  • Steven A. Demurjian
Conference paper
Part of the Lecture Notes in Computer Science book series (LNCS, volume 10074)


Secure data sharing between computational systems is a necessity to many workflows across domains such as healthcare informatics, law enforcement and national security. While there exist many approaches towards securing data for the purpose of dissemination, the vast majority follows the traditional thought of security engineering that occurs as the last step of the overall software engineering process. In this paper we extend the Unified Modeling Language (UML) standard to: (1) modeling tree-structured data and associated schemas and (2) information security via role-based, lattice-based, and discretionary access control; both push it towards the forefront of the software development life-cycle. Tree structured data and associated schemas are dominant in information modeling and exchange formats including: the eXtensible Markup Language (XML), JavaScript Object Notation (JSON), etc. New UML artifacts for tree-structured data and schemas would allow the modeling of generalized information solutions from which XML, JSON, RDF, etc., could be generated; this is akin to generating different object-oriented programming language code from UML class diagrams. This UML extension also allows security experts to model and define information security requirements at the schema level as well, before code is written. The end-result is the assurance of information security for the purpose of sharing across computational systems.


Unify Modeling Language Resource Description Framework Security Policy Access Control Model Clinical Document Architecture 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Information modeling is focused on representing the information that is used and exchanged in large-scale applications and system-to-system operability with a common representation for scalable reuse. The implementation of information modeling has been predominately pursued using standards that utilize languages that facilitate structure, such as the eXtensible Markup Language (XML) [8], which models documents as schemas that dictate and enforce the required format for instances. Sample application areas and standards that use XML include: healthcare via the Health Level 7’s Clinical Document Architecture (HL7 CDA) [12, 14]; cXML [20] for e-commerce communication; finance via the Open Financial Exchange (OFX) [22], and other standards [23]. While XML has become the de-facto standard for information modeling implementation, other formats exist that share similar capabilities: the Resource Description Framework (RDF) [17], the Web Ontology Language (OWL) [19], and the JavaScript Object Notation (JSON) [9]. XML, RDF, OWL, and JSON can all model data utilizing a tree-structure of index and entity nodes that allows for information to be represented via schemas (that define structure), which can then be used as blueprints for the creation of new documents (instances) and their validation (enforcement), with some of them providing semantic modeling capabilities as well (RDF and OWL).

This paper proposes extensions to the Unified Modeling Language (UML) [2, 15] standard with new constructs that achieve a two-fold objective. The first objective supports the modeling of tree-structured data and schemas with new UML diagrams to allow generalized design from which target schemas/instances in XML, JSON, RDF, etc., can be generated. The second objective supports the definition of new UML diagrams from role-based access control (RBAC) [13], lattice-based access control (LBAC) [30], and discretionary access control (DAC) [31]) for tree-structure schemas and their instance. The end result is the ability to model tree-structured schemas at a generalized level including access thereby elevating the process of secure information design as a first-class citizen of the software engineering process. By tackling the problem from a perspective of tree-structured schemas, any document format that is represented by such a structure (e.g. XML, specialized JSON structures, RDF, OWL, etc.) can be modeled, secured and safely shared. This effectively allows us to provide separation of concerns with respect to information modeling and RBAC, LBAC, and DAC by defining the information model itself and security requirements in a software process phase.

The remainder of this paper is organized as follow: Sect. 2 provides background knowledge on UML utilized in the paper. Section 3 details the initial set of UML extensions for tree-structured data. Section 4 utilizes this initial set of extensions to UML and builds upon the need for RBAC, LBAC and DAC support by presenting diagram extensions that allow a security engineer to define access control requirements on tree-structured data. Section 5 presents the automated strategy utilized to generate enforcement policies via the proposed UML diagrams. Section 6 discusses related work. Section 7 concludes the paper.

2 Background

UML is a general-purpose modeling language for object-oriented systems [15, 32]. Currently managed by the Object Management Group (OMG), UML can be used throughout the software development cycle by combining data, business and object modeling. UML provides the benefit of reducing misinterpretation and promoting simple communication of domain requirements with its visual notation. However, while UML can be utilized to define security requirements, what is lacking in the UML standard is actual diagrams that are dedicated to, in our interest, access control models (RBAC, LBAC, and DAC) that allow the definition of security requirements using new security UML diagrams that seamlessly integrate with the UML model and unified design process. This is particularly true for domains such as healthcare where the information to be utilized is private and often governed by legal constructs that assure its proper use and dissemination [1, 3, 4].

UML can be extended via the use of the meta-model architecture developed by OMG. This meta-model architecture, called the Meta-Object Facility [27], consists of four layers. As shown in Fig. 1, the M3 layer consists of the meta-meta model. M2-models are built using the M3 language. In turn, M2-models describe the elements of the M1-layer, while the M1-models describe the elements of the M0-layer (the runtime instance of the modeled system). Due to the inclusion of UML into ISO as a standard [2] for software systems, several tools (and development environments) exist to aid in UML modeling, including: ArgoUML [28], StarUML [18], Eclipse [21], Visual Studio [29], NetBeans [7], and others. The UML meta-model will be utilized in this paper to support the definition of new UML diagrams that are capable of modeling tree-structured data and RBAC, LBAC, and DAC requirements for said data.
Fig. 1.

UML’s Meta-Object Facility layers.

3 Extending UML with New Diagrams for Tree-Structured Schemas

This section supports the modeling of tree-structured data and schemas by extending UML with new UML to allow generalized design from which target schemas/instances in XML, JSON, RDF, etc., can be generated. The presentation is in two parts. First, section introduces the new UML Document Schema Class Diagram (DSCD), a UML extension that can handle any tree-structured schema to model the data and realize the instance. Second, the DSCD is demonstrated at an instance level utilizing the HL7 CDA schema, which are specializations of a tree-structure document whose structure can be represented with the UML DSCD modeling construct called the UML Profile.

The new UML Document Schema Class Diagram (DSCD) is an artifact that holds all of the characteristics of the schema, including structure, data type, and value constraints. The DSCD graphically represents the schemas utilized by an information system. Recall the requirement of all data modeling be represented by a tree-like structure, possibly complimented with data type constraints. To achieve this, we utilize a UML profile for tree-structured documents. There has been research in UML profiles for tree-structured documents, mainly utilizing XML [5, 6], which range from information modeling to systems modeling represented in XML [8]. This work also considers round-trip engineering, a concept that denotes the ability of producing a UML diagram from XML and vice-versa, without the loss of information. For the scope of the work in this paper, we generate a DSCD a UML diagram from a source tree-document schema, which for the purposes or demonstrating the concepts, is actually an XML schema. To facilitate this process, we utilize the UML Profile concept that allows new diagrams to be defined using the various UML concepts (stereotypes, tags, constraints applied to classes, attributes, operations, etc.) that allow a tree structured document to be transitioned into DSCD, and for the particular purposes of this section, to demonstrate the way that an XML schema (a tree structured format) can be transitioned to the new UML DSCD diagram; this is shown in Table 1.
Table 1.

Specialized UML profile for tree-structured document to DSCD with XML cases.

While it is possible to utilize the UML profile to represent an entire schema as a UML package, we instead have chosen to represent each schema as a tree of stereotyped classes. This approach was chosen in order to capture the hierarchical structure of a schema as a series of related classes. Table 1 has three columns: the first column represents the features of tree structured document, the second column defines the corresponding XML equivalents of these features, and the third column transitions the second column into the equivalent UML profile concept. In the first row of Table 1, a general element in the tree-structured document is equivalent to an XML element ( xsd:element ) and is realized as a UML class; the second row maps the element name to a UML class name. In the third row of Table 1, an element attribute in the tree-structured document is equivalent to a generic attribute in XML which can be mapped to a «stereotyped» attribute in UML. The fourth row corresponds to a patient – child relationship at the schema level to identify a tree and its subtrees, which in XML is observed as nested elements, and is represented as a UML dependency relationship in the DSCD. The fifth row of Table 1 describes complex elements (those that are built out of many sub-elements), which in XML are denoted as xsd:complexType and in the DSCD are denoted as a UML class with the «complexType» stereotype. The sixth row covers a similar case, considering sequences or lists of elements, which in XML are denoted as xsd:sequence and in the DSCD are denoted as a UML class with the «sequence» stereotype. Aggregation of attributes are handled with the seventh row of Table 1 and is represented as xsd:attributeGroup in XML and as a UML class with the «attributeGroup» stereotype in the DSCD. In the eighth row of Table 1, groups of elements in a tree-structured document are equivalent to an XML xsd:group node and is represented as a UML class with the «group» stereotype in DSCD. The ninth row of Table 1 handles acceptable or allowable values for elements, which in XML are usually maxOccurs and minOccurs attributes to an XML element constraints, realized as a «constraint» stereotyped class member in DSCD. In the tenth row of Table 1, indirect references allow elements of a tree-structure document to be associated with one another, which in XML is a ref attribute on an element that are represented as a «ref» class member from UML profile in the DSCD. Lastly, in the eleventh row of Table 1, for tree-structured document, the parent-child relationship between non-named elements corresponds to non-named elements in XML (e.g., xsd:complexType , xsd:attributeGroup , etc.) and is represented with a UML directed association relationship between classes in the DSCD. Note that by using these mappings in Table 1 it is possible to develop an algorithm that operate over an XML schema to generate a DSCD equivalent in UML. Note also that there would need to be other versions of Table 1 for other data formats (e.g., JSON, RDF, etc.) where the second column of the table would be replaced with the relevant model constructs from the other formats.

As an example of utilizing the UML profile approach to convert a tree-structured data into a DSCD, lets utilize the MMUCC schema [16] that is utilized in the law enforcement domain. The conversion of the schema from Fig. 2 into a DSCD follows a mapping process guided by the profile of Table 1, resulting in a DSCD as shown in Fig. 3.
Fig. 2.

Segment of MMUCC from Alaska Collision Report 12-200 Schema.

Fig. 3.

A DSCD for the MMUCC Segment.

4 Extending UML Extensions to Model RBAC, LBAC, and DAC of Tree-Structured Schemas

This section presents a set of new UML diagrams from role-based access control (RBAC), lattice-based access control (LBAC), and discretionary access control (DAC) for tree-structure schemas and their instance. This is accomplished by detailing UML standard extension via, a metamodel built on top of the foundation of the security model in Sect. 3. UML provides a large variety of diagrams for the visualization of different software requirements: class, component, deployment, activity, use-case, state-machine, communication, sequence, etc. [15] The work presented in this section leverages off of early work that has extended UML with new diagrams for RBAC, MAC, and DAC capabilities [24] from an object-oriented perspective. The extensions presented in this section are achieved via the UML Meta-Object Facility (MOF), which allows the extension of the modeling language with several degrees of formality, as reviewed in Sect. 2.

The tree-document schemas, as shown in the example DSCD in Fig. 3, can be constrained to identify those portions of the schema that require security control. To achieve this, we introduce the new UML Secure Information Diagram, which identifies those portions (elements and subtrees) of an application’s schema (DSCD in Fig. 3) on which both RBAC permissions and LBAC classifications will be defined. For the SID, the M2 metamodel is shown in Fig. 4 where each class that is part of the SID is represented as meta-class (SecureInformation) associated with many possible instances of any given schema element as represented with the Element meta-class. Following the example of the MMUCC, the realization of the SID is shown in Fig. 5, a subset of the information from Fig. 3 that needs to be secure.
Fig. 4.

Secure Information Diagram M2 metamodel.

Fig. 5.

SID with MMUCC elements.

The next extension is the new Document Role-Slice Diagram (DRSD), with the purpose of supporting RBAC of operations that target schemas and their instances and to enable granular LBAC labeling of elements. The DRSD organizes the roles into a hierarchy. The metamodel for the DRSD (as shown in Fig. 6) consists of the RoleSlice meta-class represents the role slices that will be defined with permissions against the SID (see Fig. 5 again) with respect to the schema(s) of the application to be secured. The Permission meta-class represents the permissions allowed over the instances validated against the secured schema (read, aggregate, insert, update, delete) that define what a role can and can’t do for the elements in a schema. In order to create a relation between the RoleSlice meta-class (which contains all of the DRSD instances) and the Permission meta-class (which contains all of the schema targeting permissions), it is necessary to create a relation between the users and their roles. In Fig. 6, the UserRole meta-class is a parent-class of the RoleSlice meta-class and a sibling class of the Permission meta-class. The connections between the UserRole and Permission meta-classes are given by the permitted permission (PP) relation. The Element meta-class in turn represents all of the instances of elements (from the schema) that are targeted by the different permissions. This connection is tagged with the targeted element (TE) label in Fig. 6. Again, following the example of the MMUCC, the realization of the DRSD with sample roles against the SID of Fig. 5 is shown in Fig. 7.
Fig. 6.

Document Role Slice Diagram M2 metamodel.

Fig. 7.

DRSD Role hierarchy for MMUCC access in the law enforcement scenario.

Next, the new LBAC Secure Information Diagram (LSID) is shown in Fig. 8, a UML package with the stereotype «SecureInformation» that decorates the SID and contains all of the respective classes of elements from the schema to be secured per access modes (ams) and classifications (cls). The meta-model for the LSID consists of four meta-classes: User, AccessMode, Element, and SensitivityLevel. These metaclasses are interconnected to represent the relations between the user (User), its clearance level (Sensitivity), and access modes (read, aggregate, insert, update, delete; AccessMode) for each of the elements (xs:element, xs:complexTyp, etc.; Element) from the SID that need to be protected. To represent the relation between User and SensitivityLevel, an arrow with a UC (user clearance) tag is used. This relation indicates that the user could either have a clearance level or is without a clearance level, therefore the utilization of the 0..1 cardinality constraint. Element and Sensitivity are similarly related, represented with the arrow tagged EC (element classification). The relationship between Element and AccessMode is represented with the 1.. + cardinality constraint to cover the case of an element with different possible access modes. The result of the metamodel instantiation with the MMUCC example is shown in Fig. 9.
Fig. 8.

LSID M2 metamodel.

Fig. 9.

LSID for MMUCC access.

Next, at the metamodel layer (M2) of the MOF, the new User Diagram (UD) extension is presented in Fig. 10. The interplay of users, their roles and delegation permissions (for RBAC), their clearance levels (for LBAC), and their authorization permissions (DAC) require the proper definition of a user concept. The work in secure software engineering [26] proposed a UML extension for users via a User Diagram. In this paper, we build upon this first iteration of the User Diagram to extend to include both LBAC and RBAC user features directly to the metamodel. The metamodel of the UD is composed of six major meta-classes as given in Fig. 10: User, SensitivityLevel, UserRole, RoleSlice, SOD, and ME. The User meta-class represents all of the possible instances of users in a particular application. Both the User meta-class and the RoleSlice meta-class, is a subtype of the UserRole meta-class. The UR tag represents user-role assignments (RBAC), the separation of duty (SOD) meta-class represents the separation of duty relations, and, the mutual exclusion (ME) meta-class represents the mutual exclusion relations between roles. The SensitivityLevel meta-class, which represents the sensitivity as related to LBAC is a clearance level for a user and is tied to the User meta-class. This distinction shows an important feature of the security framework presented in this dissertation, namely, that RBAC and LBAC capabilities are orthogonal. Following the examples of the roles in Fig. 7, we show an example UD for the MMUCC in Fig. 11.
Fig. 10.

User Diagram M2 metamodel.

Fig. 11.

User Diagram for the Law Enforcement Scenario.

The delegation component of the underlying security model is supported with the new Delegation Diagram (DD) extension to the UML standard given as a metamodel in Fig. 12. The metamodel consists of three meta-classes: OriginalUser, DelegableUser, and RoleSlice. The OriginalUser meta-class, along with the RoleSlice meta-class represents the original users of the application and their assigned roles. The DelegableUser, connected to the RoleSlice meta-class, represents the user/role pairs of authorized delegations. In turn, the Delegation tag in the connection between OringalUsers and DelegableUsers represents the ability to perform the delegation operation. Figure 13 shows a sample instantiation of the DD metamodel would look in the example of the MMUCC.
Fig. 12.

Role Delegation Diagram M2 metamodel.

Fig. 13.

DD for User Rob in police captain role in a law enforcement scenario.

The final extension of the UML standard to support the security model consists of new the Authorization Diagram (AD) metamodel in Fig. 14 that consists of four meta-classes: UserRole, Authorization, Instance, and Schema. The UserRole meta-class represents the specific user/role pair in a similar fashion as the case of the UD in Fig. 6. The Authorization meta-class is connected to the Instance and Schema meta-classes to represent whether an authorization to an instance or schema exists and is represented with the 0.. + tag on the directional connection. This metamodel definition allows scenarios in which a user might not be authorized to any schema/instance, or any combination of the two (e.g. all schemas and all instances). Figure 15 shows an MMUCC related AD with the users and roles utilized from Figs. 11 and 7, respectively.
Fig. 14.

Authorization Diagram M2 metamodel.

Fig. 15.

AD for user van in the law enforcement scenario.

5 Generating Enforcement Policies from UML Extensions to XACML

In this section, we provide a high-level view of the security policy generation process that combines the access control concepts and capabilities of our security model with the new UML diagrams into an architecture. As shown in Fig. 16, the new UML extensions in the first column (DSCD, SID, DRSD, LBAC, UD, DD, and AD) are used in various combinations (see four different arrow types) in order to start a process that can map them through access control models RBAC, LBAC, DAC delegations, and authorizations (see column two) in order to identify the key policy components (see column three) that are then utilized to automatically generate a security policy (fourth column). First, DSCD, SID, DRSD and UD are combined to produce an RBAC oriented policy for each user/role combination; as a result, multiple security policies are generated on a user/role basis. Second, DSCD, SID, LSID, and UD are combined to produce an LBAC oriented policy for each user; again, specific security policies are generated for each user. Third, DRSD, UD, and DD are combined to produce a security policy that defines the delegable users and the role that can be delegated; again, this results in a separate policy each user/role combination. Finally, DSCD, DRSD, UD, and AD are combined to generate the policy that identifies the schemas and instances are authorized for a specific user. For each of these combinations, there is a transition to the policy components that form the basis of the generated policies. The last step in the process, illustrates the alternative policies that can be generated, including XACML (the focus of this dissertation), SQL DDL code for a relational database system, and aspect-oriented programing (AOP) for an object-oriented application [25].
Fig. 16.

Generating policies from UML diagrams.

The process of generating an XACML policy from the new UML standard extensions can be automated with an algorithm, as shown by Fig. 17. From a high-level perspective, the first step is to iterate over every user of the information system that requires security. Once a user is selected, the next step is to find that user’s role and the respective DRSD that describes all of the permissions over every element. Then, by iterating over every permission in the relevant DRSD, the algorithm creates an XACML <Rule> object that would map the role to the <Subject>, the elements to the <Resources>, and the permissions (operations) to the <Actions>. Then, after that initial mapping is done, a check for LBAC features is done. If any LBAC features exist, such as simple-security, simple-integrity, etc., a <Condition> element is added to that rule. This process is repeated over every permission, resulting in one <Rule> with a <Condition> element if LBAC is needed for each permission in the DRSD. This iteration is repeated for every role the user might hold. After the mappings over RBAC and LBAC capabilities are complete, then delegations and authorizations are tackled. For each delegation and authorization, a <Rule> element is created that would map the schemas and instances to <Resources> inside the rule for authorization, or roles and delegable users to <Resources> and <DelegationTargets> respectively, for delegation. The end result of this high-level process is the creation of one XACML policy instance per user, which could be readily deployed. Figure 18 shows the culmination of the MMUCC example with a sample policy created by this process.
Fig. 17.

Pseudo-code for XACML policy instance generation algorithm.

Fig. 18.

Resulting XACML policy for user rob and role PoliceCaptain.

6 Related Work

There have been attempts to provide design level security for tree-structured data in the past, though the majority of the efforts focus on securing document formats such as XML in real-life scenarios. For example, [10] presents an access control system that embeds the definition and enforcement of the security policies in the structure of the XML DTD and documents in order to provide customizable security. This is similar to our work in that security policies act in both a descriptive level of the XML instances and target the XML instances, but differs in their use of the outdated XML DTD’s and their security policies are embedded into the XML instance for a high cost for security updates (recall Sect. 1). Another effort by [11] details a model that tries to combine the two discussed methodologies to provide security to XML datasets with three security attributes (access, condition and dirty) with changes updated in the both the XML schema its instances. This is similar to our work at the XACML policy level, but differs by our also taking into consideration XML document writing; their XPath’s design only allows reads.

In terms of applying similar approaches to the one presented in this paper, but for functional aspects of a software system, work in [24] provides the most influential effort for the research presented in this paper by extending UML to represent RBAC and DAC via the introduction of the Role Slice Diagram, the User Diagram, the Delegation Diagram, and MAC extensions coupled with a Secure Subsystem Diagram. The work in [24] aims to provide security to the functional aspects of a software component, down to the granularity of methods in classes (in contrast, our work aims to provide the same level of security assurance to the information/data aspect of the software). To achieve this, the Secure Subsystem Diagram presented by [24] denotes the subset of an application’s overall classes and methods that are restricted and require permissions to be in place for authorized users. The Role Slice Diagram, similar to the Document Role Slice in this paper, denotes RBAC policies from a role perspective. From an enforcement perspective, once defined, the diagrams are utilized to generate aspect-oriented enforcement code in AspectJ that is able to verify, at runtime, whether the active user has a role with permissions over the protected method and grants or denies access accordingly.

7 Conclusion

Information modeling is focused on representing, using, and exchanging data in large-scale applications or system-to-system operability. The work presented in this paper is a comprehensive approach that enables the modeling tree-structured schema in UML with the addition of the modeling of access control requirements (RBAC, LBAC, DAC) on said data for implementation solutions such as XML, JSON, and RDF. There were main contributions presented in the paper. The first contribution Sect. 3 supported the modeling of tree-structured data and schemas with the proposal of a new UML Document Schema Class Diagram (DSCD) in Sect. 3 that allowed generalized design from which target schemas/instances in XML, JSON, RDF, etc., can be generated. The second contribution in Sect. 4 proposed new UML diagrams for RBAC, LBAC, and DAC via the Secure Information Diagram (SID), the Document Role-Slice Diagram (DRSD), the LBAC Secure Information Diagram (LSID), the User Diagram (UD), the Delegation Diagram (DD), and the Authorization Diagram (AD). The combination of DSCD in Sect. 3 along with the security diagrams presented in Sect. 4 allowed the automatic generation of enforcement code via XACML as presented in Sect. 5. The end result is an underlying information security model that abstracts away from specific document formats and considers their most basic form as tree-structured containers while supporting access control capabilities as an integrated solution; and abstracting the comprehensive information security model with new UML diagrams that are capable of modeling tree-structured schemas and their associated RBAC, LBAC, and DAC.


  1. 1.
  2. 2.
    UML ISO standard. Object Management Group (2014). http://www.omg.org/spec/UML/
  3. 3.
    Annas, G.J.: HIPAA regulations—a new era of medical-record privacy? N. Engl. J. Med. 348, 1486–1490 (2003)CrossRefGoogle Scholar
  4. 4.
    Baumer, D., Earp, J.B., Payton, F.C.: Privacy of medical records: IT implications of HIPAA, pp. 137–152 (2006)Google Scholar
  5. 5.
    Bernauer, M., Kappel, G., Kramler, G.: Representing XML schema in UML–A comparison of approaches, pp. 767–769 (2004)Google Scholar
  6. 6.
    Bernauer, M., Kappel, G., Kramler, G.: Representing XML schema in UML-an UML profile for XML schema (2003)Google Scholar
  7. 7.
    Boudreau, T., Glick, J., Greene, S., Spurlin, V., Woehr, J.J.: NetBeans: The Definitive Guide. O’Reilly Media Inc., Sebastopol (2002)Google Scholar
  8. 8.
    Bray, T., Paoli, J., Sperberg-McQueen, C.M., Maler, E., Yergeau, F.: Extensible markup language (XML) (1998)Google Scholar
  9. 9.
    Crockford, D.: JSON: the fat-free alternative to XML (2006)Google Scholar
  10. 10.
    Damiani, E., Capitani, De, di Vimercati, S., Paraboschi, S., Samarati, P.: Design and implementation of an access control processor for XML documents. Comput. Netw. 33, 59–75 (2000)CrossRefGoogle Scholar
  11. 11.
    Damiani, E., Fansi, M., Gabillon, A., Marrara, S.: A general approach to securely querying XML. Comput. Stand. Interfaces 30, 379–389 (2008)CrossRefGoogle Scholar
  12. 12.
    Dolin, R.H., Alschuler, L., Boyer, S., Beebe, C., Behlen, F.M., Biron, P.V., Shvo, A.S.: HL7 clinical document architecture, release 2. J. Am. Med. Inform. Assoc. 13, 30–39 (2006)CrossRefGoogle Scholar
  13. 13.
    Ferraiolo, D.F., Sandhu, R., Gavrila, S., Kuhn, D.R., Chandramouli, R.: Proposed NIST standard for role-based access control. ACM Trans. Inform. Syst. Secur. 4, 224–274 (2001)CrossRefGoogle Scholar
  14. 14.
    Ferranti, J.M., Musser, R.C., Kawamoto, K., Hammond, W.: The clinical document architecture and the continuity of care record: A critical analysis. J. Am. Med. Inform. Assoc. 13, 245–252 (2006)CrossRefGoogle Scholar
  15. 15.
    Fowler, M.: UML distilled: a brief guide to the standard object modeling language. Addison-Wesley Professional, Boston (2004)Google Scholar
  16. 16.
    Guideline, M.: Model minimum uniform crash criteria. 811, 631 (2012)Google Scholar
  17. 17.
    Klyne, G., Carroll, J.J., McBride, B.: Resource description framework (RDF): Concepts and abstract syntax. 10 (2004)Google Scholar
  18. 18.
    Lee, M., Kim, H., Kim, J., Lee, J.: StarUML 5.0 developer guide’ (2005)Google Scholar
  19. 19.
    McGuinness, D.L., Van Harmelen, F.: OWL web ontology language overview. 10, 10 (2004)Google Scholar
  20. 20.
    Merkow, M.: cXML: a new taxonomy for E-commerce (1999)Google Scholar
  21. 21.
    Moore, B., Dean, D., Gerber, A., Wagenknecht, G., Vanderheyden, P.: Eclipse development. 379 (2004)Google Scholar
  22. 22.
    OFX, Open Financial Exchange SpecificationGoogle Scholar
  23. 23.
    Ogle, J.H., Alluri, P., Sarasua, W.: MMUCC and MIRE: the role of segmentation in safety analysis (2011)Google Scholar
  24. 24.
    Pavlich-Mariscal, J., Michel, L., Demurjian, S.: Enhancing UML to model custom security aspects (2007)Google Scholar
  25. 25.
    Pavlich-Mariscal, Jaime A., Michel, Laurent, Demurjian, Steven A.: A formal enforcement framework for role-based access control using aspect-oriented programming. In: Briand, Lionel C., Williams, Clay (eds.) MoDELS 2005. LNCS, vol. 3713, pp. 537–552. Springer, Heidelberg (2005)CrossRefGoogle Scholar
  26. 26.
    Pavlich-Mariscal, J.A., Demurjian, S.A., Michel, L.D.: A framework for security assurance of access control enforcement code. Comput. Secur. 29, 770–784 (2010)CrossRefGoogle Scholar
  27. 27.
    Poernomo, I.: The meta-object facility typed, pp. 1845–1849 (2006)Google Scholar
  28. 28.
    Ramirez, A., Vanpeperstraete, P., Rueckert, A., Odutola, K., Bennett, J., Tolke, L., van der Wulp, M.: ArgoUML user manual: a tutorial and reference description (2003)Google Scholar
  29. 29.
    Randolph, N., Gardner, D., Anderson, C., Minutillo, M.: Professional Visual Studio 2010. Wiley, Hoboken (2010)Google Scholar
  30. 30.
    Sandhu, R.S.: Lattice-based access control models. Computer 26, 9–19 (1993)CrossRefGoogle Scholar
  31. 31.
    Sandhu, R.S., Samarati, P.: Access control: principle and practice. IEEE Commun. Mag. 32, 40–48 (1994)CrossRefGoogle Scholar
  32. 32.
    Warmer, J.B., Kleppe, A.G.: The object constraint language: Precise modeling with uml (addison-wesley object technology series) (1998)Google Scholar

Copyright information

© Springer International Publishing AG 2016

Authors and Affiliations

  • Alberto De la Rosa Algarín
    • 1
  • Steven A. Demurjian
    • 2
  1. 1.Loki Labs IncBaltimoreUSA
  2. 2.Department of Computer Science and EngineeringUniversity of ConnecticutStorrsUSA

Personalised recommendations