UML class diagrams

Summary

このビデオスクリプトでは、UMLクラスダイアグラムの基本特性から始まり、クラスの属性、メソッド、可視性、そして継承、関連性、集約、合成などのクラス間の関係について学びます。動物園の例を使って、これらの概念を説明し、さらにオンラインショッピングカートの実際の例を通じて、クラス間の多重度やその他の関係を理解します。最後に、Lucidchartを使用したUMLクラスダイアグラムの作成方法も紹介しています。

Takeaways

• 📚 UMLクラス図は、システム内の異なる要素をクラスとして表し、それらの関係性を可視化するツールです。
• 🐾 クラスは、動物園の動物を例にすると、属性（name, id, ageなど）とメソッド（setName, eatなど）で特徴化されます。
• 🔑 属性とメソッドには可視性があり、プライベート（-）、パブリック（+）、プロテクテッド（#）、デフォルト（〜）の4つがあります。
• 👶 継承は、スーパークラス（动物）の属性とメソッドをサブクラス（亀、水獺、 lorisなど）が継承する関係を表します。
• 🔄 抽象化は、動物クラスのように、システム内でインスタンス化されることがないが、コードの再利用を促進するクラスを指します。
• 🔗 関連は、オッターと海うにのような単純な関係を表し、依存関係はなく、単純にオッターが海うにを食べるだけです。
• 💬 集約は、亀の群れ（creep）と亀の関係のように、部分が全体から独立して存在できる関係を表します。
• 🏠 構成は、ビジターセンターとロビー、トイレの関係のように、部分が全体から独立して存在できない関係を表します。
• 🔢 多重性は、関係における数値の制約を設定し、1..1、0..1、0..*、1..*など様々なタイプがあります。
• 🛒 オンラインショッピングカートのUMLクラス図は、実際のシステムにおけるクラスと関係性の例を示しており、ユーザー、顧客、管理者のクラスが含まれています。
• 🔍 Lucidchartなどのダイアグラムアプリケーションを使用することで、UMLクラス図の作成がより簡単かつ直感的になります。

Q & A

UMLクラスダイアグラムとは何ですか？

UMLクラスダイアグラムは、ソフトウェア開発においてクラスとその関係を視覚化する図記法です。オブジェクト指向プログラミングにおいては、システムの構造を理解するための重要なツールです。

クラスダイアグラムでクラスはどのように表されますか？

クラスダイアグラムでは、クラスは長方形で表され、クラス名が上部に書かれ、属性が中央に、メソッドが下部に配置されます。

属性とは何で、どのように表すのですか？

属性は、クラスのインスタンスを特定する重要なデータの一部であり、フィールド、変数、プロパティとも呼ばれます。属性は中央のセクションに表示され、可視性、属性名、データ型の順で書きます。

メソッドとは何で、どのように表すのですか？

メソッドは、クラスの振る舞いを指定する機能であり、操作や関数とも呼ばれます。メソッドは下部のセクションに表示され、可視性、メソッド名、パラメータ（必要に応じて）が書かれます。

可視性とは何で、どのような種類がありますか？

可視性は、属性やメソッドへのアクセスを制御するものです。プライベート（-）、パブリック（+）、プロテクテッド（#）、パッケージ（〜）、抽象（イタリック）があります。

継承関係とは何で、どのように表すのですか？

継承関係は、あるクラス（スーパークラス）の属性やメソッドを他のクラス（サブクラス）が継承する関係です。継承関係は、オープンな矢印で表されます。

関連関係とは何で、どのように表すのですか？

関連関係は、クラス間の基本的な関係を表すもので、単純な線で表されます。例えば、オッターが海うにを食べるという関係です。

集約関係と合成関係の違いは何ですか？

集約関係は、全体とその部分の関係を表す特殊な関連関係であり、部分が全体の外部で存在できることを示します。一方、合成関係では、部分は全体の外部で存在できないことを示します。

多重性とは何で、どのように表すのですか？

多重性は、関係における数的限制を表すもので、例えば「1」「0..1」「*」「1..N」「N..M」などがあります。これは、クラス間の関係において、特定のクラスが他クラスと関連する数を示します。

実際のオンラインショッピングカートの例では、クラス間の継承関係や合成関係はどのように表されていますか？

オンラインショッピングカートの例では、顧客クラスと管理者クラスがユーザークラスから継承しています。また、顧客クラスからショッピングカート、配送情報、注文詳細への合成関係が示されており、これらの部分は顧客クラスの外部で存在できないことを表しています。

Lucidchartとは何で、どのように使いますか？

Lucidchartは、UMLクラスダイアグラムを含むさまざまな図を作成するための図表アプリケーションです。メールアドレスで無料でアカウントを作成し、クラスダイアグラムを作成することができます。

このチュートリアルの最後に提供されるリンクはどのようなものですか？

このチュートリアルの最後に提供されるリンクは、トレーニングのウェブサイト「training.lucid.co」へのリンクで、図表、プロセス、システム、組織に関するさらに学習に興味がある場合にアクセスできます。

Outlines

00:00

📚 UMLクラス図の基本

この段落では、UMLクラス図の基本的な特徴について解説しています。動物園のシステムを例に、クラスの表現方法や属性、メソッド、可視性（private, public, protected, package）について説明しています。クラス図を作成する際には、図形アプリケーションを使うことが有効で、Lucidchartを使ったデモンストレーションが行われています。

05:02

🔄 クラス間の関係性

継承、関連、集約、合成、および多重性について学びます。動物園の例を使って、継承はクラス同士の共通属性を共有する方法であり、関連はクラス間の単純な関係を表す方法、集約は部分が全体から独立して存在できる関係、合成は部分が全体から独立して存在できない関係を表す方法を説明しています。また、多重性は関係における数的限制を表す方法です。

10:04

🛒 オンラインショッピングカートのUMLクラス図

実際の例としてオンラインショッピングカートのUMLクラス図を分析しています。ユーザークラス、顧客クラス、管理者クラスの属性とメソッド、継承関係、そして顧客クラスとショッピングカート、配送情報、注文詳細の間の合成関係について説明しています。また、顧客が注文を持つことができる多重性や、注文が顧客に属する1対1の関係についても触れています。

Keywords

💡UMLクラス図

UMLクラス図は、オブジェクト指向ソフトウェア開発においてクラスとその関係を視覚化する図式です。このビデオでは、UMLクラス図の基本特性やクラス間の関係性について説明し、動物園の例を使って具体的なクラスと属性、メソッドを紹介しています。

💡クラス

クラスは、UMLクラス図においてシステム内のものを表す単位です。クラスは属性とメソッドを持ち、特定のインスタンスを特定するためのデータを含むことができます。ビデオでは動物クラスを例に、動物の属性として名前、ID、年齢を挙げています。

💡属性

属性は、クラスのインスタンスを特定するための重要なデータの一部であり、フィールド、変数、プロパティとも呼ばれます。ビデオでは、動物クラスの属性として名前、ID、年齢が挙げられており、これらは各動物の特定の値を保持します。

💡メソッド

メソッドとは、クラスの動作特徴を指定する関数であり、操作や機能を表します。ビデオでは、動物クラスのメソッドとしてsetName（名前の変更）やeating（食べる動作）が紹介されており、これらはクラスの振る舞いを定義しています。

💡可視性

可視性は、属性やメソッドに対するアクセスの制限を表します。ビデオでは、プライベート（-）、パブリック（+）、プロテクテッド（#）、パッケージ（〜）の可視性を説明しており、これにより他のクラスやサブクラスがどのように属性やメソッドにアクセスするかを制御できます。

💡継承

継承は、クラス間の関係性の一種で、サブクラスがスーパークラスの属性とメソッドを継承できるようにします。ビデオでは動物園の亀、カワウソ、スローローリスのクラスが動物クラスから継承している例を通じて継承の概念が説明されています。

💡抽象クラス

抽象クラスは、具体的なインスタンス化ができないクラスであり、他のクラスの基底として使われます。ビデオでは動物クラスが抽象クラスとして位置づけられており、これはシステム内で直接インスタンス化されることなく、他のクラスの基礎として機能します。

💡関連

関連は、クラス間の単純な関係を表すもので、クラス同士がどのように相互作用するかを示します。ビデオではカワウソがウニを食べるという関連関係が紹介されており、これはクラス間の基本的な相互作用を表しています。

💡集約

集約は、関連の一種で、全体とその部分との関係を示します。ただし、部分は全体から独立して存在することができます。ビデオでは、ツルモグリのクラスがツルモグリのグループであるクリープと集約関係にある例が挙げられています。

💡組成

組成は、集約と似ていますが、部分が全体から独立して存在できないという点が異なります。ビデオでは、ビジターセンターがロビーとトイレと組成関係にある例が紹介されており、これは部分が全体なしには存在できないことを示しています。

💡多重性

多重性は、クラス間の関係における数値的な制約を設定する方法です。ビデオでは、ビジターセンターが1つのロビーを持つべきであり、トイレは1つ以上を持つことができるという多重性を説明しています。

💡オンラインショッピングカート

ビデオの後半では、オンラインショッピングカートのUMLクラス図が紹介されており、これはリアルワールドの例として、ユーザー、顧客、管理者、ショッピングカート、注文などのクラスとその関係性について理解を深めるのに役立ちます。

Highlights

介绍UML类图的基本特性。

使用动物园系统作为类图示例，帮助理解概念。

类通过特定的形状表示，例如动物类。

属性用于标识类的每个实例，如动物的名称、ID和年龄。

属性的格式包括可见性、名称、数据类型。

方法定义类的任何行为特征，如动物的setName和eating方法。

方法的格式包括可见性、名称和函数的参数。

可见性定义属性或方法的可访问性，如私有、公共、受保护。

使用Lucidchart软件绘制UML类图。

继承关系允许子类继承超类的属性和方法。

抽象类用于简化代码，避免重复，如动物类。

关联关系表示类之间的基本联系，如海獭和海胆。

聚合关系表示整体和部分的关系，如龟群和龟。

组合关系表示部分不能独立于整体存在，如访客中心和其房间。

多重性设置关系的数量限制，如访客中心的大厅和浴室数量。

在线购物车系统的UML类图实例分析。

用户类、客户类和管理员类之间的关系和属性。

组合关系在客户类中的体现，如购物车和订单。

多重性在客户和订单关系中的应用。

教程结束，鼓励访问training.lucid.co了解更多。

Transcripts

Hi, my name is Bear, and 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 finally we'll finish up by going through a few examples together.

All right, 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 us illustrate.

So let's say we're building a system for a zoo.

And keep in mind, these examples I'm going to use probably wouldn't

ever find their way into an actual program, but humor me

as I use these concepts to make it easier to understand.

So in our zoo, we want to describe the different things that are in the system.

You represent these things through classes,

and a class is depicted with this shape here.

So what's in a zoo?

Well, a ton of animals.

So we can 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'll 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 setName.

We can 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 in parentheses to the eat method as well.

Now let's talk about visibility.

The visibility of an attribute or 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 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,

employee ID,

phone number

and department.

We'll want all of these attributes to be private and we could create a simple

method like updating a phone number which we'll go ahead and set to public.

So you might have noticed that I'm using

a diagraming application to create these UML class diagrams.

The same principles apply if you're using pen and paper.

But a diagraming software makes it much easier.

The diagraming application that I'm using today is Lucidchart.

You can sign up for a free account with your email address

and then you'll be able to follow along as we make these class diagrams together.

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 going to 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 just a little 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'll make three classes for a tortoise, otter, and slow loris.

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 order class is going to inherit the attributes of name, age and ID.

And then we could also add an attribute specific to the 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 of its subclasses.

in this scenario, we also have what's called abstraction.

Animal is an abstract class because in our system,

any time 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.

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 group 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.

That'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 visitor centers was torn down, the lobby

and the bathroom of that visitor center would also be destroyed.

Those rooms couldn't exist apart from the visitor center that is contained 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 we talk about relationships in UML 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 0 to 1, which is an optional relationship.

N representing the 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 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 the 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 is set to private.

You can see how the values returned by those attributes

would specifically describe an instance of the user class.

Down below we have a public method of verify

log in returning a boolean and this makes sense.

Right? Methods are behaviors of a class.

So if you were to log into 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 the catalog, but the customer can't.

Stemming from customer, there are also several lines with the closed end diamond.

So if you recall, these are composition relationships

which mean that the parts cannot exist without the whole.

in the instance of the customer class, if that customer’s account was destroyed,

his shopping cart would be destroyed as well and all of his orders would be lost.

They can't exist outside of the customer.

The same applies for the 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 1 to 1 relationship.

Each order has one and only one order details

and order details belongs to one and only one order.

Okay, that wraps up our tutorial for UML class diagrams.

If you're interested in learning more about diagraming, processes, systems

and organizations, visit training.lucid.co I hope to see you there.