- ~ Posted by Deepak Kamboj on October 8, 2009
A Sequence Diagram is an Object Diagram that describes object interaction. Objects are shown at the very top from left to right, while the time flows from top to bottom. Arrows indicate messages and other interactions between objects.
The official UML definition for Sequence Diagram is: A diagram that shows object interactions arranged in time sequence. In particular, it shows the objects participating in the interaction and the sequence of messages exchanged. Unlike a collaboration diagram, a sequence diagram includes time sequences but does not include object relationships. A sequence diagram can exist in a generic form (describes all possible scenarios) and in an instance form (describes one actual scenario). Sequence diagrams and Collaboration Diagrams express similar information, but show it in different ways.
We use sequence diagrams to realize use cases in the analysis model. Before we demonstrate the realization, we need to have a good understanding of sequence diagrams. Sequence diagrams are a type of interaction diagram. Collaboration diagrams are another type of interaction diagram. Although each of these types of interaction diagrams provides the same information, the focus of attention is different. Collaboration diagrams focus on the objects that work together to accomplish a given task or series of tasks. Sequence diagrams focus on the interaction of a given task or series of tasks as observed over time. In fact, some modeling tools automatically convert one diagram to the other.
- ~ Posted by Deepak Kamboj on October 8, 2009
A collaboration diagram, also called a communication diagram or interaction diagram, is an illustration of the relationships and interactions among software objects in the Unified Modeling Language (UML). The concept is more than a decade old although it has been refined as modeling paradigms have evolved. Collaboration diagrams, like Sequence Diagrams, show how objects interact over the course of time. However, instead of showing the sequence of events by the layout on the diagram, collaboration diagrams show the sequence by numbering the messages on the diagram. This makes it easier to show how the objects are linked together, but harder to see the sequence at a glance.
A collaboration diagram resembles a flowchart that portrays the roles, functionality and behavior of individual objects as well as the overall operation of the system in real time. Objects are shown as rectangles with naming labels inside. These labels are preceded by colons and may be underlined. The relationships between the objects are shown as lines connecting the rectangles. The messages between objects are shown as arrows connecting the relevant rectangles along with labels that define the message sequencing.
Collaboration diagrams are best suited to the portrayal of simple interactions among relatively small numbers of objects. As the number of objects and messages grows, a collaboration diagram can become difficult to read. Several vendors offer software for creating and editing collaboration diagrams.
A Collaboration Diagram is a diagram that shows object interactions organized around the objects and their links to each other. Unlike a Sequence Diagram, a Collaboration Diagram shows the relationships among the objects. Sequence diagrams and collaboration diagrams express similar information, but show it in different ways.
From the Visio Enterprise help: A collaboration diagram represents a collaboration, which is a set of object roles related in a particular context, and an interaction, which is the set of messages exchanged among the objects to achieve an operation or result. It is an interaction diagram that shows, for one system event defined by one Use Case, how a group of objects collaborate with one another. Unlike a Sequence Diagram, a collaboration diagram shows relationships among object roles and it does not express time as a separate dimension. Therefore, the messages in a collaboration diagram are numbered to indicate their sequence.
- ~ Posted by Deepak Kamboj on October 7, 2009
This article provides a brief introduction to Facade Design Patterns. Facade Design pattern provides an easy to use interface to an otherwise complicated collection of interfaces or subsystems. It makes things easier by hiding the details of the implementation.
When designing good programs, programmers usually attempt to avoid excess coupling between module/classes. Using this pattern helps to simplify much of the interfacing that makes large amounts of coupling complex to use and difficult to understand.
In a nutshell, this is accomplished by creating a small collection of classes that have a single class (Facade) that is used to access them.
The facade pattern is an object-oriented design pattern. A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can accomplish all of the following.
- It can make a software library easier to use and understand since the facade has convenient methods for common tasks.
- It makes code that uses the library more readable for the same reason.
- It can reduce dependencies of outside code on the inner workings of a library since most code uses the facade. This allows for more flexibility in developing the system.
- It can wrap a poorly designed collection of APIs with a single well-designed API.
Class Diagram
Code in C#
This structural code demonstrates the Facade pattern which provides a simplified and uniform interface to a large subsystem of classes.
// Facade pattern -- Structural example
using System;
namespace GangOfFour.Facade.Structural
{
/// <summary>
/// MainApp startup class for Structural
/// Facade Design Pattern.
/// </summary>
class MainApp
{
/// <summary>
/// Entry point into console application.
/// </summary>
public static void Main()
{
Facade facade = new Facade();
facade.MethodA();
facade.MethodB();
// Wait for user
Console.ReadKey();
}
}
/// <summary>
/// The 'Subsystem ClassA' class
/// </summary>
class SubSystemOne
{
public void MethodOne()
{
Console.WriteLine(" SubSystemOne Method");
}
}
/// <summary>
/// The 'Subsystem ClassB' class
/// </summary>
class SubSystemTwo
{
public void MethodTwo()
{
Console.WriteLine(" SubSystemTwo Method");
}
}
/// <summary>
/// The 'Subsystem ClassC' class
/// </summary>
class SubSystemThree
{
public void MethodThree()
{
Console.WriteLine(" SubSystemThree Method");
}
}
/// <summary>
/// The 'Subsystem ClassD' class
/// </summary>
class SubSystemFour
{
public void MethodFour()
{
Console.WriteLine(" SubSystemFour Method");
}
}
/// <summary>
/// The 'Facade' class
/// </summary>
class Facade
{
private SubSystemOne _one;
private SubSystemTwo _two;
private SubSystemThree _three;
private SubSystemFour _four;
public Facade()
{
_one = new SubSystemOne();
_two = new SubSystemTwo();
_three = new SubSystemThree();
_four = new SubSystemFour();
}
public void MethodA()
{
Console.WriteLine("\nMethodA() ---- ");
_one.MethodOne();
_two.MethodTwo();
_four.MethodFour();
}
public void MethodB()
{
Console.WriteLine("\nMethodB() ---- ");
_two.MethodTwo();
_three.MethodThree();
}
}
}
Conclusion
Thus, Facade is a design pattern that hides the details and complexities of the lower-level software services for which it is written, making the service easier to use. In fact, the lower-level classes need not be classes at all; they can be an API in the form of a code library or a Web service.
A Facade also provides a unified entry point into the layers of the software. This reduces the application's dependency on the software service details and allows the Facade to hide future changes in the software service itself.
References:
http://www.dofactory.com/patterns/patternfacade.aspx
http://aspalliance.com/970_Facade_Design_Pattern.4
- ~ Posted by Deepak Kamboj on September 30, 2009
Introduction
There are times, when one need to have a class which can be only instantiated once. Singleton Design Pattern addresses to such situation by providing a design for such classes (known as Singleton class).
Description:
There are at least two solutions or scenario for implementing Singleton Class. The first solution says that there should be only one shared object and reference to that object should be available only through static method like GetInstance() while making the constructor private. A number of clients can be awarded the reference to such shared object. The second solution says that the constructor should be public (as it appears in most cases) but once an object has been instantiated, an exception should be thrown for each successive constructor call; thus limiting the class to only one object.
An Example:
First case Singleton can be used in a data repository or data collection where creation of more than one object can be resource wastage. Hence each client is given a reference to a single shared object to operate on. While the second case Singleton can be used in locking mechanisms. Once a client has got the object, no other client can have an object.
Class Diagram:
Implementation:
Let us first discuss the code of first case Singleton which is like:
class Singleton
{
private static Singleton instance;
private static int numOfReference;
private string code;
private Singleton()
{
numOfReference = 0;
code = "Deepak Kamboj";
}
public static Singleton GetInstance()
{
if (instance == null)
{
instance = new Singleton();
}
numOfReference++;
return instance;
}
public static int Reference
{
get { return numOfReference; }
}
public string Code
{
get { return code; }
set { code = value; }
}
}There are 3 fields in the Singleton class. Static field instance is a reference to shared object in this Singleton class. Static field numOfReference is an integer variable to hold the number of current references to the single shared object of Singleton class. Code is a string value, it is used to demonstrate that the object is shared b/w references and change made to this field through one reference can be realized through other reference.
The constructor is made private and used to initialize the numOfReference and default value of code. GetInstance() method checks the instance, if it is null then it assign it an instance of Singleton otherwise return the old reference. GetInstance() also increments the numOfReference each time it is called to keep track of current number of reference to our shared instance. Property Reference returns the number of reference referencing our shared object while Code property can be used to set/get the code string of shared object.
The second case Singleton class (Singleton2) looks like:
public class Singleton2
{
private static int numOfInstance = 0;
public Singleton2()
{
if (numOfInstance == 0)
{
Console.WriteLine("\r\nCreating First "
+ "Object of Singleton2 class...");
numOfInstance++;
}
else
{
throw new Exception("This class is Singleton" +
", so only one object of it can be instantiated.");
}
}
}Here we make the constructor public and use a private field numOfInstance which is incremented for each constructor call. If numOfInstance is zero (no object is yet instantiated), a new object is allowed to made. But, if this value is not zero (there is already an object of Singleton2 class, an exception is thrown.
Now let us try these with Main() method, the code in main is like:
class Program
{
static void Main(string[] args)
{
Singleton obj1 = Singleton.GetInstance();
obj1.Code = "Deepak Kamboj";
Console.WriteLine("No. of references : " + Singleton.Reference);
Console.WriteLine("First Objects code: " + obj1.Code);
Singleton obj2 = Singleton.GetInstance();
Console.WriteLine("No. of references : " + Singleton.Reference);
Console.WriteLine("Second Objects code: " + obj2.Code);
Singleton2 obj3 = new Singleton2();
Singleton2 obj4 = new Singleton2();
}
}First we called GetInstance() and took the reference to the new object in obj1. The code for this object is changed to Faraz Rasheed which was Maasoom Faraz by default. Then, we check for number of references to this object and code set for this. Next, we get another reference to this object through GetInstance() in obj2. We again check the number of references and code using this reference. If both the references are pointing to the same shared object, the number of references now should be 2 while the code should also be Faraz Rasheed (remember if obj2 points to a new object then code would have been Maasoom Faraz, the default one) which is shown in the output.
We also made an object of Singleton2. When constructor is called for the first reference (obj3), the new object is instantiated printing the message on Console. But when another instance of Singleton2 is attempted to be made through obj4, an exception is thrown saying Singleton class can only be instantiated once.
Sample output from the program is:
No. of references : 1
First Objects code: Deepak Kamboj
No. of references : 2
Second Objects code: Deepak Kamboj
Creating First Object of Singleton2 class...
Unhandled Exception: System.Exception: This class is Singleton,so only one object of it can be instantiated.
at Singleton.Singleton2..ctor() in c:\documents and settings\msff\my documents\visual studio projects\singleton\class1.cs:line 75
at Singleton.Client.Main(String[] args) in c:\documents and settings\msff\my
documents\visual studio projects\singleton\class1.cs:line 20
Press any key to continue
The complete source code is also attached with the article. Take a look at it to understand it to full.
Conclusion:
By using Singleton Design Pattern, it is possible for a programmer to control the instantiation of class by allowing only single object to be instantiated when desirable.
Backtrack: http://www.c-sharpcorner.com/UploadFile/faraz.rasheed/SingletonPattern12052005063955AM/SingletonPattern.aspx
- ~ Posted by Deepak Kamboj on September 22, 2009
The factory method pattern is a creational design pattern used in software development to encapsulate the process of creating the objects.
Concerns:
- Which object needs to be created.
- Managing the life time of the object.
- Managing the build-up and tear down concerns of the object.
Definition:
“Define an interface for creating an object, but let subclasses decide which class to instantiate”
C# Implementation of Factory method
abstract class Factory
{
//Factory Method Declaration
public abstract Product GetProduct();
}
——————————————————————————————-
class concreteFactoryforProcuct1 : Factory
{
//Factory Method Implementation
public override Product GetProduct()
{
return new Product1();
}
}
——————————————————————————————–
class concreteFactoryforProcuct2 : Factory
{
//Factory Method Implementation
public override Product GetProduct()
{
return new Product2();
}
}
——————————————————————————————–
interface Product
{
void GetDetails();
}
class Product1 : Product
{
public void GetDetails()
{
Console.WriteLine("Product1 Details are Called");
}
}
class Product2 : Product
{
public void GetDetails()
{
Console.WriteLine("Product2 Details are called");
}
}
——————————————————————————————–
protected void Page_Load(object sender, EventArgs e)
{
Factory[] objFactories = new Factory[2];
objFactories[0] = new concreteFactoryforProcuct1();
objFactories[1] = new concreteFactoryforProcuct2();
foreach (Factory objFactory in objFactories)
{
Product objProduct = objFactory.GetProduct();
objProduct.GetDetails();
}
}
——————————————————————————————–
References: dofactory.com