Hi my name is Zach, and I'm with Lucidchart.
Today I'll be teaching you about UML Class Diagrams.
We'll start with some of the basic characteristics.
Then we'll talk about relationships.
And we'll finish up by going through some examples together.
Alright, let's talk about some of the basic characteristics of class diagrams.
To help explain these characteristics, I'm going to make up an example to help illustrate.
So let's say we're building a system for a zoo.
And, by the way, these examples I'm going to use probably wouldn't ever find their
way into an actual program, but it'll make all these concepts easier to understand.
So in our zoo, we'd want to describe the different things that are in the system.
You represent those things through classes, and a class is depicted with this shape here.
So what's in a zoo?
Well there are a ton of animals.
So we could create a class for our animals.
To do that, you just write the name of the class in this top section.
If our class is Animal, an instance of that class would be a specific animal.
So the question is, how would you go about identifying each instance of that class?
You do that through attributes.
An attribute is a significant piece of data containing values that describe each instance
of that class.
They're also known as fields, variables, or properties, and they go in the middle section here.
So for our animal class, we could create attributes like name, ID, and age.
That way we could identify a specific instance of the animal class.
Like Ruth, ID number 304, age 114.
These need to be formatted a certain way though.
You start with visibility, which we'll talk about later. The name of the attribute beginning
with a lowercase letter.
Then you follow it with a colon and the data type.
For the name, we'd want to return a string.
And we can format the other attributes the same way, except that we'd want to return
an integer since these are numbers.
Now that we've got some attributes for our Animal class, we get to the bottom section here.
This is where you put methods, which are also known as operations or functions.
Methods allow you to specify any behavioral features of a class.
So we might ask ourselves, what are some different behaviors of this Animal class?
Maybe we'd want to be able to change our animals' names.
Like Ruth should actually be called Rita.
So let's create a function called Set Name.
We could also create a method for eating, since all of our animals eat.
Methods also need to be formatted a certain way.
You start with visibility (which we'll talk about next), then the method beginning with
a lowercase letter.
Next you put parentheses to signify the function you're going to program later.
You can also add variables and the data type in here, but in most cases, it's not really necessary.
We'll add visibility and parentheses to the eat method as well.
Now let's talk about the visibility.
The visibility of an attribute or a method sets the accessibility for that attribute
or method.
So right now we have a minus sign for all of these, which indicates that each of these
attributes and methods are private.
They can't be accessed by any other class or subclass.
The exact opposite is the plus sign, which means an attribute or method is public and
can be accessed by any other class.
Another visibility type is indicated by the hash,
which means an attribute or method is protected.
These can only be accessed by the same class or its subclasses.
And finally, there's the tilde (or the squiggly as I like to call it).
This sets the visibility to package or default, which means it can be used by any other class
as long as it's in the same package.
But that one is rarely ever used.
In most cases, your attributes are going to be Private or Protected, and methods are often Public.
Let's quickly review these basics with another example.
Let's make a class for Employee.
We could give an Employee attributes like name, employeeID, phone number, and department.
We'll want all these attributes to be private.
And then we could create a simple method, like updating the phone number.
Which we'll go ahead and set to public.
So you may have noticed that I'm using diagramming software to create these UML Class Diagrams.
The same principles apply if you're using pen and paper.
But a diagramming software makes it much easier.
The diagramming software I'm using today is Lucidchart.
And you can sign up for free by clicking on the link at the top right.
All it takes is an email address and then you'll be able to follow along as we make
these class diagrams.
So the next thing we'll need to cover are the different relationships that exist between classes.
The first type of relationship that we'll describe is inheritance.
And I'm gonna keep going with the zoo example because it makes it easy to understand the
logic of these relationships.
We'll get to a more technical, real-world example later.
Okay, so inheritance.
Let's say in our zoo, the only animals we have are tortoises, otters, and the lesser
known but nonetheless amazing slow loris.
In our system, we want to distinguish each of them as their own class.
So we make three new classes for Tortoise, Otter, and Slow Loris.
And I'll make these a little smaller so you can see them better.
Now instead of duplicating attributes for name, ID, and age, we can make these classes
into subclasses of the animal class by drawing open arrows like this.
This is an inheritance relationship.
We're saying that these subclasses inherit all the attributes and methods of the superclass.
You could also use the terms child and parent class.
So our Otter class is going to inherit the attributes of name, age, and ID.
And then we could add an attribute specific to Otter, like whisker length.
One of the advantages of inheritance is that if we wanted to change or add an attribute
for all animals, we wouldn't have to go in and make that change to Tortoise, and then
Otter, and then Slow Loris.
We just make the change to the Animal class and it applies across all subclasses.
In this scenario, we also have what's called abstraction.
Animal is an abstract class.
Because in our system, anytime we want to instantiate one of our classes, it's going
to be a tortoise, otter, or slow loris.
We wouldn't instantiate the animal class itself.
The animal class is just a way to simplify things and keep the code "dry"
so you don't repeat yourself.
So to show that this is an abstract class, we'll put the name in italics.
You could put the class name inside these things as well, but I prefer italics.
Okay another type of relationship is association.
So if we had a class for Sea Urchin we could draw an association, which is just depicted
by a simple line, between Otter and Sea Urchin.
And we could say Otter eats Sea Urchin.
There's no dependency between them.
It's just a basic association relationship and it's pretty simple.
The next type of relationship is aggregation.
It's a special type of association that specifies a whole and its parts.
So to continue with our zoo example...again, this is just to help explain the logic...let's
create a new class for a group of tortoises.
A group of tortoises is called a creep, and that's pretty cool.
So here's our Creep class and it's got a relationship with tortoise.
Any of our zoo's tortoises could be part of a creep.
But they don't have to be.
A tortoise could leave the creep at any point and still exist on its own.
That type of relationship, where a part can exist outside the whole, is aggregation and
we note it with an open diamond.
There's also a relationship where the part can't exist outside the whole.
It's called composition.
To illustrate this, I'm going to create a few new classes.
Let's just say we have several different visitor centers in our zoo.
And each of those visitor centers has a lobby and a bathroom.
Now if one of our visitors centers was torn down, the lobby and the bathroom of that visitor
center would be destroyed as well.
Those rooms couldn't exist apart from the Visitor Center that they're in.
That's composition...when a child object wouldn't be able to exist without its parent object.
We note a composition relationship with a closed diamond.
Another important concept when talking about relationships in UML class diagrams is multiplicity.
Multiplicity allows you to set numerical constraints on your relationships.
For example, let's say we want to specify that our visitor centers are going to have
just one lobby.
We simply write the number one here, meaning there can be one and only one lobby per visitor center.
But for bathrooms, maybe we want to make it so that there's at least one bathroom per
visitor center, but leave the option to have as many as you'd like.
We'd use this notation to denote one or many bathrooms.
Other types of multiplicity are zero to one, which is an optional relationship.
N, representing a specific amount, which in our example was one, but it could be any other
number depending on your use case.
Zero to many.
One to many.
Or a specific number range.
Hopefully our zoo examples have helped explain those concepts, but I want to show you what
a real world example would look like.
This is a UML class diagram for an online shopping cart, and if you want to look at
this diagram with me, just click the link in the top right corner.
You can see that this system has several classes and relationships, so let's walk through
a couple of them.
We'll start with the user class.
It's got attributes for user ID, password, login status, and register date.
You've got the different return types on the right, and on the left, the visibility,
which are set to private.
You can see how the values returned by these attributes would specifically describe an
instance of the User class.
Down below we have a public method of verify login, returning a boolean.
And this makes sense, right?
Methods are behaviors of a class.
So if you were to log in to your user account, there's a function in place that verifies
your login credentials.
Let's move on to the Customer class.
This arrow tells us that Customer is a child of User.
So Customer inherits all the attributes and methods of the User class.
And same thing for the Administrator class.
Both of these inherit from User, but also have their own specific attributes and methods.
Like Administrator can update catalog, but Customer can't.
Stemming from Customer, there are several lines with the closed-in diamond.
So if you recall, these are composition relationships which means that the parts cannot exist without
the whole.
If an instance of the Customer class, if that customer's account was destroyed, his shopping
cart would be destroyed and his orders would be lost.
They can't exist outside of the customer.
The same applies for Shipping Info and Order Details.
If there's no order, there's not going to be any order details or shipping info.
The last thing we'll look at in this example is multiplicity.
You can see that a customer can have zero or many orders.
Makes sense, right?
You could create a customer account for an online store but never buy anything.
Or you could be a frequent customer and place several different orders.
And then on the flip side, an order can belong to only one customer.
It'd be pretty confusing if a specific order with a unique order ID was duplicated across
several different customers.
And here you can see a one-to-one relationship.
Each Order has one and only one Order Details.
And Order Details belongs to one and only one Order.
Thanks for watching this tutorial on UML Class Diagrams.
Be sure to subscribe to the channel and leave a comment below.
Lastly, don't forget to sign up for a free Lucidchart account by using this link.
And you'll be able to start making your own UML Class Diagrams in no time.
For more infomation >> Carmen Salinas opina sobre la situación que viven Giovanni Medina y Ninel Conde - Duration: 1:10. 
For more infomation >> Raúl González llega a nuestra casa para contarnos todos los detalles de "Gran Oportunidad" - Duration: 4:57. 
For more infomation >> NIOBONEWS - RIP BOWENS - Duration: 4:44. 
For more infomation >> Ezio Oliva - Como Le Hago (Audio) - Duration: 3:28. 
Không có nhận xét nào:
Đăng nhận xét