The Getting Started Tutorial is composed of a number of smaller tutorials, each of which is designed to show the Java Application Programmer how to accomplish one or more specific programming tasks using the Tensegrity Graph Framework. This framework allows you, among other things, to associate “entities” with one another and graphically render all of their interrelationships.
In order to make the examples more intuitive, applicable and enjoyable, we have chosen to model user and functional rights administration. This we presume is a typical subsystem of any business software application. In this manner, the business workflow should be well-known and intuitive, so that you may concentrate on our framework design and APIs instead of the underlying business case our framework is going to model and graphically render.
In a nutshell, the entities and relationships found in the business case are as follows. They will be randomly found in the subsequent tutorials in this manual.
User:
Literally that thing which “uses.” A person is usually referred to as a user when he or she has a private password and is assigned at least one role in an application context. A user does not represent any named and persistent functional role but simply describes a person who has the ability to log into and use a particular software application. In a more abstract context, a “user” may refer to any runtime object that “uses” another resource.
Group:
A set of users forms a group. In systems that have many users in them, groups are easier to handle when assigning roles to large numbers of equally-capable individuals.
Role:
An abstraction which encapsulates a set of application rights. Roles are used to group these rights into named objects which can be subsequently assigned to users and groups of users in an application context.
Right:
Sometimes called a “functional right.” Rights are persistent objects that encapsulate the capability to do something with a named resource. Rights form the core of authorization services and are typically bundled by roles.
Permission:
A permission is not the same thing as a right. A permission is created when a user is assigned to a particular right, thereby granting him/her access to the action defined in that right.
Resource:
This can mean anything and everything. Resources usually describe things that live in the application domain. Complete files or parts of them, database records and runtime objects are three of many types of resources that users may interact with in an application context.
Action:
This defines what a user can actually do with a resource. An action includes a verb and the resource or class of resources that are involved. It might help to think of actions as particular class methods, such as constructors (create), destructors (delete), getter methods (read), setter methods (write) and so on. Usually a subset of the classes of an application domain, also known as “course-grained” entities, are used to define actions for use in authorization schemes.
Application:
There is never just one application in a company. Different applications offer access to different resources and as such provide a unique set of user roles. Sometimes applications are further broken down into subsystems, services or “modules,” which provide fine-grained control in the administrative process.
The following domain diagram illustrates the fundamental entities of the introduced business case.
In the conceptual diagram above, you can see how most of the aforementioned domain entities statically relate to each other. In most cases, the identified domain objects represent concrete types that have persistent attributes and/or behavioral responsibilities. For this reason, their names are bounded by rectangular boxes to signify that they are types in the domain model and/or classes in a subsequent design model.
In at least one case, however, an entity from our domain model represents a unique association between two concrete types. For this reason, that entity type (Permissions) is modeled as a line connecting the two entities that are involved in the special relationship.
Note
In the context of the Tensegrity Graph Framework and the business entities above, a Node represents a class and an Edge represents a relationship from one of those classes to another class. In other domain languages, an Edge might be referred to as an arc, a link, an association, a transition or something else altogether. Additionally, graph theory uses the term “vertex” to designate what we call a Node.
It is important to remember that both nodes and edges belong to the graph domain and that the Tensegrity Graph Framework allows attributes to be associated with them. These attributes can include names, states and anything else required for the business entities being modeled.