So I wondered on the bus out to a dive called Spawnpoint on 63rd and Foster.  Basically a black light gaming center.  It's perty kewl if your into gaming, which I am, but I'm sitting writing code samples and checking stuff out at the moment.

Speaking of projects though, I'm somewhat focused on the idea of Six Sigma Software Projects and writing code libraries based on that.  Pareto ideas of benificial and mutual success etc., etc... etc.

The big question though is, "What code libraries would be most benificial for doing just that, six sigma product, manufacturing, and streamlinging of such processes?"

So just a quick overview of what exactly Six Sigma entails and what I'm trying to acheive with it.  First off, Six Sigma is not a software development cycle, it would be better described as a "do something perfect the first time" cycle.  GE, Bank of America, Toyota, Honda, Nissan, Sony DuPont, Merill Lynch and other major groups have used Six Sigma to create products and processes that are amazingly accurate and repeatable.

The title Six Sigma itself is in relation to the Greek symbol used to denote the deviations from mean.  Six Sigma specifically is the acheivement of no more than 3.4 defects per million, or 99.997% perfection.  That might seem like an impossible idea but it is far from it.  Many companies and processes far exceed that measurement.

Airlines, doctors, and other entities have to stay far better than 99.997% and often times stay far above 99.99995% or better.  They have to, or it would be a slaughter!

Simply put what I'm thinking of is creating a base library package to streamline Six Sigma Projects, based on a root level at integrating systems that currently exist, CRMs, ERPs, or whatever is in place at a corporation that needs integration.  The amazing this is that these systems promise so much integration but then are usually setup without the said integrations, thus a company ends up with completely seperate and disparate systems that cannot communicate with each other.  Just ticking away employee time in correlating data, attempting to provide information that is useful.  Some companies have used Six Sigma to such a degree as to know how much time is wasted and how much money is lost by non-integrated systems.

It seems a lofty goal to want to integrate such and provide such a service, but it is needed and there are not enough people out there doing this.  The question is, what approach, what tools should be used, what ways can be called upon to integrate said software?

...maybe I'll come up with some good ideas, maybe I won't.

Read ** First (bottom of entry) - then continue - Ok, so my first task that I've set out to complete is to get an actual SmartPart displayed.  I've dug through the documentation and hands on lab that are available at this point and must say that I'm somewhat unhappy with the documentation available at this point.  So with that I'm going to start writing up some of these how-to things as I work through this.  So at some point I might possibly put together and submit some of these things via a book on CAB and SCSF.  But I digress, back to the topic at hand, how to get a SmartPart displayed on screen.

So here's the approach to getting a SmartPart to display on a simple old screen.

First start a standard Guidance Package based SCSF/CAB Based Application.

Set the root namespace next.  Feel free to uncheck the "Show related documentation after running the recipe".

The completed project should display as below.

At this point the skeleton of the project is available.  At this point I deemed it necessary to split the default Shell up a little bit.  Navigate to the ShellForm.cs file in the Shell Project.  Bring up the ShellForm.cs file and delete the DeckWorkspace control that is currently on the page.

Once you've deleted the DeckWorkspace do a quick build by hitting Ctrl+Shift+B.  You should get two errors and a few warnings as displayed below.

Double click on the #5 error and the ShellForm.cs file will open up.  Delete the line of code that it links to.

_layoutWorkspace.Name = WorkspaceNames.LayoutWorkspace;

then do the same for the #6 error.  Delete that line of code.

Microsoft.Practices.CompositeUI.SmartParts.ISmartPartInfoProvider ensureProvider = this;

Next open the primary ShellForm back up and drop a split container on the screen.  Name it splitPrimaryDivider for good measure and to give it a non-default name.  Next drag a DeckWorkspace on each section of the screen split.  Click on the task arrow...

 ...and select Dock in parent container.  This will push the corners of the DeckWorkspace into the edges of the respective split sections.

Name the right hand side name for the DeckWorkspace to deckPrimaryContent.  Name the other DeckWorkspace to deckLeftItems.

At this point open up the Infrastructure.Layout Project and delete the three files; Module.cs, ShellLayoutView.cs, and ShellLayoutViewPresenter.cs.  Now the application can actually be executed and the shell will display.

Now one can get down to getting some SmartPart Components to display in the Shell.  The tasks left to get the DeckWorkspace to display the deckPrimaryContent and deckLeftItems SmartParts is;

1. Place some controls on the SmartParts so we can make them do something and also be able to tell when they display (the standard gray on gray doesn't really help us).
2. Create an interface to describe the methods needed to show the SmartParts in the Shell.
3. Create a WorkItem Class to implement WorkItem and show the SmartParts.
4. Write code in the ModuleInit to actually start the application and begin the loading process.

 PLACE PICTURES HERE FOR CONTROLS ON PAGE

Create in the Infrastructure.Layout Project a ShowInShell.cs file.  Toss in an interface to use to pass SmartParts in for display.

using System;
using System.Collections.Generic;
using System.Text;
// Added Reference
using Microsoft.Practices.CompositeUI.SmartParts;

namespace MySmartClientTest.Infrastructure.Layout
{
 public interface IShowInShell
 {
  void Show(IWorkspace sideBar, IWorkspace content);
 }
}

Create a WorkItem Class to implement the WorkItem and IShowInShell interface to show the SmartParts.  Add a directory (just to keep things neat) name WorkItems to the Infrastructure.Module and then place a file called MyWorkItem.cs in the Project Folder.  Before adding any code make a reference to the MySmartClientTest.  You might need to add a few using references, which are listed below and then just toss in the following code. 

// Added References
using Microsoft.Practices.CompositeUI;
using Microsoft.Practices.CompositeUI.SmartParts; // For the IWorkspace implementation.
// Added Local Projects
using MySmartClientTest.Infrastructure.Layout;

public class MyWorkItem : WorkItem, IShowInShell
{
 private IWorkspace contentWorkspace;
 public IWorkspace ContentWorkspace
 {
  get { return contentWorkspace; }
 }

public void Show(IWorkspace sideBar, IWorkspace content)
{
  contentWorkspace = content;

  //this.Items.AddNew<MainContentSmartPart>("MainContent");

  MainContentSmartPart mainContentView = this.Items.AddNew<MainContentSmartPart>();
  LeftMenuSmartPart leftMenuView = this.Items.AddNew<LeftMenuSmartPart>();

  sideBar.Show(leftMenuView);
  content.Show(mainContentView);
  this.Activate();
 }

 protected override void OnActivated()
 {
  base.OnActivated();
 }
}

At this point just click on old F5 and run that dog...

...ok so at this point I ran into a stupid problem.  The name according to what I've given then project is too long.  ?!  Stupid stupid problem to have...   so anyway.  Hopefully you read this line first because I don't feel like changing the text.**

Ok, so I've started on my own Composite UI Application Block (CAB) based Smart Client Software Factory Application (SCSF).

My first sentiment, after studying this on and off for a few weeks, is that this is no simple approach. I've looked at the little charts and flow diagrams that tell the high altitude story of how these things are supposed to work together. With all the WorkItems, Views, SmartParts, and all this other stuff one has to keep up with the CAB can become a very complex application for a single individual to keep up with. I am aware of course that the CAB and SCSF are designed to be used by a team or group of developers working on and supporting a single application. In this scenario though it is just me, myself, and I working on this thing. My current project at work also has each developer working inside one single vertical scope of the application, which dictates that we each must learn the CAB, SCSF, and every other layer of the application. From a managerial perspective I'm not following the logic, but from a developers perspective I have been euphoric that I will be able to work with each aspect of the application. Lots of experience ensue!

So on with what I've actually setup using the SCSF and CAB.

So with that let me start with some basic explanations of what in the hell is going on with the various aspects of these application block and factory libraries. Both the application block (CAB) and the factory (SCSF) are setup to implement a Model-View-Presenter (MVP) type pattern. The whole point of this is so that various aspects of the development for an application user interface can be split out to different developers. One can work on business use cases by working with the WorkItems, another can simultaneously work on the user interface by building SmartParts.

So if I have it straight the following are a simple description of the various parts of the SCSF, CAB, and the MVP Pattern.

• Modules are composed of a set of services, WorkItems, SmartParts, controllers, business entities, and the Module Initilization class, which initializes the module's WorkItems.
  • Services:  Module Services are objects that can be registered once by using the Service attribute and then referenced from any component in WorkItem.
  • WorkItems:  WorkItems are run-time containers of components that collaborate to complete a use case.  It contains the following:
    • Start-up (initialization) that begins the use case.
    • State that is shared by components collaborating in the use case.  State can be persisted by calling the Load and Save methods on WorkItem.  State can be persisted to any storage medium by using an infrastructure service that implements IStatePersistenceService.  There are built in implementations called;  FileStatePersistenceService, which persists the WorkItem to a file in the same directory as the executable and IsolateStorageStatePersistenceService, which persists the WorkItem to a file in Isolated Storage.
    • Contoller classes that act on the state and resources.
    • View casses that interact with their controllers and reference state.
    • Tear-down code that cleans up the application.
  • SmartParts:  SmartParts provide the visual elements in the application.  These are seperated from the application so a single person can be dedicated to just SmartPart development if need be.
  • Controllers:  These implement the business logic behind the view.
  • Business Entities:  These are the standard business objects that any application type should use to utilize business cases and apply logic to during the use of an application.
  • Module Initialization Class:  This is what is responsible for starting and loading the application.  When one starts the application this initialization begins.
• Views
• Presenters

Another few specific things the CAB provides are below;

• Infrastructure Services that can be used in applications being developed.  Custom services and infrastructure services can also be built and added to applications.  The application block provides the following infrastructure;
  • Catalog Reader Service
  • Module Loader Service
  • Authentication Service
  • State Persistence Service

So these are my definitions so far, I hope to be able to add and flesh out each point with more specific and descriptive detail in coming CAB/SCSF entries that I will be making.

As one can see, especially if it is their first time, it is not a small list of things to keep up with.  This is merely the simple CAB/SCSF 101 Introductory stuff to learn and keep up with too, it's not "advanced CAB/SCSF"!  So my next entry will hopefully include some working samples of stuff, that aren't duplications of the few hands on labs and rare code snippets here and there.  I hope to help make this model of application development proliferate a little bit.  It never hurts to push one self either.  :)