Whatis Framework

From Projectivity Documentation
Jump to: navigation, search
Go back to Documentation home

Contents

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.

Projectivity Stack.png

Framework Development Process

In order to develop a framework we have to go through 3 main phases:

  1. Design
  2. Implementation
  3. Deployment

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.

Workspace

The most important concept of Projectivity is the Workspace.

Workspaces:

  • 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.

Workspace hierarchy.png

Framework

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

Framework Model

We define 3 workspace types:

  • Company
  • Region
  • Customer

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.

Framework and workspaces.png

Workspace Attributes and Roles

The following table specifies the attributes and the roles of each workspace type (note the role cardinality).

Workspace Type Attributes Roles
Company
  • Web Site:URL
  • Slogan:String
  • CEO (1)
  • Sales Director (1)
  • Staff (0..*)
Region
  • Region Definition:WideString
  • Country Manager (1)
  • Account Managers Group (0..*)
  • SalesMan (0..*)
Customer
  • Customer Code:SerialCode(YYYY, 000)
  • Creation Date:Date
  • Full Name:String
  • Address:WideString
  • Billing Address:WideString
  • VAT Number:Number
  • Industry:List(Telecom, Automotiv, ....)
  • Status:List(Lead, Customer, Closed)
  • Account Manager (1)

Default Document Structure

The Customer workspace will have a default document structure as follows:

  • Customer Profile
    • Customer Profile.doc
  • Orders
    • Order.doc
  • Invoices
    • Invoice.doc

On Customer creation, the system will automatically create that folder structure and fill it with the document templates.

Notification Rules

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
Personal tools
Downloads
Other Resources