UML - Diagrams Required

Hi,

Check this: http://creately.com/blog/diagrams/uml-diagram-types-examples/

Check this: https://arun-architect.blogspot.com/2017/09/collection-of-visio-shapes.html

Here this article covers the major inputs for UML.

• Diagrams required in various phases of s/w development

Diagrams required in various phases:

Here we’ll see what diagrams are required to sketch in the various phases of s/w development.

• Not all diagrams are compulsory.
• The minimum diagrams according to software life cycle phases are :-

• Requirement phase: - Use Case Diagrams, Activity 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.

Below is a sample figure which shows all the documents in relevant phases.

Requirement phase (Use Case Diagrams, Activity diagrams)

Use Case Diagrams

These are required to be developed in Requirement phase. Requirement phase is the phase where you normally gather requirement and Use Cases are the best things to make explanation of the system. Shows a necessary connection between Use Cases. Shows an optional behaviour for a Use Case. Identify ‘VERBS’ in a system. These verbs will be Use Cases. E.g. For a Washing Machine system, Use Cases can be –, Wash Clothes, Rinse Clothes & Dry Clothes Find out possible Use Cases Find out possible Actors Depict interaction among each Actor and Use Case Detail each Use Case in terms of Scenarios Find out the relationship among various Use Cases.

Activity Diagrams

These are developed in Requirement phase If the Use cases are really complicated Activity diagram are prepared. Example CRUD (creates, read, update and delete) operation use cases has no significance for making activity diagrams. Activity diagrams will only be needed when you want some simplified look of a complicated use case. Inputs - UseCase Diagram Activity diagram’s map to a Use Case.

Design phase (Component diagrams à Class diagrams à Object diagrams à Collaboration diagrams à Sequence diagrams à State diagrams à Deployment diagrams)

Component Diagrams	In the Design phase the first document after the using the Use Case document should 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.
Class Diagrams	Once the high level grouping is done you can go ahead with class diagrams. From my point of view class diagrams should be compulsory in projects. Inputs – UseCase Diagram From the Use Case get the “NOUNS” which can form the class name and “VERBS” the method name. For a Use Case there are multiple Scenarios. From the collection of Scenarios (determined for a Use Case) identify Objects (NOUNS) & their Responsibilities (VERBS). Then identify Relation among Objects. Then you can draw Class Diagrams with Relationships.
Object Diagrams	Object diagrams are not compulsory it depends on how complicated your project. Object diagrams show’s 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, it’s 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 created from that object.
Collaboration Diagrams	Collaboration diagrams mainly depict interaction between object to depict a purpose. These diagrams are more useful than Object diagrams as they are addressed for some purpose. Example “Login Process” which will use “Login object”, “User Object” etc to fulfill the login purpose.  Thumb rule - If there is activity diagram which shows some serious complicated scenarios I will like to go for this diagram for more simplified explanation.
State Diagrams	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. E.g. In a call center project where the agent phone pickup and hang state has to be depicted. So my first state was when agent picks up the phone and the final  stage was when agent hangs the phone, the in between process was very complicated, which can only be shown by using state chart diagrams.
Sequence Diagrams	Sequence diagrams are needed if some sequence is complicated. Inputs – UseCase Diagram Sequence diagrams show Object interaction in sequence. For a Use Case there are multiple Scenarios. From the collection of Scenarios (determined for a Use Case) we identify Objects (NOUNS). Now for the identified Objects, in a particular UseCase – Draw Sequence Diagram to show the interaction among those Objects. The Sequence Diagram represents the interaction among the Objects on a time scale.
Deployment Diagrams	Deployment diagrams are again not a compulsory requirement. It shows 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.

Thanks & Regards,

Arun Manglick || Senior Tech Lead