TECHNOCKTAIL

DEMYSTIFY THE

PRESENT.

Subscribe via RSS

 HOME
 ABOUT

29JAN/100

Provisioning

Modeling
 in

SharePoint

Abstract
A new modeling technique for SharePoint using standard UML diagrams. The technique will
be addressed as an architect tool for SharePoint during implementation and deployment of
SharePoint Applications.

Introduction
Microsoft SharePoint is a server product targeted for the collaboration between business
owners, researchers, and employees. Its target is to clearly help the organization structure,
documents, and process flow to be shared into one organized location.

This location is then managed and moderated by a group of selected users in the firm that
strictly speaking (the ones who are aware of the business requirements to the organization)

This article will discuss a modeling technique for SharePoint Applications (developed during
the work with SharePoint 2007).

Although the article will give a decent definitions of SharePoint concepts, but a little
experience of SharePoint will be helpful to continue reading this Article.
 SharePoint

Provisioning

Containers

Figure 1: Typical SharePoint hierarchy Relation

Farm
The SharePoint farm is the biggest conceptual entity in the SharePoint hierarchy model.
Farm is the container to all web servers, and sql servers that synchronize the content
between all of resources together.
 Web

Application
The SharePoint web application (Encapsulated in SPWebApplication) is a direct
representation to the port number beside the http address protocol for example
(http://HeavyPoint:5000).

When you create a web application you actually should keep the following items in mind:

o Application Database.
o Application Security.
o Sub Web applications that help in interfacing for
o Internet
o Extranet
o Intranet
o Application Configurations (web.config)

Site

Collection
The second conceptual entity under SharePoint is the Site Collection.

Site collection is the entry point for development under SharePoint.

By creating site collection please keep in mind:

o Sub Sites Container

o Global Features (Per Site Collection)
 o Variation Root. (This is the multi-cultural support under SharePoint.)

Sub

site
The minimum conceptual container of SharePoint and the exit point for development. Sub
sites has the same anatomy of Site Collection however they have their private settings that
is not shared among other sites also they inherit their site collection parent settings.

UML

(Unified

Modeling

Language)

Diagrams
UML introduced to us a lot of diagrams that theoretically can be used to describe any
software architecture. The special stereo type of UML is the key point of describing the
SharePoint Provisioning.

Therefore we are going to introduce the important diagrams that we are using in this article
(I'll assume that the reader does know the class diagram, so I will not mention its usage
here)
 Component

Diagram

Figure 2: Component Diagram with one Component.

The Component diagram is a container for a lot of other UML entities. Figure 2 illustrate a
component called World have inside it a Vertex class.

Components actually in my opinion don't have a specific 1 to 1 scenario to describe its

usage. However we can describe the component by characteristics as:

o The minimum executable entity that can be plugged in and out to the application.
o Standalone object modules.
o Hold a complete implementation to specific functionality.
o Can't be used independently out of the host application.
From these characteristics Components concept can be expanded to hold component in
component mechanism. A sample of components is DirectX, Servlets, ActiveX, and Flash
Objects.
 Deployment

Diagram

The deployment diagram is a valuable diagram to describe where a specific thing will be
put (provisioned)??

The deployment diagram is a collection of physical or nearly physical locations that can be
stated, categorized and documented.

SharePoint

Definition vs.
Provision
The difference between Definition and Provision in SharePoint is the same as the difference
between declaring a class and using objects of these classes in the programming language.

Samples of definitions are

o List Definition
o WebPart Definition
o Content Types
o Site Columns
o Site Definition
o Workflow Definition
Provisioning in SharePoint is the Process of putting SharePoint Definitions into their
appropriate containers in SharePoint. And the center entity that contains all definitions
together is the SharePoint Features.

SharePoint

Feature
SharePoint Feature is the minimum deployable entity that can be enabled on the site or sub
site level. The Feature contains schemas of definitions.

When you enable a feature over a site it takes all the schemas inside it and tries to put it
inside the site or the site collection. Features include any selected numbers of List
definitions, web parts, and workflows.

Features has a receivers that perform specific behavior while installation and activation
Features have 4 specific operations:

o Installation (Transfer the Feature Files from File System into the content database)
o Activation (The Feature is provisioning its contents into the site that it was
activated into, and execute the receiver activation code)
o Deactivation (opposite of activation)
o Uninstallation (Remove the Feature Files from the Database)

Provisioning

Modeling
Now after we've reviewed SharePoint Concepts and the Required UML Diagrams we can
jump into the modeling technique itself.

As we mentioned before the SharePoint Feature is the main entity that control the
provisioning, so it is certainly the most suitable to choose as a starting point of our solution.

Table 1: Representation of SharePoint Entities in UML

SharePoint Definition UML Representation Stereo Type

List Definition Class Shape <<SPList>>

List Provisioning Object Shape

WebPart Class Shape <<WebPart>>

 <<SPSiteColumn>>
Site Column Class Shape
<<Type="Image, Text, or etc.>>

Content Type Class Shape <<SPContentType>>

Feature Component Shape <<Scope=Site, Web, or Farm>>

And by employing the UML diagram rules to the relations between types (association, and
aggregation) we can form a relation between Content Type and List Object or Site
Column and Content Type or List Definition

UML

Representation

Example
Let us assume that we have a List hold two Content Types and one site column, one of the
content types depend on other site columns.

NOTE: Lists in SharePoint may have multiple Content Types (like publishing feature with
Pages List)

Component Diagram
First we draw a component diagram for the feature that tells us "What in the feature?"
Figure 3: Feature as a Component

The diagram actually tells us a lot of information about the feature called "Press Publishing
Feature". It tells us that there is list definition called ArticlesList with two content types
Press Page, and Critic Page.

Also the custom Site Columns that we've created are actually appearing in the component
diagram which increases the illustrative aim of the diagram.

With this simple representation to the feature content, we can now leverage the potential
of this technique in modularizing our SharePoint features and their contents

However we still lake very important information!! Where all of these contents will go
when we activate this feature?? The answer simply lies in the next lines.

Feature Activation (Deployment Diagram)

Every feature in SharePoint has a time of activation. When we activate the feature it takes
its contents from the content database and read the xml files inside it and begin to
distribute its contents based on the developer will.

This can be illustrated with the following UML deployment diagram

Figure 4: Deployment of Features

The diagram really describes the provisioning schema of the features of this Sample
SharePoint Application.

We can see clearly that there are a SiteCollection "_ThisSiteCollection" with Two Features

o Press Publishing Feature

o Pages WebParts Feature
Also a subsite called "Statistics" which has another feature activated in it "Statistics
Feature"

In the Statistics Feature Note that we put two instances shapes that represent what will the
feature provision when activate.

In order

o Press Publishing Feature Provision

o MainArticlesList of the list definition ArticlesList
o CuratorArticles of the list definition ArticlesList
o Pages WebParts Feature Provision two webparts with the same definition
o HeadLines
 o WikiArticles
o Statistics Feature Provision
o StatisticsList of the list definition StatListDefition
o StatisticsViewer of StatViewer WebPart definition
Summing all concepts together we can state clearly that every Feature should have two
diagrams

o Component Diagram: responsible of describing "WHAT IN THIS FEATURE??"

o Deployment Diagram: responsible of describing "WHERE TO PUT ITS CONTETNS??"

Conclusion
By answering the two questions of Feature (What and Where). We feel confident about our
approach in describing the intent of feature among features inside custom SharePoint
Application.

As SharePoint product now is entering its 2010 version, organizations are ready for more
adoption to this technology. However the lake of a clear modeling of what is required to
build a successful SharePoint application that Business Owners, Developers, and Decision
makers can sense and measure its usefulness, increase the barrier of using SharePoint in
the right direction.

By introducing a modeling technique based on standard UML notation, we think that this
step will leverage more potential of SharePoint and its usage.

Also this technique encourages the description by business perspective more than
development perspective which can be positioned as a middle representation for all parties
involved in SharePoint development.

By this contribution to the SharePoint community we wish to see more complex scenarios
that simplified by this technique and to help developers to think about architecture before
webpart implementation. Also to encourage the complete views for solutions not partial
views that always lake the illustrative understanding of the desired functionality.

Filed under: SharePointNo Comments

14JAN/100
Second-Generation

Nanotechnology

Despite its versatility, protein has shortcomings as an engineering material. Protein

machines quit when dried, freeze when chilled, and cook when heated. We do not build
machines of flesh, hair, and gelatin; over the centuries, we have learned to use our hands
of flesh and plastic. We will do likewise in the future. We will use protein machines to build
nanomachines of tougher stuff than protein.

As nanotechnology moves beyond reliance on proteins, it will grow more ordinary from an
engineer’s point of view. Molecules will be assembled like the components of an erector set, and
well-bonded parts will stay put. Just as ordinary tools can build ordinary machines from parts, so
molecular tools will bond molecules together to make tiny gears, motors, levers, and casings, and
assemble them to make complex machines.

Parts containing only a few atoms will be lumpy, but engineers can work with lumpy parts if they
have smooth bearings to support them. Conveniently enough, some bonds between atoms make fine
bearings; a part can be mounted by means of a single chemical bond that will let it turn freely and
smoothly. Since a bearing can be made using only two atoms (and since moving parts need have only
a few atoms), nanomachines can indeed have mechanical components of molecular size.
How will these better machines be built? Over the years, engineers have used technology to improve
technology. They have used metal tools to shape metal into better tools, and computers to design and
program better computers. They will likewise use protein nanomachines to build better
nanomachines. Enzymes show the way: they assemble large molecules by “grabbing” small
molecules from the water around them, then holding them together so that a bond forms. Enzymes
assemble DNA, RNA, proteins, fats, hormones, and chlorophyll in this way — indeed, virtually the
whole range of molecules found in living things. Biochemical engineers, then, will construct new
enzymes to assemble new patterns of atoms. For example, they might make an enzyme-like machine
which will add carbon atoms to a small spot, layer on layer. If bonded correctly, the atoms will build
up to form a fine, flexible diamond fiber having over fifty times as much strength as the same weight
of aluminum. Aerospace companies will line up to buy such fibers by the ton to make advanced
composites. (This shows one small reason why military competition will drive molecular technology
forward, as it has driven so many fields in the past.)

By KEVIN ULMER Director of Exploratory Research

Genex Corporation

Engines of Creation 2.0

Filed under: NanotechnologyNo Comments

10JAN/100

Technology

Cocktail
Hello and Welcome to the technology cocktail blog.

In this blog, we will not concentrate on a specific subject. However we will try to
concentrate our thinking and our effort to the complete views of science, and engineering
aspects that when integrating together gives us the complete recipe of technology.

The blog ideology will be anti-separation of subjects it deals with.

Moreover we will try as much as we can to track the possibilities of deconstructing and
constructing the subject in concern, so that we end up with a new explaining model that is
informative and illustrative in its content on the inside and outside level.
For the sake of this aim, this blog will not be a demonstration of the strong skills of its
writers, but will be a guide to the best solution the writers think about based on their
expertise and their point of view.

So you may ask, what will this blog really about ?!!.

Speaking on my self I will blog on Mechanical Engineering, Software Engineering, and Music
Engineering. Also I will share news, thoughts, and my thoughts about it.

but I really wish to have others that share with me the passion of complete views not
partial views that their environment force them to align with.

I've refused to be known by my job title nor by my ideological directions. but as myself as a
human being who has a complex feelings that is not tied to the market need, or to be
another "Instrumental Reason Entity".

In this blog we will bypass the partial technical problems into a complete view technical
solutions.

But we will not deceive ourselves or the reader with FINAL SOLUTIONS.

I hope that I've demystified the reason of this blog (at least for me).

Filed under: UncategorizedNo Comments

Pages

 About

Categories

 Nanotechnology
 SharePoint
 Thermodynamics
 Uncategorized

Blogroll

 Personal Blog
 Quantity System Blog

Archive

 April 2010
 February 2010
 January 2010
Meta

 Register
 Log in
 RSS
 Comments RSS

Copyright © 2011 Technocktail · Powered by WordPress

Lightword Theme by Andrei LucaGo to top ↑