UML Modeling for JAFFA Security Plugin

Overview

Jaffa Security plugin generates the xml files based on the UML models designed for the specific application. The UML models must be designed first in order to generate the xml files.This section describes the requirements for modeling UML components in order to generate the xml files.

Prerequisite

Use Case Model

• Actors
  The actor hierarchy should be modeled onto a Use case diagram and should be stereotyped as <<actorhierarchy>> There is no specific requirement for modeling actors .They are modeled as standard UML Actor. Any actor modeled in the Actor Heirarachy diagram should be used as a shortcut in other diagrams in order to include it in the XML file generation.
  
Click here to see a demo of Actor Heirarchy

• Actor-Use case link
  There is no specific requirement for modeling the associations between an actor and a Use Case.They are modeled as standard UML Associations.
• Use Case
  A Use Case will have hyperlink to the components it uses.Basically it will hyperlink to a UML component from the component diagram.
  A Use Case will have <<includes>> links to an encapsulated use case.

Click here to see a demo of Use Case Model

• Modeling Mutually Exclusive Roles
  Mutually exclusive roles are modeled using notes.
  Firstly create a note on the actor diagram.
  The text of the note should be of the format "Excludes ActorName{, ActorName}"
  The note should be linked to one or more actors as appropriate

Click here to see a demo of Hyperlinking Use Case

Component Models

• Each Jaffa Component modeled as a UML Component Object
• Each Jaffa Business Function Switch modeled as a UML Interface Object with the stereotype <<business-function>>
• One or more component diagrams per module. The diagram should use the stereotype <<Jaffa>>
• All components for that module drawn on diagrams
• All dependant components from other models as short cuts, from owning module
• All business functions for module drawn on diagrams
• All dependant business functions needed for this module’s components, as short cuts from owning module
• The Name of the Component must be the name to be used in component.xml
• The Name of the Business Function must be the name to be used in business-functions.xml
• Linking a business function to a component is done with the ‘UML dependency link’. The tool requires that the stereotype used on that link is either <<needs>> or <<supports>>. These two stereotypes are used for mandatory and optional business functions respectively. Any other, or a missing stereotype for this kind of link will generate an error in the tool.
• Component Dependencies should be modeled with the ‘UML dependency link’. If you give access to a component, it infers access to the dependant components. It is not recommended to consider lookups as dependent components.
• Each component should be hyperlinked to one and only one UML Class Object, which should extend the ‘org.jaffa.presentation.portlet.component.Component’ or implement ‘org.jaffa.presentation.portlet.component.IComponent’

How to model different security access to the same component?

• Each level of access needs to be modeled as a separate use case. For example, Full and Limited.
• Each actor is associated to the use case with the appropriate access level
• A given component is defined with specific mandatory business function requirements, but can utilize other business functions to control optional secured features.
• Typically hyper-linking a use-case to a component only gives access to that components mandatory business functions. For a use case that needs access to some of the optional business functions as well, these need to be manually hyperlinked to the use-case too.
• The Extends link will show the dependency between Full and Limited Use Cases.
• The mandatory business function(s) will be hyperlinked in the Limited Use Case only. The optional business function(s) will be hyperlinked in the Full Use Case.

How To Clone Core Use Case Models for Customer Variants?

• A Root Package for all Customer specific Use Case diagrams must be specified
• Create an Actor Hierarchy diagram based on the customers organization.
• None of the Actors should be short cuts from the Core Diagram; they must be distinct actors for the customer, however the Actor names can be the same.
• All Use Cases on these diagrams should be short cuts from the ‘Core’ set of diagrams.
• The Hyperlinks for the Use Case (links to Components and/or business-functions) are maintained along with the shortcuts.
• Once the Use Case Model is designed , you are ready to generate the Xml file using the Jaffa Plugin.