UML

	What is UML? The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. UML provides blue prints for business process, System function, programming language statements, database schemas and reusable components.
	How many types of diagrams are there in UML? There are nine types of diagrams in UML :- 1. Use case diagram - They describe "WHAT" of a system rather than "HOW" the system does it.They are used to identify the primary elements and processes that form the system. The primary elements are termed as "actors" and the processes are called "use cases". Use Case diagrams shows "actors" and there "roles". 2. Class diagram - From the use case diagram we can now go to detail design of system, for which the primary step is class diagram. The best way to identify classes is to consider all "NOUNS" in use cases as classes, "VERBS" as methods of classes, relation between actors can then be used to define relation between classes. The relationship or association between the classes can be either an "is-a" or "has-a" relationship which can easily be identified from use cases. 3. Object diagram - An object is an instance of a class. Object diagram captures the state of classes in the system and their relationships or associations at a specific point of time. 4. State diagram - A state diagram, as the name suggests, represents the different states that objects in the system undergo during their life cycle. Object change in response to certain simulation so this simulation effect is captured in state diagram. So basically it has a initial state and final state and events that happen in between them. Whenever you think that some simulations are complicated you can go for this diagram. 5. Sequence diagram - Sequence diagrams can be used to explore the logic of a complex operation, function, or procedure. They are called sequence diagrams because sequential nature is shown via ordering of messages. First message starts at the top and the last message ends at bottom. The important aspect of a sequence diagram is that it is time-ordered. This means that the exact sequence of the interactions between the objects is represented step by step. Different objects in the sequence diagram interact with each other by passing "messages". 6. Collaboration diagram - A collaboration diagram groups together the interactions between different objects to fulfill a common purpose. 7. Activity diagram - Activity diagram is typically used for business process modeling, for modeling the logic captured by a single use case, or for visualizing the detailed logic of a business rule.Complicated process flows in the system are captured in the activity diagram. Similar to a state diagram, an activity diagram also consists of activities, actions, transitions, initial and final states, and guard conditions. But difference is state diagrams are in context of simulation while activity gives detail view of business logic. 8. Deployment diagram - Deployment diagrams show the hardware for your system, the software that is installed on that hardware, and the middleware used to connect the disparate machines to one another. It shows how the hardware and software work together to run a system. In one line its shows the deployment view of the system. 9. Component diagram - The component diagram represents the high-level parts that make up the system. From .NET angle point of view they form the "NAMESPACES". This diagram depicts, at a high level, what components form part of the system and how they are interrelated. Its shows the logical grouping of classes or group of other components.
	What are advantages of using UML? As the name suggest UNIFIED MODELING LANGUAGE. Modelling has been around for years, not only in software field but also in other trades like civil, mechanical etc. Example in civil engineering drawing the main architecture built of diagram is a model by itself. Modelling makes complex and huge system to break up in to simple and discrete pieces that can be individually understood. Example simple flowchart drawing is modeling. There are two main advantages of modeling:- 1. Readability - Representing your whole architecture in flowchart, class diagrams, ER diagrams etc makes your project more readable. Especially when programmer’s change jobs handover becomes easier. More the project is not readable more the dependencies. 2. Reusability - After the system is more readable and broken down to pieces, it becomes easier to identify redundant and similar modules. Thus increasing reusability. So why UML? Well different languages have different ways of coding and syntaxes. In order to bring all languages in one roof UML is in to picture. As the term comes in UNIFIED, it unifies all disparate languages in one roof so that can be understood by people who are working on some other platforms.
	What is the sequence of UML diagrams in project? First let me say some fact about this question, you can not implement all the nine diagrams given by UML in one project; you can but can be very rare scenario. The way UML is implemented in project varies from project to project and company to company. Second very important point to remember is normally all diagrams are not implemented in project, but some basic diagrams are important to have in order that project is readable. When we talk about projects every project have phases example (Requirements phase, design phase, coding phase etc ). As every phase of the software cycle proceeds these diagrams come in picture. Some diagrams span across multiple phases. Normally following are different basic phases:- Requirement phase (Use Case Diagrams, Activity diagrams) Requirement phase is the phase where you normally gather requirement and Use Cases are the best things to make explanation of the system. In requirement phase you can further make complicated Use Cases more simple and easy to understand by using activity diagrams, but I do not see it as must in every project. If the Use cases are really complicated go for a Activity diagram. Example CRUD (creates, read, update and delete) operation use cases have no significance for making activity diagrams. So in short the outcome UML documents from requirement phase will be Use Case and Activity diagram documents (Activity diagram documents will only be there if there are complicated Use Cases to be simplified). Do I need all UML diagrams in a project? Not all diagrams are needed in a project. For example: - Activity diagrams will only be needed when you want some simplified look of a complicated use case. Design phase (Class diagrams, object diagrams, Component diagrams, Collaboration diagrams, Deployment diagrams, Sequence diagrams) Design phase is the phase where you design your technical architecture of your project. Now again in this you do not use all UML documents of a project. But the next document after the Use Case document will be the Component diagram. Component diagrams form a high level classification of the system. So after "Use Cases" just try to come out with a high level classification / grouping of related functionalities. This should be compulsory diagram as outcome of this document will form "NAMESPACES" structure of .NET project. Now once your high level grouping is done you can go ahead with class diagrams. Especially from Use Case you get the "NOUNS" and "VERBS" which can form the class name and the method name respectively. Object diagrams are not compulsory it depends on how complicated your project. Object diagrams shows the relation between instances of class at runtime. In short it captures the state and relation of classes at any given moment of time. Example you have class which creates objects of different classes, its like a factory. In class diagram you will only show that it as a simple class with a method called as "CreateObject". But in object diagrams actually you will show the types of instances create from that object. Collaboration diagrams mainly depict interaction between object to depict some purpose. So if you find the process very complicated go for this diagram. I see as a thumb rule if there is an activity diagram which show some serious complicated scenarios. I will like to go for this diagram in order to simplify the explanation. State chart diagram is again created if your project requires it. If your project has some complicated start and end states to show then this diagram is most useful. Sequence diagrams are needed if some sequence is complicated. Do not confuse sequence diagrams with Activity diagram, Activity diagrams map to a Use Case while sequence diagrams show object interaction in sequence. Deployment diagrams are again not a compulsory requirement. It will show the hardware and software deployment of your system. If you really have leisure in your project go for it or if you want to make the client smile seeing some diagrams. Implementation phase / Coding phase (Class diagrams for reverse engineering, Other diagrams for validity check) In this phase mostly class diagrams are re-engineered with the source code. But other diagrams are also present for validity check example state chart diagrams will be used in case to check that the both activity between those states follow the proper logic. If some things have to be changed then again there is iteration backward to the Requirement phase. Testing phase This phase mostly goes for the testing department. Where the testing department will look at all diagrams to prepare a test plan and execute it. Example it will see the Use Case document to see the business rules, it will see the activity diagram and sequence diagrams to see the proper flow of modules. If some things are not proper there is iteration back to the Design phase. Roll out and close over phases. All document just to re-check that things are proper, example all modules deployed according to the deployment diagrams, are all business rules in Use Cases satisfied. Let us revise the following points:- Not all diagrams are compulsory. The minimum diagrams according to software life cycle phases are :- Requirement phase - Use Case Diagrams Design Phase - Component diagrams, Class diagrams Implementation phase - All diagrams derived from pervious phases specially class diagram for reverse engineering. Testing phase - All diagrams derived from requirement and design phases for verification and preparing test plans. Roll out and close over phase - All document derived from Design phase and requirement phases.