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