UML (Unified Modeling Language) is a standardized general-purpose modeling language in the field of object-oriented software engineering .It is a visual language for specifying, constructing, and documenting the artifacts of systems. The UML offers a standard way to write a system's blueprints, including conceptual things such as business processes and system functions as well as concrete things such as programming language statements, database schemas, and reusable software components.
Advantages of UML:
There are two main advantages of UML:
- 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.
- Reusability: - After the system is more readable and broken down to pieces, it becomes easier to identify redundant and similar modules. Thus increasing reusability.
Disadvantages of UML:
The various disadvantages of UML are:
- Still no specification for modeling of user interfaces.
- Business rule specification – a group exists for this within the OMG, so we should see something in UML
- Poor for distributed systems – no way to formally specify serialization and object persistence.
- Example – no way to specify that an object resides on a server process and shared among instances of a running process.
As per my learning there are 13 types of UML Diagrams that are one by one described as under:
1. 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.
Let us consider the example of attending a course lecture, at 8 am.
2. 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.
Sketch of a conceptual class diagram.
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. Object diagrams can be imagined as the snapshot of a running system at a particular moment. In a brief, object diagrams are used for:
- Making the prototype of a system.
- Reverse engineering.
- Modeling complex data structures.
- Understanding the system from practical perspective.
Example: Object Diagram of an object management system.
4. Component Diagram:
Component diagrams are particularly useful with larger teams. 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. They are building blocks so a component can eventually encompass a large portion of a system.
5. Composite Structure Diagram:
A composite structure diagram is similar to a class diagram, but it depicts individual parts instead of whole classes. Before you can define the internal structure of a classifier, you must either show its structure compartment or open a composite structure diagram. You can then model the parts that represent the instances that the containing classifier owns. You can add connectors to link two or more parts in an association or dependency relationship.
In composite structure diagrams, ports define the interaction point between a classifier and its environment or between a classifier and its internal parts. You can use a port to specify the services that a classifier provides to and requires from its environment.
6. Package Diagram:
A package diagram is a UML diagram composed only of packages and the dependencies between them. Package diagrams are used to reflect the organization of packages and their elements. When used to represent class elements, package diagrams provide a visualization of the namespaces. The most common use for package diagrams is to organize use case diagrams and class diagrams, although the use of package diagrams is not limited to these UML elements.
Continue to Part 2