Unified Modelling Language (UML) Introduction Video Lecture - Embedded

In this session
we will try to understand
what is UML
We will try to go through the basic definition of UML
then finally we will try to see
what
exactly is UML
in real software life
It is nothing but basically
Unified Modeling Language
It is not
a programming language
it is a modeling language
Many of the people think it is probably a language something like C# or JAVA
Its nothing related with programming
It is related with Modeling
What does a Modeling Language mean?
First try to understand what does a Modeling Language means
First try to understand what is a Model
that's more essential
A model is nothing but its a final
representation of a product
For example
if you are doing a construction
building a house or a bridge or something
The civil engineers first make a model
and taking the model. The workers finally make a output
which is either your
whatever construction process. Whatever construction it is either building or a bridge
In the same way in software
We can
create this models much before coding or execution
using unified modeling language
Now define it
we can say that
it is a language by which
a technical architect
can communicate to his developer
What exactly he wants and how should the project proceed?
Or what should be the road map or the technical road map
of
the project execution
In another way
if you want to really define at a very ground level you can say that
It is a way by which one can express or the technical architect can express
the design of a software architect
One line sentence again we put it its a blue print of your source code
In software life cycle you get a requirement
Once you a get requirement you start making a technical document
Technical document is where UML will play his part of role
In the technical document the architect tries to
put as much as
clarity
or define the technical road map by which
during the execution phase
it becomes easier to achieve the goal
It has in all nine diagrams which we can use
And all this diagrams in UML have there own perspective of
expressing the design of the software architect. For example if you look at the class diagrams it basically represent the static structure of the software architect
If you look at the deployment diagrams it basically shows that how the software is going to be install or deploy across the servers
Each of these diagram define a point of view towards a software
architecture
How does this actually happen
If you can make us understand by simple example
I have taken a simple screen which you see in a video
This is a simple Voucher entry screen
The user who comes in
when he starts the UI
The first things happens is that
the debit account number and the credit account numbers get loaded in a combo box
They get flourished
then the users comes in and he enters a voucher number, the date he selects the debit account number. He selects what kind of credit account number
puts in whatever cash description or voucher description we are discussing about
Puts in the amount
and
adds a voucher. Once he adds a voucher
a entry goes inside in the grid
Again he takes a second voucher number he puts in the date
In case he feels that there is something wrong he can use the cancel voucher and cancel the transaction
Finally when everything is right
he clicks on submit voucher
which reads to edition in the database
This is a pretty complicated screen
This can be made
easier
if we make one UML diagram and that UML diagram can give us
the way to construct this in actual execution
In the next diagram
we will try to put
a technical road map
using one of the UML diagrams called as a sequence diagram
to see how we can execute this particular screen or how we can technically achieve this particular screen
What are the various component in this screen?
What are the various way they will interact?
Here is your accountant/User
who will actually load the UI
This is the UI i.e your voucher entry screen
then I have
made certain components like vouchers, account masters and the data access layer component
When the user first starts a screen
the UI is loaded
There were two combo boxes which had accounts codes to be filled
The UI query is the account master compose and says please give me the account codes
The account masters sends a message to the data access layer saying can you please
go to SQL Server or oracle whatever database you have in your system
and get me the code
He returns a values
to the account master. Account masters returns a value to the UI
and UI display it to the user
The first sequence is completed
In the second sequence
The accountant enters all the vouchers he adds a voucher button
As soon as they add the voucher button the UI send this instruction to the voucher component
If you look at the top
you have a voucher component, account master, a data access layer, a UI
The voucher component adds this voucher to his collection or a temporary memory
resident
and whatever in memory representation of the voucher object
He says do he want to add more vouchers
If yes then again this cycle continues
If no then he goes to the click submit
and then the click submit calls all the vouchers
in a loop and adds to the database
This diagram has given me some
detailed
technical road map
by which
a developer can actually code
In the sense probably he will be making
voucher class, accounts master class, a data access class
probably he will be making a load
the UI
load UI methods
He will be having probably a add method in the vouchers
In this way
by this UML diagram we have defined a technical road map
for
the programmers
This is what basically is UML all about
UML
is
blue print of your code
The best part about UML is
you can define a UML
and later
its either Java or its either C# or either it is C++
it doesn't matter
because classes are classes in all these languages
Components are components in this languages
The object oriented concepts all basically remain same
You can
push ahead
or you can design your technical documentation
irrespective of what language is going to come later on
I hope we have understood UML
and I conclude this video over here
Just one point to remember is
we have nine diagrams in UML
It doesn't mean that we need to use all the nine diagrams for example
in this diagram I have used this sequence diagram to show the simplicity of that UI
but
its possible that you don't need this complicated diagram probably you will need some other diagrams like the state diagram or probably you will just need a class diagram
or you will just need
a component diagram to define because if your system is simple
then you don't need all the diagram
One essential thing to remember is
use those diagrams which your project needs
See the context of your project. If project is very simple
don't try to put all the nine diagrams
But if your project is very probably having lot of activities lot of sequences lot of states
lot of components lot of interaction between them
then at the moment you need to define
what is a way of representing this into the final solution
and then decide a UML diagram
In the further coming videos we will try to understand all these nine diagrams step by step
One important point to remember is that decide the diagram depending on your problem context