1. What is UML ( Unified Modelling language )
1.1. UML(Unified Modeling Language) is a standardized general-purpose modeling language in the field of object-oriented software engineering.
1.2. Unified Modeling Language (UML) makes it possible to describe systems with words and pictures.
2. References
2.1. Unified Modeling Language
2.2. UML diagrams example
3. Why to use UML diagrams ??
3.1. to build comprehensive design before actual coding
3.2. To communicating with others with common graphical language
3.3. To Document software artifacts
3.4. UML provides a common vocabulary for the stakeholders like developer, BA, architects.
4. when to draw UML diagrams and when to stop ? when not to draw ?
4.1. when to draw ??
4.1.1. when several people need to understand the structure of a partic- ular part of the design because they are all going to be working on it simulta- neously.
4.1.2. Draw diagrams when two or more people disagree on how a particular element should be designed, and you want team consensus. Put the discussion into a time- box choose a means for deciding, like a vote, or an impartial judge.
4.1.3. Draw diagrams when you need to explain the structure of some part of the code to someone else, or to yourself.
4.2. when to stop ??
4.2.1. Stop when everyone agrees that they understand.
4.2.2. Stop at the end of the timebox, or when the decision can be made. Then erase the diagra
4.2.3. Stop when the explanation would be better done by looking at code.
4.3. when not to draw??
4.3.1. Don’t draw diagrams because you feel guilty not drawing them or because you think that’s what good designers do. Good designers write code and draw dia- grams only when necessary
5. Total 13 UML diagrams are classified into
5.1. Structural diagrams
5.1.1. Structural diagrams describes components of the system. This diagram defines the static features of the system.
5.1.2. Class diagrams
5.1.2.1. why to use class diagram???
5.1.2.1.1. Class diagram defines a set of classes and interfaces
5.1.2.1.2. Its most popular UML diagram which give pure OO flavor for visualising interface, class and objects relations .
5.1.2.2. where to use class diagram ??
5.1.3. Component diagrams
5.1.3.1. provide a visual representation of a system's physical components
5.1.4. Composite structure diagrams
5.1.5. Deployment diagrams
5.1.6. Object diagrams
5.1.7. Package diagrams
5.2. Behavioral diagrams
5.2.1. Behavioral diagrams helps to understand how system components interacts to form a system.
5.2.2. Activity diagrams
5.2.2.1. This illustrate the flow of process in system.
5.2.2.2. This dig helps to visually document the activities within a system or a functionality .
5.2.3. Interaction diagrams
5.2.3.1. Interaction diagrams visually document how system components interact with each other
5.2.3.2. Sequence diagram
5.2.3.2.1. Sequence diagrams are used to show a specific use case scenario
5.2.3.3. Communication diagram
5.2.3.3.1. this helps to understand how system participants are linked to one another.
5.2.3.4. Timing diagram
5.2.3.4.1. Timing UML diagrams provide a visual representation of a system's time constraints
5.2.4. State machine diagrams
5.2.4.1. This helps to visually describe a system's behavior
5.2.4.2. The key components of these diagrams include states and transitions.
5.2.5. Use case diagrams
5.2.5.1. This diagram document the interactions between your users and your system
6. Building blocks of UML diagrams
6.1. Structural
6.1.1. class
6.1.1.1. class represents template for object , its like a blueprint for its object.
6.1.2. Interface
6.1.2.1. Interface defines a set of behaviour which needs to be implemented by class
6.1.3. useCase
6.1.3.1. Use case represents a set of actions performed by a system for a specific goal.
6.1.4. Component
6.1.4.1. Component describes the physical part of the system
6.2. Behavioral
6.2.1. Interaction
6.2.1.1. interaction represented by this diagram , this represents group of messages exchanged.
6.2.2. state
6.2.2.1. this represents state of an object
6.3. Grouping
6.3.1. package
6.3.1.1. describe group of things
6.3.2. note
6.3.2.1. this is to capture special note or remark
6.4. Relationship
6.4.1. Dependency
6.4.1.1. Dependency is a relationship between two things in which change in one element also affects the other
6.4.2. Association
6.4.2.1. It describes the link between objects
6.4.3. Generalization
6.4.3.1. Describes Inheritance relationship.
6.4.4. Realization
6.4.4.1. One element describes some responsibility, which is not implemented and the other one implements them. This relationship exists in case of interfaces.