diff options
Diffstat (limited to 'usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles')
37 files changed, 0 insertions, 4355 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 deleted file mode 100644 index 3cc0326..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/1 - Lesson Overview - lang_en_vs4.srt +++ /dev/null @@ -1,35 +0,0 @@ -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 deleted file mode 100644 index 4dd6994..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/10 - Modeling Classes Quiz Solution - lang_en_vs4.srt +++ /dev/null @@ -1,47 +0,0 @@ -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 deleted file mode 100644 index 6d86101..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/11 - Running Example Explanation - lang_en_vs5.srt +++ /dev/null @@ -1,115 +0,0 @@ -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 deleted file mode 100644 index b2c9579..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/12 - UML Structural Diagrams: Class Diagram - lang_en_vs4.srt +++ /dev/null @@ -1,47 +0,0 @@ -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 deleted file mode 100644 index b02e6ea..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/13 - Class Diagram: Class - lang_en_vs5.srt +++ /dev/null @@ -1,259 +0,0 @@ -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 deleted file mode 100644 index e1230c9..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/14 - Class Diagram: Attributes - lang_en_vs5.srt +++ /dev/null @@ -1,135 +0,0 @@ -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 deleted file mode 100644 index 8943fca..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/15 - Class Diagram: Operations - lang_en_vs5.srt +++ /dev/null @@ -1,111 +0,0 @@ -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 deleted file mode 100644 index ef6550d..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/16 - Class Diagram: Relationships - lang_en_vs5.srt +++ /dev/null @@ -1,111 +0,0 @@ -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 deleted file mode 100644 index 90ffe63..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/17 - Class Diagram Relationships Quiz - lang_en_vs4.srt +++ /dev/null @@ -1,55 +0,0 @@ -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 deleted file mode 100644 index ca674bf..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/18 - Class Diagram Relationships Quiz Solution - lang_en_vs5.srt +++ /dev/null @@ -1,23 +0,0 @@ -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 deleted file mode 100644 index 54c7da3..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/19 - Class Diagram: Dependency Relationship - lang_en_vs4.srt +++ /dev/null @@ -1,71 +0,0 @@ -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 deleted file mode 100644 index 44fdd74..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/2 - Object Orientation Introduction - lang_en_vs5.srt +++ /dev/null @@ -1,187 +0,0 @@ -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 deleted file mode 100644 index 8770928..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/20 - Class Diagram: Association & Aggregation Relationships - lang_en_vs5.srt +++ /dev/null @@ -1,219 +0,0 @@ -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 deleted file mode 100644 index 513413b..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/21 - Class Diagram: Generalization Relationship - lang_en_vs5.srt +++ /dev/null @@ -1,75 +0,0 @@ -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 deleted file mode 100644 index 8aa0204..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/22 - Class Diagram: Creation Tips - lang_en_vs5.srt +++ /dev/null @@ -1,143 +0,0 @@ -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 deleted file mode 100644 index 8ce2080..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/23 - UML Structural Diagrams: Component Diagram - lang_en_vs5.srt +++ /dev/null @@ -1,235 +0,0 @@ -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 deleted file mode 100644 index 07c9a3e..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/24 - UML Structural Diagrams: Deployment - lang_en_vs4.srt +++ /dev/null @@ -1,95 +0,0 @@ -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 deleted file mode 100644 index bdfe33a..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/25 - UML Behavioral Diagrams: Use Case - lang_en_vs5.srt +++ /dev/null @@ -1,111 +0,0 @@ -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 deleted file mode 100644 index 4d80c61..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/26 - Use Case Diagram: Actors - lang_en_vs5.srt +++ /dev/null @@ -1,167 +0,0 @@ -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 deleted file mode 100644 index 4c62396..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/27 - Building a Use Case Diagram - lang_en_vs5.srt +++ /dev/null @@ -1,203 +0,0 @@ -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 deleted file mode 100644 index 8f8bead..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/28 - Use Case Example - lang_en_vs5.srt +++ /dev/null @@ -1,243 +0,0 @@ -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 deleted file mode 100644 index 11c0187..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/29 - Role of Use Cases - lang_en_vs5.srt +++ /dev/null @@ -1,151 +0,0 @@ -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 deleted file mode 100644 index 85bb32f..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/3 - Objects and Classes - lang_en_vs5.srt +++ /dev/null @@ -1,83 +0,0 @@ -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 deleted file mode 100644 index ccf7d0e..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/30 - Use Case Diagram: Creation Tips - lang_en_vs5.srt +++ /dev/null @@ -1,127 +0,0 @@ -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 deleted file mode 100644 index cbeb4d8..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/31 - UML Behavioral Diagrams: Sequence - lang_en_vs5.srt +++ /dev/null @@ -1,227 +0,0 @@ -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 deleted file mode 100644 index ab1bd6a..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/32 - UML Behavioral Diagrams: State Transition Diagram - lang_en_vs5.srt +++ /dev/null @@ -1,175 +0,0 @@ -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 deleted file mode 100644 index 6c4c1bf..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/33 - State Transition Diagram Example - lang_en_vs5.srt +++ /dev/null @@ -1,227 +0,0 @@ -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 deleted file mode 100644 index 458137f..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/34 - Recap Quiz - lang_en_vs4.srt +++ /dev/null @@ -1,31 +0,0 @@ -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 deleted file mode 100644 index 1172c26..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/35 - Recap Quiz Solution - lang_en_vs4.srt +++ /dev/null @@ -1,47 +0,0 @@ -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 deleted file mode 100644 index bdc7298..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/36 - Recap Quiz - lang_en_vs4.srt +++ /dev/null @@ -1,15 +0,0 @@ -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 deleted file mode 100644 index 7f8f313..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/37 - Recap Quiz Solution - lang_en_vs4.srt +++ /dev/null @@ -1,63 +0,0 @@ -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 deleted file mode 100644 index 2650d6e..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/4 - Benefits of OO - lang_en_vs5.srt +++ /dev/null @@ -1,51 +0,0 @@ -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 deleted file mode 100644 index 5942254..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/5 - OO Benefits Quiz - lang_en_vs4.srt +++ /dev/null @@ -1,43 +0,0 @@ -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 deleted file mode 100644 index c97c453..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/6 - OO Benefits Quiz Solution - lang_en_vs4.srt +++ /dev/null @@ -1,71 +0,0 @@ -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 deleted file mode 100644 index 843126e..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/7 - OO Analysis History - lang_en_vs4.srt +++ /dev/null @@ -1,175 +0,0 @@ -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 deleted file mode 100644 index fccd722..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/8 - OO Analysis Overview - lang_en_vs4.srt +++ /dev/null @@ -1,147 +0,0 @@ -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 deleted file mode 100644 index 6c3c61b..0000000 --- a/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/9 - Modeling Classes Quiz - lang_en_vs4.srt +++ /dev/null @@ -1,35 +0,0 @@ -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. |