[usth/ICT2.7] Engineer software

author: Nguyễn Gia Phong <mcsinyx@disroot.org> 2020-05-24 16:34:31 +0700
committer: Nguyễn Gia Phong <mcsinyx@disroot.org> 2020-05-24 16:34:31 +0700
commit: b2d80610db6beda38573890ed169815e495bc663 (patch)
tree: 176e1bca6fe644c619d53cf1c24682c244b79cf6 /usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles
parent: 49376ab97c7427f1c1eca64072d1a934c2e52f50 (diff)
download: cp-b2d80610db6beda38573890ed169815e495bc663.tar.gz
37 files changed, 4355 insertions, 0 deletions
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/1 - Lesson Overview - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/1 - Lesson Overview - lang_en_vs4.srt
new file mode 100644
index 0000000..3cc0326
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/1 - Lesson Overview - lang_en_vs4.srt
@@ -0,0 +1,35 @@
+1
+00:00:00,460 --> 00:00:03,770
+Hi. In the last lesson we discussed
+
+2
+00:00:03,770 --> 00:00:08,370
+requirements engineering. This lesson is about object orientation
+
+3
+00:00:08,370 --> 00:00:11,958
+and other related concepts. The lesson is split
+
+4
+00:00:11,958 --> 00:00:14,720
+in two main parts. In the first part,
+
+5
+00:00:14,720 --> 00:00:16,870
+we will provide a quick introduction to
+
+6
+00:00:16,870 --> 00:00:20,890
+object orientation and object oriented analysis and design.
+
+7
+00:00:20,890 --> 00:00:22,750
+In the second part, we will cover the
+
+8
+00:00:22,750 --> 00:00:25,710
+essential of UML, which is the notation that
+
+9
+00:00:25,710 --> 00:00:29,190
+we will use in the rest of the course and also in our projects.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/10 - Modeling Classes Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/10 - Modeling Classes Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..4dd6994
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/10 - Modeling Classes Quiz Solution - lang_en_vs4.srt
@@ -0,0 +1,47 @@
+1
+00:00:00,120 --> 00:00:03,110
+Looking at the requirements, item is definitely a relevant element
+
+2
+00:00:03,110 --> 00:00:07,060
+for my system, so it is appropriate to model item as
+
+3
+00:00:07,060 --> 00:00:09,300
+a class. Sale, on the other hand, is more of
+
+4
+00:00:09,300 --> 00:00:12,610
+a characteristic of an item, an attribute of an item, rather
+
+5
+00:00:12,610 --> 00:00:14,960
+than a class in itself. So, we're not going to mark
+
+6
+00:00:14,960 --> 00:00:18,460
+this one. Shopping cart sounds, as well, as an important element
+
+7
+00:00:18,460 --> 00:00:21,550
+for my system. Time can be an important system in some
+
+8
+00:00:21,550 --> 00:00:25,420
+contexts, but in this case we're measuring time just because more
+
+9
+00:00:25,420 --> 00:00:28,430
+than one item at a time can be added to the shopping cart.
+
+10
+00:00:28,430 --> 00:00:32,770
+So, time really doesn't have any reason for being modeled as a class.
+
+11
+00:00:32,770 --> 00:00:36,550
+And finally, user also seems to also have an important role to play
+
+12
+00:00:36,550 --> 00:00:40,260
+in the system, and therefore we will model user as a class as well.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/11 - Running Example Explanation - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/11 - Running Example Explanation - lang_en_vs5.srt
new file mode 100644
index 0000000..6d86101
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/11 - Running Example Explanation - lang_en_vs5.srt
@@ -0,0 +1,115 @@
+1
+00:00:00,100 --> 00:00:02,700
+This concludes the first part of this lesson in which
+
+2
+00:00:02,700 --> 00:00:06,080
+we discussed the basic object-oriented concepts. And, we started to
+
+3
+00:00:06,080 --> 00:00:09,830
+look at how to perform object-oriented analysis. In the second
+
+4
+00:00:09,830 --> 00:00:12,630
+part of the lesson, I will introduce UML, and we will
+
+5
+00:00:12,630 --> 00:00:15,990
+perform the object-oriented analysis steps that we just saw using
+
+6
+00:00:15,990 --> 00:00:19,240
+an example. A course management system so before getting to
+
+7
+00:00:19,240 --> 00:00:22,380
+the second part, let me introduce the example. As we
+
+8
+00:00:22,380 --> 00:00:25,420
+mentioned before, the first step is to start from a textual
+
+9
+00:00:25,420 --> 00:00:27,800
+description of the system the we need to analyze and
+
+10
+00:00:27,800 --> 00:00:30,080
+that we need to build. So that's exactly what I'm going
+
+11
+00:00:30,080 --> 00:00:33,272
+to do. I'm just going to read through this description then we'll
+
+12
+00:00:33,272 --> 00:00:36,590
+reuse throughout the rest of the lesson. The registration manager sets
+
+13
+00:00:36,590 --> 00:00:40,090
+up the curriculum for a semester using a scheduling algorithm and
+
+14
+00:00:40,090 --> 00:00:43,600
+the registration manager here is the registrar. So we will refer
+
+15
+00:00:43,600 --> 00:00:47,510
+to the registration manager both as registration manager and as registrar
+
+16
+00:00:47,510 --> 00:00:50,500
+in the rest of the lesson. One course may have multiple
+
+17
+00:00:50,500 --> 00:00:52,860
+course offerings, which is pretty standard. Each
+
+18
+00:00:52,860 --> 00:00:55,490
+course offering has a number, location, and a
+
+19
+00:00:55,490 --> 00:00:59,160
+time associated with it. Students select four primary
+
+20
+00:00:59,160 --> 00:01:02,410
+courses and two alternative courses by submitting a
+
+21
+00:01:02,410 --> 00:01:05,860
+registration form. Students might use the course management
+
+22
+00:01:05,860 --> 00:01:08,460
+system to add or drop courses for a
+
+23
+00:01:08,460 --> 00:01:11,660
+period of time after registration. Professors use the
+
+24
+00:01:11,660 --> 00:01:15,250
+system to receive their course offering rosters. Finally,
+
+25
+00:01:15,250 --> 00:01:19,280
+users of the registration system are assigned passwords which are used for
+
+26
+00:01:19,280 --> 00:01:21,882
+login validation. So, as you can see, this is a kind of a
+
+27
+00:01:21,882 --> 00:01:25,440
+high-level description of a standard course management system. So, if you ever
+
+28
+00:01:25,440 --> 00:01:27,160
+used a course management system, you'll
+
+29
+00:01:27,160 --> 00:01:29,836
+recognize some of the functionality described here.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/12 - UML Structural Diagrams:  Class Diagram - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/12 - UML Structural Diagrams:  Class Diagram - lang_en_vs4.srt
new file mode 100644
index 0000000..b2c9579
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/12 - UML Structural Diagrams:  Class Diagram - lang_en_vs4.srt
@@ -0,0 +1,47 @@
+1
+00:00:00,200 --> 00:00:04,410
+Let's now start talking about UML, the Unified Modeling Language.
+
+2
+00:00:04,410 --> 00:00:06,530
+And we are going to start by looking at UML
+
+3
+00:00:06,530 --> 00:00:11,390
+structural diagrams. This are the diagrams that represent static characteristics
+
+4
+00:00:11,390 --> 00:00:13,430
+of the system that we need to model. This is
+
+5
+00:00:13,430 --> 00:00:17,170
+in contrast with dynamic models which instead behaviors of the
+
+6
+00:00:17,170 --> 00:00:19,200
+system that we need to model. And we will also
+
+7
+00:00:19,200 --> 00:00:22,424
+discuss dynamic models, later on in the lesson. We're going
+
+8
+00:00:22,424 --> 00:00:25,670
+to discuss several kinds of diagrams, starting from the class
+
+9
+00:00:25,670 --> 00:00:28,228
+diagram, which is a fundamental one in UML.
+
+10
+00:00:28,228 --> 00:00:31,390
+The class diagram represents a static, structural view of
+
+11
+00:00:31,390 --> 00:00:34,190
+the system, and it describes the classes and their
+
+12
+00:00:34,190 --> 00:00:37,630
+structure, and the relationships among classes in the system.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/13 - Class Diagram: Class - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/13 - Class Diagram: Class - lang_en_vs5.srt
new file mode 100644
index 0000000..b02e6ea
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/13 - Class Diagram: Class - lang_en_vs5.srt
@@ -0,0 +1,259 @@
+1
+00:00:00,120 --> 00:00:02,370
+So how do we represent a class in a class
+
+2
+00:00:02,370 --> 00:00:06,140
+diagram? Class is represented as a rectangle with three parts. The
+
+3
+00:00:06,140 --> 00:00:09,290
+first part is the class name. Classes should be named using
+
+4
+00:00:09,290 --> 00:00:12,160
+the vocabulary of the domain, so we should pick names that
+
+5
+00:00:12,160 --> 00:00:16,059
+make sense. And the normal naming standard requires that the classes
+
+6
+00:00:16,059 --> 00:00:19,720
+are singular nouns starting with a capital letter. The second part
+
+7
+00:00:19,720 --> 00:00:22,840
+of the class are the attributes of the class, where the
+
+8
+00:00:22,840 --> 00:00:25,310
+set of attribute for the class, we find the state for
+
+9
+00:00:25,310 --> 00:00:27,940
+the class. And, we can list an attribute simply by
+
+10
+00:00:27,940 --> 00:00:31,060
+name, or we can provide the additional information. For example,
+
+11
+00:00:31,060 --> 00:00:33,520
+we might define the title of the attribute, and we
+
+12
+00:00:33,520 --> 00:00:37,450
+might also define the initial. Value for the attribute. Finally, the
+
+13
+00:00:37,450 --> 00:00:40,850
+third part of the class consist of the operations of
+
+14
+00:00:40,850 --> 00:00:44,050
+the class. And normally, the operations of the class are represented
+
+15
+00:00:44,050 --> 00:00:47,090
+by name, with a list of arguments. That the operation
+
+16
+00:00:47,090 --> 00:00:50,340
+will take as input, and with a result type. So the
+
+17
+00:00:50,340 --> 00:00:53,750
+type of the result produced by the operation. Something
+
+18
+00:00:53,750 --> 00:00:55,940
+else you can notice in this representation is the
+
+19
+00:00:55,940 --> 00:00:58,450
+fact that there is a minus before these attributes
+
+20
+00:00:58,450 --> 00:01:01,810
+and a plus before this operation. This indicates what is
+
+21
+00:01:01,810 --> 00:01:04,739
+called the visibility of these class members. So the
+
+22
+00:01:04,739 --> 00:01:08,950
+minus indicates that the attributes are private to the class.
+
+23
+00:01:08,950 --> 00:01:12,600
+So only instances of this class, roughly speaking, can
+
+24
+00:01:12,600 --> 00:01:15,340
+access these attributes. And notice that this is what allows
+
+25
+00:01:15,340 --> 00:01:19,030
+to enforce the information hiding principle, because clients of
+
+26
+00:01:19,030 --> 00:01:22,000
+the class cannot see what's inside this box, what are
+
+27
+00:01:22,000 --> 00:01:25,360
+these attributes. The plus conversely indicates that this is a
+
+28
+00:01:25,360 --> 00:01:28,850
+public operation. So something that is visible outside the class.
+
+29
+00:01:28,850 --> 00:01:30,790
+And, in fact, normally, this is what we use to
+
+30
+00:01:30,790 --> 00:01:35,110
+define the interface for my class. So we encapsulate the
+
+31
+00:01:35,110 --> 00:01:37,730
+state of the class and we make it accessible to
+
+32
+00:01:37,730 --> 00:01:40,370
+the extent that we want and that is needed through
+
+33
+00:01:40,370 --> 00:01:43,850
+a set of public operations. Last thing I want to
+
+34
+00:01:43,850 --> 00:01:46,730
+note is the use of these ellipses that we can
+
+35
+00:01:46,730 --> 00:01:49,520
+utilize if we want to indicate that there are more
+
+36
+00:01:49,520 --> 00:01:52,400
+attributes for example, or more operations. But we just don't
+
+37
+00:01:52,400 --> 00:01:55,160
+want to list them now. Okay now that we know what
+
+38
+00:01:55,160 --> 00:01:58,020
+a class is, and how it is represented, let's start
+
+39
+00:01:58,020 --> 00:02:02,150
+our analysis of our course management system. By identifying the
+
+40
+00:02:02,150 --> 00:02:05,530
+relevant classes in the system, we need to bring back the
+
+41
+00:02:05,530 --> 00:02:08,270
+description of our system. And what we want to
+
+42
+00:02:08,270 --> 00:02:10,389
+do, is that we want to go through the description
+
+43
+00:02:10,389 --> 00:02:14,840
+and underline the relevant nouns in the description. And here
+
+44
+00:02:14,840 --> 00:02:17,020
+I encourage you to stop the video and to do
+
+45
+00:02:17,020 --> 00:02:20,450
+the exercise of underlying such nouns yourself before listening to
+
+46
+00:02:20,450 --> 00:02:23,910
+my explanation into how I do it. For example in
+
+47
+00:02:23,910 --> 00:02:28,030
+this case I might want to underlined the registration manager which
+
+48
+00:02:28,030 --> 00:02:30,820
+is a noun and probably a relevant one. The scheduling
+
+49
+00:02:30,820 --> 00:02:33,800
+algorithm, also seems like a relevant concept, so
+
+50
+00:02:33,800 --> 00:02:37,890
+is the course. The course offerings, again, course offerings
+
+51
+00:02:37,890 --> 00:02:40,930
+over here. Definitely, the students seem to be a
+
+52
+00:02:40,930 --> 00:02:44,750
+relevant noun and so is probably the registration form
+
+53
+00:02:44,750 --> 00:02:47,140
+and the professors. Okay, so, at this point, I
+
+54
+00:02:47,140 --> 00:02:50,630
+identified seven possible classes for my system. So, what
+
+55
+00:02:50,630 --> 00:02:53,340
+I'm going to do is simply to create classes for
+
+56
+00:02:53,340 --> 00:02:55,980
+each one of these nouns. So my initial class
+
+57
+00:02:55,980 --> 00:03:00,100
+diagram looks exactly like this, with the seven classes where
+
+58
+00:03:00,100 --> 00:03:03,140
+for each class, I picked the name that is representative of
+
+59
+00:03:03,140 --> 00:03:05,680
+the domain. So, in this case, it's pretty straightforward. The
+
+60
+00:03:05,680 --> 00:03:08,950
+registration form is called registration form, the student is called student
+
+61
+00:03:08,950 --> 00:03:10,780
+and so on and so forth. But you can already
+
+62
+00:03:10,780 --> 00:03:14,490
+see how this analysis method is starting from a description of
+
+63
+00:03:14,490 --> 00:03:17,950
+the real world and it's just identifying objects or classes
+
+64
+00:03:17,950 --> 00:03:21,240
+in the real world and transforming them into entities in my
+
+65
+00:03:21,240 --> 00:03:22,260
+analysis document.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/14 - Class Diagram: Attributes - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/14 - Class Diagram: Attributes - lang_en_vs5.srt
new file mode 100644
index 0000000..e1230c9
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/14 - Class Diagram: Attributes - lang_en_vs5.srt
@@ -0,0 +1,135 @@
+1
+00:00:00,090 --> 00:00:02,435
+Now that we identify the classes in my system,
+
+2
+00:00:02,435 --> 00:00:04,930
+let's see how we can identify the attributes for
+
+3
+00:00:04,930 --> 00:00:08,680
+these classes. First of all let's recall what attributes
+
+4
+00:00:08,680 --> 00:00:12,355
+are. Attributes represent the structure of a class the individual
+
+5
+00:00:12,355 --> 00:00:15,530
+data items that compose the state of the class.
+
+6
+00:00:15,530 --> 00:00:18,530
+So how do we identify these attributes? Attributes may be
+
+7
+00:00:18,530 --> 00:00:21,070
+found in one of three ways. By examining class
+
+8
+00:00:21,070 --> 00:00:25,330
+definitions, by studying the requirements, and by applying domain knowledge.
+
+9
+00:00:25,330 --> 00:00:28,400
+And notice that I want to stress, that this is always
+
+10
+00:00:28,400 --> 00:00:31,800
+a very important aspect. No matter what kind of system you're
+
+11
+00:00:31,800 --> 00:00:35,670
+developing. Domain knowledge tends to be fairly important to identify things
+
+12
+00:00:35,670 --> 00:00:38,200
+Which might not be provided in the descriptions of the system
+
+13
+00:00:38,200 --> 00:00:41,070
+that tend to be incomplete. And that you can derive by
+
+14
+00:00:41,070 --> 00:00:44,390
+the fact that you are familiar with the domain. So always
+
+15
+00:00:44,390 --> 00:00:47,340
+keep in mind the domain knowledge is important for analysis, for
+
+16
+00:00:47,340 --> 00:00:50,430
+design, for requirements gathering and so on. So now let's go
+
+17
+00:00:50,430 --> 00:00:53,530
+back to our description of the system. As I said,
+
+18
+00:00:53,530 --> 00:00:55,450
+I will bring you back for each step of our
+
+19
+00:00:55,450 --> 00:00:58,200
+analysis. And in this case, we're going to focus on
+
+20
+00:00:58,200 --> 00:01:01,550
+course offering. And we can say that the course offering, according
+
+21
+00:01:01,550 --> 00:01:04,610
+to the description, has a number, a location, and a
+
+22
+00:01:04,610 --> 00:01:08,140
+time. So this is a pretty clear indication that these are
+
+23
+00:01:08,140 --> 00:01:11,650
+important aspects of the course offering. So they probably should
+
+24
+00:01:11,650 --> 00:01:15,600
+become attributes of the course offering class. So now if we
+
+25
+00:01:15,600 --> 00:01:19,400
+report here that sentence, and once more, we underline
+
+26
+00:01:19,400 --> 00:01:22,330
+the information that we underlined in the description. We can
+
+27
+00:01:22,330 --> 00:01:25,540
+clearly see how this can be mapped into the definition
+
+28
+00:01:25,540 --> 00:01:28,730
+of the class. So our class course offering after this
+
+29
+00:01:28,730 --> 00:01:32,900
+step the analysis will have 3 attributes: number, location, and
+
+30
+00:01:32,900 --> 00:01:35,270
+time. And as you can see here, I'm not specifying
+
+31
+00:01:35,270 --> 00:01:37,540
+the type or any other additional information. So in this
+
+32
+00:01:37,540 --> 00:01:40,640
+first step I'm just interested in having a first draft.
+
+33
+00:01:40,640 --> 00:01:42,170
+of the class diagram, that I can then
+
+34
+00:01:42,170 --> 00:01:44,440
+refine in the next iterations of my analysis.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/15 - Class Diagram: Operations - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/15 - Class Diagram: Operations - lang_en_vs5.srt
new file mode 100644
index 0000000..8943fca
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/15 - Class Diagram: Operations - lang_en_vs5.srt
@@ -0,0 +1,111 @@
+1
+00:00:00,110 --> 00:00:02,920
+At this point we have our classes, our attributes,
+
+2
+00:00:02,920 --> 00:00:05,740
+what we're missing is the operations for the class.
+
+3
+00:00:05,740 --> 00:00:08,340
+Let me remind you that operations represent the behavior
+
+4
+00:00:08,340 --> 00:00:10,370
+of a class, and that they may be found by
+
+5
+00:00:10,370 --> 00:00:14,310
+examining interactions among entities in the description of my
+
+6
+00:00:14,310 --> 00:00:18,480
+system. So once more, let's bring back our description, and
+
+7
+00:00:18,480 --> 00:00:22,090
+let's in this case focus on this specific item.
+
+8
+00:00:22,090 --> 00:00:25,330
+That says that the students may use the system to
+
+9
+00:00:25,330 --> 00:00:29,800
+add courses. So this is clearly indicating an action
+
+10
+00:00:29,800 --> 00:00:32,320
+that the students should be able to perform. But notice
+
+11
+00:00:32,320 --> 00:00:35,100
+that this doesn't mean that this is an operation that
+
+12
+00:00:35,100 --> 00:00:38,370
+should be provided by the student's class. It rather means
+
+13
+00:00:38,370 --> 00:00:41,860
+that there should be, somewhere in the system, the possibility
+
+14
+00:00:41,860 --> 00:00:45,080
+of performing this operation. So let's see what this means
+
+15
+00:00:45,080 --> 00:00:47,920
+for our example. This might mean, for example, if we
+
+16
+00:00:47,920 --> 00:00:50,400
+focus on the RegistrationManager, so that there should be an
+
+17
+00:00:50,400 --> 00:00:53,520
+operation in the RegistrationManager that allows me to add
+
+18
+00:00:53,520 --> 00:00:56,300
+a student to a course. And this, in turn, means
+
+19
+00:00:56,300 --> 00:01:00,270
+that both Course and CourseOffering should provide a way to
+
+20
+00:01:00,270 --> 00:01:04,140
+add a student. And therefore, I add this corresponding operation
+
+21
+00:01:04,140 --> 00:01:07,790
+to the RegistrationManager, to the Course, and to the CourseOffering.
+
+22
+00:01:07,790 --> 00:01:10,020
+So after doing that we will continue and populate in
+
+23
+00:01:10,020 --> 00:01:13,080
+a similar way, the other classes in the system. So
+
+24
+00:01:13,080 --> 00:01:16,040
+let me recap. Now we saw how to identify classes.
+
+25
+00:01:16,040 --> 00:01:18,300
+How to identify members of the classes, and
+
+26
+00:01:18,300 --> 00:01:21,910
+particular attributes, and operations. There is one thing that
+
+27
+00:01:21,910 --> 00:01:24,060
+we're missing, a very important aspect of the
+
+28
+00:01:24,060 --> 00:01:28,140
+class diagram which is the relationships between these classes.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/16 - Class Diagram: Relationships - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/16 - Class Diagram: Relationships - lang_en_vs5.srt
new file mode 100644
index 0000000..ef6550d
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/16 - Class Diagram: Relationships - lang_en_vs5.srt
@@ -0,0 +1,111 @@
+1
+00:00:00,130 --> 00:00:02,620
+And that's exactly what we're going to look at next,
+
+2
+00:00:02,620 --> 00:00:05,630
+relationships in the class diagram, how they're represented and
+
+3
+00:00:05,630 --> 00:00:08,010
+what they mean. First of all relationships as the
+
+4
+00:00:08,010 --> 00:00:12,550
+name says, describe interactions between classes or between objects in
+
+5
+00:00:12,550 --> 00:00:15,510
+my system. And we will describe three main types
+
+6
+00:00:15,510 --> 00:00:19,060
+of relationships. The first one is called a Dependency
+
+7
+00:00:19,060 --> 00:00:22,450
+relationship. And we can express that as X uses
+
+8
+00:00:22,450 --> 00:00:25,840
+Y and we represent it with a dashed directed line.
+
+9
+00:00:25,840 --> 00:00:28,170
+So when we have such a line between two classes
+
+10
+00:00:28,170 --> 00:00:31,020
+that means that the first class uses the second one. And
+
+11
+00:00:31,020 --> 00:00:33,520
+we're going to provide an example of a dependency in a
+
+12
+00:00:33,520 --> 00:00:37,960
+minute. The second type of relationship is an association that can
+
+13
+00:00:37,960 --> 00:00:40,880
+also be an aggregation. We'll see what the distinction is.
+
+14
+00:00:40,880 --> 00:00:43,470
+But basically, what this means is that we can express that
+
+15
+00:00:43,470 --> 00:00:47,640
+as a X has a y. So x contains a
+
+16
+00:00:47,640 --> 00:00:50,950
+y. And if it is in association, we indicate it with
+
+17
+00:00:50,950 --> 00:00:53,570
+a solid undirected line. If it's an aggregation,
+
+18
+00:00:53,570 --> 00:00:55,740
+we indicate it in the same way, but with
+
+19
+00:00:55,740 --> 00:00:58,510
+a diamond at one of the ends. Finally, the
+
+20
+00:00:58,510 --> 00:01:02,740
+third type of relationship is what is called Generalization.
+
+21
+00:01:02,740 --> 00:01:05,300
+And this can be expressed as x is a
+
+22
+00:01:05,300 --> 00:01:09,620
+y. So this is the relationship that expresses inheritance.
+
+23
+00:01:09,620 --> 00:01:13,600
+Specialization between two classes. It's represented with a solid
+
+24
+00:01:13,600 --> 00:01:16,190
+directed line with a large open arrow head at
+
+25
+00:01:16,190 --> 00:01:19,030
+the end. Going from the more specialized class to
+
+26
+00:01:19,030 --> 00:01:21,770
+the less specialized class. So going from the subclass to
+
+27
+00:01:21,770 --> 00:01:24,740
+the super class. So now let's look at each relationship
+
+28
+00:01:24,740 --> 00:01:28,360
+in more detail using our example, our course management system.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/17 - Class Diagram Relationships Quiz - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/17 - Class Diagram Relationships Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..90ffe63
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/17 - Class Diagram Relationships Quiz - lang_en_vs4.srt
@@ -0,0 +1,55 @@
+1
+00:00:00,200 --> 00:00:02,840
+Before doing that, though, now that we discuss the different kinds
+
+2
+00:00:02,840 --> 00:00:05,510
+of relationships among classes in the class diagram. I would like
+
+3
+00:00:05,510 --> 00:00:08,230
+to ask you to look at a list of relationships that
+
+4
+00:00:08,230 --> 00:00:11,920
+I'm providing here and mark the relationships that you think actually
+
+5
+00:00:11,920 --> 00:00:15,120
+hold for the classes in the system that we are modeling.
+
+6
+00:00:15,120 --> 00:00:18,260
+So here I have a list of possible relationships for each
+
+7
+00:00:18,260 --> 00:00:22,070
+relationship. I'm first defining what the relationship is and then what
+
+8
+00:00:22,070 --> 00:00:25,270
+kind of relationship that is, for example, for the first one I'm
+
+9
+00:00:25,270 --> 00:00:27,500
+saying that the registration manager uses
+
+10
+00:00:27,500 --> 00:00:30,090
+the scheduling algorithm, which is a dependency
+
+11
+00:00:30,090 --> 00:00:33,860
+relationship. And similarly for the other ones. So like for you to go back
+
+12
+00:00:33,860 --> 00:00:37,070
+to the example, look at the classes that we defined, think about the
+
+13
+00:00:37,070 --> 00:00:40,360
+requirements, and identify which ones of this
+
+14
+00:00:40,360 --> 00:00:42,610
+relationships you think hold in the system.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/18 - Class Diagram Relationships Quiz Solution - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/18 - Class Diagram Relationships Quiz Solution - lang_en_vs5.srt
new file mode 100644
index 0000000..ca674bf
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/18 - Class Diagram Relationships Quiz Solution - lang_en_vs5.srt
@@ -0,0 +1,23 @@
+1
+00:00:00,130 --> 00:00:02,130
+So, I'm going to start by marking the
+
+2
+00:00:02,130 --> 00:00:04,920
+relationships that actually hold in the system.
+
+3
+00:00:04,920 --> 00:00:08,860
+Which are these ones. And then what I'm going to do, I'm going to explain this
+
+4
+00:00:08,860 --> 00:00:12,480
+answers. Not here but in the next part of this lesson. By looking at the
+
+5
+00:00:12,480 --> 00:00:14,860
+different relationships in the context of our
+
+6
+00:00:14,860 --> 00:00:17,240
+example. Which will make the explanation much clearer.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/19 - Class Diagram: Dependency Relationship - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/19 - Class Diagram: Dependency Relationship - lang_en_vs4.srt
new file mode 100644
index 0000000..54c7da3
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/19 - Class Diagram: Dependency Relationship - lang_en_vs4.srt
@@ -0,0 +1,71 @@
+1
+00:00:00,110 --> 00:00:03,040
+So let's start with the dependency example. A dependency,
+
+2
+00:00:03,040 --> 00:00:06,720
+as we said, expresses the relationship between a supplier
+
+3
+00:00:06,720 --> 00:00:09,290
+and a client that relies on it. There is
+
+4
+00:00:09,290 --> 00:00:12,490
+a dependency because changes in the supplier can affect the
+
+5
+00:00:12,490 --> 00:00:14,770
+client. Here in this example I am showing that
+
+6
+00:00:14,770 --> 00:00:18,510
+a dependency example involving the registration manager and the
+
+7
+00:00:18,510 --> 00:00:21,590
+scheduling algorithm. As you can see the, the dependency
+
+8
+00:00:21,590 --> 00:00:25,710
+is indicated with a dashed line pointing from the client
+
+9
+00:00:25,710 --> 00:00:28,520
+to the supplier. And here it's pretty clear why
+
+10
+00:00:28,520 --> 00:00:31,820
+the RegistrationManager is dependent on the Scheduling Algorithm. It's
+
+11
+00:00:31,820 --> 00:00:35,710
+because the RegistrationManager uses this Scheduling Algorithm. And therefore,
+
+12
+00:00:35,710 --> 00:00:39,130
+if the Scheduling Algorithm changes, the RegistrationManager might be
+
+13
+00:00:39,130 --> 00:00:42,210
+affected by that change. Another less obvious example is
+
+14
+00:00:42,210 --> 00:00:45,600
+the dependency between the Registration Manager and the Student.
+
+15
+00:00:45,600 --> 00:00:48,040
+In this case, because the Registration Manager gets a
+
+16
+00:00:48,040 --> 00:00:51,620
+Student object as a parameter here there is a dependency
+
+17
+00:00:51,620 --> 00:00:55,740
+between the two. Again, if the Student class were to change the Registration
+
+18
+00:00:55,740 --> 00:01:00,270
+Manager might be affected because it's relying on the Student for it's behavior.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/2 - Object Orientation Introduction - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/2 - Object Orientation Introduction - lang_en_vs5.srt
new file mode 100644
index 0000000..44fdd74
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/2 - Object Orientation Introduction - lang_en_vs5.srt
@@ -0,0 +1,187 @@
+1
+00:00:00,390 --> 00:00:03,750
+Let's start with a quick introduction to object orientation and
+
+2
+00:00:03,750 --> 00:00:07,920
+the fundamental concepts behind it. And let's start by discussing what
+
+3
+00:00:07,920 --> 00:00:11,100
+exactly is object orientation? If you're younger than me, it
+
+4
+00:00:11,100 --> 00:00:13,700
+could be that the first programming language you learned was already
+
+5
+00:00:13,700 --> 00:00:17,030
+an object-oriented language. But things were not always like this.
+
+6
+00:00:17,030 --> 00:00:20,660
+Before object orientation became prevalent, people were not used to thinking
+
+7
+00:00:20,660 --> 00:00:23,447
+in terms of objects. So what happened afterwards? And what does
+
+8
+00:00:23,447 --> 00:00:25,727
+it mean to think in terms of objects and to follow
+
+9
+00:00:25,727 --> 00:00:28,583
+an object-oriented approach? First of all, it
+
+10
+00:00:28,583 --> 00:00:32,203
+means to give precedence of data over function.
+
+11
+00:00:32,203 --> 00:00:35,377
+Did items rather than functionality become the center
+
+12
+00:00:35,377 --> 00:00:39,020
+of development activities. This also allows for enforcing
+
+13
+00:00:39,020 --> 00:00:42,200
+the very important concept of information hiding,
+
+14
+00:00:42,200 --> 00:00:45,460
+which is the encapsulation and segregation of data
+
+15
+00:00:45,460 --> 00:00:49,710
+behind well-defined and ideally stable interfaces. In order
+
+16
+00:00:49,710 --> 00:00:51,490
+to be able to hide the design and
+
+17
+00:00:51,490 --> 00:00:54,130
+also implementation decisions. And note that the terms
+
+18
+00:00:54,130 --> 00:00:58,580
+encapsulation and information hiding are often used interchangeably, although
+
+19
+00:00:58,580 --> 00:01:01,270
+some people prefer to think of information hiding
+
+20
+00:01:01,270 --> 00:01:04,709
+as being the principle and encapsulation being the technique
+
+21
+00:01:04,709 --> 00:01:07,990
+to achieve information hiding. The key concept though,
+
+22
+00:01:07,990 --> 00:01:10,110
+no matter which term you use, is really to
+
+23
+00:01:10,110 --> 00:01:13,460
+gather, to seclude this data behind sort of
+
+24
+00:01:13,460 --> 00:01:16,610
+a wall and give access to the data only
+
+25
+00:01:16,610 --> 00:01:20,270
+through interfaces that you, the developer define. And why is
+
+26
+00:01:20,270 --> 00:01:22,800
+that important? Oh, for many reasons, and one of the main
+
+27
+00:01:22,800 --> 00:01:26,690
+ones is that it makes code more maintainable. Because the
+
+28
+00:01:26,690 --> 00:01:28,860
+rest of the code, the rest of the system doesn't have
+
+29
+00:01:28,860 --> 00:01:32,370
+to be concerned on how the implementation details or the
+
+30
+00:01:32,370 --> 00:01:37,220
+design are defined. And therefore, any change that happens behind this
+
+31
+00:01:37,220 --> 00:01:39,580
+wall doesn't concern the rest of the system. And, doesn't
+
+32
+00:01:39,580 --> 00:01:41,820
+affect the rest of the system, as long as you keep
+
+33
+00:01:41,820 --> 00:01:45,730
+your interfaces consistent. Another advantage of focusing on
+
+34
+00:01:45,730 --> 00:01:49,230
+objects and encapsulating the information into cohesive entities is
+
+35
+00:01:49,230 --> 00:01:52,130
+that it allows the reuse of object definitions
+
+36
+00:01:52,130 --> 00:01:55,000
+by incremental refinement. Which is what we normally call
+
+37
+00:01:55,000 --> 00:01:58,830
+inheritance. And inheritance is definitely a fundamental concept
+
+38
+00:01:58,830 --> 00:02:01,560
+in object orientation. For example, we can define a
+
+39
+00:02:01,560 --> 00:02:04,030
+car as a refinement of the vehicle. That there's
+
+40
+00:02:04,030 --> 00:02:06,850
+some additional characteristics with respect to a generic vehicle.
+
+41
+00:02:06,850 --> 00:02:11,220
+And then we can use the car wherever a vehicle can be used, which is what we
+
+42
+00:02:11,220 --> 00:02:14,200
+call polymorphism. And we'll continue this discussion for a
+
+43
+00:02:14,200 --> 00:02:16,440
+very long time. Because there's so many things that
+
+44
+00:02:16,440 --> 00:02:18,860
+could be discussed when we talk about object orientation,
+
+45
+00:02:18,860 --> 00:02:21,890
+its characteristics and its advantages. But in the interest
+
+46
+00:02:21,890 --> 00:02:24,000
+of time, let's for now just stop here. And
+
+47
+00:02:24,000 --> 00:02:27,020
+start talking about two key concepts in object orientation.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/20 - Class Diagram: Association & Aggregation Relationships - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/20 - Class Diagram: Association & Aggregation Relationships - lang_en_vs5.srt
new file mode 100644
index 0000000..8770928
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/20 - Class Diagram: Association & Aggregation Relationships - lang_en_vs5.srt
@@ -0,0 +1,219 @@
+1
+00:00:00,080 --> 00:00:02,469
+The next example of relationship we're going to look at is
+
+2
+00:00:02,469 --> 00:00:06,740
+the association relationship. This is a relationship in which objects of
+
+3
+00:00:06,740 --> 00:00:09,570
+one class are connected to objects of another. And it's
+
+4
+00:00:09,570 --> 00:00:12,480
+called an has a relationship. So it means that objects of
+
+5
+00:00:12,480 --> 00:00:15,930
+one class have objects of another class. So let's see
+
+6
+00:00:15,930 --> 00:00:18,750
+what that means. Let's do it by considering two classes in
+
+7
+00:00:18,750 --> 00:00:22,370
+our example system. The student class and the course offering class.
+
+8
+00:00:22,370 --> 00:00:25,300
+In this case, there is an association between the student and
+
+9
+00:00:25,300 --> 00:00:28,010
+the course offering, because the student is registering for the
+
+10
+00:00:28,010 --> 00:00:31,750
+course offering. So, in a sense, the course offering has students.
+
+11
+00:00:31,750 --> 00:00:35,360
+Contains students, to indicate this fact we add a solid
+
+12
+00:00:35,360 --> 00:00:38,750
+line between the student class and the course offering. And the
+
+13
+00:00:38,750 --> 00:00:40,540
+fact that having a solid line doesn't really tell us
+
+14
+00:00:40,540 --> 00:00:44,780
+much about the nature of the relationship, so to clarify such
+
+15
+00:00:44,780 --> 00:00:47,550
+nature we can use what we call adornments that we
+
+16
+00:00:47,550 --> 00:00:51,010
+can apply to associations we can add to associations to clarify
+
+17
+00:00:51,010 --> 00:00:53,850
+their meaning. In particular we can add a label to
+
+18
+00:00:53,850 --> 00:00:57,550
+an association and the label describes the nature of the relationship.
+
+19
+00:00:57,550 --> 00:01:00,440
+In this case, for example, it clarifies that the student
+
+20
+00:01:00,440 --> 00:01:03,970
+registers for CourseOffering. We can also add a triangle to
+
+21
+00:01:03,970 --> 00:01:07,050
+further clarify the direction of the relationship. So in this
+
+22
+00:01:07,050 --> 00:01:10,240
+case, the triangle will indicate that it's the student That registers
+
+23
+00:01:10,240 --> 00:01:13,120
+for the course offering, and not the other way around. Another
+
+24
+00:01:13,120 --> 00:01:16,650
+important adornment or limitation that we can put on an association,
+
+25
+00:01:16,650 --> 00:01:20,800
+is multiplicity. Multiplicity defines the number of instances of one
+
+26
+00:01:20,800 --> 00:01:23,540
+class that are related to one instance of the other
+
+27
+00:01:23,540 --> 00:01:26,900
+class. We can define multiplicity at either end of the
+
+28
+00:01:26,900 --> 00:01:29,620
+relationship. In this case, for instance, we can say that
+
+29
+00:01:29,620 --> 00:01:31,890
+if we look at the student, the student can register
+
+30
+00:01:31,890 --> 00:01:35,410
+for two or more course offerings. Whereas, if we look
+
+31
+00:01:35,410 --> 00:01:37,560
+at the course offering, we can say that each course
+
+32
+00:01:37,560 --> 00:01:42,260
+offering can have or can enroll between 1 and 50 students.
+
+33
+00:01:42,260 --> 00:01:45,120
+So as you can see by adding a label, a direction,
+
+34
+00:01:45,120 --> 00:01:49,590
+and multiplicity, we make it much clearer what the relationship is
+
+35
+00:01:49,590 --> 00:01:52,170
+and what it means and what are its characteristics. As we
+
+36
+00:01:52,170 --> 00:01:55,130
+saw when we introduced relationships, there is a different kind of
+
+37
+00:01:55,130 --> 00:01:58,860
+association, kind of a specialized one, which we call aggregation. So
+
+38
+00:01:58,860 --> 00:02:01,130
+here we're going to look at an example of an aggregation. So
+
+39
+00:02:01,130 --> 00:02:03,490
+first of all what is an aggregation? An aggregation is a
+
+40
+00:02:03,490 --> 00:02:07,580
+relationship between 2 classes in which 1 represents a larger class
+
+41
+00:02:07,580 --> 00:02:10,610
+like a whole which consists of smaller classes which are
+
+42
+00:02:10,610 --> 00:02:13,430
+the parts of this whole. So lets look at an example
+
+43
+00:02:13,430 --> 00:02:16,960
+in the context of our system. Let's consider a Course
+
+44
+00:02:16,960 --> 00:02:19,160
+and the CourseOffering. And in this case, we can see
+
+45
+00:02:19,160 --> 00:02:23,000
+that the Course consists of multiple CourseOfferings. So in
+
+46
+00:02:23,000 --> 00:02:26,520
+a sense, a course is a whole and the course offerings
+
+47
+00:02:26,520 --> 00:02:29,430
+are the parts of this whole. So this a perfect case
+
+48
+00:02:29,430 --> 00:02:32,620
+in which we will use an aggregation to express this relationship.
+
+49
+00:02:32,620 --> 00:02:37,630
+So we will add a solid line with a diamond on the side of the whole class
+
+50
+00:02:37,630 --> 00:02:42,380
+to indicate that the course consists of multiple course offerings.
+
+51
+00:02:42,380 --> 00:02:44,670
+And as we did for associations even though we
+
+52
+00:02:44,670 --> 00:02:46,010
+are not going to do it for this specific
+
+53
+00:02:46,010 --> 00:02:49,540
+example, we could also in this case add multiplicity
+
+54
+00:02:49,540 --> 00:02:52,830
+information on the aggregation to indicate how many classes
+
+55
+00:02:52,830 --> 00:02:55,310
+of the two types are involved in the relationships.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/21 - Class Diagram: Generalization Relationship - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/21 - Class Diagram: Generalization Relationship - lang_en_vs5.srt
new file mode 100644
index 0000000..513413b
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/21 - Class Diagram: Generalization Relationship - lang_en_vs5.srt
@@ -0,0 +1,75 @@
+1
+00:00:00,100 --> 00:00:02,420
+The third type of relationship that we saw, is
+
+2
+00:00:02,420 --> 00:00:07,060
+Generalization. Generalization is a relationship, between a general class,
+
+3
+00:00:07,060 --> 00:00:10,150
+which we normally call super-class and the more specific
+
+4
+00:00:10,150 --> 00:00:13,510
+class, a class the refines the super-class and that
+
+5
+00:00:13,510 --> 00:00:16,950
+we normally call sub-class. It's also known as a
+
+6
+00:00:16,950 --> 00:00:19,690
+kind of or is a relationship because we can
+
+7
+00:00:19,690 --> 00:00:22,850
+say that the subclass is a super class and
+
+8
+00:00:22,850 --> 00:00:25,450
+it's expressed with a solid line with a big arrow
+
+9
+00:00:25,450 --> 00:00:27,580
+head at the end. So let's see an example of
+
+10
+00:00:27,580 --> 00:00:30,160
+that. In this case I'm going to indicate. Two of this kind
+
+11
+00:00:30,160 --> 00:00:33,950
+of relationships. The first one involving the RegistrationUser and
+
+12
+00:00:33,950 --> 00:00:37,000
+a student. And the second one, a RegistrationUser and the
+
+13
+00:00:37,000 --> 00:00:39,960
+professor. So, basically what we're showing here is a
+
+14
+00:00:39,960 --> 00:00:43,170
+typical case in which the registration user is a more general
+
+15
+00:00:43,170 --> 00:00:46,630
+concept then the Student and the Professor. So both the student
+
+16
+00:00:46,630 --> 00:00:50,710
+and the professor are RegistrationUsers. So there is a relationship,
+
+17
+00:00:50,710 --> 00:00:54,360
+the Professor is a registration user and the Student is a RegistrationUser.
+
+18
+00:00:54,360 --> 00:00:56,780
+And therefore we can indicate that using
+
+19
+00:00:56,780 --> 00:01:00,040
+the generalization relationship in our class diagram.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/22 - Class Diagram: Creation Tips - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/22 - Class Diagram: Creation Tips - lang_en_vs5.srt
new file mode 100644
index 0000000..8aa0204
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/22 - Class Diagram: Creation Tips - lang_en_vs5.srt
@@ -0,0 +1,143 @@
+1
+00:00:00,140 --> 00:00:02,320
+The last thing that I want to mention about class diagrams is
+
+2
+00:00:02,320 --> 00:00:05,830
+some creation tips. So something I know based on my experience and the
+
+3
+00:00:05,830 --> 00:00:09,300
+experience of others, I can recommend to do when creating a class
+
+4
+00:00:09,300 --> 00:00:12,780
+diagram. So the first tip is to understand the problem. So take the
+
+5
+00:00:12,780 --> 00:00:15,070
+time to look at the description of the system that you have
+
+6
+00:00:15,070 --> 00:00:18,500
+to build, to make sure that you understand the domain. That you understand
+
+7
+00:00:18,500 --> 00:00:21,230
+what you are supposed to build. Because that is going to save you
+
+8
+00:00:21,230 --> 00:00:25,550
+time later. It's going to help you identify from the beginning, a more relevant
+
+9
+00:00:25,550 --> 00:00:28,370
+set of entities in the description of the system. This
+
+10
+00:00:28,370 --> 00:00:30,730
+one might seem trivial but is very important to choose
+
+11
+00:00:30,730 --> 00:00:34,910
+good class names. Why? Because class names communicate the intent
+
+12
+00:00:34,910 --> 00:00:37,770
+of the class, and clarify what the class refers to. So
+
+13
+00:00:37,770 --> 00:00:40,510
+having a good class name allows you, makes it easier, to
+
+14
+00:00:40,510 --> 00:00:44,390
+create the mapping between the real-world object and the entities in
+
+15
+00:00:44,390 --> 00:00:46,610
+your model. And of course, it also makes it easier
+
+16
+00:00:46,610 --> 00:00:50,100
+to understand the system, after the system is built. Third tip,
+
+17
+00:00:50,100 --> 00:00:53,480
+concentrate on the what. So here, in the class diagram,
+
+18
+00:00:53,480 --> 00:00:57,390
+we're just representing the structure of the system. We're representing
+
+19
+00:00:57,390 --> 00:01:00,150
+what is in the system. What are the entities? What
+
+20
+00:01:00,150 --> 00:01:03,140
+are the characteristics of the entities? We are not focusing
+
+21
+00:01:03,140 --> 00:01:06,850
+at all, on how things are done. So, be careful.
+
+22
+00:01:06,850 --> 00:01:09,430
+DonÃ¢ÂÂt think about the how, just think about the what.
+
+23
+00:01:09,430 --> 00:01:12,150
+Proceed in an itinerary way. So, start with a simple
+
+24
+00:01:12,150 --> 00:01:14,910
+diagram and refine it. There is no need to identify,
+
+25
+00:01:14,910 --> 00:01:17,650
+right away, all of the details of the system you need to
+
+26
+00:01:17,650 --> 00:01:21,570
+build. It is much easier to look at the description, identify an initial
+
+27
+00:01:21,570 --> 00:01:24,670
+rough class diagram and then refine it, because in this way, you'll
+
+28
+00:01:24,670 --> 00:01:27,650
+also gather more understanding of the system as you build it, and you'll
+
+29
+00:01:27,650 --> 00:01:30,670
+most likely end up with a better product at the end. And
+
+30
+00:01:30,670 --> 00:01:33,360
+if you proceed in this way, then make sure to refine until you
+
+31
+00:01:33,360 --> 00:01:36,920
+feel the class diagram is complete, until you feel that you represent
+
+32
+00:01:36,920 --> 00:01:39,960
+the system that you're supposed to build. So your final goal should be
+
+33
+00:01:39,960 --> 00:01:41,820
+to have a class diagram that is complete.
+
+34
+00:01:41,820 --> 00:01:43,870
+So it represents all of the relevant entities
+
+35
+00:01:43,870 --> 00:01:45,870
+in the system and their characteristics, and it's
+
+36
+00:01:45,870 --> 00:01:48,170
+correct so it represents them in the right way
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/23 - UML Structural Diagrams: Component Diagram - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/23 - UML Structural Diagrams: Component Diagram - lang_en_vs5.srt
new file mode 100644
index 0000000..8ce2080
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/23 - UML Structural Diagrams: Component Diagram - lang_en_vs5.srt
@@ -0,0 +1,235 @@
+1
+00:00:00,100 --> 00:00:02,160
+There's two more structural diagrams that I want to
+
+2
+00:00:02,160 --> 00:00:04,670
+mention before we move to the behavioral ones. The
+
+3
+00:00:04,670 --> 00:00:07,420
+first one's the component diagram. A component diagram is
+
+4
+00:00:07,420 --> 00:00:09,690
+a static view of components in a system and of
+
+5
+00:00:09,690 --> 00:00:13,010
+their relationships. More precisely, a node in a component
+
+6
+00:00:13,010 --> 00:00:16,700
+diagram represents a component where a component consists of one
+
+7
+00:00:16,700 --> 00:00:21,090
+or more classes with a well-defined interface. Edges conversely
+
+8
+00:00:21,090 --> 00:00:25,290
+indicate relationships between the components. You can read this relationship
+
+9
+00:00:25,290 --> 00:00:29,600
+as component A uses services of component B. And notice that the
+
+10
+00:00:29,600 --> 00:00:32,990
+component diagrams can be used to represent an architecture, which is
+
+11
+00:00:32,990 --> 00:00:36,110
+a topic that we will cover extensively in the next mini-course.
+
+12
+00:00:36,110 --> 00:00:39,540
+So let's illustrate this with an example. So, what I'm representing
+
+13
+00:00:39,540 --> 00:00:43,160
+here is a component diagram for our example system, the course
+
+14
+00:00:43,160 --> 00:00:46,220
+management system. And as you can see, it's slightly more complex
+
+15
+00:00:46,220 --> 00:00:48,390
+than the other diagrams that we saw. But there's really no
+
+16
+00:00:48,390 --> 00:00:50,700
+need to go through all the steps and all the details.
+
+17
+00:00:50,700 --> 00:00:53,470
+Important thing is to point out some key aspects of
+
+18
+00:00:53,470 --> 00:00:56,370
+this diagram. So the first one is that these rectangular
+
+19
+00:00:56,370 --> 00:00:58,560
+nodes are the nodes in the system, so are my
+
+20
+00:00:58,560 --> 00:01:02,960
+components. For example, student is a component, schedule is a component,
+
+21
+00:01:02,960 --> 00:01:05,069
+and so on. And as far as edges are concerned,
+
+22
+00:01:05,069 --> 00:01:08,580
+I'm representing two kinds of edges. The first kind of dashed
+
+23
+00:01:08,580 --> 00:01:12,060
+edges which were part of the original uml definition and
+
+24
+00:01:12,060 --> 00:01:16,120
+indicate use. So an edge, for example, between this compnent and
+
+25
+00:01:16,120 --> 00:01:19,570
+this compnent indicated that the seminar management uses the
+
+26
+00:01:19,570 --> 00:01:23,890
+facilities component. More recently, in UML two, a richer representation
+
+27
+00:01:23,890 --> 00:01:26,240
+was introduced, which is the one that I'm also showing
+
+28
+00:01:26,240 --> 00:01:27,860
+here. So if we look at this part of the
+
+29
+00:01:27,860 --> 00:01:29,540
+diagram, you can see this sort of you now,
+
+30
+00:01:29,540 --> 00:01:34,080
+lollipop socket representation. And in this case, what this represents,
+
+31
+00:01:34,080 --> 00:01:37,920
+is that a lollipop indicates a provided interface. So an
+
+32
+00:01:37,920 --> 00:01:41,500
+interface that is provided by the component. So, for example,
+
+33
+00:01:41,500 --> 00:01:45,940
+this security component provides encryption capabilities. The socket,
+
+34
+00:01:45,940 --> 00:01:49,190
+conversely, indicates a required interface. So, for example, in
+
+35
+00:01:49,190 --> 00:01:52,270
+this case, it's saying that the facilities component
+
+36
+00:01:52,270 --> 00:01:55,920
+is needing access control capabilities, which, by the way,
+
+37
+00:01:55,920 --> 00:01:58,660
+is provided by the security component. So in
+
+38
+00:01:58,660 --> 00:02:02,240
+a sense these sockets and lollipop indicate interfaces between
+
+39
+00:02:02,240 --> 00:02:04,770
+a provider of some of functionality, and the client
+
+40
+00:02:04,770 --> 00:02:06,630
+of that functionality and you can look at those
+
+41
+00:02:06,630 --> 00:02:09,740
+as basically APIs. So sets of methods that
+
+42
+00:02:09,740 --> 00:02:12,160
+provide a given functionality. To give you another
+
+43
+00:02:12,160 --> 00:02:14,760
+example, if we look at the persistence components
+
+44
+00:02:14,760 --> 00:02:19,110
+the persistence component provides, unsurprisingly, persistent services. And
+
+45
+00:02:19,110 --> 00:02:21,650
+those persistent services are required by several other
+
+46
+00:02:21,650 --> 00:02:24,520
+components in the system. And in turn, the persistent
+
+47
+00:02:24,520 --> 00:02:28,320
+components relies on the University database component to
+
+48
+00:02:28,320 --> 00:02:31,740
+provide such services. So, there's the University DB components
+
+49
+00:02:31,740 --> 00:02:34,700
+provide these sort of low-level database services that are used
+
+50
+00:02:34,700 --> 00:02:38,150
+by the persistence component To in turn provided services. Last thing
+
+51
+00:02:38,150 --> 00:02:41,080
+I want to note is that components or relationships can be
+
+52
+00:02:41,080 --> 00:02:44,450
+annotated, so, for example if we look at the seminar management
+
+53
+00:02:44,450 --> 00:02:47,090
+and the student administration components you can see that they
+
+54
+00:02:47,090 --> 00:02:51,360
+are annotated here to indicate that they are user inferfaces. So
+
+55
+00:02:51,360 --> 00:02:53,600
+that's all I wanted to say on the component diagrams, but
+
+56
+00:02:53,600 --> 00:02:56,750
+again the key piece of information is that they represent components
+
+57
+00:02:56,750 --> 00:03:00,250
+in the system where a component consists of one or more classes indicate the
+
+58
+00:03:00,250 --> 00:03:03,540
+interfaces that these components provide or require.
+
+59
+00:03:03,540 --> 00:03:06,210
+and describe the interactions between these components.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/24 - UML Structural Diagrams: Deployment - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/24 - UML Structural Diagrams: Deployment - lang_en_vs4.srt
new file mode 100644
index 0000000..07c9a3e
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/24 - UML Structural Diagrams: Deployment - lang_en_vs4.srt
@@ -0,0 +1,95 @@
+1
+00:00:00,100 --> 00:00:02,980
+The last UML structural diagram I want to discuss
+
+2
+00:00:02,980 --> 00:00:06,750
+is the deployment diagram. The deployment diagram provides a static
+
+3
+00:00:06,750 --> 00:00:10,220
+deployment view of a system, and unlike previous diagram,
+
+4
+00:00:10,220 --> 00:00:13,980
+it is about the physical allocation of components to computational
+
+5
+00:00:13,980 --> 00:00:16,950
+units. Think, for example, of a client-server system in
+
+6
+00:00:16,950 --> 00:00:19,130
+which you'll have to define which components will go on
+
+7
+00:00:19,130 --> 00:00:20,880
+the server and which component will go on the
+
+8
+00:00:20,880 --> 00:00:25,200
+client. For deployment diagram, the nodes correspond to computation unit;
+
+9
+00:00:25,200 --> 00:00:29,090
+for example, a specific device. And the edges indicate communication
+
+10
+00:00:29,090 --> 00:00:32,880
+between these units. Also in this case, I'm going to illustrate deployment
+
+11
+00:00:32,880 --> 00:00:36,720
+diagrams using an example for our course management system. And
+
+12
+00:00:36,720 --> 00:00:39,820
+also in this case, I'm going to use a slightly more complex
+
+13
+00:00:39,820 --> 00:00:41,910
+diagram than usual. But I don't want you to look
+
+14
+00:00:41,910 --> 00:00:45,170
+at all the individual details. Instead, I would like to focus
+
+15
+00:00:45,170 --> 00:00:47,530
+on a few main aspects. So, if you look at
+
+16
+00:00:47,530 --> 00:00:50,700
+this diagram, there are three things that you should clearly see.
+
+17
+00:00:50,700 --> 00:00:53,555
+First, you should see how the system involves four
+
+18
+00:00:53,555 --> 00:00:56,590
+nodes, a web server, an application server, a DB
+
+19
+00:00:56,590 --> 00:00:59,740
+server, and a mainframe. Second, you should see which
+
+20
+00:00:59,740 --> 00:01:03,500
+components are deployed on which nodes. For example, the student
+
+21
+00:01:03,500 --> 00:01:07,400
+component is deployed on the application server. And finally,
+
+22
+00:01:07,400 --> 00:01:09,570
+you should see how the nodes communicate with one
+
+23
+00:01:09,570 --> 00:01:11,880
+another. For example, you can see that the application
+
+24
+00:01:11,880 --> 00:01:17,030
+server and the university database communicate using a JDBC protocol.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/25 - UML Behavioral Diagrams: Use Case - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/25 - UML Behavioral Diagrams: Use Case - lang_en_vs5.srt
new file mode 100644
index 0000000..bdfe33a
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/25 - UML Behavioral Diagrams: Use Case - lang_en_vs5.srt
@@ -0,0 +1,111 @@
+1
+00:00:00,110 --> 00:00:04,700
+We now discuss UML's behavioral diagrams. Those diagrams that
+
+2
+00:00:04,700 --> 00:00:07,490
+have to do with the behavior, the dynamic aspects
+
+3
+00:00:07,490 --> 00:00:09,940
+of the system, rather than the static ones. The
+
+4
+00:00:09,940 --> 00:00:12,670
+first behavioral diagram I want to discuss is a very
+
+5
+00:00:12,670 --> 00:00:15,590
+fundamental one, the Use Case Diagram. So, let's start
+
+6
+00:00:15,590 --> 00:00:18,370
+by seeing what a Use Case is. A Use Case
+
+7
+00:00:18,370 --> 00:00:21,800
+represents two main things. First the sequence of interactions
+
+8
+00:00:21,800 --> 00:00:25,250
+of outside entities which is what we normally call actors
+
+9
+00:00:25,250 --> 00:00:27,990
+with the system that we're modelling and the second thing
+
+10
+00:00:27,990 --> 00:00:32,290
+is the system actions that yield an observable result of values
+
+11
+00:00:32,290 --> 00:00:35,380
+to the actors. And basically these two things, and nothing else
+
+12
+00:00:35,380 --> 00:00:38,010
+that the outside view of the system. So the view of
+
+13
+00:00:38,010 --> 00:00:41,060
+the system in which we look at the interaction between
+
+14
+00:00:41,060 --> 00:00:44,170
+this system, and the outside world. If you want to parallel, think
+
+15
+00:00:44,170 --> 00:00:48,070
+about designing a house. Considering how you would use the house.
+
+16
+00:00:48,070 --> 00:00:50,550
+And you might have seen use cases called with different names.
+
+17
+00:00:50,550 --> 00:00:54,820
+So for example, they're also called scenarios, scripts or user stories,
+
+18
+00:00:54,820 --> 00:00:58,220
+but in the context of UML, we'll call the use cases.
+
+19
+00:00:58,220 --> 00:01:00,650
+Now let's look at the basic notation for a use case,
+
+20
+00:01:00,650 --> 00:01:03,910
+which is fairly simple. We have a use case which is represented
+
+21
+00:01:03,910 --> 00:01:05,760
+by an oval, with a name, which is the name of
+
+22
+00:01:05,760 --> 00:01:08,520
+the use case. We have an actor, which is represented by
+
+23
+00:01:08,520 --> 00:01:12,330
+this icon and is normally identified by a role name. And
+
+24
+00:01:12,330 --> 00:01:15,820
+finally we have an edge which is a solid line that connects
+
+25
+00:01:15,820 --> 00:01:18,970
+actors and use cases and indicates that an actor
+
+26
+00:01:18,970 --> 00:01:21,270
+is the actor of a given use case. And just
+
+27
+00:01:21,270 --> 00:01:24,360
+for completeness let me note there are some additional notational
+
+28
+00:01:24,360 --> 00:01:27,750
+elements but now for simplicity we'll just use these ones.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/26 - Use Case Diagram: Actors - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/26 - Use Case Diagram: Actors - lang_en_vs5.srt
new file mode 100644
index 0000000..4d80c61
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/26 - Use Case Diagram: Actors - lang_en_vs5.srt
@@ -0,0 +1,167 @@
+1
+00:00:00,110 --> 00:00:02,320
+Now, let's look at use cases in a little more detail.
+
+2
+00:00:02,320 --> 00:00:05,480
+And start by defining exactly what an actor is. An actor
+
+3
+00:00:05,480 --> 00:00:08,710
+represents an entity, which can be a human or a device,
+
+4
+00:00:08,710 --> 00:00:12,750
+that plays a role within my system, so that interacts with my
+
+5
+00:00:12,750 --> 00:00:15,660
+system. It's some entity from the outside world, with respect to
+
+6
+00:00:15,660 --> 00:00:18,510
+my system, that interacts with my system. It is important to
+
+7
+00:00:18,510 --> 00:00:21,750
+clarify that an entity can play more than one role. For
+
+8
+00:00:21,750 --> 00:00:25,240
+example, you might have somebody working in a bank that can be
+
+9
+00:00:25,240 --> 00:00:28,400
+both an employee of the bank, or a customer of
+
+10
+00:00:28,400 --> 00:00:31,280
+the bank, depending on how it interacts with the banking
+
+11
+00:00:31,280 --> 00:00:34,360
+system. And, obviously, more than one entity can play the
+
+12
+00:00:34,360 --> 00:00:37,570
+same role. Using the same example, we can have both an
+
+13
+00:00:37,570 --> 00:00:40,350
+employee of the bank and just a regular customer, playing
+
+14
+00:00:40,350 --> 00:00:43,280
+the role of the customer. So again, it all depends on
+
+15
+00:00:43,280 --> 00:00:46,120
+what the entity does, how the entity interacts with the
+
+16
+00:00:46,120 --> 00:00:50,150
+system, what kind of functionality of the system the entity uses.
+
+17
+00:00:50,150 --> 00:00:53,270
+And finally, actors may appear in more than one use case.
+
+18
+00:00:53,270 --> 00:00:55,930
+So it's fairly normal for the same actor to interact with
+
+19
+00:00:55,930 --> 00:00:58,540
+the system in different ways. And therefore, to appear in more
+
+20
+00:00:58,540 --> 00:01:00,710
+than one use case. Just think about the use cases in
+
+21
+00:01:00,710 --> 00:01:04,230
+scenarios of usage. If the same actor can interact with the
+
+22
+00:01:04,230 --> 00:01:07,440
+system in different ways, that actor will appear in multiple use
+
+23
+00:01:07,440 --> 00:01:11,210
+cases. Now let's go back to the description of our course
+
+24
+00:01:11,210 --> 00:01:15,140
+management system, and see how we can identify actors in the system.
+
+25
+00:01:15,140 --> 00:01:17,500
+And as we did for the class diagram before, I encourage
+
+26
+00:01:17,500 --> 00:01:20,160
+you to stop the video and try to identify the actors
+
+27
+00:01:20,160 --> 00:01:22,301
+in the system yourself, before I do it.
+
+28
+00:01:23,475 --> 00:01:27,250
+If we look at the description, we can see that, for example, the Registration
+
+29
+00:01:27,250 --> 00:01:30,890
+Manager is clearly an actor for the system. Students are actors
+
+30
+00:01:30,890 --> 00:01:34,400
+for the system. Professors are actors for the system. And notice
+
+31
+00:01:34,400 --> 00:01:36,060
+that we're not doing the same thing that we were doing
+
+32
+00:01:36,060 --> 00:01:38,360
+when identifying classes. Here we're identifying
+
+33
+00:01:38,360 --> 00:01:40,460
+entities that are from the outside
+
+34
+00:01:40,460 --> 00:01:43,090
+world, and have an active role in interacting with my
+
+35
+00:01:43,090 --> 00:01:46,830
+system. Again, Registration Manager, that we will just call registrar for
+
+36
+00:01:46,830 --> 00:01:50,660
+simplicity, students, and professors. So once we have identified the
+
+37
+00:01:50,660 --> 00:01:53,760
+actors for our example, we can simply draw them, using the
+
+38
+00:01:53,760 --> 00:01:56,550
+notation that we just introduced. So we have the registrar,
+
+39
+00:01:56,550 --> 00:01:59,830
+and notice how for every actor we clarify the role that
+
+40
+00:01:59,830 --> 00:02:02,450
+the actor plays. We have the professor, and we have
+
+41
+00:02:02,450 --> 00:02:05,480
+the student. So here, these are the three actors that we
+
+42
+00:02:05,480 --> 00:02:07,000
+identified for our system.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/27 - Building a Use Case Diagram - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/27 - Building a Use Case Diagram - lang_en_vs5.srt
new file mode 100644
index 0000000..4c62396
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/27 - Building a Use Case Diagram - lang_en_vs5.srt
@@ -0,0 +1,203 @@
+1
+00:00:00,080 --> 00:00:02,120
+Now if you want to build a use case diagram for
+
+2
+00:00:02,120 --> 00:00:04,520
+our example, we have to add the use cases for
+
+3
+00:00:04,520 --> 00:00:07,710
+these different actors. For instance, if we consider the student
+
+4
+00:00:07,710 --> 00:00:10,810
+and the registrar, they might be both interacting with the maintain
+
+5
+00:00:10,810 --> 00:00:14,950
+schedule system, the registrar by updating the schedule and the
+
+6
+00:00:14,950 --> 00:00:18,125
+students by using the schedule that has been updated by the
+
+7
+00:00:18,125 --> 00:00:20,860
+registrar. As you can see, different roles for the same
+
+8
+00:00:20,860 --> 00:00:24,962
+use case. Another possible use case is the request course roster.
+
+9
+00:00:24,962 --> 00:00:28,520
+And on this case, the professor will request the roster
+
+10
+00:00:28,520 --> 00:00:31,960
+by interacting with the system. We will continue in this way
+
+11
+00:00:31,960 --> 00:00:35,270
+by further refining and by further adding use cases as we
+
+12
+00:00:35,270 --> 00:00:39,240
+identify possible interactions of the actors that we identified with our
+
+13
+00:00:39,240 --> 00:00:42,380
+system. So in summary, what the use case diagram is doing
+
+14
+00:00:42,380 --> 00:00:45,370
+is to show the actors and their interaction with the system
+
+15
+00:00:45,370 --> 00:00:47,680
+through a set of use cases. At this point, it should
+
+16
+00:00:47,680 --> 00:00:49,990
+be pretty clear that sure, this gives us an idea of
+
+17
+00:00:49,990 --> 00:00:53,630
+the interactions but we don't really know how these interactions occur.
+
+18
+00:00:53,630 --> 00:00:55,870
+So there is one piece that is missing, which is how
+
+19
+00:00:55,870 --> 00:00:58,850
+do we document the use cases, how do we describe what
+
+20
+00:00:58,850 --> 00:01:02,010
+happens and what these interactions actually are. And that's exactly what
+
+21
+00:01:02,010 --> 00:01:05,410
+we're going to discuss now, how to document use cases. So the
+
+22
+00:01:05,410 --> 00:01:09,000
+behavior of a use case can be specified by describing its
+
+23
+00:01:09,000 --> 00:01:11,650
+flow of events. And it is important to note that the
+
+24
+00:01:11,650 --> 00:01:15,190
+flow of events should be described from an actor's point of view,
+
+25
+00:01:15,190 --> 00:01:17,690
+so from the point of view of the external entity that
+
+26
+00:01:17,690 --> 00:01:22,070
+is interacting with my system. So the description should detail what
+
+27
+00:01:22,070 --> 00:01:24,480
+the system must provide to the actor when the use case
+
+28
+00:01:24,480 --> 00:01:28,170
+is executed. In particular, it should describe how the use case
+
+29
+00:01:28,170 --> 00:01:31,670
+starts and ends. It should describe the normal flow of events,
+
+30
+00:01:31,670 --> 00:01:34,280
+what is the normal interaction. And in addition to the normal
+
+31
+00:01:34,280 --> 00:01:37,720
+flow of events, it should also describe possibly alternative flows of
+
+32
+00:01:37,720 --> 00:01:40,240
+events. For example, in the case in which there are multiple
+
+33
+00:01:40,240 --> 00:01:44,450
+ways of accomplishing one action or performing a task. And finally,
+
+34
+00:01:44,450 --> 00:01:47,880
+it should also describe exceptional flow of events. For example, assume that
+
+35
+00:01:47,880 --> 00:01:50,910
+you are describing a use case for withdrawing money from an
+
+36
+00:01:50,910 --> 00:01:54,230
+ATM. You may want to describe the normal flow of events in which
+
+37
+00:01:54,230 --> 00:01:56,590
+I insert my card, I provide my pin and so on.
+
+38
+00:01:56,590 --> 00:01:59,750
+An alternative one in which, in addition to withdrawing cash, maybe I'll
+
+39
+00:01:59,750 --> 00:02:02,550
+also first ask for some information about how much money is
+
+40
+00:02:02,550 --> 00:02:05,390
+in my account. And finally, I may want to also describe an exceptional
+
+41
+00:02:05,390 --> 00:02:07,900
+flow of events in which I get my pin wrong and,
+
+42
+00:02:07,900 --> 00:02:11,140
+therefore, I'm not able to perform the operation. One more thing I
+
+43
+00:02:11,140 --> 00:02:14,140
+want to mention, when we talk about documenting use cases, is
+
+44
+00:02:14,140 --> 00:02:17,770
+the fact that the description of this information can be provided in
+
+45
+00:02:17,770 --> 00:02:20,650
+two main ways, in an informal way or in a formal
+
+46
+00:02:20,650 --> 00:02:23,330
+way. In the case of an informal description, we could just have
+
+47
+00:02:23,330 --> 00:02:27,540
+a textual description of the flow of events in natural language.
+
+48
+00:02:27,540 --> 00:02:30,250
+In the case of a formal or structured description, we may use,
+
+49
+00:02:30,250 --> 00:02:32,610
+for example, pre and post conditions, pseudo
+
+50
+00:02:32,610 --> 00:02:34,680
+code to indicate the steps. We could
+
+51
+00:02:34,680 --> 00:02:38,010
+also use the sequence diagrams, which is something that we will see in a minute.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/28 - Use Case Example - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/28 - Use Case Example - lang_en_vs5.srt
new file mode 100644
index 0000000..8f8bead
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/28 - Use Case Example - lang_en_vs5.srt
@@ -0,0 +1,243 @@
+1
+00:00:00,140 --> 00:00:02,310
+So, as we did for the previous cases, now let's look
+
+2
+00:00:02,310 --> 00:00:06,890
+at an example. Let's consider a specific use case, maintain curriculum, in
+
+3
+00:00:06,890 --> 00:00:10,570
+which we have the registrar that interacts with the system to do
+
+4
+00:00:10,570 --> 00:00:14,320
+operations for maintaining the curriculum. And, let's define the flow of events
+
+5
+00:00:14,320 --> 00:00:17,040
+for this use case. To do this, we're going to go back, as
+
+6
+00:00:17,040 --> 00:00:20,380
+usual, to the description of our system. So this is the one
+
+7
+00:00:20,380 --> 00:00:22,670
+that you already saw several times, but I would like for you
+
+8
+00:00:22,670 --> 00:00:25,080
+to do something. I would like for you to stop the video,
+
+9
+00:00:25,080 --> 00:00:27,890
+look back at the spec, the one that is shown here.
+
+10
+00:00:27,890 --> 00:00:30,850
+And write on your own, what you think is the informal flow
+
+11
+00:00:30,850 --> 00:00:35,060
+of events that categorizes the interaction of the registration manager with
+
+12
+00:00:35,060 --> 00:00:37,500
+the system. And it is very important that you keep in mind
+
+13
+00:00:37,500 --> 00:00:40,140
+something as you're doing that. You should keep in mind that,
+
+14
+00:00:40,140 --> 00:00:41,940
+as it always happens, when extracting
+
+15
+00:00:41,940 --> 00:00:44,270
+requirements from an initial specification, in
+
+16
+00:00:44,270 --> 00:00:47,570
+particular an informal one like this one, a high-level one, you
+
+17
+00:00:47,570 --> 00:00:50,130
+will have to be able to read between the lines and fill
+
+18
+00:00:50,130 --> 00:00:52,690
+in the blanks. That is, you have to provide the information
+
+19
+00:00:52,690 --> 00:00:55,770
+for the missing parts using your domain knowledge. So try to
+
+20
+00:00:55,770 --> 00:00:58,820
+do that exercise. Read the description, and see how you will
+
+21
+00:00:58,820 --> 00:01:02,470
+define the steps, the flow of events for the maintain curriculum use
+
+22
+00:01:02,470 --> 00:01:06,230
+case. If you're done with that, now let's see the possible
+
+23
+00:01:06,230 --> 00:01:09,080
+informal paragraph that describes that flow of events. And the one
+
+24
+00:01:09,080 --> 00:01:12,070
+I'm providing now is just one possibility, based on my experience
+
+25
+00:01:12,070 --> 00:01:15,040
+and based on the way I see this possible flow of events.
+
+26
+00:01:15,040 --> 00:01:17,950
+So yours might look different, of course. In my case, because
+
+27
+00:01:17,950 --> 00:01:20,880
+the description was measuring the fact that every user has got
+
+28
+00:01:20,880 --> 00:01:23,590
+a log-in and a password. I decided that the first step
+
+29
+00:01:23,590 --> 00:01:27,120
+should be that the registrar logs onto the system and enters his
+
+30
+00:01:27,120 --> 00:01:30,390
+or her password. As it normally happens with password protected systems,
+
+31
+00:01:30,390 --> 00:01:32,660
+if the password is valid, the registrar will get into the
+
+32
+00:01:32,660 --> 00:01:35,870
+system. And the system at this point should ask to specify
+
+33
+00:01:35,870 --> 00:01:40,810
+a semester for which the maintain curriculum activity has to be performed.
+
+34
+00:01:40,810 --> 00:01:44,290
+The registrar will therefor enter the desired semester. The interface
+
+35
+00:01:44,290 --> 00:01:46,740
+I envisioned is one in which the system will prompt
+
+36
+00:01:46,740 --> 00:01:50,690
+the registrar to select the desired activity. Add, delete, review,
+
+37
+00:01:50,690 --> 00:01:53,560
+or quit. And if the registrar selects add, the system
+
+38
+00:01:53,560 --> 00:01:56,060
+will allow the registrar to add a course to the
+
+39
+00:01:56,060 --> 00:01:59,660
+course list for the selected semester. Similarly, if the registrar
+
+40
+00:01:59,660 --> 00:02:02,550
+selects delete, the system will let the registrar delete a
+
+41
+00:02:02,550 --> 00:02:05,840
+course from the course list for the selected semester. And again
+
+42
+00:02:05,840 --> 00:02:08,660
+similarly, if the registrar selects review, the system will
+
+43
+00:02:08,660 --> 00:02:12,030
+simply display the course information in the course list for
+
+44
+00:02:12,030 --> 00:02:15,230
+the selected semester. And finally, if the registrar selects quit,
+
+45
+00:02:15,230 --> 00:02:18,110
+the system will simply exit and our use case will
+
+46
+00:02:18,110 --> 00:02:21,150
+end. So, again, there's the main knowledge that goes into
+
+47
+00:02:21,150 --> 00:02:23,620
+this. But this is a good example of how you
+
+48
+00:02:23,620 --> 00:02:27,960
+can refine the initial description to identify these scenarios that
+
+49
+00:02:27,960 --> 00:02:30,830
+then you will use to specify and implement your system.
+
+50
+00:02:30,830 --> 00:02:33,770
+And as we discussed a few minutes ago, we provided the information
+
+51
+00:02:33,770 --> 00:02:37,420
+that is requested for the use case, how the use case starts,
+
+52
+00:02:37,420 --> 00:02:40,620
+by logging into the system. And how it ends, by selecting quit.
+
+53
+00:02:40,620 --> 00:02:43,294
+We described the normal flow of events. And, of course, these flow
+
+54
+00:02:43,294 --> 00:02:46,580
+of events could be improved, because right now even though we described
+
+55
+00:02:46,580 --> 00:02:50,020
+how the use case starts and ends, we just described one possible
+
+56
+00:02:50,020 --> 00:02:53,340
+flow of events. But there's many alternative ways we could provide and
+
+57
+00:02:53,340 --> 00:02:55,890
+we do not describe any exception of flow of events. So this could
+
+58
+00:02:55,890 --> 00:02:58,540
+be the starting point for multiple use cases, or
+
+59
+00:02:58,540 --> 00:03:02,092
+for use cases just richer and contains more information, more
+
+60
+00:03:02,092 --> 00:03:04,474
+steps to a richer flow. But you should have
+
+61
+00:03:04,474 --> 00:03:06,510
+gotten the idea of what a use case should be.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/29 - Role of Use Cases - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/29 - Role of Use Cases - lang_en_vs5.srt
new file mode 100644
index 0000000..11c0187
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/29 - Role of Use Cases - lang_en_vs5.srt
@@ -0,0 +1,151 @@
+1
+00:00:00,100 --> 00:00:02,510
+As I mentioned when we started talking about use cases, use
+
+2
+00:00:02,510 --> 00:00:06,040
+cases are fundamental in UML, and in general. So, now I
+
+3
+00:00:06,040 --> 00:00:08,510
+would like to discuss why they're so important and what are
+
+4
+00:00:08,510 --> 00:00:11,900
+the different roles that use cases can play. The first obvious one
+
+5
+00:00:11,900 --> 00:00:15,510
+is for requirements elicitation. It is much easier to describe what
+
+6
+00:00:15,510 --> 00:00:17,650
+the system should do if we think about the system in
+
+7
+00:00:17,650 --> 00:00:21,070
+terms of scenarios of usage. Rather than trying to describe the
+
+8
+00:00:21,070 --> 00:00:25,450
+whole functionality of the system at once. So, use cases can help
+
+9
+00:00:25,450 --> 00:00:28,890
+performing a more effective requirement solicitation. As we will
+
+10
+00:00:28,890 --> 00:00:31,700
+see when we discuss the unified software process, they can
+
+11
+00:00:31,700 --> 00:00:34,980
+be used for architectural analysis. So, use cases are the
+
+12
+00:00:34,980 --> 00:00:38,165
+starting point for the analysis of the architecture of the
+
+13
+00:00:38,165 --> 00:00:40,765
+system that can help identify the main blocks of
+
+14
+00:00:40,765 --> 00:00:44,016
+the system. And therefore, can help define in the initial
+
+15
+00:00:44,016 --> 00:00:47,360
+architecture. And as I said, we'll talk more extensively about
+
+16
+00:00:47,360 --> 00:00:50,460
+that. They can be used for user prioritization. For example,
+
+17
+00:00:50,460 --> 00:00:53,230
+imagine to have multiple actors in the system, and you
+
+18
+00:00:53,230 --> 00:00:56,160
+might want to prioritize some of them. For instance, using
+
+19
+00:00:56,160 --> 00:00:59,810
+again the banking system example, we might want to first
+
+20
+00:00:59,810 --> 00:01:03,477
+provide functionality for the administrators of the bank. And only
+
+21
+00:01:03,477 --> 00:01:06,384
+in a second time provide functionality for the customers, because
+
+22
+00:01:06,384 --> 00:01:09,342
+of course, if the administrator cannot perform any operation, the
+
+23
+00:01:09,342 --> 00:01:12,030
+customers cannot use the system. So again, they can be
+
+24
+00:01:12,030 --> 00:01:15,980
+used to prioritize the users. Or the actors, and therefore
+
+25
+00:01:15,980 --> 00:01:19,390
+define which part of the system should be built in which order.
+
+26
+00:01:19,390 --> 00:01:22,120
+Related to this point, they can be used for planning. If I
+
+27
+00:01:22,120 --> 00:01:25,000
+know which pieces of functionality I need to build and in which
+
+28
+00:01:25,000 --> 00:01:27,980
+order, I can better plan the development of my system. And again,
+
+29
+00:01:27,980 --> 00:01:31,280
+we will see how this becomes very important in many different software
+
+30
+00:01:31,280 --> 00:01:35,037
+life cycles. So, both in the unified software process, for instance, but
+
+31
+00:01:35,037 --> 00:01:38,570
+also in more agile development processes. And finally, use cases can be
+
+32
+00:01:38,570 --> 00:01:40,980
+used for testing. If I have an early description of what the
+
+33
+00:01:40,980 --> 00:01:44,290
+system should do, what are the main pieces of functionality of the system. And I
+
+34
+00:01:44,290 --> 00:01:46,700
+know how the interaction between the actors and
+
+35
+00:01:46,700 --> 00:01:49,510
+the system is, I can easily define test
+
+36
+00:01:49,510 --> 00:01:52,010
+cases, even before writing the code, even before
+
+37
+00:01:52,010 --> 00:01:54,180
+defining my system. And when we discuss testing,
+
+38
+00:01:54,180 --> 00:01:57,590
+we will get back to this and talk a little more extensively about this, as well.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/3 - Objects and Classes - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/3 - Objects and Classes - lang_en_vs5.srt
new file mode 100644
index 0000000..85bb32f
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/3 - Objects and Classes - lang_en_vs5.srt
@@ -0,0 +1,83 @@
+1
+00:00:00,090 --> 00:00:02,770
+Let's start with objects. An object is a
+
+2
+00:00:02,770 --> 00:00:06,330
+computing unit organized around a collection of state
+
+3
+00:00:06,330 --> 00:00:09,350
+or instance variables that define the state of
+
+4
+00:00:09,350 --> 00:00:12,390
+the object. In addition, each object has associated
+
+5
+00:00:12,390 --> 00:00:15,150
+with it a set operations or methods that
+
+6
+00:00:15,150 --> 00:00:17,850
+operate on such state. So what that means
+
+7
+00:00:17,850 --> 00:00:21,420
+is that operations and methods read and write
+
+8
+00:00:21,420 --> 00:00:25,210
+instance variables. And in traditional object orientation, we say
+
+9
+00:00:25,210 --> 00:00:28,240
+that operations are invoked by sending a message
+
+10
+00:00:28,240 --> 00:00:30,520
+to the appropriate object, which is what we call
+
+11
+00:00:30,520 --> 00:00:33,660
+normally a method implication. So now that we define
+
+12
+00:00:33,660 --> 00:00:37,590
+what an object is, state variables, or attributes, and
+
+13
+00:00:37,590 --> 00:00:41,440
+operations or methods, let's see what a class is.
+
+14
+00:00:41,440 --> 00:00:44,900
+A class is basically a template. A blueprint, if
+
+15
+00:00:44,900 --> 00:00:47,700
+you wish, from which new objects, which is what
+
+16
+00:00:47,700 --> 00:00:50,655
+we call instances of the class can be created.
+
+17
+00:00:50,655 --> 00:00:52,800
+And notice that the fact of having a blueprint for
+
+18
+00:00:52,800 --> 00:00:55,610
+objects that allows us to create as many objects as
+
+19
+00:00:55,610 --> 00:00:58,390
+we want can further reuse, and also contribute to make
+
+20
+00:00:58,390 --> 00:01:00,300
+the code more readable, understandable,
+
+21
+00:01:00,300 --> 00:01:02,270
+and therefore ultimately more maintainable.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/30 - Use Case Diagram: Creation Tips - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/30 - Use Case Diagram: Creation Tips - lang_en_vs5.srt
new file mode 100644
index 0000000..ccf7d0e
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/30 - Use Case Diagram: Creation Tips - lang_en_vs5.srt
@@ -0,0 +1,127 @@
+1
+00:00:00,080 --> 00:00:02,190
+Now, as we did for the class diagram, let's look at
+
+2
+00:00:02,190 --> 00:00:05,440
+some creation tips for use case diagrams. The first tip is that
+
+3
+00:00:05,440 --> 00:00:09,050
+when you define a use case, use a name that communicates purpose.
+
+4
+00:00:09,050 --> 00:00:12,080
+It should be clear what the use case refers to by just
+
+5
+00:00:12,080 --> 00:00:14,320
+looking at the name of the use case. Second tip is
+
+6
+00:00:14,320 --> 00:00:17,700
+to define one atomic behavior per use case. So try not to
+
+7
+00:00:17,700 --> 00:00:21,900
+put more than one specific scenario into a use case. Why? Because
+
+8
+00:00:21,900 --> 00:00:25,380
+these will make the use cases easier to understand and better suited
+
+9
+00:00:25,380 --> 00:00:28,940
+for their roles that we just discussed to define test cases,
+
+10
+00:00:28,940 --> 00:00:31,370
+to do planning, to define an architecture and so on and
+
+11
+00:00:31,370 --> 00:00:34,790
+so forth. Define the flow of events clearly. So again, do
+
+12
+00:00:34,790 --> 00:00:37,820
+it from the perspective of an outsider. An outsider should be able
+
+13
+00:00:37,820 --> 00:00:40,390
+to read the description of the flow of events and understand
+
+14
+00:00:40,390 --> 00:00:43,770
+exactly how the system works or how that specific piece of
+
+15
+00:00:43,770 --> 00:00:47,572
+functionality works. As we suggested for the class diagram, provide only
+
+16
+00:00:47,572 --> 00:00:50,450
+essential details. So there is no need to provide all the nitty
+
+17
+00:00:50,450 --> 00:00:53,720
+gritty details about the use case, just provide enough details so
+
+18
+00:00:53,720 --> 00:00:57,540
+that the use case is complete and understandable. And finally, even
+
+19
+00:00:57,540 --> 00:00:59,960
+though we didn't cover that, there is a way to factor
+
+20
+00:00:59,960 --> 00:01:03,890
+common behaviors and factor variants when defining use cases. So I will
+
+21
+00:01:03,890 --> 00:01:06,580
+encourage you to look at how to do that. For example,
+
+22
+00:01:06,580 --> 00:01:09,290
+by looking at the additional UML documentation and to try to
+
+23
+00:01:09,290 --> 00:01:12,875
+factor out this common behaviors and variants. Typical example would be
+
+24
+00:01:12,875 --> 00:01:15,550
+a system that requires login, like the one that we just discussed,
+
+25
+00:01:15,550 --> 00:01:18,350
+will probably require an initial login step for each use
+
+26
+00:01:18,350 --> 00:01:22,080
+case. It is possible that instead of describing the same steps,
+
+27
+00:01:22,080 --> 00:01:24,600
+or same sub-steps, for each use case, you can factor
+
+28
+00:01:24,600 --> 00:01:26,740
+that out. And create a use case that you should then
+
+29
+00:01:26,740 --> 00:01:29,180
+include in your own use cases. As I said, we
+
+30
+00:01:29,180 --> 00:01:32,790
+didn't cover this for simplicity, but feel free to further read
+
+31
+00:01:32,790 --> 00:01:35,450
+about UML and to see how you can actually factor out
+
+32
+00:01:35,450 --> 00:01:38,890
+behaviors and factor variants. Which can be very useful in practice.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/31 - UML Behavioral Diagrams: Sequence - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/31 - UML Behavioral Diagrams: Sequence - lang_en_vs5.srt
new file mode 100644
index 0000000..cbeb4d8
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/31 - UML Behavioral Diagrams: Sequence - lang_en_vs5.srt
@@ -0,0 +1,227 @@
+1
+00:00:00,080 --> 00:00:02,400
+Now that we have seen use cases, the next behavioral
+
+2
+00:00:02,400 --> 00:00:05,540
+diagram I want to discuss is the sequence diagram. So
+
+3
+00:00:05,540 --> 00:00:08,070
+what is a sequence diagram? It is an interaction diagram
+
+4
+00:00:08,070 --> 00:00:12,710
+that emphasizes how objects communicate and the time ordering of
+
+5
+00:00:12,710 --> 00:00:15,940
+the messages between objects. To illustrate sequence diagrams in a
+
+6
+00:00:15,940 --> 00:00:18,600
+practical way, and hopefully in a clear way, I will
+
+7
+00:00:18,600 --> 00:00:21,960
+introduce them by creating an actual sequence diagram using an
+
+8
+00:00:21,960 --> 00:00:25,160
+example taken from our course management system. So let's see what
+
+9
+00:00:25,160 --> 00:00:28,050
+are the steps needed to build such a sequence diagram. The first
+
+10
+00:00:28,050 --> 00:00:30,900
+thing we want to do is place the objects that participate in
+
+11
+00:00:30,900 --> 00:00:34,460
+the interaction at the top of the diagram along the x-axis, and
+
+12
+00:00:34,460 --> 00:00:36,410
+you also want to place them in a specific way. You want
+
+13
+00:00:36,410 --> 00:00:39,770
+to place objects that initiate the interaction at the left, and place
+
+14
+00:00:39,770 --> 00:00:42,260
+increasingly more subordinate objects to the
+
+15
+00:00:42,260 --> 00:00:44,430
+right. So basically, this should reflect
+
+16
+00:00:44,430 --> 00:00:47,660
+the way the events will flow for the majority of the interactions
+
+17
+00:00:47,660 --> 00:00:50,202
+in the system. Next thing you want to do is to add
+
+18
+00:00:50,202 --> 00:00:53,910
+what is called the object lifeline. It's a vertical line that
+
+19
+00:00:53,910 --> 00:00:57,300
+shows the existence of objects over a period of time. And
+
+20
+00:00:57,300 --> 00:01:00,660
+it's normally represented with a dashed line, except for the outermost
+
+21
+00:01:00,660 --> 00:01:03,190
+object for which it is a solid line. Now that you
+
+22
+00:01:03,190 --> 00:01:06,450
+have your object lifeline you can start placing messages that these
+
+23
+00:01:06,450 --> 00:01:09,285
+objects send and receive. You want to put them along the
+
+24
+00:01:09,285 --> 00:01:12,860
+y-axis in order of increasing time, from top to bottom. And
+
+25
+00:01:12,860 --> 00:01:15,550
+you can also put a number on the message to further
+
+26
+00:01:15,550 --> 00:01:18,230
+clarify the sequence. So in this case what we're showing
+
+27
+00:01:18,230 --> 00:01:21,550
+is that the student will send the fill in info
+
+28
+00:01:21,550 --> 00:01:24,330
+message to the registration form. And this is the first
+
+29
+00:01:24,330 --> 00:01:27,960
+message in the sequence diagram, the first interaction. Then the student
+
+30
+00:01:27,960 --> 00:01:30,900
+might submit the form and this is also a message
+
+31
+00:01:30,900 --> 00:01:33,370
+that goes to the registration form. At this point, when
+
+32
+00:01:33,370 --> 00:01:36,440
+the submission takes place, the registration form will send the
+
+33
+00:01:36,440 --> 00:01:39,990
+message, so it will invoke some functionality in the registration manager.
+
+34
+00:01:39,990 --> 00:01:43,560
+Specifically you will invoke the add course functionality
+
+35
+00:01:43,560 --> 00:01:46,400
+and pass Joe, the name of the student and
+
+36
+00:01:46,400 --> 00:01:49,410
+Math 101 which is the specific course for which
+
+37
+00:01:49,410 --> 00:01:53,180
+Joe is registering. Then the registration manager will ask
+
+38
+00:01:53,180 --> 00:01:56,780
+the Math 101 course whether it accepts registrations,
+
+39
+00:01:56,780 --> 00:01:59,780
+and the interaction will continue. So that Math 101
+
+40
+00:01:59,780 --> 00:02:02,820
+will actually check for a specific offering, if everything
+
+41
+00:02:02,820 --> 00:02:05,070
+goes fine, you will receive an ack, you'll send
+
+42
+00:02:05,070 --> 00:02:07,180
+back the act to the registration manager and so
+
+43
+00:02:07,180 --> 00:02:10,650
+on. Until at the end, Joe will be registered for
+
+44
+00:02:10,650 --> 00:02:13,390
+Math 101. As you can see, it is very
+
+45
+00:02:13,390 --> 00:02:17,600
+easy to see how the interaction occurs between these different
+
+46
+00:02:17,600 --> 00:02:21,010
+objects at run time, dynamically. So what the behavior
+
+47
+00:02:21,010 --> 00:02:24,070
+of the system is for this specific scenario. So the
+
+48
+00:02:24,070 --> 00:02:26,780
+last notational element that I want to add to this
+
+49
+00:02:26,780 --> 00:02:30,350
+diagram is the focus of control. Which is this tall
+
+50
+00:02:30,350 --> 00:02:32,880
+thin rectangle, that shows the period of time
+
+51
+00:02:32,880 --> 00:02:35,190
+that an object is performing an action, either
+
+52
+00:02:35,190 --> 00:02:37,270
+directly or indirectly. So if we look at
+
+53
+00:02:37,270 --> 00:02:39,240
+the registration form, this is telling us that
+
+54
+00:02:39,240 --> 00:02:41,670
+the registration form is active for this amount
+
+55
+00:02:41,670 --> 00:02:43,170
+of time. And the same thing we can
+
+56
+00:02:43,170 --> 00:02:45,520
+do for the registration manager, the Math 101
+
+57
+00:02:45,520 --> 00:02:49,170
+course offering, and the Math 101 specific section.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/32 - UML Behavioral Diagrams: State Transition Diagram - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/32 - UML Behavioral Diagrams: State Transition Diagram - lang_en_vs5.srt
new file mode 100644
index 0000000..ab1bd6a
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/32 - UML Behavioral Diagrams: State Transition Diagram - lang_en_vs5.srt
@@ -0,0 +1,175 @@
+1
+00:00:00,100 --> 00:00:02,430
+The very last diagram that I want to discuss is
+
+2
+00:00:02,430 --> 00:00:05,900
+the state transition diagram. The state transition diagram is defined for
+
+3
+00:00:05,900 --> 00:00:09,270
+each relevant class in the system and basically shows the
+
+4
+00:00:09,270 --> 00:00:12,880
+possible live history of a given class or object. So what
+
+5
+00:00:12,880 --> 00:00:15,090
+does it mean to describe the life history? It means
+
+6
+00:00:15,090 --> 00:00:18,630
+that it describes the possible states of the class as defined
+
+7
+00:00:18,630 --> 00:00:21,910
+by the values of the class attributes. And it also describes
+
+8
+00:00:21,910 --> 00:00:25,710
+the events that cause a transition from one state to another.
+
+9
+00:00:25,710 --> 00:00:28,800
+Finally, it describes the actions that result from a state
+
+10
+00:00:28,800 --> 00:00:31,050
+change. So if you put all of this together you
+
+11
+00:00:31,050 --> 00:00:33,760
+can see how this can represent the whole history of
+
+12
+00:00:33,760 --> 00:00:36,860
+the class, from its creation to its destruction. So let me
+
+13
+00:00:36,860 --> 00:00:40,610
+discuss the transition diagram in more detail, and also provide
+
+14
+00:00:40,610 --> 00:00:43,550
+information about the notation used to represent them. We have
+
+15
+00:00:43,550 --> 00:00:46,770
+states, that are represented by ovals with a name. And
+
+16
+00:00:46,770 --> 00:00:51,820
+we have transitions marked by the event that triggers the transition.
+
+17
+00:00:51,820 --> 00:00:55,500
+What transitions indicate is the passage from one state to
+
+18
+00:00:55,500 --> 00:00:59,430
+another state as the consequence of some external stimuli. Notice
+
+19
+00:00:59,430 --> 00:01:01,930
+that not all events will cause a state transition. So
+
+20
+00:01:01,930 --> 00:01:04,930
+for example, some events might be consumed within a single state.
+
+21
+00:01:04,930 --> 00:01:06,500
+And we'll get to that in a second. But in
+
+22
+00:01:06,500 --> 00:01:10,200
+most cases, an event will trigger some state transition. Events
+
+23
+00:01:10,200 --> 00:01:13,480
+may also produce actions and they may also have attributes
+
+24
+00:01:13,480 --> 00:01:17,100
+which are analogous to parameters in a method call. And Boolean
+
+25
+00:01:17,100 --> 00:01:20,830
+conditions that guard the state transition that is prevented
+
+26
+00:01:20,830 --> 00:01:22,860
+from happening in the case the conditions are not
+
+27
+00:01:22,860 --> 00:01:26,630
+satisfied. States may also be associated with activities and
+
+28
+00:01:26,630 --> 00:01:31,450
+actions. Specifically, activities are operations performed by an object
+
+29
+00:01:31,450 --> 00:01:33,410
+when it is in a given state and that
+
+30
+00:01:33,410 --> 00:01:36,690
+takes time to complete. Actions, conversely, just like the
+
+31
+00:01:36,690 --> 00:01:40,270
+actions corresponding to an event are instantaneous operations that
+
+32
+00:01:40,270 --> 00:01:42,420
+are performed by an object. And can be triggered
+
+33
+00:01:42,420 --> 00:01:46,050
+on entry. So, when the object reaches a given state,
+
+34
+00:01:46,050 --> 00:01:48,970
+when the object exits that state, and also when a
+
+35
+00:01:48,970 --> 00:01:53,240
+specific event occurs. And in this case, this notation is
+
+36
+00:01:53,240 --> 00:01:55,930
+basically a shortcut for any event that will cause a
+
+37
+00:01:55,930 --> 00:01:58,840
+state transition that will bring the object back into the
+
+38
+00:01:58,840 --> 00:02:01,696
+same state. Since we have several actions and activities, it
+
+39
+00:02:01,696 --> 00:02:04,480
+is probably worthwhile clarifyinig the ordering of such actions and
+
+40
+00:02:04,480 --> 00:02:07,559
+activities. So the way in which these actions and activities
+
+41
+00:02:07,559 --> 00:02:10,079
+occur is, first of all, we have the actions on the
+
+42
+00:02:10,079 --> 00:02:13,737
+incoming transition, so this is performed first. Then if there is an
+
+43
+00:02:13,737 --> 00:02:17,321
+entry action that is the next action that would be performed, then
+
+44
+00:02:17,321 --> 00:02:22,370
+we have activity and event actions as appropriate. And finally exit actions.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/33 - State Transition Diagram Example - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/33 - State Transition Diagram Example - lang_en_vs5.srt
new file mode 100644
index 0000000..6c4c1bf
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/33 - State Transition Diagram Example - lang_en_vs5.srt
@@ -0,0 +1,227 @@
+1
+00:00:00,090 --> 00:00:02,850
+As usual were going to illustrate these kind of diagrams by
+
+2
+00:00:02,850 --> 00:00:06,050
+using an example. In particular we are going to describe the state
+
+3
+00:00:06,050 --> 00:00:09,330
+transition diagram for part of our example, for part of
+
+4
+00:00:09,330 --> 00:00:12,640
+our course management system. And we're going to focus on the course
+
+5
+00:00:12,640 --> 00:00:15,540
+offering class. When the class is created, it enters the
+
+6
+00:00:15,540 --> 00:00:19,490
+initialization state, in which the activity performed is to initialize the
+
+7
+00:00:19,490 --> 00:00:22,580
+course. At this point, a simple case is the case in
+
+8
+00:00:22,580 --> 00:00:25,550
+which the class is cancelled, so there is a cancelled event.
+
+9
+00:00:25,550 --> 00:00:28,700
+And if that happens, the class is simply cancelled. So it
+
+10
+00:00:28,700 --> 00:00:31,720
+gets into this final state, which is the state cancelled. And
+
+11
+00:00:31,720 --> 00:00:35,500
+the activity in this case is to notify the registered students.
+
+12
+00:00:35,500 --> 00:00:38,580
+Obviously if this is the flow there will be no registered students.
+
+13
+00:00:38,580 --> 00:00:41,110
+However something else can happen when we are in this initial
+
+14
+00:00:41,110 --> 00:00:43,930
+state. So what can happen is that a student can register, so
+
+15
+00:00:43,930 --> 00:00:47,260
+in this case the add student event is triggered. And the
+
+16
+00:00:47,260 --> 00:00:50,620
+corresponding action is to set the count, in this case it would
+
+17
+00:00:50,620 --> 00:00:53,270
+be the count of students for the course offering, to one. And
+
+18
+00:00:53,270 --> 00:00:55,570
+there will be a change of state and the course offering will
+
+19
+00:00:55,570 --> 00:00:58,870
+get into this open state. And the action that will be performed
+
+20
+00:00:58,870 --> 00:01:02,260
+on entry will be to register the student. At this point more
+
+21
+00:01:02,260 --> 00:01:06,920
+students may register. So other student events might occur and notice that we
+
+22
+00:01:06,920 --> 00:01:10,630
+have a curve here that tells us this event will trigger this
+
+23
+00:01:10,630 --> 00:01:13,790
+transition only if the count is less than 10. So we're assuming
+
+24
+00:01:13,790 --> 00:01:16,120
+that we're not going to have more than 10 students just for lack
+
+25
+00:01:16,120 --> 00:01:19,010
+of a better number in our course offering. So if that
+
+26
+00:01:19,010 --> 00:01:21,960
+happens, if the count is less than ten so then the count
+
+27
+00:01:21,960 --> 00:01:25,880
+is incremented so the increment count action takes place. And the
+
+28
+00:01:25,880 --> 00:01:28,910
+system goes back into the open state, and the new student
+
+29
+00:01:28,910 --> 00:01:32,100
+is registered. Now here we have an interesting transition, because there's
+
+30
+00:01:32,100 --> 00:01:35,380
+no event triggering the transition, but simply the fact that the
+
+31
+00:01:35,380 --> 00:01:37,780
+count is equal to 10. So you can imagine this as
+
+32
+00:01:37,780 --> 00:01:40,930
+being a transition that is always enabled so can always be triggered,
+
+33
+00:01:40,930 --> 00:01:43,410
+but will be guarded. By the fact that the count has
+
+34
+00:01:43,410 --> 00:01:46,750
+to be exactly ten. So basically this transition will take place
+
+35
+00:01:46,750 --> 00:01:49,800
+only when enough students are added, such we get to count
+
+36
+00:01:49,800 --> 00:01:52,900
+them. Being incremented and being equal to ten and then the transition
+
+37
+00:01:52,900 --> 00:01:55,590
+will occur. And we will get into the closed state, in
+
+38
+00:01:55,590 --> 00:01:59,025
+which the class is no longer open because there are enough students
+
+39
+00:01:59,025 --> 00:02:01,730
+registered. And at this point, what will happen is that the
+
+40
+00:02:01,730 --> 00:02:06,320
+course will be finalized. So there will be this activity which performs
+
+41
+00:02:06,320 --> 00:02:09,699
+some operation that is needed to finalize the course. Another possibility
+
+42
+00:02:09,699 --> 00:02:12,150
+is that when we are in the open state, the course
+
+43
+00:02:12,150 --> 00:02:14,680
+is cancelled. And if the course is cancelled, in this case,
+
+44
+00:02:14,680 --> 00:02:18,320
+we go again to the cancel state. But here, the activity
+
+45
+00:02:18,320 --> 00:02:21,850
+of notifying registered students makes more sense. Because we will have
+
+46
+00:02:21,850 --> 00:02:24,960
+at least one registered student in this state, and therefore we'll
+
+47
+00:02:24,960 --> 00:02:28,190
+need to notify such student that the course offering has been
+
+48
+00:02:28,190 --> 00:02:31,470
+cancelled. Finally, is it also possible also to cancel a course
+
+49
+00:02:31,470 --> 00:02:34,050
+after it has been closed? And in this case again, the
+
+50
+00:02:34,050 --> 00:02:38,040
+same thing will happen. The class will reach the cancelled state and
+
+51
+00:02:38,040 --> 00:02:40,850
+all the students, in this case ten students, that are registered
+
+52
+00:02:40,850 --> 00:02:43,730
+for the course will be notified that the course has been cancelled.
+
+53
+00:02:43,730 --> 00:02:46,100
+So, if we look at this state transition diagram, you can
+
+54
+00:02:46,100 --> 00:02:49,860
+see that it's pretty easy to see what the evolution of objects
+
+55
+00:02:49,860 --> 00:02:52,590
+of this class can be. How they can go from their initial
+
+56
+00:02:52,590 --> 00:02:56,660
+state to various final states depending on what are the external events
+
+57
+00:02:56,660 --> 00:02:57,750
+that reach the system.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/34 - Recap Quiz - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/34 - Recap Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..458137f
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/34 - Recap Quiz - lang_en_vs4.srt
@@ -0,0 +1,31 @@
+1
+00:00:00,190 --> 00:00:02,260
+I'd like to conclude this lesson with a couple of
+
+2
+00:00:02,260 --> 00:00:05,350
+quizzes. Just to recap what we saw. And, make sure that
+
+3
+00:00:05,350 --> 00:00:08,000
+everybody's on the same page. In the first quiz, I want to
+
+4
+00:00:08,000 --> 00:00:11,930
+know whether an UML state transition diagram specifies a set of
+
+5
+00:00:11,930 --> 00:00:15,320
+objects that work together to perform some action. The events that
+
+6
+00:00:15,320 --> 00:00:17,870
+cause an object to move from one state to another. The
+
+7
+00:00:17,870 --> 00:00:20,840
+set of components in a system, or the effects of a
+
+8
+00:00:20,840 --> 00:00:24,270
+state change. And as usual, you should mark all that apply.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/35 - Recap Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/35 - Recap Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..1172c26
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/35 - Recap Quiz Solution - lang_en_vs4.srt
@@ -0,0 +1,47 @@
+1
+00:00:00,095 --> 00:00:03,320
+A UML state transition diagram does not specify a set
+
+2
+00:00:03,320 --> 00:00:05,960
+of object that work together to perform some action, because
+
+3
+00:00:05,960 --> 00:00:09,270
+this is what a sequence diagram does instead. Conversely, the
+
+4
+00:00:09,270 --> 00:00:12,530
+second one is correct. As we said, a state transition diagram
+
+5
+00:00:12,530 --> 00:00:15,790
+describes the events that cause a transition from one state
+
+6
+00:00:15,790 --> 00:00:19,300
+to another. Again, a UML state transition diagram does not
+
+7
+00:00:19,300 --> 00:00:22,270
+specify the set of components in a system, because this
+
+8
+00:00:22,270 --> 00:00:25,700
+is what a component diagram does, not a state transition diagram.
+
+9
+00:00:25,700 --> 00:00:27,620
+As for the last one, this is correct,
+
+10
+00:00:27,620 --> 00:00:30,510
+because, as we also discussed, a state transition diagram
+
+11
+00:00:30,510 --> 00:00:33,000
+describes the actions that result from a state
+
+12
+00:00:33,000 --> 00:00:35,890
+change, that is, the effects of such state change.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/36 - Recap Quiz - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/36 - Recap Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..bdc7298
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/36 - Recap Quiz - lang_en_vs4.srt
@@ -0,0 +1,15 @@
+1
+00:00:00,140 --> 00:00:01,580
+And for the last quiz, I want to know
+
+2
+00:00:01,580 --> 00:00:05,250
+which of the following diagrams are UML Structural
+
+3
+00:00:05,250 --> 00:00:08,790
+Diagrams? Use case diagram, class diagram, deployment diagram
+
+4
+00:00:08,790 --> 00:00:11,580
+and sequence diagram. Again, mark all that apply.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/37 - Recap Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/37 - Recap Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..7f8f313
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/37 - Recap Quiz Solution - lang_en_vs4.srt
@@ -0,0 +1,63 @@
+1
+00:00:00,140 --> 00:00:02,580
+And in this case, the correct answer is that class
+
+2
+00:00:02,580 --> 00:00:06,870
+diagram and deployment diagrams are the only two UML structural
+
+3
+00:00:06,870 --> 00:00:09,950
+diagrams among these four. So the answer to this quiz
+
+4
+00:00:09,950 --> 00:00:12,250
+was probably pretty obvious, but I wanted to use it
+
+5
+00:00:12,250 --> 00:00:15,840
+also to stress, once more, the difference between structural and
+
+6
+00:00:15,840 --> 00:00:19,560
+behavioral diagrams. Structural diagrams provide the static picture of the
+
+7
+00:00:19,560 --> 00:00:23,100
+system being modeled, presented from different perspective. For example, from
+
+8
+00:00:23,100 --> 00:00:26,630
+the perspective of the class diagram and of the deployment diagram.
+
+9
+00:00:26,630 --> 00:00:29,760
+Behavioral diagrams, on the other hand, provide information on
+
+10
+00:00:29,760 --> 00:00:32,460
+the dynamic behavior of the system being modeled, also
+
+11
+00:00:32,460 --> 00:00:35,020
+presented from different perspective. So it's important to be
+
+12
+00:00:35,020 --> 00:00:38,020
+able to distinguish between these two types of diagrams. This
+
+13
+00:00:38,020 --> 00:00:41,450
+concludes this lesson on object orientation and UML. But
+
+14
+00:00:41,450 --> 00:00:43,960
+I encourage you to look at the references provided
+
+15
+00:00:43,960 --> 00:00:45,390
+in the class notes, in case you want to
+
+16
+00:00:45,390 --> 00:00:49,440
+know more about object orientation, object oriented analysis, and UML.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/4 - Benefits of OO - lang_en_vs5.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/4 - Benefits of OO - lang_en_vs5.srt
new file mode 100644
index 0000000..2650d6e
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/4 - Benefits of OO - lang_en_vs5.srt
@@ -0,0 +1,51 @@
+1
+00:00:00,090 --> 00:00:02,110
+So in more general terms, why do we want to
+
+2
+00:00:02,110 --> 00:00:05,330
+use object orientation? The first reason is that object
+
+3
+00:00:05,330 --> 00:00:10,530
+orientation can help reduce long-term maintenance costs by limiting
+
+4
+00:00:10,530 --> 00:00:12,700
+the effects of changes. As we saw, the effect
+
+5
+00:00:12,700 --> 00:00:15,990
+of using encapsulation and information hiding makes it easier
+
+6
+00:00:15,990 --> 00:00:18,700
+to modify parts of the system without affecting the
+
+7
+00:00:18,700 --> 00:00:21,590
+rest of the system. Object orientation can also improve
+
+8
+00:00:21,590 --> 00:00:25,870
+the developing process by favoring code and design reuse.
+
+9
+00:00:25,870 --> 00:00:27,840
+In general, object orientation helps
+
+10
+00:00:27,840 --> 00:00:31,750
+enforcing good design principles. Principles such
+
+11
+00:00:31,750 --> 00:00:34,880
+as the ones that we saw in encapuslation, information hiding, high
+
+12
+00:00:34,880 --> 00:00:39,470
+cohesion, low coupling and we will discuss these aspects more extensively
+
+13
+00:00:39,470 --> 00:00:42,750
+in the next mini course which is centered around design concepts.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/5 - OO Benefits Quiz - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/5 - OO Benefits Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..5942254
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/5 - OO Benefits Quiz - lang_en_vs4.srt
@@ -0,0 +1,43 @@
+1
+00:00:00,110 --> 00:00:02,600
+Now let's make sure that we understand the benefits of
+
+2
+00:00:02,600 --> 00:00:06,270
+object orientation through a quiz. Imagine that acme corporation decided
+
+3
+00:00:06,270 --> 00:00:09,180
+to use an objetory entered approach in its software development
+
+4
+00:00:09,180 --> 00:00:12,230
+process. If this is the case what benefits can they expect
+
+5
+00:00:12,230 --> 00:00:14,640
+to receive from this decision. And here I'm listing some
+
+6
+00:00:14,640 --> 00:00:18,120
+possible benefits. Increased reuse because of the modular cooling style.
+
+7
+00:00:18,120 --> 00:00:21,450
+Increased maintainability because the system design can accommodate changes more
+
+8
+00:00:21,450 --> 00:00:25,530
+easily. Increased speed because object oriented systems tend to run faster.
+
+9
+00:00:25,530 --> 00:00:27,770
+And increased understandability because the
+
+10
+00:00:27,770 --> 00:00:30,680
+design models real world entities. So,
+
+11
+00:00:30,680 --> 00:00:33,310
+I would like, as usual, for you to mark all that apply.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/6 - OO Benefits Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/6 - OO Benefits Quiz Solution - lang_en_vs4.srt
new file mode 100644
index 0000000..c97c453
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/6 - OO Benefits Quiz Solution - lang_en_vs4.srt
@@ -0,0 +1,71 @@
+1
+00:00:00,080 --> 00:00:01,280
+So, now let's see which ones of these
+
+2
+00:00:01,280 --> 00:00:04,410
+benefits can actually be expected. Definitely, the first one.
+
+3
+00:00:04,410 --> 00:00:07,720
+The modular coding style typical of object-oriented approaches can,
+
+4
+00:00:07,720 --> 00:00:11,280
+and normally does, increase reuse. Similarly, because of the
+
+5
+00:00:11,280 --> 00:00:15,830
+characteristics of typical object-oriented systems, these systems are normally
+
+6
+00:00:15,830 --> 00:00:18,390
+easier to change. Because they're more modular, they're more
+
+7
+00:00:18,390 --> 00:00:21,890
+cohesive, they're more decoupled. And therefore, all of this
+
+8
+00:00:21,890 --> 00:00:25,520
+contributes to increase the maintainability of the resulting systems.
+
+9
+00:00:25,520 --> 00:00:27,810
+So we're going to mark this benefit as well.
+
+10
+00:00:27,810 --> 00:00:31,500
+There's really nothing about object-oriented systems. That make them
+
+11
+00:00:31,500 --> 00:00:34,550
+run faster and, therefore, this is not a benefit
+
+12
+00:00:34,550 --> 00:00:36,432
+that we can expect from the use of an
+
+13
+00:00:36,432 --> 00:00:39,910
+object-oriented approach. Conversely, the last one is an expected
+
+14
+00:00:39,910 --> 00:00:43,950
+benefit because normally, the fact of designing real-world entities,
+
+15
+00:00:43,950 --> 00:00:46,120
+which is one of the characteristics of the object
+
+16
+00:00:46,120 --> 00:00:50,530
+oriented approaches, does increase understandability. It's easier to understand
+
+17
+00:00:50,530 --> 00:00:54,370
+the system because we can relate. To the system because we can recognize in
+
+18
+00:00:54,370 --> 00:00:58,000
+the systems, real world entities that we are used to see and that we understand.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/7 - OO Analysis History - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/7 - OO Analysis History - lang_en_vs4.srt
new file mode 100644
index 0000000..843126e
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/7 - OO Analysis History - lang_en_vs4.srt
@@ -0,0 +1,175 @@
+1
+00:00:00,060 --> 00:00:02,160
+The use of object orientation and object oriented
+
+2
+00:00:02,160 --> 00:00:06,430
+concepts led to what we call OOAD, object oriented
+
+3
+00:00:06,430 --> 00:00:10,650
+analysis and design. OOAD is a software engineering approach
+
+4
+00:00:10,650 --> 00:00:13,790
+whose main characteristics is to model a software system
+
+5
+00:00:13,790 --> 00:00:16,600
+as a group of interacting objects, and we'll
+
+6
+00:00:16,600 --> 00:00:19,160
+see what that means. In particular, in this lesson
+
+7
+00:00:19,160 --> 00:00:21,590
+we will specifically focus on the first part of
+
+8
+00:00:21,590 --> 00:00:25,360
+this, object oriented analysis, which is a requirements analysis
+
+9
+00:00:25,360 --> 00:00:29,650
+technique that concentrates on modeling real world objects. And
+
+10
+00:00:29,650 --> 00:00:31,340
+as I usually like to do, I would like
+
+11
+00:00:31,340 --> 00:00:34,812
+to start by providing some historical perspective on object
+
+12
+00:00:34,812 --> 00:00:37,472
+oriented analysis to better understand how we went from a
+
+13
+00:00:37,472 --> 00:00:40,990
+function-centric world to a data-centric world. And several people
+
+14
+00:00:40,990 --> 00:00:43,800
+contributed to this shift in perspective, but I'd like
+
+15
+00:00:43,800 --> 00:00:46,960
+to mention a few that were particularly influential. Starting
+
+16
+00:00:46,960 --> 00:00:50,540
+from James Rumbaugh, which in the 90s developed an integrated
+
+17
+00:00:50,540 --> 00:00:53,900
+approach to object oriented modelling with three main aspects.
+
+18
+00:00:53,900 --> 00:00:56,680
+A data aspect, so the modelling was based on
+
+19
+00:00:56,680 --> 00:01:00,390
+using an extended version of entity relationship diagrams to
+
+20
+00:01:00,390 --> 00:01:03,680
+describe classes and inheritance. So that's what was called
+
+21
+00:01:03,680 --> 00:01:06,770
+the object model. And the second aspect has to
+
+22
+00:01:06,770 --> 00:01:09,770
+do with functions. So data flow diagrams were used
+
+23
+00:01:09,770 --> 00:01:12,850
+to represent the functional aspects of the system, where
+
+24
+00:01:12,850 --> 00:01:16,070
+each function was then becoming a method in a class.
+
+25
+00:01:16,070 --> 00:01:18,500
+So this is what is called the functional model.
+
+26
+00:01:18,500 --> 00:01:22,120
+So object model and functional model. The third model
+
+27
+00:01:22,120 --> 00:01:25,120
+in Rumbaugh's methodology had to do with control. So
+
+28
+00:01:25,120 --> 00:01:29,301
+it was representing the dynamic aspects of a system. And
+
+29
+00:01:29,301 --> 00:01:31,880
+it uses state machines, which we'll cover in more
+
+30
+00:01:31,880 --> 00:01:35,730
+detail, to represent how a system would evolve going from
+
+31
+00:01:35,730 --> 00:01:37,650
+one state to the other based on what happened
+
+32
+00:01:37,650 --> 00:01:41,260
+to the system. These three models together represented what was
+
+33
+00:01:41,260 --> 00:01:44,950
+called the Object Modeling Technique, or OMT. And
+
+34
+00:01:44,950 --> 00:01:47,860
+OMT combined with contributions from several people, and in
+
+35
+00:01:47,860 --> 00:01:51,290
+particular Jacobson and Booch, evolved into what we call
+
+36
+00:01:51,290 --> 00:01:54,910
+the Unified Modeling Language, which is UML, which is
+
+37
+00:01:54,910 --> 00:01:56,910
+probably the modeling language that most of you
+
+38
+00:01:56,910 --> 00:02:00,480
+are familiar with. UML extends OMT by providing more
+
+39
+00:02:00,480 --> 00:02:03,460
+diagrams and a broader view of a system from
+
+40
+00:02:03,460 --> 00:02:06,270
+multiple perspectives. So, in the second part of the
+
+41
+00:02:06,270 --> 00:02:07,850
+lesson, we will cover some of these
+
+42
+00:02:07,850 --> 00:02:10,530
+diagrams in details, but before that, I'd like
+
+43
+00:02:10,530 --> 00:02:12,215
+to talk a little bit more about object
+
+44
+00:02:12,215 --> 00:02:14,540
+oriented analysis, and how we can perform it.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/8 - OO Analysis Overview - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/8 - OO Analysis Overview - lang_en_vs4.srt
new file mode 100644
index 0000000..fccd722
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/8 - OO Analysis Overview - lang_en_vs4.srt
@@ -0,0 +1,147 @@
+1
+00:00:00,110 --> 00:00:02,540
+So let's look at the object-oriented analysis in a
+
+2
+00:00:02,540 --> 00:00:05,540
+little more detail. As I said earlier, traditional analysis
+
+3
+00:00:05,540 --> 00:00:08,890
+and design techniques were functionally oriented. What that means
+
+4
+00:00:08,890 --> 00:00:11,980
+is that they concentrated on the functions to be performed,
+
+5
+00:00:11,980 --> 00:00:14,510
+whereas the data upon which the functions operated were
+
+6
+00:00:14,510 --> 00:00:18,900
+secondary to the functions themselves. Conversely, object oriented analysis, is
+
+7
+00:00:18,900 --> 00:00:22,100
+primarily concerned that with a data objects, so we
+
+8
+00:00:22,100 --> 00:00:25,500
+went from a functional oriented view to a data oriented
+
+9
+00:00:25,500 --> 00:00:28,070
+view, what that means is that during the analysis phase,
+
+10
+00:00:28,070 --> 00:00:30,770
+we define a system first in terms of the data
+
+11
+00:00:30,770 --> 00:00:34,380
+types and their relationships, and the functions or methods are
+
+12
+00:00:34,380 --> 00:00:38,130
+defined only later and associated with specific objects which are sets
+
+13
+00:00:38,130 --> 00:00:40,380
+of data. So let's see how we can perform object
+
+14
+00:00:40,380 --> 00:00:44,040
+orientated analysis in practice, so the basic idea is to be
+
+15
+00:00:44,040 --> 00:00:47,060
+focused on the objects of the real world. So to
+
+16
+00:00:47,060 --> 00:00:51,310
+go from a real world objects to a set of requirements.
+
+17
+00:00:51,310 --> 00:00:55,340
+And we can describe this as a four-step process. The first
+
+18
+00:00:55,340 --> 00:00:57,790
+step is to obtain or prepare a textual description of the
+
+19
+00:00:57,790 --> 00:01:00,400
+problem to be solved. So obviously, we need to start from
+
+20
+00:01:00,400 --> 00:01:03,300
+some description of the system that we need to build. And
+
+21
+00:01:03,300 --> 00:01:06,120
+this is a very practical oriented approach, so that the next
+
+22
+00:01:06,120 --> 00:01:08,390
+thing we do is that we take the description and we
+
+23
+00:01:08,390 --> 00:01:12,670
+underline nouns. In this description. And the nouns that we underline
+
+24
+00:01:12,670 --> 00:01:16,710
+will become classes in my analysis. We then look at adjectives in
+
+25
+00:01:16,710 --> 00:01:19,530
+the document. We underline those, and we use that
+
+26
+00:01:19,530 --> 00:01:23,130
+information to identify the attributes of the classes that we've
+
+27
+00:01:23,130 --> 00:01:26,370
+previously identified. At this point we focus on active
+
+28
+00:01:26,370 --> 00:01:29,610
+verbs in the description, and the analysis of the active
+
+29
+00:01:29,610 --> 00:01:32,710
+verbs will give us the operations that we'll need
+
+30
+00:01:32,710 --> 00:01:36,830
+to define for our classes. So, again, underline nouns, and
+
+31
+00:01:36,830 --> 00:01:38,950
+those will become the classes in my system. Then,
+
+32
+00:01:38,950 --> 00:01:42,150
+objectives. And, those will be the attributes of the classes.
+
+33
+00:01:42,150 --> 00:01:46,650
+And, finally, active verbs that will become the operations of my classes. And
+
+34
+00:01:46,650 --> 00:01:48,840
+of course, this is a high level view to take this with a
+
+35
+00:01:48,840 --> 00:01:51,790
+grain of salt. But we will see that it's a very good pragmatic
+
+36
+00:01:51,790 --> 00:01:54,760
+approach to identifying requirements, starting from a
+
+37
+00:01:54,760 --> 00:01:56,570
+description of the system to be built.
diff --git a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/9 - Modeling Classes Quiz - lang_en_vs4.srt b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/9 - Modeling Classes Quiz - lang_en_vs4.srt
new file mode 100644
index 0000000..6c3c61b
--- /dev/null
+++ b/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/9 - Modeling Classes Quiz - lang_en_vs4.srt
@@ -0,0 +1,35 @@
+1
+00:00:00,190 --> 00:00:02,890
+Now let's see how object oriented analysis might work
+
+2
+00:00:02,890 --> 00:00:06,640
+in practice by considering the following requirement for an online
+
+3
+00:00:06,640 --> 00:00:10,230
+shopping website. The requirement says that users can add
+
+4
+00:00:10,230 --> 00:00:12,890
+more than one item on sale at a time to
+
+5
+00:00:12,890 --> 00:00:15,590
+a shopping cart. So, looking at this requirement I
+
+6
+00:00:15,590 --> 00:00:18,180
+would like you to tell me which of the following
+
+7
+00:00:18,180 --> 00:00:21,285
+elements should be modeled as classes. And the elements
+
+8
+00:00:21,285 --> 00:00:25,650
+are: item, sale, shopping cart, time and user. So mark
+
+9
+00:00:25,650 --> 00:00:26,370
+all that apply.
author	Nguyễn Gia Phong <mcsinyx@disroot.org>	2020-05-24 16:34:31 +0700
committer	Nguyễn Gia Phong <mcsinyx@disroot.org>	2020-05-24 16:34:31 +0700
commit	b2d80610db6beda38573890ed169815e495bc663 (patch)
tree	176e1bca6fe644c619d53cf1c24682c244b79cf6 /usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles
parent	49376ab97c7427f1c1eca64072d1a934c2e52f50 (diff)
download	cp-b2d80610db6beda38573890ed169815e495bc663.tar.gz