You must be wondering why is UML described in this blog (Advanced .Net concepts).Before you start feeling “IT’s time wastage”, let me re-assure you about its importance by restoring to a real life example.
Although “Kites”(Indian movie released in 2010) was a blunder at the box-office , however it gives us an opportunity to fit the UML discussion in the story line(although it never had any story).
Let’s start by asking Why UML. The answer, the Hero of the movie did not understand Spanish and the lady didn’t know English (mess created), would have been avoided if both of them knew a common language (might be Hindi!!!).
Any software is a global product involving Architects, designers, developers/Coders (situation is same as described above) .To develop, the pre-requisite is “understanding” and UML shortens the cycle involved in understanding.
The UML is applicable to object-oriented problem solving. Object oriented solutions begin with the construction of a model. A model is an abstraction of the underlying problem
Models consist of objects that interact by sending messages to each other.
Objects have things they know (attributes) and things they can do (behaviors or operations). And last but not the least, values of an object's attributes, its state.
Classes are the "blueprints" for objects. A class wraps attributes (data) and behaviors (methods or functions) into a single distinct entity.
There are three main Categories of UML diagrams, namely
- Behavior diagrams. As the name suggests, these diagrams depict behavioral features of a system or business process. This category includes activity, state machine, and use case diagrams and the four interaction diagrams.
- Interaction diagrams. This is a subset of behavior diagrams and emphasizes object interactions. This includes communication, interaction overview, sequence, and timing diagrams.
- Structure diagrams. Used for specifying the system structurally. This includes class, composite structure, component, deployment, object, and package diagrams.
The table below describes the Summary of the diagrams and detailed articles about each single diagram will be covered in the next article.
Diagram | Description |
Activity Diagram | Depicts high-level business processes, including data flow, or to model the logic of complex logic within a system. |
Class Diagram | Shows a collection of static model elements such as classes and types, their contents, and their relationships. |
Communication Diagram | Shows instances of classes, their interrelationships, and the message flow between them. Communication diagrams typically focus on the structural organization of objects that send and receive messages. Formerly called a Collaboration Diagram. |
Component Diagram | Depicts the components that compose an application, system, or enterprise. The components, their interrelationships, interactions, and their public interfaces are depicted. |
Composite Structure Diagram | Depicts the internal structure of a classifier (such as a class, component, or use case), including the interaction points of the classifier to other parts of the system. |
Deployment Diagram | Shows the execution architecture of systems. This includes nodes, either hardware or software execution environments, as well as the middleware connecting them. |
Interaction Overview Diagram | A variant of an activity diagram which overviews the control flow within a system or business process. Each node/activity within the diagram can represent another interaction diagram. |
Object Diagram | Depicts objects and their relationships at a point in time, typically a special case of either a class diagram or a communication diagram. |
Package Diagram | Shows how model elements are organized into packages as well as the dependencies between packages. |
Sequence Diagram | Models the sequential logic, in effect the time ordering of messages between classifiers. |
State Machine Diagram | Describes the states an object or interaction may be in, as well as the transitions between states. Formerly referred to as a state diagram, state chart diagram, or a state-transition diagram |
Timing Diagram | Depicts the change in state or condition of a classifier instance or role over time. Typically used to show the change in state of an object over time in response to external events. |
Use Case Diagram | Shows use cases, actors, and their interrelationships. |
The table above has been excerpted from the book(The Object Primer 3rd Edition: Agile Modeling Driven Development with UML 2.)
I forgot to tell you something about UML in the beginning. We’ll it’s not too late yet.
UML current version is 2.0 and the article is applicable to this version only.
Version 1.0 had only 9 diagrams.
Till next we connect Happy Reading….
Comments
Post a Comment