From Projectivity Documentation
What is a Framework
Projectivity is a generic Enterprise Management Platform. This means that it allows the implementation of Enterprise Management Application in a easy and cheap way.
A Framework is what turns the Platform into an Application.
Framework Development Process
In order to develop a framework we have to go through 3 main phases:
The Design, ie the phase where you define the framework that fulfils your business need, is the key step that requires a deep understanding of both the requirements and the framework technology.
The others steps, Implementation and Deployment, are fairly straightforward and are documented in Framework_Development_Guide
The Framework is implemented in the Java programming language using the Projectivity Framework API.
The most important concept of Projectivity is the Workspace.
- represent any meaningful entity in your application domain, such a Business Unit, a Project, or an Activity.
- are typed, ie each workspace has a well defined type
- are organized in a folder like structure (a tree data structure).
- group the information (attributes and documents) related to the entities they model
- are cooperative web environments that assigned resources access to find tools and needed information
You can have more information on workspaces in Understanding_Workspaces section.
The following figure shows an example workspace hierarchy.
A Framework defines:
- The workspace types
- The workspaces tree structure
- The attributes of each workspace type
- The default documentation structure of each workspace repository
- The roles that resources can play in workspaces of each type
- The business events to be notified
A Simple Example
In order to better understand what a framework is, let's go through the definition of a simple Customer Management Application.
Requirements of Customer Management Application
The Customer Management Application allows managing of customers and related information.
We have two Regions, Italy and France, and each Region has several Customers.
Each Customer has one Account Manager, who is responsible for managing their relationship.
We want notifications email to be sent to key roles when important business events occur.
Each Customer workspace will group the important information about it:
- Attributes such as billing information
- Documents such as Orders and Invoices
We define 3 workspace types:
The following figure shows the framework model together with a corresponding Workspace hierarchy. There is only one Company (it is the root of the hierarchy), 2 regions (Italy and France) and few Customers.
Note how you specify the relationships between workspace types. They are modelled with an arrow; the arrow going from Company to Region specifies that it will only be possible to have a workspace of type Region under a workspace of type Company.
Note also the cardinality of that relationship. Two and only two Regions can be created under the workspace Company, any number of Customers can be created under each Region. Cardinalities are expressed as [min..max] or [n] when the minimun is equal to the maximum. When the minimum cardinality is greater than zero, the system will auto-create min instances of workspaces of that type when the parent is created.
Workspace Attributes and Roles
The following table specifies the attributes and the roles of each workspace type (note the role cardinality).
Default Document Structure
The Customer workspace will have a default document structure as follows:
- Customer Profile
- Customer Profile.doc
On Customer creation, the system will automatically create that folder structure and fill it with the document templates.
We define the following event notification rules:
- When a customer is created send an email to the Sales Director and to the CEO
- When the status of a customer is modified send an email to the Account Manager
- When a document is created or modified in the repository of a Customer send an email to the Account Manager