diff options
Diffstat (limited to 'usth')
342 files changed, 43454 insertions, 0 deletions
diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/1 - Introduction - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/1 - Introduction - lang_en.srt new file mode 100644 index 0000000..aea69ae --- /dev/null +++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/1 - Introduction - lang_en.srt @@ -0,0 +1,40 @@ +1 +00:00:00,350 --> 00:00:03,570 +Hi, everybody, and welcome to the first lesson + +2 +00:00:03,570 --> 00:00:07,970 +of the Software Engineering Course. In this introductory lesson + +3 +00:00:07,970 --> 00:00:09,820 +I will first provide an overview of the + +4 +00:00:09,820 --> 00:00:13,100 +whole course and then try to answer two important + +5 +00:00:13,100 --> 00:00:16,630 +questions about software engineering, which are, what is + +6 +00:00:16,630 --> 00:00:20,310 +software engineering and why do we need it? And + +7 +00:00:20,310 --> 00:00:22,370 +to spice up the content a bit I + +8 +00:00:22,370 --> 00:00:25,480 +will also interview several experts in the software engineering + +9 +00:00:25,480 --> 00:00:30,080 +field from both academia and industry and ask them these + +10 +00:00:30,080 --> 00:00:34,410 +very questions. So without any further ado, let's begin the lesson. + diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/10 - Software Development - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/10 - Software Development - lang_en.srt new file mode 100644 index 0000000..b1f822e --- /dev/null +++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/10 - Software Development - lang_en.srt @@ -0,0 +1,108 @@ +1 +00:00:00,060 --> 00:00:01,970 +Now that we saw how software engineering was born and we + +2 +00:00:01,970 --> 00:00:04,580 +saw some of the problems that led to the birth of software + +3 +00:00:04,580 --> 00:00:07,020 +engineering. Let's see how we can do better. How can we + +4 +00:00:07,020 --> 00:00:10,580 +preform software development in a smarter, in a better way, a more + +5 +00:00:10,580 --> 00:00:13,150 +successful way? So what I'm going to show here is the + +6 +00:00:13,150 --> 00:00:14,730 +way I see software development. To + +7 +00:00:14,730 --> 00:00:17,080 +me software development is fundementally going + +8 +00:00:17,080 --> 00:00:21,150 +from an abstract idea in somebody's head, for example, the customer's head, + +9 +00:00:21,150 --> 00:00:25,300 +to a concrete system that actually implements that idea and hopefully it + +10 +00:00:25,300 --> 00:00:27,640 +does it in the right way. And this is a very + +11 +00:00:27,640 --> 00:00:31,290 +complex process. It can be overwhelming. So, unless we are talking about + +12 +00:00:31,290 --> 00:00:34,800 +the trivial system, it's very complex for us to keep in mind + +13 +00:00:34,800 --> 00:00:37,020 +all the different aspects of the systems, and to do all the + +14 +00:00:37,020 --> 00:00:40,270 +different steps required to build this system, automatically. So that's when + +15 +00:00:40,270 --> 00:00:43,630 +software processes come to the rescue. So what is a software process? + +16 +00:00:43,630 --> 00:00:46,380 +A software process is nothing else but a way of breaking down + +17 +00:00:46,380 --> 00:00:50,320 +this otherwise unmanageable task into smaller steps. In smaller steps that we + +18 +00:00:50,320 --> 00:00:53,270 +can handle. And that can be tackled individually. So having a + +19 +00:00:53,270 --> 00:00:56,580 +software process is of fundamental importance for several reasons. First of + +20 +00:00:56,580 --> 00:00:59,530 +all, for non-trivial systems, you can't just do it by getting + +21 +00:00:59,530 --> 00:01:01,680 +it, by just sitting down and developing. What you have to + +22 +00:01:01,680 --> 00:01:04,629 +do instead is to break down the complexity in a systematic + +23 +00:01:04,629 --> 00:01:08,250 +way. So software processes are normally systematic. And you need to + +24 +00:01:08,250 --> 00:01:11,370 +break down this complexity, in a more or less formal way. + +25 +00:01:11,370 --> 00:01:15,800 +So software processes are also a formal, or semiformal, way of + +26 +00:01:15,800 --> 00:01:19,120 +discussing, or describing, how software should be developed. + +27 +00:01:19,120 --> 00:01:21,370 +So what are the steps involved in developing software? + diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/11 - Software Process - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/11 - Software Process - lang_en.srt new file mode 100644 index 0000000..98592eb --- /dev/null +++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/11 - Software Process - lang_en.srt @@ -0,0 +1,96 @@ +1 +00:00:00,200 --> 00:00:02,580 +One thing you need to know right away about software processes + +2 +00:00:02,580 --> 00:00:05,750 +is that there's not just one single process, but there are multiple, + +3 +00:00:05,750 --> 00:00:08,840 +possible processes, depending on your context, depending on the kind of + +4 +00:00:08,840 --> 00:00:11,535 +applications that you are developing. In this course, we are going to try + +5 +00:00:11,535 --> 00:00:14,760 +to cover the spectrum of the possible processes, as much as + +6 +00:00:14,760 --> 00:00:18,900 +possible, by focusing on four main software processes. The first one is + +7 +00:00:18,900 --> 00:00:22,480 +what we call normally the waterfall process. And, we call it waterfall + +8 +00:00:22,480 --> 00:00:25,490 +because in the process we go from one phase to the other + +9 +00:00:25,490 --> 00:00:28,300 +in the same way in which water follows the flow + +10 +00:00:28,300 --> 00:00:30,910 +in a waterfall. The second process that we consider is what + +11 +00:00:30,910 --> 00:00:34,580 +we call evolutionary prototyping, and in this case, instead of + +12 +00:00:34,580 --> 00:00:37,790 +following this set of rigid steps, all we're trying to do + +13 +00:00:37,790 --> 00:00:40,930 +is to start with an initial prototype and evolve it + +14 +00:00:40,930 --> 00:00:43,670 +based on the feedback from the customer. We will then move + +15 +00:00:43,670 --> 00:00:47,150 +towards a slightly more formal process, which is the rational unified + +16 +00:00:47,150 --> 00:00:50,590 +process or the unified software process. And this is a kind + +17 +00:00:50,590 --> 00:00:53,040 +of project heavily based on the use of UML, so we + +18 +00:00:53,040 --> 00:00:56,263 +will also cover UML when discussing this kind of project. Finally, + +19 +00:00:56,263 --> 00:00:58,680 +the fourth kind of process we will consider is the family + +20 +00:00:58,680 --> 00:01:01,670 +of agile software processes. And these are processes in which we + +21 +00:01:01,670 --> 00:01:04,280 +sacrifice the discipline a little bi,t in order to be more + +22 +00:01:04,280 --> 00:01:07,380 +flexible and be more able to account for changes and in + +23 +00:01:07,380 --> 00:01:10,760 +particular for changes in requirements. We are going to cover each + +24 +00:01:10,760 --> 00:01:14,620 +one of these four processes extensively in the rest of the class. + diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/12 - Preliminary Questions - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/12 - Preliminary Questions - lang_en.srt new file mode 100644 index 0000000..20ef47f --- /dev/null +++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/12 - Preliminary Questions - lang_en.srt @@ -0,0 +1,32 @@ +1 +00:00:00,110 --> 00:00:01,450 +So, now before we actually jump to the + +2 +00:00:01,450 --> 00:00:03,410 +discussion of software processes I want to ask you + +3 +00:00:03,410 --> 00:00:05,770 +a couple of preliminary questions. The first one is, + +4 +00:00:05,770 --> 00:00:08,140 +what is the largest software system on which you + +5 +00:00:08,140 --> 00:00:10,860 +had worked? And you should enter here the size. + +6 +00:00:10,860 --> 00:00:12,850 +And the second question I'm going to ask is how + +7 +00:00:12,850 --> 00:00:15,070 +many LOC or how many lines of code per + +8 +00:00:15,070 --> 00:00:17,380 +day you were producing when working on this system? + diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/13 - Preliminary Questions Solution - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/13 - Preliminary Questions Solution - lang_en.srt new file mode 100644 index 0000000..fe239c6 --- /dev/null +++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/13 - Preliminary Questions Solution - lang_en.srt @@ -0,0 +1,16 @@ +1 +00:00:00,110 --> 00:00:01,620 +We're going to go back to these two questions + +2 +00:00:01,620 --> 00:00:03,260 +and to your answers later. But I wanted to + +3 +00:00:03,260 --> 00:00:05,810 +gather this information beforehand, so that your answers are + +4 +00:00:05,810 --> 00:00:08,590 +not biased, they're not influenced by this subsequent discussion. + diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/14 - Preliminary Questions - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/14 - Preliminary Questions - lang_en.srt new file mode 100644 index 0000000..936b50d --- /dev/null +++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/14 - Preliminary Questions - lang_en.srt @@ -0,0 +1,24 @@ +1 +00:00:00,090 --> 00:00:03,200 +So now I want to ask you one additional question, which is how many lines + +2 +00:00:03,200 --> 00:00:05,030 +of code a day do you think professional + +3 +00:00:05,030 --> 00:00:07,370 +software engineers produce? Do you think they produce + +4 +00:00:07,370 --> 00:00:12,160 +25 lines of code? Between 25 and 50? Between 50 and 100? Between 100 and 1000? + +5 +00:00:12,160 --> 00:00:13,720 +Or more than 1000 a day? And remember + +6 +00:00:13,720 --> 00:00:16,379 +that here we're talking about professional software engineers. + diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/15 - Preliminary Questions Solution - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/15 - Preliminary Questions Solution - lang_en.srt new file mode 100644 index 0000000..1a040e2 --- /dev/null +++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/15 - Preliminary Questions Solution - lang_en.srt @@ -0,0 +1,32 @@ +1 +00:00:00,180 --> 00:00:03,450 +Studies has shown that, on average, developers produce between + +2 +00:00:03,450 --> 00:00:07,030 +50 and 100 lines of code a day. And that + +3 +00:00:07,030 --> 00:00:09,530 +might not seem much. Why, why only 50 to + +4 +00:00:09,530 --> 00:00:11,580 +100 lines of code in a whole day? And the + +5 +00:00:11,580 --> 00:00:14,350 +answer is because coding is not everything. When you + +6 +00:00:14,350 --> 00:00:17,020 +develop a system writing code is not the only thing + +7 +00:00:17,020 --> 00:00:18,890 +you have to do. It's not the only activity that + +8 +00:00:18,890 --> 00:00:20,800 +you have to perform. And that's a very important point. + diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/16 - Software Phases - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/16 - Software Phases - lang_en.srt new file mode 100644 index 0000000..7fc30ef --- /dev/null +++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/16 - Software Phases - lang_en.srt @@ -0,0 +1,100 @@ +1 +00:00:00,110 --> 00:00:03,730 +In fact, software processes are normally characterized by several phases, what + +2 +00:00:03,730 --> 00:00:07,240 +we call the software phases, and only one of these phases is + +3 +00:00:07,240 --> 00:00:09,970 +mainly focused on coding. The other phases are meant to support + +4 +00:00:09,970 --> 00:00:13,440 +other parts of software development. The first of these phases is called + +5 +00:00:13,440 --> 00:00:16,110 +requirements engineering and that's the phase in which we talk to + +6 +00:00:16,110 --> 00:00:19,640 +the customer, to the stakeholders, whoever we are building the software for. + +7 +00:00:19,640 --> 00:00:22,120 +And we try to understand what kind of system we need + +8 +00:00:22,120 --> 00:00:25,650 +to build. Then we use this information to define our design and + +9 +00:00:25,650 --> 00:00:28,840 +the design is the high-level structure, that then can become more + +10 +00:00:28,840 --> 00:00:31,800 +and more detailed, of our software system. Once we've defined our + +11 +00:00:31,800 --> 00:00:34,180 +design we can actually move to the next phase, which is + +12 +00:00:34,180 --> 00:00:37,480 +the implementation, in which we write code that implements the design which + +13 +00:00:37,480 --> 00:00:40,630 +we just defined. After implementing the code, we need to verify + +14 +00:00:40,630 --> 00:00:43,510 +and validate the code. We need to make sure that the code + +15 +00:00:43,510 --> 00:00:46,930 +behaves as intended. And finally, we need to maintain the code. + +16 +00:00:46,930 --> 00:00:48,992 +And maintenance involves several activities like, + +17 +00:00:48,992 --> 00:00:50,980 +for example, adding new functionality or + +18 +00:00:50,980 --> 00:00:54,568 +eliminating bugs from the code or responding to problems that + +19 +00:00:54,568 --> 00:00:57,420 +were reported from the field after we released the software. + +20 +00:00:57,420 --> 00:00:59,020 +We will look at all of these activities and of + +21 +00:00:59,020 --> 00:01:01,670 +the software development process in detail, in the rest of the + +22 +00:01:01,670 --> 00:01:03,610 +class. And for each activity, we will look at the + +23 +00:01:03,610 --> 00:01:06,460 +fundamental principles and how it is done currently. And in + +24 +00:01:06,460 --> 00:01:08,780 +some cases, we will also look at some advance ways + +25 +00:01:08,780 --> 00:01:11,680 +to do it. For example, more research approaches for that activity. + diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/17 - Tools of the Trade - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/17 - Tools of the Trade - lang_en.srt new file mode 100644 index 0000000..077c0f8 --- /dev/null +++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/17 - Tools of the Trade - lang_en.srt @@ -0,0 +1,160 @@ +1 +00:00:00,072 --> 00:00:02,960 +We will also look at how tools can improve software phases, + +2 +00:00:02,960 --> 00:00:06,660 +the software activities, and can support software development tasks in general. + +3 +00:00:06,660 --> 00:00:08,890 +And this is something that I will repeat over and over + +4 +00:00:08,890 --> 00:00:12,340 +in the class, tools and automation are fundamental, in software engineering. + +5 +00:00:12,340 --> 00:00:15,910 +And they're fundamental for improving productivity, not only efficiency but also + +6 +00:00:15,910 --> 00:00:19,820 +effectiveness of our activities in the software development process. So let + +7 +00:00:19,820 --> 00:00:22,110 +me go back to one of the diagrams that I showed + +8 +00:00:22,110 --> 00:00:25,170 +you before. If you remember we had this qualititive diagram in which + +9 +00:00:25,170 --> 00:00:27,170 +we were showing that one of the issues that led to the + +10 +00:00:27,170 --> 00:00:30,350 +software crisis was the fact that developers' productivity was not able to + +11 +00:00:30,350 --> 00:00:33,580 +keep up with the software size and complexity, with the growth in + +12 +00:00:33,580 --> 00:00:36,750 +the importance and the complexity of software. What tools can help us + +13 +00:00:36,750 --> 00:00:40,150 +to do is to change this and basically move this curve from + +14 +00:00:40,150 --> 00:00:43,950 +this original position up here. So that it gets closer and closer + +15 +00:00:43,950 --> 00:00:45,970 +to what we need to develop the software that we need to + +16 +00:00:45,970 --> 00:00:50,230 +build. So let me discuss examples on how tools can improve productivity. + +17 +00:00:50,230 --> 00:00:52,970 +For example, if we are talking about development, think about + +18 +00:00:52,970 --> 00:00:54,890 +what kind of improvement it was to go from punch + +19 +00:00:54,890 --> 00:00:58,440 +cards to modern IDEs. If we're talking about languages, think + +20 +00:00:58,440 --> 00:01:02,210 +about of how much more productive developers became when going from + +21 +00:01:02,210 --> 00:01:05,830 +writing machine code to writing code in high-level languages. And + +22 +00:01:05,830 --> 00:01:08,750 +finally, if we talk about debugging, which is a very important + +23 +00:01:08,750 --> 00:01:12,140 +and expensive activity, moving from the use of print lines + +24 +00:01:12,140 --> 00:01:16,060 +to the use of symbolic debuggers dramatically improve the effectiveness and + +25 +00:01:16,060 --> 00:01:18,810 +efficiency of development. And these are just some of the + +26 +00:01:18,810 --> 00:01:21,050 +tools that we will discuss in the rest of the class + +27 +00:01:21,050 --> 00:01:23,350 +and notice that we will also use the tools in practice. + +28 +00:01:23,350 --> 00:01:26,290 +So we will use the tools before projects and also during + +29 +00:01:26,290 --> 00:01:30,153 +the lessons and for assignments. In particular, we will use + +30 +00:01:30,153 --> 00:01:33,920 +three main kinds of tools. The first type is IDE's. And + +31 +00:01:33,920 --> 00:01:37,140 +I'm pretty sure you're familiar with IDE's. These are integrated development + +32 +00:01:37,140 --> 00:01:41,250 +environments. So, advanced editors in which you can write, compile, run, + +33 +00:01:41,250 --> 00:01:43,950 +and debug and even test your code. We'll also use a + +34 +00:01:43,950 --> 00:01:48,190 +version control system, systems that allow you to save, and restore, and + +35 +00:01:48,190 --> 00:01:51,750 +check the differences between different versions of the code, in particular + +36 +00:01:51,750 --> 00:01:53,950 +we will be working with git. We will also be looking at + +37 +00:01:53,950 --> 00:01:57,460 +other kinds of tools like coverage and verification tools. These are + +38 +00:01:57,460 --> 00:02:00,310 +tools that can help you during testing and I'm a big fan + +39 +00:02:00,310 --> 00:02:02,710 +of these tools, so I'm really going to stress the usefulness + +40 +00:02:02,710 --> 00:02:05,530 +of these tools and how you should use them in your development. + diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/2 - Importance of Software Engineering - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/2 - Importance of Software Engineering - lang_en.srt new file mode 100644 index 0000000..858a75a --- /dev/null +++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/2 - Importance of Software Engineering - lang_en.srt @@ -0,0 +1,572 @@ +1 +00:00:00,150 --> 00:00:02,106 +First, let me start by asking a couple of very + +2 +00:00:02,106 --> 00:00:04,820 +natural questions that you might have when considering whether to take + +3 +00:00:04,820 --> 00:00:07,800 +this course. The first one is what is software engineering. + +4 +00:00:07,800 --> 00:00:10,050 +And the second, very related one, is why do we need + +5 +00:00:10,050 --> 00:00:12,430 +it? So what I did was actually to go out + +6 +00:00:12,430 --> 00:00:15,430 +and ask some of the main experts in the field, both + +7 +00:00:15,430 --> 00:00:18,290 +in academia and industry, these very questions and let's see what + +8 +00:00:18,290 --> 00:00:22,160 +they said. What is software engineering and why is it important? + +9 +00:00:23,170 --> 00:00:25,150 +>> Okay, can I start with another question? + +10 +00:00:25,150 --> 00:00:26,020 +>> Of course. + +11 +00:00:26,020 --> 00:00:31,290 +>> Okay, first what is a computer? It's a programmable device. So the essence + +12 +00:00:31,290 --> 00:00:34,730 +of computing is programming. So program development + +13 +00:00:34,730 --> 00:00:37,240 +is basically the most essential use of the + +14 +00:00:37,240 --> 00:00:41,010 +computer. So software engineering is the discipline + +15 +00:00:41,010 --> 00:00:44,850 +that investigates program development. So, how can it + +16 +00:00:44,850 --> 00:00:47,390 +been done more efficiently? What's the best + +17 +00:00:47,390 --> 00:00:50,170 +way of doing program development? And how can + +18 +00:00:50,170 --> 00:00:53,140 +you develop reliable programs? So that's how I would define + +19 +00:00:53,140 --> 00:00:55,060 +it. But I consider any + +20 +00:00:55,060 --> 00:00:57,345 +software development activity software engineering activity + +21 +00:00:58,825 --> 00:01:04,239 +>> Software engineering is the systematic application of methods to build + +22 +00:01:04,239 --> 00:01:07,884 +software in a rigorous way. And I think one of the + +23 +00:01:07,884 --> 00:01:11,196 +aspects that I like to bring into the notion of software + +24 +00:01:11,196 --> 00:01:15,228 +engineering is that it's something that involves not only kind of + +25 +00:01:15,228 --> 00:01:18,612 +technically building the system but understanding the + +26 +00:01:18,612 --> 00:01:22,317 +requirements, working with stake holders. Trying to + +27 +00:01:22,317 --> 00:01:28,232 +find a solution that balances all of the stakeholder needs in order to deliver + +28 +00:01:28,232 --> 00:01:34,338 +the software thats tested and its rigorous to meet the needs of a stakeholder. + +29 +00:01:34,338 --> 00:01:37,656 +Well, software engineering is the whole process + +30 +00:01:37,656 --> 00:01:41,460 +of creation of software using engineering principles. + +31 +00:01:41,460 --> 00:01:42,886 +>> My view is kind of a holistic + +32 +00:01:42,886 --> 00:01:45,490 +view and I think about it from the perspective + +33 +00:01:45,490 --> 00:01:49,440 +of how is software engineering different from programming. + +34 +00:01:49,440 --> 00:01:52,940 +So, I think that research about programming is all + +35 +00:01:52,940 --> 00:01:57,550 +about the create part of software. And that + +36 +00:01:57,550 --> 00:02:00,270 +software engineering is about the entire life cycle. So, + +37 +00:02:00,270 --> 00:02:03,070 +that's one aspect. And the other aspect of the + +38 +00:02:03,070 --> 00:02:07,350 +definition is it's about quality, the quality of software. + +39 +00:02:07,350 --> 00:02:12,330 +Software engineering even considers things long after you ship which we all know + +40 +00:02:12,330 --> 00:02:18,310 +is one of the, it is the largest economic piece of software development. + +41 +00:02:18,310 --> 00:02:22,990 +>> So, improve, software engineering process + +42 +00:02:22,990 --> 00:02:26,440 +for better software productivity and quality. + +43 +00:02:26,440 --> 00:02:32,472 +>> The set of activities that one engages in when building software + +44 +00:02:32,472 --> 00:02:39,634 +systems or software products. It's fundamentally a venue-creating + +45 +00:02:39,634 --> 00:02:45,492 +activity. It involves social processes. + +46 +00:02:45,492 --> 00:02:47,247 +>> Software engineering is the act + +47 +00:02:47,247 --> 00:02:49,652 +of many people working together and putting + +48 +00:02:49,652 --> 00:02:52,057 +together many versions of large and complex + +49 +00:02:52,057 --> 00:02:57,110 +systems. And our world depends on software, + +50 +00:02:57,110 --> 00:02:58,910 +software is immensely complex and we need + +51 +00:02:58,910 --> 00:03:01,700 +many, many smart people to build these things. + +52 +00:03:01,700 --> 00:03:05,610 +>> Well, engineering I think is the activity of envisioning and + +53 +00:03:05,610 --> 00:03:10,180 +realizing valuable new functions with sufficient + +54 +00:03:10,180 --> 00:03:13,500 +and justifiable confidence that the resulting + +55 +00:03:13,500 --> 00:03:18,190 +system will have all of the critical quality attributes that are necessary + +56 +00:03:18,190 --> 00:03:22,140 +for the system to be a success. And software engineering is the + +57 +00:03:22,140 --> 00:03:24,790 +activity of doing this not only for + +58 +00:03:24,790 --> 00:03:27,550 +the software components of engineering systems but + +59 +00:03:28,830 --> 00:03:31,740 +for the system overall, given that it's + +60 +00:03:31,740 --> 00:03:35,500 +so heavily reliant on it's underlying software technologies. + +61 +00:03:35,500 --> 00:03:40,440 +>> So, I would say software engineering is the + +62 +00:03:40,440 --> 00:03:44,070 +kind of art and practice of building software systems. + +63 +00:03:44,070 --> 00:03:47,610 +>> Software engineering, in a nutshell, is a set of + +64 +00:03:47,610 --> 00:03:52,140 +methods and principles and techniques that we have developed to enable us to + +65 +00:03:53,220 --> 00:03:57,830 +engineer, or build, large software systems that + +66 +00:03:59,090 --> 00:04:03,960 +outstrip or outpace one engineer's or even a small + +67 +00:04:03,960 --> 00:04:08,900 +team of engineer's ability or abilities to understand + +68 +00:04:08,900 --> 00:04:13,330 +and construct and maintain + +69 +00:04:13,330 --> 00:04:17,339 +over time. So it requires a lot of people, it requires a long, + +70 +00:04:17,339 --> 00:04:21,820 +term investment by an organization or a number of organizations, and often times + +71 +00:04:21,820 --> 00:04:28,040 +it requires support for systems that that are intended for one purpose but end + +72 +00:04:28,040 --> 00:04:33,930 +up getting used for many additional purposes in addition to the original one. + +73 +00:04:33,930 --> 00:04:38,656 +>> Software engineering is about building and constructing very large-scale + +74 +00:04:38,656 --> 00:04:42,800 +high-quality systems, so the high quality is the big issue. + +75 +00:04:42,800 --> 00:04:46,268 +>> Software engineering is engineering discipline of developing + +76 +00:04:46,268 --> 00:04:52,800 +software-based systems, usually embedded into larger systems composed of + +77 +00:04:52,800 --> 00:04:58,544 +hardware and and humans [LAUGH] and business + +78 +00:04:58,544 --> 00:05:04,943 +processes and processes in general. And why is that important? + +79 +00:05:04,943 --> 00:05:06,971 +Well, because software is pervasive in all industry sectors + +80 +00:05:06,971 --> 00:05:09,001 +and therefore systems must be reliable, safe and secure. + +81 +00:05:09,001 --> 00:05:13,232 +>> Why can't we just get that by sitting down and writing software? + +82 +00:05:13,232 --> 00:05:16,697 +>> Well, you could if software was small and + +83 +00:05:16,697 --> 00:05:20,162 +simple enough to be developed by one or two + +84 +00:05:20,162 --> 00:05:25,360 +people together in a room. But software development now + +85 +00:05:25,360 --> 00:05:31,550 +is distributed, involves teams of people with different backgrounds + +86 +00:05:31,550 --> 00:05:37,450 +who have to communicate with each other. It also involves customers, + +87 +00:05:37,450 --> 00:05:42,512 +clients, users. Software engineers have to work with + +88 +00:05:42,512 --> 00:05:47,462 +hardware engineers, with domain experts and therefore, + +89 +00:05:47,462 --> 00:05:52,233 +well, no, we can't simply sit down and start coding. + +90 +00:05:52,233 --> 00:05:57,380 +>> Software engineering is mostly being able + +91 +00:05:57,380 --> 00:06:02,775 +to program. And you need to be able to put big + +92 +00:06:02,775 --> 00:06:06,920 +systems together so that they actually work. That's my simple definition. + +93 +00:06:06,920 --> 00:06:09,210 +>> And if you don't use software engineering practices, + +94 +00:06:09,210 --> 00:06:10,670 +you're not going to be able to put them together? + +95 +00:06:10,670 --> 00:06:13,290 +>> Well, you're not going to be able to reliably + +96 +00:06:13,290 --> 00:06:16,160 +put them together. So basically, you could maybe hack something up, + +97 +00:06:16,160 --> 00:06:18,750 +but it's not going to necessarily stand the test of time. + +98 +00:06:18,750 --> 00:06:21,221 +If somebody wants to change it it's probably going to break. + +99 +00:06:21,221 --> 00:06:24,140 +>> It's important + +100 +00:06:24,140 --> 00:06:29,700 +because if you don't think about how you're building this system and + +101 +00:06:29,700 --> 00:06:31,600 +how you're trading off different aspects, + +102 +00:06:31,600 --> 00:06:35,580 +like performance and scalability and reliability, then + +103 +00:06:35,580 --> 00:06:39,900 +it's going to end up breaking or not lasting very long or not, + +104 +00:06:39,900 --> 00:06:42,900 +not doing everything that you want it to do, or being really expensive. + +105 +00:06:43,960 --> 00:06:45,800 +>> If it's not done in a principled way it will + +106 +00:06:45,800 --> 00:06:49,220 +be bad and every user will suffer. That's why we need + +107 +00:06:49,220 --> 00:06:49,970 +software engineering. + +108 +00:06:49,970 --> 00:06:56,252 +>> Why is it important? Because, I mean these two goal, productivity, faster, + +109 +00:06:56,252 --> 00:06:59,480 +in developing software. And higher quality + +110 +00:06:59,480 --> 00:07:03,551 +would be apparently important. Software is everywhere. + +111 +00:07:03,551 --> 00:07:08,260 +>> It's important because we use software in everyday life. Everything's + +112 +00:07:08,260 --> 00:07:14,120 +built on software systems. And these are ubiquitous across our society. + +113 +00:07:14,120 --> 00:07:14,300 +>> It's + +114 +00:07:14,300 --> 00:07:20,820 +important because software is everywhere around us and the way we build it, + +115 +00:07:20,820 --> 00:07:26,910 +and the way we maintain it, is something that determines almost a basic + +116 +00:07:26,910 --> 00:07:33,940 +quality of life nowadays. And getting that software right can make a difference, + +117 +00:07:33,940 --> 00:07:39,590 +oftentimes, between a really fun product and one that you won't like to use + +118 +00:07:40,640 --> 00:07:45,750 +a reasonably successful company, or one that fails. And in + +119 +00:07:45,750 --> 00:07:49,690 +more extreme cases even the difference between life and death, + +120 +00:07:49,690 --> 00:07:51,510 +if you think about the software that runs in the + +121 +00:07:51,510 --> 00:07:56,380 +airplane on which many of you fly on a regular basis. + +122 +00:07:56,380 --> 00:08:00,790 +>> There are programs out there that if they screw up we are all screwed. + +123 +00:08:00,790 --> 00:08:02,440 +>> Software engineering is crucially + +124 +00:08:02,440 --> 00:08:06,460 +important because it's the engineering discipline + +125 +00:08:06,460 --> 00:08:10,250 +that is uniquely capable of carrying out + +126 +00:08:10,250 --> 00:08:13,848 +the engineering mission for software reliant systems. + +127 +00:08:13,848 --> 00:08:17,620 +>> In the U.S we've all seen an unfortunate example with + +128 +00:08:17,620 --> 00:08:23,032 +a system that went badly wrong in healthcare.gov and that system wasn't + +129 +00:08:23,032 --> 00:08:26,740 +engineered correctly. And I think if we look at the reasons for + +130 +00:08:26,740 --> 00:08:32,350 +that, they stem back to somewhere at the intersection between requirements and + +131 +00:08:32,350 --> 00:08:37,470 +architecture and politics and project management, and all of these things are + +132 +00:08:37,470 --> 00:08:43,270 +important concepts that have to go into the software engineering mix. + +133 +00:08:43,270 --> 00:08:45,570 +>> It would end up in lots and lots of chaos because people + +134 +00:08:45,570 --> 00:08:47,220 +wouldn't know how to organize themselves and + +135 +00:08:47,220 --> 00:08:49,400 +wouldn't know how to organize software. Many + +136 +00:08:49,400 --> 00:08:53,830 +of software engineering has very simple rules that you need to apply properly in + +137 +00:08:53,830 --> 00:08:57,280 +order to get things done. And people who look at these rules and think, + +138 +00:08:57,280 --> 00:09:01,050 +these rules are so super simple. This is totally obvious. But once + +139 +00:09:01,050 --> 00:09:05,495 +you try to apply them, you'll find out they're not obvious at all. + +140 +00:09:05,495 --> 00:09:07,670 +>> Now that we've heard these experts, let me show you an + +141 +00:09:07,670 --> 00:09:10,080 +example that illustrates what can happen + +142 +00:09:10,080 --> 00:09:12,410 +when software engineering practices are not suitably + +143 +00:09:15,310 --> 00:09:24,010 +applied. [NOISE]. + diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/3 - Software Failure Quiz - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/3 - Software Failure Quiz - lang_en.srt new file mode 100644 index 0000000..f98f98f --- /dev/null +++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/3 - Software Failure Quiz - lang_en.srt @@ -0,0 +1,32 @@ +1 +00:00:00,110 --> 00:00:01,940 +Now that you watched this small video, I like + +2 +00:00:01,940 --> 00:00:03,660 +to ask you, what is this? Do you think + +3 +00:00:03,660 --> 00:00:06,330 +it's fireworks for the 4th of July celebration, or + +4 +00:00:06,330 --> 00:00:08,280 +maybe it was a flare gun in action, or + +5 +00:00:08,280 --> 00:00:10,240 +maybe again it was the explosion of the Ariane + +6 +00:00:10,240 --> 00:00:12,280 +five rocket due to a software error. What do + +7 +00:00:12,280 --> 00:00:14,190 +you think? And in case it helps, I'm also + +8 +00:00:14,190 --> 00:00:16,450 +going to show you an actual picture of this event. + diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/4 - Software Failure Quiz Solution - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/4 - Software Failure Quiz Solution - lang_en.srt new file mode 100644 index 0000000..db633e2 --- /dev/null +++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/4 - Software Failure Quiz Solution - lang_en.srt @@ -0,0 +1,48 @@ +1 +00:00:00,100 --> 00:00:02,600 +As you probably guessed, these are not fireworks for the 4th of + +2 +00:00:02,600 --> 00:00:06,670 +July but, rather, the explosion of the Ariane 5, which happened 30 seconds + +3 +00:00:06,670 --> 00:00:09,250 +or so after takeoff due to a software error. And this is + +4 +00:00:09,250 --> 00:00:12,020 +just an example of what can go wrong when we don't build software + +5 +00:00:12,020 --> 00:00:15,600 +and we don't test and verify and perform quality assurance of software + +6 +00:00:15,600 --> 00:00:18,540 +in the right way, and quite an expensive one. In fact, to develop + +7 +00:00:18,540 --> 00:00:21,250 +and to build the Ariane 5 it took 10 years. The cost + +8 +00:00:21,250 --> 00:00:25,240 +was around $7 billion and there were $500 million of cargo on board. + +9 +00:00:25,240 --> 00:00:27,280 +Luckily, at least there were no humans on the + +10 +00:00:27,280 --> 00:00:29,400 +rocket. And you can find more details in case + +11 +00:00:29,400 --> 00:00:31,610 +you're interested about the Ariane 5 accident in the + +12 +00:00:31,610 --> 00:00:33,230 +lesson notes. I put a couple of links there. + diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/5 - Discipline of Software Engineering - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/5 - Discipline of Software Engineering - lang_en.srt new file mode 100644 index 0000000..6933222 --- /dev/null +++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/5 - Discipline of Software Engineering - lang_en.srt @@ -0,0 +1,80 @@ +1 +00:00:00,140 --> 00:00:02,469 +And even if we don't go to these extreme examples, I'm + +2 +00:00:02,469 --> 00:00:04,380 +sure that you have all experienced + +3 +00:00:04,380 --> 00:00:06,540 +software problems, typically manifested in what + +4 +00:00:06,540 --> 00:00:09,630 +we call a crash. And that crash might happen while you're + +5 +00:00:09,630 --> 00:00:13,230 +finishing your homework or that three-page long email that you were preparing + +6 +00:00:13,230 --> 00:00:15,900 +for the last two hours. But why's it so difficult to + +7 +00:00:15,900 --> 00:00:20,220 +build software, or better, why's it so difficult to build good software? + +8 +00:00:20,220 --> 00:00:22,200 +And how can we do it? This is exactly the topic + +9 +00:00:22,200 --> 00:00:25,190 +of this class. And the reason why software engineering is a fundamental + +10 +00:00:25,190 --> 00:00:28,330 +discipline in computer science. To motivate that, in this class, we + +11 +00:00:28,330 --> 00:00:32,259 +will study a set of methodologies, techniques, and tools, that will help + +12 +00:00:32,259 --> 00:00:35,150 +us build high quality software that does what it's supposed to + +13 +00:00:35,150 --> 00:00:38,540 +do. And therefore, makes our customers happy. And that does it within + +14 +00:00:38,540 --> 00:00:42,375 +the given time and money constraints. So within the budget that + +15 +00:00:42,375 --> 00:00:44,300 +is allocated for the software. Before + +16 +00:00:44,300 --> 00:00:46,222 +jumping into today's software engineering techniques + +17 +00:00:46,222 --> 00:00:48,010 +though, let me take a step back and look at how + +18 +00:00:48,010 --> 00:00:50,240 +we got here, as I believe it is very important to have + +19 +00:00:50,240 --> 00:00:52,690 +some historical perspective on how this discipline was + +20 +00:00:52,690 --> 00:00:54,840 +born and how it was developed over the years. + diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/6 - The Software Crisis - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/6 - The Software Crisis - lang_en.srt new file mode 100644 index 0000000..41061a5 --- /dev/null +++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/6 - The Software Crisis - lang_en.srt @@ -0,0 +1,208 @@ +1 +00:00:00,072 --> 00:00:02,190 +To do that we'll have to go back in time to + +2 +00:00:02,190 --> 00:00:05,280 +the late 60s. So what was happening in the 60s? Well for + +3 +00:00:05,280 --> 00:00:08,410 +example the first man landed on the moon. That was also + +4 +00:00:08,410 --> 00:00:11,720 +time when Woodstock took place and also the time when the first + +5 +00:00:11,720 --> 00:00:16,149 +60 second picture from Polaroid was created. Concurrently to these events, + +6 +00:00:16,149 --> 00:00:18,910 +which you probably didn't witness in first person, that was also the + +7 +00:00:18,910 --> 00:00:22,280 +time when people started to realize that they were not able + +8 +00:00:22,280 --> 00:00:25,610 +to build the software they needed. This happened for several reasons and + +9 +00:00:25,610 --> 00:00:29,220 +resulted in what we call the software crisis. So let's + +10 +00:00:29,220 --> 00:00:31,820 +look at some of the most important reasons behind this + +11 +00:00:31,820 --> 00:00:35,760 +crisis. The first cause was the rising demand for software. + +12 +00:00:35,760 --> 00:00:38,500 +Now you're used to see software everywhere: in your phone, + +13 +00:00:38,500 --> 00:00:41,530 +in your car, even your washing machine. Before the 60s, + +14 +00:00:41,530 --> 00:00:44,590 +however, the size and complexity of software was very limited + +15 +00:00:44,590 --> 00:00:47,580 +and hardware components were really dominating the scene. Then things + +16 +00:00:47,580 --> 00:00:51,490 +started to change and software started to be increasingly prevalent. + +17 +00:00:51,490 --> 00:00:53,940 +So we move from a situation where everything was mostly + +18 +00:00:53,940 --> 00:00:57,380 +hardware to a situation in which software became more and more + +19 +00:00:57,380 --> 00:01:00,660 +important. To give an example, I'm going to show you the growth + +20 +00:01:00,660 --> 00:01:04,080 +in the software demand at NASA along those years. And in + +21 +00:01:04,080 --> 00:01:07,610 +particular, from the 1950s to more or less 2000. And this + +22 +00:01:07,610 --> 00:01:10,350 +is just a qualitative plot but that's more or less the + +23 +00:01:10,350 --> 00:01:13,880 +ways things went. So the demand for software in NASA grow + +24 +00:01:13,880 --> 00:01:16,930 +exponentially. And the same happened in a lot of other companies. + +25 +00:01:16,930 --> 00:01:19,020 +For example, just to cite one, for Boeing. So the + +26 +00:01:19,020 --> 00:01:22,350 +amount of software on airplanes became larger and larger. The + +27 +00:01:22,350 --> 00:01:26,170 +second cause for the software crisis was the increasing amount + +28 +00:01:26,170 --> 00:01:30,210 +of development effort needed due to the increase of product complexity. + +29 +00:01:30,210 --> 00:01:34,260 +Unfortunately, software complexity does not increase linearly with size. It + +30 +00:01:34,260 --> 00:01:36,170 +is not the same thing to write software for a + +31 +00:01:36,170 --> 00:01:39,410 +class exercise or a small project, or a temp project, + +32 +00:01:39,410 --> 00:01:41,970 +than it is to build a software for a word processor, + +33 +00:01:41,970 --> 00:01:45,950 +an operating system, a distributed system, or even more complex and larger + +34 +00:01:45,950 --> 00:01:49,390 +system. And what I'm giving here is just an indicative size for + +35 +00:01:49,390 --> 00:01:52,643 +the software so the class exercise might be 100 lines of code, + +36 +00:01:52,643 --> 00:01:55,600 +the small project might be 1000 lines of code, in the other thousand + +37 +00:01:55,600 --> 00:01:58,328 +lines of code, and so on and so forth. For the former, + +38 +00:01:58,328 --> 00:02:01,510 +the heroic effort of an individual developer can get the job done. + +39 +00:02:01,510 --> 00:02:03,850 +So that's what we call a programming effort. If you're a good + +40 +00:02:03,850 --> 00:02:07,340 +programmer, you can go sit down and do it, right. For the latter, + +41 +00:02:07,340 --> 00:02:09,330 +this is not possible. This is what we called the + +42 +00:02:09,330 --> 00:02:13,810 +software engineering effort. In fact, no matter how much programming languages, + +43 +00:02:13,810 --> 00:02:17,280 +development environments, and software tools improve, developers could not keep + +44 +00:02:17,280 --> 00:02:20,220 +up with increasing software size and complexity. Which leads us to + +45 +00:02:20,220 --> 00:02:22,280 +the third problem that I want to mention and the + +46 +00:02:22,280 --> 00:02:25,020 +third reason for the software crisis. And this cause is the + +47 +00:02:25,020 --> 00:02:28,790 +slow developer's productivity growth. So let me show this again + +48 +00:02:28,790 --> 00:02:32,243 +with a qualitative diagram. And this is taken from the IEEE + +49 +00:02:32,243 --> 00:02:35,550 +Software Magazine. And what I'm showing here is the growth in + +50 +00:02:35,550 --> 00:02:39,930 +software size and complexity over time, and how the developers' productivity + +51 +00:02:39,930 --> 00:02:43,800 +really couldn't keep up with this additional software complexity, which resulted + +52 +00:02:43,800 --> 00:02:47,170 +in this gap between what was needed and what was actually available. + diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/7 - The Software Crisis Quiz - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/7 - The Software Crisis Quiz - lang_en.srt new file mode 100644 index 0000000..004a36c --- /dev/null +++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/7 - The Software Crisis Quiz - lang_en.srt @@ -0,0 +1,44 @@ +1 +00:00:00,078 --> 00:00:02,480 +So now let's take a quick break and have a recap + +2 +00:00:02,480 --> 00:00:05,300 +of what we just discussed. I want you to think about what + +3 +00:00:05,300 --> 00:00:07,850 +are the major causes of the software crisis. I'm going to provide you + +4 +00:00:07,850 --> 00:00:10,250 +a set of possibilities and I would like for you to mark + +5 +00:00:10,250 --> 00:00:14,160 +all that apply. Was that increasing costs of computers? Was it increasing + +6 +00:00:14,160 --> 00:00:17,990 +product complexity, or maybe the lack of programmers? Or was it, instead, + +7 +00:00:17,990 --> 00:00:20,000 +this slow programmers productivity growth? The + +8 +00:00:20,000 --> 00:00:21,540 +lack of funding for software engineering + +9 +00:00:21,540 --> 00:00:25,210 +research? The rise in demand for software? And finally, was it maybe + +10 +00:00:25,210 --> 00:00:26,500 +the lack of caffeine in software + +11 +00:00:26,500 --> 00:00:29,570 +development organizations? Again, mark all that apply. + diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/8 - The Software Crisis Quiz Solution - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/8 - The Software Crisis Quiz Solution - lang_en.srt new file mode 100644 index 0000000..33f5c6c --- /dev/null +++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/8 - The Software Crisis Quiz Solution - lang_en.srt @@ -0,0 +1,52 @@ +1 +00:00:00,090 --> 00:00:02,440 +So, if you think about what we just discussed. Definitely one + +2 +00:00:02,440 --> 00:00:06,210 +of the causes was the increasing product complexity. Products were becoming more + +3 +00:00:06,210 --> 00:00:09,510 +and more complex and software was replacing more and more, what + +4 +00:00:09,510 --> 00:00:11,860 +was before, provided by hardware components. + +5 +00:00:11,860 --> 00:00:14,160 +Slow productivity growth was another problem, + +6 +00:00:14,160 --> 00:00:17,350 +because programmers could not keep up with the additional complexity of + +7 +00:00:17,350 --> 00:00:19,720 +the software that they had to develop. I would like to say + +8 +00:00:19,720 --> 00:00:22,480 +there was lack of funding for software engineering research because I'm + +9 +00:00:22,480 --> 00:00:25,230 +a software engineering researcher, but that was not one of the reasons + +10 +00:00:25,230 --> 00:00:27,200 +for the software crisis. Instead, it was + +11 +00:00:27,200 --> 00:00:30,140 +the rising demand for software. Again, more + +12 +00:00:30,140 --> 00:00:32,060 +and more software was being required and + +13 +00:00:32,060 --> 00:00:33,850 +more and more software was replacing hardware. + diff --git a/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/9 - Evidence of the Software Crisis - lang_en.srt b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/9 - Evidence of the Software Crisis - lang_en.srt new file mode 100644 index 0000000..0592078 --- /dev/null +++ b/usth/ICT2.7/P1L1 Introduction and Overview Subtitles/9 - Evidence of the Software Crisis - lang_en.srt @@ -0,0 +1,116 @@ +1 +00:00:00,120 --> 00:00:03,220 +After recapping the three major issues that characterize a software crisis + +2 +00:00:03,220 --> 00:00:05,626 +let's see what was the evidence that there was indeed a + +3 +00:00:05,626 --> 00:00:07,900 +crisis. So what I want to discuss now is the result + +4 +00:00:07,900 --> 00:00:11,060 +of a study performed by Davis in 1990s. So in even + +5 +00:00:11,060 --> 00:00:13,670 +more recent times than the 60s and the 70s. And the + +6 +00:00:13,670 --> 00:00:17,280 +study was performed on nine software projects that were totaling a + +7 +00:00:17,280 --> 00:00:20,990 +cost around $7 million and I'm going to show you how this + +8 +00:00:20,990 --> 00:00:25,190 +projects went using this representation, this pi representation, in which I'm + +9 +00:00:25,190 --> 00:00:27,520 +going to discuss what each of the segment of the + +10 +00:00:27,520 --> 00:00:30,010 +pi represent. So let's start looking at the first one. + +11 +00:00:30,010 --> 00:00:32,920 +This is a software that was usable as delivered. Other + +12 +00:00:32,920 --> 00:00:36,590 +software was delivered, and usable, either after some changes or + +13 +00:00:36,590 --> 00:00:41,080 +after some major modifications, so within additional costs involved. + +14 +00:00:41,080 --> 00:00:43,530 +But the striking piece of information here is that the + +15 +00:00:43,530 --> 00:00:46,890 +vast majority of the software, so these two slices, were + +16 +00:00:46,890 --> 00:00:50,250 +software that was either delivered but never successfully used or + +17 +00:00:50,250 --> 00:00:53,730 +software that was not even delivered. And this corresponded + +18 +00:00:53,730 --> 00:00:57,500 +to five over the seven total million dollars for + +19 +00:00:57,500 --> 00:01:00,050 +all the projects. So clearly, this shows a pretty + +20 +00:01:00,050 --> 00:01:03,910 +grim picture for software development and its success. In short, + +21 +00:01:03,910 --> 00:01:06,410 +there was clear evidence the software was becoming to + +22 +00:01:06,410 --> 00:01:08,990 +difficult too build and that the software industry was facing + +23 +00:01:08,990 --> 00:01:11,190 +a crisis. And this is what led to the + +24 +00:01:11,190 --> 00:01:15,130 +NATO Software Engineering Conference that was held in January 1969, + +25 +00:01:15,130 --> 00:01:19,100 +which is what we can consider the birth of software engineering. And what + +26 +00:01:19,100 --> 00:01:23,080 +I'm showing here is a drawing of the proceedings for that conference. And if + +27 +00:01:23,080 --> 00:01:26,020 +you look at the class notes you can see a link to the actual + +28 +00:01:26,020 --> 00:01:27,640 +proceedings, in case you are interested in + +29 +00:01:27,640 --> 00:01:29,180 +looking at the issues that were discussed. + diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/1 - Introduction with Barry Boehm - lang_en_vs7.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/1 - Introduction with Barry Boehm - lang_en_vs7.srt new file mode 100644 index 0000000..954db98 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/1 - Introduction with Barry Boehm - lang_en_vs7.srt @@ -0,0 +1,163 @@ +1 +00:00:00,430 --> 00:00:06,300 +Hi, in the last lesson we provided an overview of the course and motivated the + +2 +00:00:06,300 --> 00:00:09,570 +need for software engineering. In this lesson, + +3 +00:00:09,570 --> 00:00:13,090 +we will present and start discussing several traditional + +4 +00:00:13,090 --> 00:00:16,090 +software engineering life cycle models. We will + +5 +00:00:16,090 --> 00:00:18,790 +talk about their main advantages, and also about + +6 +00:00:18,790 --> 00:00:21,840 +their shortcomings. We will also talk about + +7 +00:00:21,840 --> 00:00:25,720 +classic mistakes in software engineering that is well + +8 +00:00:25,720 --> 00:00:29,530 +known ineffective development practices, that when + +9 +00:00:29,530 --> 00:00:32,590 +followed, tend to lead to better results. And + +10 +00:00:32,590 --> 00:00:35,120 +covering those, will hopefully help us to avoid + +11 +00:00:35,120 --> 00:00:38,350 +them in the future. And because in this + +12 +00:00:38,350 --> 00:00:41,290 +lesson, I will discuss some fundamental aspects of + +13 +00:00:41,290 --> 00:00:44,730 +software engineering, to suitably introduce these topics, I + +14 +00:00:44,730 --> 00:00:47,110 +went to the University of Southern California, to + +15 +00:00:47,110 --> 00:00:50,300 +interview one of the fathers of software engineering; + +16 +00:00:50,300 --> 00:00:53,070 +Professor Barry Boehm. + +17 +00:00:53,070 --> 00:00:59,060 +>> A well, a software life cycle is a sequence of, of decisions that you + +18 +00:00:59,060 --> 00:01:01,895 +make, and it's fundamentally those decisions are + +19 +00:01:01,895 --> 00:01:05,280 +going to be part of the history of the + +20 +00:01:05,280 --> 00:01:09,500 +software that. You are going to build that other people are going to use, and + +21 +00:01:09,500 --> 00:01:15,330 +the process model is basically answering the question of what do I do next and + +22 +00:01:15,330 --> 00:01:20,550 +how long shall I do it for. And again, because there are a lot of different ways + +23 +00:01:20,550 --> 00:01:24,220 +you can make that decision, you need to + +24 +00:01:24,220 --> 00:01:27,640 +figure out which models are good for which particular + +25 +00:01:27,640 --> 00:01:31,475 +situations. So, for example, we've, written a book + +26 +00:01:31,475 --> 00:01:34,846 +that's called Balancing Agility and Discipline. It says under + +27 +00:01:34,846 --> 00:01:37,835 +what conditions should you use agile methods, under + +28 +00:01:37,835 --> 00:01:40,824 +which conditions should you invest more time in analyzing + +29 +00:01:40,824 --> 00:01:44,826 +the situation and planning what you're going to do and the like. And so, + +30 +00:01:44,826 --> 00:01:49,866 +typically if the project is, is small where it's three to ten + +31 +00:01:49,866 --> 00:01:55,271 +people, agile works pretty well. If it's 300 + +32 +00:01:55,271 --> 00:02:00,545 +people, then I think we don't want to go that way. If the affect of + +33 +00:02:00,545 --> 00:02:05,960 +the defect is loss of comfort or limited funds, then agile is fine, + +34 +00:02:05,960 --> 00:02:11,184 +but if it is a loss of life, then you don't. On the other hand if, if + +35 +00:02:11,184 --> 00:02:13,776 +you have a situation where you have lot + +36 +00:02:13,776 --> 00:02:17,745 +of unpredictable change, you really don't want to spend + +37 +00:02:17,745 --> 00:02:23,439 +a lot of time writing plans and lots of documents. In some cases you may have a + +38 +00:02:23,439 --> 00:02:26,907 +project where you want to do waterfall in + +39 +00:02:26,907 --> 00:02:31,140 +some parts and agile in others. So, these are + +40 +00:02:31,140 --> 00:02:36,180 +the kind of things that, that make the choice of life cycle process + +41 +00:02:36,180 --> 00:02:41,409 +model very important and very interesting as a subject of research. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/10 - Software Process Model Introduction - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/10 - Software Process Model Introduction - lang_en_vs4.srt new file mode 100644 index 0000000..39d418b --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/10 - Software Process Model Introduction - lang_en_vs4.srt @@ -0,0 +1,79 @@ +1 +00:00:00,240 --> 00:00:02,600 +At this point, you know the possible activities, the + +2 +00:00:02,600 --> 00:00:06,520 +possible phases performed during the software development process. But there + +3 +00:00:06,520 --> 00:00:08,710 +this something that we still haven't discussed, which is + +4 +00:00:08,710 --> 00:00:11,910 +very important. And that is how should we put these + +5 +00:00:11,910 --> 00:00:14,990 +activities together to develop software? And this all comes + +6 +00:00:14,990 --> 00:00:18,360 +down to the concept of software process model. Also called + +7 +00:00:18,360 --> 00:00:21,520 +software lifecycle model. And what this is, is a + +8 +00:00:21,520 --> 00:00:25,470 +prescriptive model of what should happen from the very beginning + +9 +00:00:25,470 --> 00:00:28,960 +to the very end. Of a software development process. The + +10 +00:00:28,960 --> 00:00:31,360 +main function of the life cycle model is to determine + +11 +00:00:31,360 --> 00:00:34,290 +the order of the different activities so that we know + +12 +00:00:34,290 --> 00:00:37,920 +which activities should come first and which ones should follow. Another + +13 +00:00:37,920 --> 00:00:40,910 +important function of the life cycle model is to determine + +14 +00:00:40,910 --> 00:00:45,290 +the transition criteria between activities. So, when we can go from + +15 +00:00:45,290 --> 00:00:48,000 +one phase to the subsequent one. In other words, what + +16 +00:00:48,000 --> 00:00:50,840 +the model should describe is what should we do next and + +17 +00:00:50,840 --> 00:00:53,450 +how long should we continue to do it for each activity + +18 +00:00:53,450 --> 00:00:56,290 +in the model. Now lets see a few traditional software process + +19 +00:00:56,290 --> 00:00:58,920 +models. I will discuss them here at the high level and + +20 +00:00:58,920 --> 00:01:02,000 +then revisit some of these models in the different mini courses. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/11 - Waterfall Process - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/11 - Waterfall Process - lang_en_vs4.srt new file mode 100644 index 0000000..b3d7c07 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/11 - Waterfall Process - lang_en_vs4.srt @@ -0,0 +1,95 @@ +1 +00:00:00,070 --> 00:00:02,830 +The first model we want to discuss is the grandfather of + +2 +00:00:02,830 --> 00:00:05,900 +all life cycle models. And it is the waterfall model. In + +3 +00:00:05,900 --> 00:00:08,890 +the waterfall model the project progresses to an orderly sequence of + +4 +00:00:08,890 --> 00:00:13,040 +steps. From the initial software concept, down until the final phase. + +5 +00:00:13,040 --> 00:00:16,110 +Which is system testing. And at the end of each phase + +6 +00:00:16,110 --> 00:00:18,510 +there will be a review to determine whether the project is + +7 +00:00:18,510 --> 00:00:22,120 +ready to advance to the next phase. The pure waterfall model + +8 +00:00:22,120 --> 00:00:25,340 +performs well for softer products in which there is a stable + +9 +00:00:25,340 --> 00:00:28,400 +product definition. The domain is well known and the technologies + +10 +00:00:28,400 --> 00:00:31,220 +involved are well understood. In these kind of domains, the + +11 +00:00:31,220 --> 00:00:34,350 +waterfall model helps you to find errors in the early, + +12 +00:00:34,350 --> 00:00:37,180 +local stages of the projects. If you remember what we discussed, + +13 +00:00:37,180 --> 00:00:39,950 +this is the place where we want to find errors, + +14 +00:00:39,950 --> 00:00:43,440 +not down here because finding them here will reduce the cost + +15 +00:00:43,440 --> 00:00:47,160 +of our overall software development. The main advantage of the + +16 +00:00:47,160 --> 00:00:50,930 +waterfall model is that it allows you to find errors early. + +17 +00:00:50,930 --> 00:00:53,910 +However, the main disadvantages of the waterfall model arise + +18 +00:00:53,910 --> 00:00:56,550 +from the fact that it is not flexible. Normally, + +19 +00:00:56,550 --> 00:00:59,520 +it is difficult to fully specify requirements at the + +20 +00:00:59,520 --> 00:01:02,470 +beginning of a project. And this lack of flexibility is + +21 +00:01:02,470 --> 00:01:04,800 +far from ideal when dealing with project in which + +22 +00:01:04,800 --> 00:01:07,310 +requirements change, the developers are not domain experts or + +23 +00:01:07,310 --> 00:01:11,130 +the technology used are new and evolving, that is + +24 +00:01:11,130 --> 00:01:14,440 +it is less than ideal for most real world projects. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/12 - Spiral Process - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/12 - Spiral Process - lang_en_vs4.srt new file mode 100644 index 0000000..2d0cdf9 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/12 - Spiral Process - lang_en_vs4.srt @@ -0,0 +1,191 @@ +1 +00:00:00,120 --> 00:00:02,600 +The next model that we will discuss is the spiral + +2 +00:00:02,600 --> 00:00:05,630 +model, which was first described by Barry Boehm, which is + +3 +00:00:05,630 --> 00:00:08,010 +the professor that we interviewed at the beginning of this + +4 +00:00:08,010 --> 00:00:12,240 +lesson. In his paper from 1986 that was entitled A Spiral + +5 +00:00:12,240 --> 00:00:15,730 +Model of Software Development and Enhancement. And one of the + +6 +00:00:15,730 --> 00:00:18,520 +main characteristics of that paper is that it was describing the + +7 +00:00:18,520 --> 00:00:21,670 +spiral model using a diagram, which is the one that + +8 +00:00:21,670 --> 00:00:25,130 +I'm showing you here, and this diagram has become very very + +9 +00:00:25,130 --> 00:00:27,950 +popular, and you probably saw it either in this + +10 +00:00:27,950 --> 00:00:30,400 +form or one of the many variations of the + +11 +00:00:30,400 --> 00:00:32,680 +diagram. So I'm not going to discuss all of + +12 +00:00:32,680 --> 00:00:34,770 +the details of the spiral model, but I just want to + +13 +00:00:34,770 --> 00:00:37,510 +give you an idea of its main characteristics. The + +14 +00:00:37,510 --> 00:00:41,580 +spiral model is an incremental risk-oriented lifecycle model that has + +15 +00:00:41,580 --> 00:00:46,330 +four main phases listed here: determine objectives, identify and + +16 +00:00:46,330 --> 00:00:51,180 +resolve risks, development and tests, and plan the next iteration. + +17 +00:00:51,180 --> 00:00:53,690 +A software project will go through these four phases in + +18 +00:00:53,690 --> 00:00:57,020 +an iterative way. In the first phase, the requirements will + +19 +00:00:57,020 --> 00:00:59,470 +be gathered. In the second phase, the risks and the + +20 +00:00:59,470 --> 00:01:04,010 +alternate solutions will be identified, and a prototype will be produced. + +21 +00:01:04,010 --> 00:01:06,190 +Software and tests for the software are produced in the + +22 +00:01:06,190 --> 00:01:09,210 +development and test phase, which is the third step of the + +23 +00:01:09,210 --> 00:01:12,830 +process. Finally, in the fourth phase, the output of the + +24 +00:01:12,830 --> 00:01:16,880 +project, so far, is evaluated, and the next iteration is planned. + +25 +00:01:16,880 --> 00:01:19,960 +So basically, what the spiral process prescribes is a + +26 +00:01:19,960 --> 00:01:23,262 +way of developing software by going through these phases in + +27 +00:01:23,262 --> 00:01:26,020 +an iterative way, in which we learn more and more + +28 +00:01:26,020 --> 00:01:29,420 +of the software, we identify more and more, and account + +29 +00:01:29,420 --> 00:01:32,250 +for, more and more risks and we go more + +30 +00:01:32,250 --> 00:01:36,000 +and more towards our final solution, our final release. There + +31 +00:01:36,000 --> 00:01:38,930 +are several advantages of using a spiral model. The first + +32 +00:01:38,930 --> 00:01:41,930 +one is that the extensive risk analysis does reduce the + +33 +00:01:41,930 --> 00:01:44,140 +chances of the project to fail. So there is a + +34 +00:01:44,140 --> 00:01:48,300 +risk reduction advantage. The second advantage is that functionality can be + +35 +00:01:48,300 --> 00:01:51,190 +added at a later phase because of the iterative nature of + +36 +00:01:51,190 --> 00:01:55,175 +the process. And finally, software is produced early in the software + +37 +00:01:55,175 --> 00:01:58,260 +lifecycle. So, at any iteration, we have something to show + +38 +00:01:58,260 --> 00:02:01,300 +for our development. We don't wait until the end before producing + +39 +00:02:01,300 --> 00:02:03,790 +something. And then of course there's also the advantage that we + +40 +00:02:03,790 --> 00:02:07,190 +can get early feedback from the customer about what we produced. + +41 +00:02:07,190 --> 00:02:09,000 +The main disadvantages on the other hand of + +42 +00:02:09,000 --> 00:02:11,870 +the spiral model, are that the risk analysis requires + +43 +00:02:11,870 --> 00:02:16,560 +a highly specific expertise. And unfortunately, the whole success + +44 +00:02:16,560 --> 00:02:19,260 +of the process is highly dependent on risk analysis. + +45 +00:02:19,260 --> 00:02:21,580 +So risk analysis has to be done right. + +46 +00:02:21,580 --> 00:02:24,510 +And finally the spiral model is way more complex + +47 +00:02:24,510 --> 00:02:27,180 +than other models, like for example, the water fall + +48 +00:02:27,180 --> 00:02:29,760 +model. And therefore it can be costly to implement. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/13 - Evolutionary Prototyping Process - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/13 - Evolutionary Prototyping Process - lang_en_vs4.srt new file mode 100644 index 0000000..cf068c0 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/13 - Evolutionary Prototyping Process - lang_en_vs4.srt @@ -0,0 +1,167 @@ +1 +00:00:00,080 --> 00:00:02,430 +The next process model I want to discuss is evolutionary + +2 +00:00:02,430 --> 00:00:05,786 +prototyping, which works in four main phases. We start + +3 +00:00:05,786 --> 00:00:08,393 +from an initial concept, then we design and implement + +4 +00:00:08,393 --> 00:00:11,509 +a prototype based on this initial concept, refine the prototype + +5 +00:00:11,509 --> 00:00:14,002 +until it is acceptable, and finally we complete and + +6 +00:00:14,002 --> 00:00:17,550 +release the prototype. Therefore, when developing a system using + +7 +00:00:17,550 --> 00:00:22,330 +evolutionary prototyping, the system is continually refined and rebuilt. + +8 +00:00:22,330 --> 00:00:25,340 +So it is an ideal process when not all requirements + +9 +00:00:25,340 --> 00:00:28,330 +are well understood. Which is a very common situation. So, looking + +10 +00:00:28,330 --> 00:00:30,370 +at this in a little more details, what happens is that + +11 +00:00:30,370 --> 00:00:33,760 +developers start by developing the parts of the system that they + +12 +00:00:33,760 --> 00:00:37,690 +understand, instead of working on developing a whole system, including parts + +13 +00:00:37,690 --> 00:00:40,520 +that might not be very clear at that stage. The partial + +14 +00:00:40,520 --> 00:00:43,900 +system is then shown to the customer and the customer feedback + +15 +00:00:43,900 --> 00:00:47,480 +is used to drive the next iteration, in which either changes + +16 +00:00:47,480 --> 00:00:50,340 +are made to the current features or new features are added. + +17 +00:00:50,340 --> 00:00:53,060 +So, either the current prototype is improved or the + +18 +00:00:53,060 --> 00:00:56,270 +prototype is extended. And finally, when the customer agrees that + +19 +00:00:56,270 --> 00:00:58,980 +the prototype is good enough, the developers will complete all + +20 +00:00:58,980 --> 00:01:01,410 +the remaining work on the system and release the prototype + +21 +00:01:01,410 --> 00:01:03,930 +as the final product. So let's discuss as we did + +22 +00:01:03,930 --> 00:01:06,780 +for the previous process models, what are the main advantages + +23 +00:01:06,780 --> 00:01:10,580 +and disadvantages of evolutionary prototyping. In this case, the main + +24 +00:01:10,580 --> 00:01:15,440 +advantage is the immediate feedback. Developers get feedback immediately as + +25 +00:01:15,440 --> 00:01:17,560 +soon as they produce a prototype and they show it to + +26 +00:01:17,560 --> 00:01:21,050 +the customer and therefore, the risk of implementing the wrong system is + +27 +00:01:21,050 --> 00:01:25,150 +minimized. The main negative is the fact that it's difficult to plan. + +28 +00:01:25,150 --> 00:01:29,070 +When using evolutionary prototype it is difficult to plan in advance how + +29 +00:01:29,070 --> 00:01:31,240 +long the development is going to take, because we don't know how + +30 +00:01:31,240 --> 00:01:34,550 +many iterations will be needed. And another drawback is that it can + +31 +00:01:34,550 --> 00:01:37,120 +easily become an excuse to do kind of do cut and fix + +32 +00:01:37,120 --> 00:01:40,530 +kind of approaches in which we hack something together, fix the main + +33 +00:01:40,530 --> 00:01:43,640 +issues when the customer gives us feedback, and then continue this + +34 +00:01:43,640 --> 00:01:46,780 +way, until the final product is something that is kind of + +35 +00:01:46,780 --> 00:01:49,830 +working, but it's not really a product of high quality. Something + +36 +00:01:49,830 --> 00:01:51,910 +else I want to point out before we move to the next + +37 +00:01:51,910 --> 00:01:54,490 +software process model is that there are many different kinds of + +38 +00:01:54,490 --> 00:01:56,700 +prototyping, so evolutionary prototyping is just + +39 +00:01:56,700 --> 00:01:58,010 +one of them. For example, throwaway + +40 +00:01:58,010 --> 00:02:02,100 +prototyping is another kind of prototyping in which the prototype is + +41 +00:02:02,100 --> 00:02:05,580 +just used to gather requirements, but is thrown away at the end + +42 +00:02:05,580 --> 00:02:08,710 +of the requirements gathering, instead of being evolved as it happens here. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/13 - Evolutionary Prototyping Process - lang_pt_vs2.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/13 - Evolutionary Prototyping Process - lang_pt_vs2.srt new file mode 100644 index 0000000..a1fefdc --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/13 - Evolutionary Prototyping Process - lang_pt_vs2.srt @@ -0,0 +1,167 @@ +1 +00:00:00,080 --> 00:00:02,430 +O próximo modelo que eu quero discutir é prototipagem + +2 +00:00:02,430 --> 00:00:05,786 +evolutiva, que funciona em quatro fases principais. Nós começamos + +3 +00:00:05,786 --> 00:00:08,393 +por um conceito inicial, então nós desenhamos e criamos + +4 +00:00:08,393 --> 00:00:11,509 +um protótipo baseado neste conceito inicial, refinamos o protótipo + +5 +00:00:11,509 --> 00:00:14,002 +até que ele se torne aceitável e finalmente nós completamos e + +6 +00:00:14,002 --> 00:00:17,550 +liberamos o protótipo. Desta maneira, quando desenvolvemos um sistema usando + +7 +00:00:17,550 --> 00:00:22,330 +prototipagem evolutiva, o sistema é constantemente refinado e refeito. + +8 +00:00:22,330 --> 00:00:25,340 +Então este é o processo ideal quando nem todos os requisitos + +9 +00:00:25,340 --> 00:00:28,330 +estão bem compreendidos. O que é uma situação bastante usual. Então, olhando + +10 +00:00:28,330 --> 00:00:30,370 +para isso um pouco mais detalhadamente, o que ocorre é que + +11 +00:00:30,370 --> 00:00:33,760 +os desenvolvedores começam no desenvolvimento das partes do sistema que eles + +12 +00:00:33,760 --> 00:00:37,690 +compreendem, ao invés de trabalhar no desenvolvimento do sistema com um tido, incluindo as + +13 +00:00:37,690 --> 00:00:40,520 +parte que não estão ainda muito claras. O sistema + +14 +00:00:40,520 --> 00:00:43,900 +parcial é então mostrado ao cliente e a opinião do cliente + +15 +00:00:43,900 --> 00:00:47,480 +é usada para guiar a próxima iteração, na qual tanto modificações + +16 +00:00:47,480 --> 00:00:50,340 +são feitas nas atuais feições, como novas feições são adicionadas. + +17 +00:00:50,340 --> 00:00:53,060 +Assim, ou o protótipo atual é melhorado ou o + +18 +00:00:53,060 --> 00:00:56,270 +protótipo é aumentado. E finalmente, quando o cliente concorda de + +19 +00:00:56,270 --> 00:00:58,980 +que o protótipo está suficientemente bom, os desenvolvedores irão completar todo + +20 +00:00:58,980 --> 00:01:01,410 +o trabalho faltante no sistema e liberar o protótipo + +21 +00:01:01,410 --> 00:01:03,930 +como o produto final. Então vamos discutir como fizemos + +22 +00:01:03,930 --> 00:01:06,780 +para os modelos de processos anteriores, quais são as principais vantagens + +23 +00:01:06,780 --> 00:01:10,580 +e desvantagens de prototipagem evolutiva. Neste caso, a principal + +24 +00:01:10,580 --> 00:01:15,440 +vantagem é apreciação imediada. Os desenvolvedores recebem a opinião imediatamente, + +25 +00:01:15,440 --> 00:01:17,560 +tão logo eles produziram o protótipo e o mostraram para o + +26 +00:01:17,560 --> 00:01:21,050 +cliente e desta maneira, o risco de implementar erradamente o sistema é + +27 +00:01:21,050 --> 00:01:25,150 +minimizado. O principal ponto negativo é que isso é difícil de planejar. + +28 +00:01:25,150 --> 00:01:29,070 +Quando é usada a prototipagem evolutiva é difícil de antecipar por + +29 +00:01:29,070 --> 00:01:31,240 +quanto tempo o desenvolvimento irá levar, porquê nós não sabemos quantas + +30 +00:01:31,240 --> 00:01:34,550 +iterações serão necessárias. E outro inconveniente é que isso pode facilmente + +31 +00:01:34,550 --> 00:01:37,120 +se tornar uma desculpa para começar a fazer aquele tipo de abordagem de + +32 +00:01:37,120 --> 00:01:40,530 +"corte-e-correção" na qual nós começamos a enjambrar as coisas, corrigir os + +33 +00:01:40,530 --> 00:01:43,640 +principais defeitos quando o cliente nos dá sua opinião e então continuamos desta + +34 +00:01:43,640 --> 00:01:46,780 +maneira, até que o produto final se torne tipo algo que + +35 +00:01:46,780 --> 00:01:49,830 +funciona, mas que não é de fato um produto de alta qualidade. Outra coisa + +36 +00:01:49,830 --> 00:01:51,910 +que eu quero apontar antes de irmos ao próximo + +37 +00:01:51,910 --> 00:01:54,490 +modelo de criação de software é que existem diversas maneiras de + +38 +00:01:54,490 --> 00:01:56,700 +prototipagem, então a prototipagem evolutiva é apenas + +39 +00:01:56,700 --> 00:01:58,010 +uma delas. Por exemplo, prototipagem + +40 +00:01:58,010 --> 00:02:02,100 +descartável é outra maneira de prototipagem na qual o protótipo é + +41 +00:02:02,100 --> 00:02:05,580 +usado apenas para coletar requisitos, mas é descartado ao final + +42 +00:02:05,580 --> 00:02:08,710 +da coleta de requisitos, ao invés de ser evoluído, como ocorre aqui. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/14 - Rational Unified Process - lang_en_vs5.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/14 - Rational Unified Process - lang_en_vs5.srt new file mode 100644 index 0000000..8bc6db8 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/14 - Rational Unified Process - lang_en_vs5.srt @@ -0,0 +1,111 @@ +1 +00:00:00,070 --> 00:00:02,969 +There are two more software process models that I want to cover, so + +2 +00:00:02,969 --> 00:00:06,120 +bear with me. The first one is the Rational Unified software Process + +3 +00:00:06,120 --> 00:00:09,500 +or IUP, which is s a very popular one based on UML. + +4 +00:00:09,500 --> 00:00:12,620 +RUP works in an iterative way, which means it that it performs different + +5 +00:00:12,620 --> 00:00:16,360 +iterations. And at each iteration, it performs four phases. So what I'm + +6 +00:00:16,360 --> 00:00:19,030 +showing you here, is a high level view of the process. And I + +7 +00:00:19,030 --> 00:00:21,630 +don't want you to focus on all the different details, because we + +8 +00:00:21,630 --> 00:00:25,170 +will discuss these details later on, in a lesson that is actually dedicated + +9 +00:00:25,170 --> 00:00:27,470 +to RUP. What I want to give you now, is just the + +10 +00:00:27,470 --> 00:00:31,020 +gist of how this works. So, in each one of these four + +11 +00:00:31,020 --> 00:00:34,680 +phases, which I'm going to describe in a second. We perform standard software + +12 +00:00:34,680 --> 00:00:38,060 +engineering activities, the ones that we just discussed. And we do them + +13 +00:00:38,060 --> 00:00:41,320 +to different extent, based on the phase in which we are. + +14 +00:00:41,320 --> 00:00:44,841 +In particular, in the inception phase the work is mostly to sculpt + +15 +00:00:44,841 --> 00:00:47,940 +the system. So basically figuring out what is the scope of the + +16 +00:00:47,940 --> 00:00:50,220 +work, what is the scope of the project, what is the domain. + +17 +00:00:50,220 --> 00:00:52,670 +So that we can be able to perform initial cost + +18 +00:00:52,670 --> 00:00:56,190 +and budget estimates. The operational phase is the phase in which + +19 +00:00:56,190 --> 00:00:59,910 +we focus on the domain analysis and define the basic architecture + +20 +00:00:59,910 --> 00:01:03,030 +for the system. So this is a phase in which analysis + +21 +00:01:03,030 --> 00:01:06,290 +and design are particularly paramount. Then there is a construction phase, + +22 +00:01:06,290 --> 00:01:09,250 +which is where the bulk of the development actually occurs. And + +23 +00:01:09,250 --> 00:01:11,640 +as you can see here, is where most of the implementation + +24 +00:01:11,640 --> 00:01:15,280 +happens. And finally, the transition phase is the phase in which + +25 +00:01:15,280 --> 00:01:18,090 +the system goes from development into production, so that + +26 +00:01:18,090 --> 00:01:20,380 +it becomes available to users. And of course, this is + +27 +00:01:20,380 --> 00:01:22,480 +the phase in which the other activities in software + +28 +00:01:22,480 --> 00:01:25,710 +development become less relevant and deployment becomes the main one. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/14 - Rational Unified Process - lang_pt_vs1.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/14 - Rational Unified Process - lang_pt_vs1.srt new file mode 100644 index 0000000..cb089cb --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/14 - Rational Unified Process - lang_pt_vs1.srt @@ -0,0 +1,111 @@ +1 +00:00:00,070 --> 00:00:02,969 +Existem ainda dois outros processos de modelagem de software que eu gostaria de tratar, então + +2 +00:00:02,969 --> 00:00:06,120 +me acompanhem. O primeiro é o Processo Unificado Racional + +3 +00:00:06,120 --> 00:00:09,500 +ou RUP que é um dos mais populares baseados em UML. + +4 +00:00:09,500 --> 00:00:12,620 +RUP opera de uma maneira iterativa, o que significa que ocorrem diversas + +5 +00:00:12,620 --> 00:00:16,360 +iterações. E em cada iteração, são desenvolvidas quatro fases. Então o que eu + +6 +00:00:16,360 --> 00:00:19,030 +estou lhe mostrando aqui, é uma vista panorâmica do processo. E eu + +7 +00:00:19,030 --> 00:00:21,630 +não quero que você foque em todos os detalhes, porquê nós + +8 +00:00:21,630 --> 00:00:25,170 +iremos discutir estes detalhes mais tarde, numa lição que é de fato dedicada + +9 +00:00:25,170 --> 00:00:27,470 +ao RUP. O que eu quero lhe dar agora, é apenas a + +10 +00:00:27,470 --> 00:00:31,020 +essência de como isso funciona. Então, em cada um dessas quatro + +11 +00:00:31,020 --> 00:00:34,680 +fases, que eu irei descrever em breve... Nós desenvolvemos atividades + +12 +00:00:34,680 --> 00:00:38,060 +de engenharia de software padrões, as que nós já discutimos. E nós as fazemos + +13 +00:00:38,060 --> 00:00:41,320 +para diferentes amplitudes, baseadas na fase em que nos encontramos. + +14 +00:00:41,320 --> 00:00:44,841 +Em particular, na fase de Concepção (Iniciação) o trabalho será sobretudo de esculpir + +15 +00:00:44,841 --> 00:00:47,940 +o sistema. E basicamente ilustrando o escopo do + +16 +00:00:47,940 --> 00:00:50,220 +trabalho, qual será o escopo do projeto, qual é o domínio. + +17 +00:00:50,220 --> 00:00:52,670 +E então nós seremos capazes de saber o custo inicial + +18 +00:00:52,670 --> 00:00:56,190 +e fazer um orçamento. A fase de Elaboração é a fase na qual + +19 +00:00:56,190 --> 00:00:59,910 +nós focamos na análise de domínio e definimos a arquitetura de base + +20 +00:00:59,910 --> 00:01:03,030 +do sistema. Então esta é a fase na qual a análise + +21 +00:01:03,030 --> 00:01:06,290 +e o projeto se tornam proeminentes. E então ocorre a fase de Construção, + +22 +00:01:06,290 --> 00:01:09,250 +na qual o desenvolvimento massivo de fato ocorre. E + +23 +00:01:09,250 --> 00:01:11,640 +como você pode ver aqui, é onde a maior parte da implementação + +24 +00:01:11,640 --> 00:01:15,280 +ocorre. E finalmente, a fase de Transição é a fase na qual + +25 +00:01:15,280 --> 00:01:18,090 +o sistema passa do desenvolvimento para a produção, e então + +26 +00:01:18,090 --> 00:01:20,380 +ele se torna disponível aos usuários. E é claro, esta é + +27 +00:01:20,380 --> 00:01:22,480 +a fase na qual as outras atividades em desenvolvimento de + +28 +00:01:22,480 --> 00:01:25,710 +software se tornam menos relevantes e a entrega se torna a principal. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/15 - Agile Process - lang_en_vs3.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/15 - Agile Process - lang_en_vs3.srt new file mode 100644 index 0000000..70ef200 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/15 - Agile Process - lang_en_vs3.srt @@ -0,0 +1,123 @@ +1 +00:00:00,150 --> 00:00:02,300 +The next type of software process models that I + +2 +00:00:02,300 --> 00:00:06,300 +want to discuss are Agile Software Development Processes. And this + +3 +00:00:06,300 --> 00:00:08,470 +is a group of software development methods that are + +4 +00:00:08,470 --> 00:00:12,620 +based on highly iterative and incremental development. And in particular, + +5 +00:00:12,620 --> 00:00:16,000 +I'm going to discuss Test Driven Development or TDD. The + +6 +00:00:16,000 --> 00:00:18,490 +space on the iteration of three main phases. In + +7 +00:00:18,490 --> 00:00:20,970 +the first one that we mark as red, we + +8 +00:00:20,970 --> 00:00:25,350 +write test cases that encode our requirements, and for which + +9 +00:00:25,350 --> 00:00:29,180 +we haven't written code yet. And therefore, they will fail, obviously. + +10 +00:00:29,180 --> 00:00:31,800 +So we're in this sort of red or fail phase. From + +11 +00:00:31,800 --> 00:00:34,830 +this phase, we move to this phase, in which after we + +12 +00:00:34,830 --> 00:00:37,970 +write the just enough code to make the test cases pass. + +13 +00:00:37,970 --> 00:00:40,670 +We have a set of test cases that are all passing. + +14 +00:00:40,670 --> 00:00:43,810 +And therefore, we can consider this as the green phase. We + +15 +00:00:43,810 --> 00:00:46,930 +had enough code to make the test cases pass because the + +16 +00:00:46,930 --> 00:00:50,520 +test cases encode our requirements. We have just written enough code to + +17 +00:00:50,520 --> 00:00:53,940 +satisfy our requirements. When we do this over time though, + +18 +00:00:53,940 --> 00:00:57,080 +what happens is that the structure of the code deteriorates, because + +19 +00:00:57,080 --> 00:00:59,100 +we keep adding pieces. So that's why we have the + +20 +00:00:59,100 --> 00:01:02,540 +first step, which is refactoring. In this step, we modify the + +21 +00:01:02,540 --> 00:01:05,724 +code, and we will talk about refactoring extensively. We'll devote + +22 +00:01:05,724 --> 00:01:08,190 +one lesson to it. We modify the code to make it + +23 +00:01:08,190 --> 00:01:12,650 +more readable, more maintainable. In general, we modify to improve the + +24 +00:01:12,650 --> 00:01:15,560 +design of the code. And after this phase, we will go + +25 +00:01:15,560 --> 00:01:17,670 +back to writing more test cases for + +26 +00:01:17,670 --> 00:01:19,730 +new requirements, write code that makes these + +27 +00:01:19,730 --> 00:01:24,870 +test cases pass, and so on. So we'll continue to iterate among these phases. And + +28 +00:01:24,870 --> 00:01:26,500 +also, in this case, we will talk + +29 +00:01:26,500 --> 00:01:29,390 +about Agile Software Processes. And in particular, + +30 +00:01:29,390 --> 00:01:32,250 +about extreme programming, or XP, and Scrum + +31 +00:01:32,250 --> 00:01:35,349 +in more details, in minor course number four. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/15 - Agile Process - lang_pt_vs1.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/15 - Agile Process - lang_pt_vs1.srt new file mode 100644 index 0000000..b2224ea --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/15 - Agile Process - lang_pt_vs1.srt @@ -0,0 +1,123 @@ +1 +00:00:00,150 --> 00:00:02,300 +O próximo tipo de modelos de processo para software que eu + +2 +00:00:02,300 --> 00:00:06,300 +gostaria de discutir são os Processos Ágil de Desenvolvimento de Software. E este + +3 +00:00:06,300 --> 00:00:08,470 +é um grupo de métodos de desenvolvimento de software que são + +4 +00:00:08,470 --> 00:00:12,620 +baseados em desenvolvimento incremental e altamente iterativo. E em particular, + +5 +00:00:12,620 --> 00:00:16,000 +eu irei discutir é o Desenvolvimento Orientado a Testes, ou TDD. O + +6 +00:00:16,000 --> 00:00:18,490 +espaço na interação de três fases principais. Na + +7 +00:00:18,490 --> 00:00:20,970 +primeira delas que iremos marcar em vermelho, nós + +8 +00:00:20,970 --> 00:00:25,350 +escrevemos casos de teste que codificam nossos requisitos, e para os quais + +9 +00:00:25,350 --> 00:00:29,180 +nós ainda não escrevemos o código. E obviamente, em seguida eles irão falhar. + +10 +00:00:29,180 --> 00:00:31,800 +E então nós iremos cair neste tipo de fase vermelha, ou de falha. Desta + +11 +00:00:31,800 --> 00:00:34,830 +fase, nós passamos para esta outra fase, a qual ocorre depois de nós + +12 +00:00:34,830 --> 00:00:37,970 +escrevermos código suficiente para que os casos de teste aprovem. + +13 +00:00:37,970 --> 00:00:40,670 +Nós temos um conjunto de casos de testes em que todos aprovaram. + +14 +00:00:40,670 --> 00:00:43,810 +E em segunda, nós podemos considerar isso como a fase verde. Nós + +15 +00:00:43,810 --> 00:00:46,930 +temos código suficiente para fazer os casos de teste aprovarem porquê os + +16 +00:00:46,930 --> 00:00:50,520 +casos de teste codificam nossos requisitos. Nós escrevemos código suficiente para + +17 +00:00:50,520 --> 00:00:53,940 +satisfazer nossos requisitos. Quando nós seguimos com isso ao longo do tempo, + +18 +00:00:53,940 --> 00:00:57,080 +o que ocorre é que a estrutura do código deteriora, porquê + +19 +00:00:57,080 --> 00:00:59,100 +nós continuamos adicionando partes! E esta é a razão de nós termos o + +20 +00:00:59,100 --> 00:01:02,540 +primeiro passo, que é a Refatoração. Neste passo, nós modificamos o + +21 +00:01:02,540 --> 00:01:05,724 +código, e nós iremos falar extensamente sobre refatoração. Nós iremos dedicar + +22 +00:01:05,724 --> 00:01:08,190 +uma aula para isso. Nós modificamos o código para o tornar mais + +23 +00:01:08,190 --> 00:01:12,650 +legível, mais fácil de dar manutenção. Em geral, nós modificamos para aprimorar a + +24 +00:01:12,650 --> 00:01:15,560 +concepção do código. E depois desta fase, nós iremos tornar a + +25 +00:01:15,560 --> 00:01:17,670 +escrever mais casos de teste para + +26 +00:01:17,670 --> 00:01:19,730 +novos requisitos... escrever código que faz com que + +27 +00:01:19,730 --> 00:01:24,870 +esses casos de teste aprovem e assim em diante. E então nós iremos continuar a iterar ao entre essas fases. E + +28 +00:01:24,870 --> 00:01:26,500 +também, neste caso, nós iremos falar + +29 +00:01:26,500 --> 00:01:29,390 +sobre Processos Ágil de Desenvolvimento de Software. E em particular, em + +30 +00:01:29,390 --> 00:01:32,250 +Programação Extrema, ou XP e SCRUM + +31 +00:01:32,250 --> 00:01:35,349 +mais detalhadamente, no subcurso número quatro. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/16 - Choosing a Model - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/16 - Choosing a Model - lang_en_vs4.srt new file mode 100644 index 0000000..d898337 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/16 - Choosing a Model - lang_en_vs4.srt @@ -0,0 +1,179 @@ +1 +00:00:00,100 --> 00:00:02,860 +We just saw several software process models, and there + +2 +00:00:02,860 --> 00:00:06,330 +are many, many more. And because these process models define + +3 +00:00:06,330 --> 00:00:09,330 +the master plan for our project, the specific process + +4 +00:00:09,330 --> 00:00:12,220 +model that we choose has as much influence over a + +5 +00:00:12,220 --> 00:00:15,700 +project's success as any other major planning decision that + +6 +00:00:15,700 --> 00:00:18,610 +we make. Therefore, it is very important that we pick + +7 +00:00:18,610 --> 00:00:22,100 +the appropriate model for our development process. Picking an appropriate + +8 +00:00:22,100 --> 00:00:25,100 +model can ensure the success of a project. On the + +9 +00:00:25,100 --> 00:00:27,830 +contrary, if we choose the wrong model, that can be a + +10 +00:00:27,830 --> 00:00:31,010 +constant source of problems and ultimately, it can make the project + +11 +00:00:31,010 --> 00:00:33,830 +fail. So how can we choose the right model for a + +12 +00:00:33,830 --> 00:00:36,310 +project? To be able to do so, we have to take into + +13 +00:00:36,310 --> 00:00:40,490 +consideration many factors. In particular, we need to be aware of + +14 +00:00:40,490 --> 00:00:44,390 +what level of understanding we have of the requirements. Do we understand + +15 +00:00:44,390 --> 00:00:46,720 +all the requirements? Are we going to be able to collect all + +16 +00:00:46,720 --> 00:00:50,430 +the requirements in advance, or collecting requirements is going to be hard and + +17 +00:00:50,430 --> 00:00:53,460 +therefore, we might want to follow a process that is more flexible + +18 +00:00:53,460 --> 00:00:57,470 +with that respect. Another important point is the expected lifetime of the + +19 +00:00:57,470 --> 00:01:00,300 +project. Is this a quick project that we are putting together for + +20 +00:01:00,300 --> 00:01:03,100 +a specific purpose or something that's going to last for for a number + +21 +00:01:03,100 --> 00:01:05,910 +of years and that we're going to maintain over all those years? + +22 +00:01:05,910 --> 00:01:08,380 +That's going to make a difference in the way we decide to develop + +23 +00:01:08,380 --> 00:01:12,190 +that project. Also, what is the level of risk involved? Do we + +24 +00:01:12,190 --> 00:01:15,530 +know the domain very well? Do we know exactly the technologies involved? + +25 +00:01:15,530 --> 00:01:19,100 +Well, if so, we might go with a more traditional process. Otherwise, + +26 +00:01:19,100 --> 00:01:21,902 +we might want to be more agile, more flexible. It is also + +27 +00:01:21,902 --> 00:01:24,900 +very important to know the schedule constraints. How much time, how many + +28 +00:01:24,900 --> 00:01:28,640 +resources do we have for this project? What is the expected interaction + +29 +00:01:28,640 --> 00:01:31,870 +with the management and the customer? In particular for this ladder, there + +30 +00:01:31,870 --> 00:01:34,840 +are many processes that rely on the fact that there can be + +31 +00:01:34,840 --> 00:01:38,310 +a continuous interaction with the customer. If that interaction is not there, + +32 +00:01:38,310 --> 00:01:41,230 +there's no way we are going to be able to use these processes. + +33 +00:01:41,230 --> 00:01:44,580 +Conversely, there are processes that don't require the presence of the customer + +34 +00:01:44,580 --> 00:01:47,868 +at all, except for the initial phase and maybe some checking points and + +35 +00:01:47,868 --> 00:01:51,020 +so if the customer is very inaccessible, we might want to follow + +36 +00:01:51,020 --> 00:01:53,740 +one of those processes, instead of one of the more demanding ones in + +37 +00:01:53,740 --> 00:01:57,340 +terms of customer's time. Finally, it is important to take into account + +38 +00:01:57,340 --> 00:02:00,450 +the level of the expertise of the people involved. Do we have people + +39 +00:02:00,450 --> 00:02:02,730 +that know the technologies that we're using? Do we know people that + +40 +00:02:02,730 --> 00:02:04,590 +know a specific kind of process? + +41 +00:02:04,590 --> 00:02:06,930 +Some processes require some specific expertise and + +42 +00:02:06,930 --> 00:02:09,320 +we're not going to be able to follow that process if we don't + +43 +00:02:09,320 --> 00:02:12,410 +have the right expertise. So we need to take into account all of + +44 +00:02:12,410 --> 00:02:15,570 +these aspects, and sometimes more, in order to be able to make + +45 +00:02:15,570 --> 00:02:19,560 +the right decision and pick the right software process model for our project. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/17 - Choosing a Model Quiz - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/17 - Choosing a Model Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..9f733ac --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/17 - Choosing a Model Quiz - lang_en_vs4.srt @@ -0,0 +1,35 @@ +1 +00:00:00,090 --> 00:00:02,080 +Now before we move to the last part of the lesson, let's + +2 +00:00:02,080 --> 00:00:04,939 +have a quick quiz on software process models to make sure that + +3 +00:00:04,939 --> 00:00:06,640 +we are all on the same page. So I am going to + +4 +00:00:06,640 --> 00:00:10,320 +ask you two questions. The first question is which of the following models + +5 +00:00:10,320 --> 00:00:14,330 +is most suitable to develop a software control system? And when you + +6 +00:00:14,330 --> 00:00:17,700 +think about the software control system, you can think about for example + +7 +00:00:17,700 --> 00:00:21,150 +the control system for the software in an airplane. Would you rather + +8 +00:00:21,150 --> 00:00:22,860 +use a pure waterfall model? Test + +9 +00:00:22,860 --> 00:00:25,840 +driven development? Or an evolutionary prototyping approach? diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/18 - Choosing a Model Quiz Solution - lang_en_vs5.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/18 - Choosing a Model Quiz Solution - lang_en_vs5.srt new file mode 100644 index 0000000..01a444c --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/18 - Choosing a Model Quiz Solution - lang_en_vs5.srt @@ -0,0 +1,47 @@ +1 +00:00:00,080 --> 00:00:02,980 +This is the context in which, typically, a pure + +2 +00:00:02,980 --> 00:00:06,310 +waterfall process will work well. Why? Well, because it's a + +3 +00:00:06,310 --> 00:00:10,160 +context in which requirements are usually well understood. The + +4 +00:00:10,160 --> 00:00:13,020 +domain is well understood, so that kind of system has + +5 +00:00:13,020 --> 00:00:15,900 +been built many times before. And also, it's a + +6 +00:00:15,900 --> 00:00:19,510 +system in which we don't expect requirements to change dramatically + +7 +00:00:19,510 --> 00:00:23,180 +over time. Therefore, a waterfall model, in which we collect + +8 +00:00:23,180 --> 00:00:25,140 +all the requirements at the beginning and then we move + +9 +00:00:25,140 --> 00:00:28,280 +to the subsequent phases might be the most appropriate one. Probably + +10 +00:00:28,280 --> 00:00:30,800 +we don't want to do evolutionary prototyping in the case of + +11 +00:00:30,800 --> 00:00:34,130 +the control system for an airplane. Same thing holds for TDD, + +12 +00:00:34,130 --> 00:00:36,460 +so we want to be a little more rigorous in those cases. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/19 - Choosing a Model Quiz - lang_en_vs5.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/19 - Choosing a Model Quiz - lang_en_vs5.srt new file mode 100644 index 0000000..570d146 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/19 - Choosing a Model Quiz - lang_en_vs5.srt @@ -0,0 +1,11 @@ +1 +00:00:00,110 --> 00:00:03,580 +The second question I want to ask you is which model is the most suitable if you + +2 +00:00:03,580 --> 00:00:06,660 +expect mid-course corrections? Would you rather use a + +3 +00:00:06,660 --> 00:00:10,430 +pure waterfall model, a spiral model, or evolutionary prototyping? diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/2 - Traditional Software Phases - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/2 - Traditional Software Phases - lang_en_vs4.srt new file mode 100644 index 0000000..cc522f0 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/2 - Traditional Software Phases - lang_en_vs4.srt @@ -0,0 +1,75 @@ +1 +00:00:00,160 --> 00:00:02,650 +As we just heard from Professor Bohem, software + +2 +00:00:02,650 --> 00:00:05,970 +engineering is an important and critical discipline, concerned + +3 +00:00:05,970 --> 00:00:09,100 +with cost effective software development. We also heard + +4 +00:00:09,100 --> 00:00:11,170 +that this is based on a systematic approach + +5 +00:00:11,170 --> 00:00:14,580 +that uses appropriate tools and techniques, operates under + +6 +00:00:14,580 --> 00:00:18,130 +specific development constraints. And most importantly, follows a + +7 +00:00:18,130 --> 00:00:20,890 +process. As we discussed in the previous lesson, + +8 +00:00:20,890 --> 00:00:25,770 +the software development process contains fundamental activities, or phases. + +9 +00:00:25,770 --> 00:00:28,480 +Since we will discuss several processes, I'm going to remind + +10 +00:00:28,480 --> 00:00:31,150 +you what these phases are. We start with requirements + +11 +00:00:31,150 --> 00:00:33,630 +engineering, followed by design, + +12 +00:00:33,630 --> 00:00:36,980 +implementation, verification and validation, and + +13 +00:00:36,980 --> 00:00:40,950 +finally maintenance. Note that we will revisit each of + +14 +00:00:40,950 --> 00:00:43,940 +these phases and devote an entire lesson or more + +15 +00:00:43,940 --> 00:00:46,160 +to each phase. So what I want to do next + +16 +00:00:46,160 --> 00:00:48,210 +is simply to give you a quick overview of + +17 +00:00:48,210 --> 00:00:51,020 +what these phases are. Note also that for now + +18 +00:00:51,020 --> 00:00:54,330 +I will follow a very traditional take on these topics. Later on in the + +19 +00:00:54,330 --> 00:00:58,260 +class we will see how things can change and did change over the years. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/20 - Choosing a Model Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/20 - Choosing a Model Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..7ea0e4f --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/20 - Choosing a Model Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,67 @@ +1 +00:00:00,150 --> 00:00:02,860 +In this case, I think about the spiral model, + +2 +00:00:02,860 --> 00:00:06,610 +and evolutionary prototyping model will work. Definitely you don't want to + +3 +00:00:06,610 --> 00:00:09,110 +have a pure water from water. Why? Well because it + +4 +00:00:09,110 --> 00:00:11,940 +is very expensive with a pure waterfall model to make + +5 +00:00:11,940 --> 00:00:15,460 +changes during the course of the project, especially changes + +6 +00:00:15,460 --> 00:00:17,860 +that involve requirements. Why? Because we saw that it can + +7 +00:00:17,860 --> 00:00:20,440 +be very expensive. Whereas with the spiral model, we saw + +8 +00:00:20,440 --> 00:00:25,220 +that being iterative, we can actually make correction throughout development. + +9 +00:00:25,220 --> 00:00:28,840 +Similarly, with evolutionary prototyping, we keep evolving our system + +10 +00:00:28,840 --> 00:00:32,170 +based on the customer feedback. And therefore, if something changes, + +11 +00:00:32,170 --> 00:00:33,810 +we will get feedback right away, and we will + +12 +00:00:33,810 --> 00:00:36,230 +be able to adapt. So the key thing here is + +13 +00:00:36,230 --> 00:00:39,060 +that anything that is iterative works better in the + +14 +00:00:39,060 --> 00:00:43,400 +case of changing environments. So, situations in which your requirements, + +15 +00:00:43,400 --> 00:00:46,720 +the situation, the project might change. Whereas waterfall is + +16 +00:00:46,720 --> 00:00:50,410 +more appropriate for situations in which the requirements are stable, + +17 +00:00:50,410 --> 00:00:53,760 +we know the domain, and possibly we also know the technologies involved. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/21 - Lifecycle Documents - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/21 - Lifecycle Documents - lang_en_vs4.srt new file mode 100644 index 0000000..20e1102 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/21 - Lifecycle Documents - lang_en_vs4.srt @@ -0,0 +1,67 @@ +1 +00:00:00,070 --> 00:00:02,650 +Now that we discussed softer process models, there is + +2 +00:00:02,650 --> 00:00:05,100 +another important point I want to cover, because it's going to + +3 +00:00:05,100 --> 00:00:08,970 +be useful for your projects. Documenting the activities carried out + +4 +00:00:08,970 --> 00:00:11,660 +during the different phases of the softer lifecycle, is a + +5 +00:00:11,660 --> 00:00:14,960 +very important task. The documents that we produce are used + +6 +00:00:14,960 --> 00:00:18,270 +for different purposes, such as communicative details of the software + +7 +00:00:18,270 --> 00:00:21,650 +systems. To difference the colors, ensure the correct implementation of + +8 +00:00:21,650 --> 00:00:25,630 +the system, facilitate maintenance, and so on. There are standardized + +9 +00:00:25,630 --> 00:00:29,230 +document that are provided by IEEE that you can use + +10 +00:00:29,230 --> 00:00:32,680 +for this purpose. However, they're kind of heavyweight. So for the + +11 +00:00:32,680 --> 00:00:35,090 +project in this class, when we will need them, I will + +12 +00:00:35,090 --> 00:00:38,760 +rather use this lightweight documents. That we created by modifying the + +13 +00:00:38,760 --> 00:00:41,730 +original ones, and make them a little simpler. In this, + +14 +00:00:41,730 --> 00:00:44,700 +our documents are actually used, while teaching this class in the + +15 +00:00:44,700 --> 00:00:47,600 +past. So they're well tested and work well for the kind + +16 +00:00:47,600 --> 00:00:50,730 +of projects that we will perform. I provide information on how + +17 +00:00:50,730 --> 00:00:52,880 +to access these documents in the class notes. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/22 - Classic Mistakes: People - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/22 - Classic Mistakes: People - lang_en_vs4.srt new file mode 100644 index 0000000..7edb042 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/22 - Classic Mistakes: People - lang_en_vs4.srt @@ -0,0 +1,163 @@ +1 +00:00:00,120 --> 00:00:02,000 +Now we get to the final part of the lesson. + +2 +00:00:02,000 --> 00:00:04,810 +And in this part I want to talk about well known, + +3 +00:00:04,810 --> 00:00:09,230 +ineffective development practices. These practices, when followed, tend to lead + +4 +00:00:09,230 --> 00:00:13,245 +to predictably bad results. So let's look at some examples of + +5 +00:00:13,245 --> 00:00:17,130 +these classic mistakes. And we're going to start with mistakes + +6 +00:00:17,130 --> 00:00:20,660 +involving people. And notice that there is a long list. So + +7 +00:00:20,660 --> 00:00:23,100 +I'm going to discuss just a few of those mistakes. + +8 +00:00:23,100 --> 00:00:25,215 +And I'm going to point you to more information on this + +9 +00:00:25,215 --> 00:00:27,550 +topic in the class notes. And some of these mistakes are + +10 +00:00:27,550 --> 00:00:30,020 +actually kind of entertaining. So I'll recommend that you look at + +11 +00:00:30,020 --> 00:00:33,210 +the class notes and go in more depth in this list. + +12 +00:00:33,210 --> 00:00:35,550 +So the first people mistake I want to mention is the + +13 +00:00:35,550 --> 00:00:38,945 +one that I define, heroics. And this refers to too much + +14 +00:00:38,945 --> 00:00:43,480 +emphasis on can do attitudes, so this idea that one person + +15 +00:00:43,480 --> 00:00:46,330 +by himself or by herself can do everything and can make + +16 +00:00:46,330 --> 00:00:50,422 +the difference in the whole project. And unfortunately, this encourages extreme + +17 +00:00:50,422 --> 00:00:53,950 +risk taking and discourages cooperation, which is plain bad for + +18 +00:00:53,950 --> 00:00:56,610 +the project. For example, it might force people not to + +19 +00:00:56,610 --> 00:00:59,600 +report schedule slips. It might force people to take on + +20 +00:00:59,600 --> 00:01:02,210 +on too much responsibility. And normally, and I saw it + +21 +00:01:02,210 --> 00:01:05,600 +happen many times, the final result is a failure. So + +22 +00:01:05,600 --> 00:01:08,410 +what you want when you're developing a larger project, is + +23 +00:01:08,410 --> 00:01:11,710 +actually to apply soft engineering principles. Have teams, have team + +24 +00:01:11,710 --> 00:01:15,580 +work, and have cooperation among the different team members, without pointing + +25 +00:01:15,580 --> 00:01:18,830 +too much on single individuals. Another classic mistake + +26 +00:01:18,830 --> 00:01:22,140 +is to not create the right working environment. We + +27 +00:01:22,140 --> 00:01:24,900 +all like to work in nice environments. And there + +28 +00:01:24,900 --> 00:01:27,790 +is strong evidence that the working environments can play + +29 +00:01:27,790 --> 00:01:30,670 +a big role in productivity. There is evidence + +30 +00:01:30,670 --> 00:01:34,280 +that productivity increases when the workplace is nice, quiet, + +31 +00:01:34,280 --> 00:01:37,950 +warm, and welcoming. Finally, some of the most important + +32 +00:01:37,950 --> 00:01:41,480 +people relating mistakes are due to poor people management. + +33 +00:01:41,480 --> 00:01:44,540 +For example, lack of leaderships, or leadership that is + +34 +00:01:44,540 --> 00:01:47,920 +exercised using the wrong means in the wrong way, which + +35 +00:01:47,920 --> 00:01:50,280 +can lead to very unhappy personnel and therefore, low + +36 +00:01:50,280 --> 00:01:54,190 +productivity, or even people leaving teams. Another classic example of + +37 +00:01:54,190 --> 00:01:57,370 +poor management is adding people to a project that + +38 +00:01:57,370 --> 00:02:01,600 +is behind schedule, which never works. Why it doesn't work? + +39 +00:02:01,600 --> 00:02:03,440 +Because these new people need to be brought up to + +40 +00:02:03,440 --> 00:02:06,520 +speed, and that causes further delays rather than improving the + +41 +00:02:06,520 --> 00:02:08,280 +situation with the project schedule. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/23 - Classic Mistakes: Process - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/23 - Classic Mistakes: Process - lang_en_vs4.srt new file mode 100644 index 0000000..83720a0 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/23 - Classic Mistakes: Process - lang_en_vs4.srt @@ -0,0 +1,79 @@ +1 +00:00:00,080 --> 00:00:03,770 +Another type of classic mistakes are process-related mistakes. And also + +2 +00:00:03,770 --> 00:00:05,850 +in this case, these kind of mistakes can be due + +3 +00:00:05,850 --> 00:00:08,970 +to many reasons. And they are of many types. One + +4 +00:00:08,970 --> 00:00:12,310 +typical example are scheduling issues, which are due to the fact + +5 +00:00:12,310 --> 00:00:15,180 +of being unable to come up with a realistic schedule. + +6 +00:00:15,180 --> 00:00:17,750 +So to have an overly optimistic schedule. And this can be + +7 +00:00:17,750 --> 00:00:21,230 +because we underestimate the effort involved in different parts of + +8 +00:00:21,230 --> 00:00:25,010 +the project. Because we overestimate the ability of the people involved. + +9 +00:00:25,010 --> 00:00:27,600 +Because we overestimate the importance, for example, of the use + +10 +00:00:27,600 --> 00:00:29,640 +of tools. But no matter what the reason is, the + +11 +00:00:29,640 --> 00:00:32,840 +result is typically that the projects end up being late, + +12 +00:00:32,840 --> 00:00:35,580 +which is a very common situation. So this is somehow + +13 +00:00:35,580 --> 00:00:39,020 +related to planning. And in general, planning is a fundamental + +14 +00:00:39,020 --> 00:00:42,720 +factor in software processes and in software development. Mistakes in + +15 +00:00:42,720 --> 00:00:46,120 +planning, such as insufficient planning or abandoning planning due to + +16 +00:00:46,120 --> 00:00:50,190 +pressure, usually lead inexorably to failure. And speaking of failures, + +17 +00:00:50,190 --> 00:00:53,040 +often there are unforeseen failures. Such as + +18 +00:00:53,040 --> 00:00:55,410 +failures on the constructor's end, for example, + +19 +00:00:55,410 --> 00:00:56,920 +that might lead to low quality or + +20 +00:00:56,920 --> 00:01:00,580 +late deliverables, which ultimately affects the downstream activities. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/24 - Classic Mistakes: Product - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/24 - Classic Mistakes: Product - lang_en_vs4.srt new file mode 100644 index 0000000..24972d9 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/24 - Classic Mistakes: Product - lang_en_vs4.srt @@ -0,0 +1,87 @@ +1 +00:00:00,090 --> 00:00:01,970 +The third category of mistakes that I want to + +2 +00:00:01,970 --> 00:00:04,970 +mention is product-related mistakes. A + +3 +00:00:04,970 --> 00:00:07,360 +typical example of product-related mistake + +4 +00:00:07,360 --> 00:00:11,010 +is gold plating of requirements. And what that means is + +5 +00:00:11,010 --> 00:00:13,710 +basically is that it's very common for projects to have + +6 +00:00:13,710 --> 00:00:17,230 +more requirements than they actually need. For example, marketing might + +7 +00:00:17,230 --> 00:00:19,090 +want to add more features than the ones that are + +8 +00:00:19,090 --> 00:00:21,460 +actually needed by the users. And of course having more + +9 +00:00:21,460 --> 00:00:25,720 +requirements lengthens the project's schedule in a totally unnecessary way. + +10 +00:00:25,720 --> 00:00:29,250 +Feature creep is another common mistake and consists in + +11 +00:00:29,250 --> 00:00:32,140 +adding more and more features to a product that were + +12 +00:00:32,140 --> 00:00:34,650 +not initially planned and are not really needed in most + +13 +00:00:34,650 --> 00:00:38,360 +cases. And here there is evidence that the average project + +14 +00:00:38,360 --> 00:00:41,180 +experiences about a 25% growth in the number of + +15 +00:00:41,180 --> 00:00:44,330 +features over its lifetime which can clearly highly effect The + +16 +00:00:44,330 --> 00:00:47,580 +project schedule. Finally, if you're working on a project that + +17 +00:00:47,580 --> 00:00:50,760 +strains the limits of computer science. For example, because you + +18 +00:00:50,760 --> 00:00:53,350 +need to develop new algorithms for the project, or you have + +19 +00:00:53,350 --> 00:00:56,670 +to use new techniques. Then that project might be more research than + +20 +00:00:56,670 --> 00:00:58,450 +actual development. And therefore, it + +21 +00:00:58,450 --> 00:01:00,600 +should be managed accordingly. For example, + +22 +00:01:00,600 --> 00:01:03,910 +by taking into account that you will have a highly unpredictable schedule. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/25 - Classic Mistakes: Technology - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/25 - Classic Mistakes: Technology - lang_en_vs4.srt new file mode 100644 index 0000000..16810ac --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/25 - Classic Mistakes: Technology - lang_en_vs4.srt @@ -0,0 +1,95 @@ +1 +00:00:00,080 --> 00:00:02,360 +The final type of classic mistakes that I want + +2 +00:00:02,360 --> 00:00:06,470 +to mention are technology related mistakes. One typical mistake + +3 +00:00:06,470 --> 00:00:09,990 +in this context is the silver-bullet syndrome. What does + +4 +00:00:09,990 --> 00:00:13,340 +that mean? Well, the silver-bullet syndrome refers to situations + +5 +00:00:13,340 --> 00:00:15,900 +in which there is too much reliance on the + +6 +00:00:15,900 --> 00:00:19,950 +advertised benefits of some previously unused technology. For example, + +7 +00:00:19,950 --> 00:00:21,980 +a new technology. And the problem here is that + +8 +00:00:21,980 --> 00:00:25,140 +we cannot expect technology alone to solve our software + +9 +00:00:25,140 --> 00:00:27,810 +development issues. So we should not rely too + +10 +00:00:27,810 --> 00:00:31,020 +much on technology alone. Another typical mistake is to + +11 +00:00:31,020 --> 00:00:33,700 +switch or add tools in the middle of + +12 +00:00:33,700 --> 00:00:36,010 +a project. And sometimes it can make sense to + +13 +00:00:36,010 --> 00:00:38,620 +upgrade a tool, but introducing new tools, which + +14 +00:00:38,620 --> 00:00:41,650 +can have a steep learning curve, has almost always + +15 +00:00:41,650 --> 00:00:46,290 +negative effects. Finally, a common unforgivable mistake is + +16 +00:00:46,290 --> 00:00:50,230 +the lack of an automated version control system for + +17 +00:00:50,230 --> 00:00:53,480 +your code and for your various artifacts. Manual and + +18 +00:00:53,480 --> 00:00:56,700 +ad hoc solutions are just not an option. It is + +19 +00:00:56,700 --> 00:00:59,270 +way too easy to make mistakes, use out of + +20 +00:00:59,270 --> 00:01:02,600 +date versions, be unable to find a previous working version, + +21 +00:01:02,600 --> 00:01:05,030 +and so on. I saw that happening many times, + +22 +00:01:05,030 --> 00:01:08,640 +and it always results in a disaster. So be warned, + +23 +00:01:08,640 --> 00:01:11,650 +use a version control system and an automated one. And + +24 +00:01:11,650 --> 00:01:14,750 +actually we will use version control systems in our projects. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/26 - Classic Mistakes Quiz - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/26 - Classic Mistakes Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..2b4263f --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/26 - Classic Mistakes Quiz - lang_en_vs4.srt @@ -0,0 +1,23 @@ +1 +00:00:00,060 --> 00:00:01,650 +To conclude this lesson, I'm going to have a + +2 +00:00:01,650 --> 00:00:03,650 +simple quiz and what I'm going to ask you + +3 +00:00:03,650 --> 00:00:07,950 +is, which kind of mistake adding people to a late project is? And you can pick + +4 +00:00:07,950 --> 00:00:10,540 +between a people mistake, a product mistake, a + +5 +00:00:10,540 --> 00:00:12,830 +technology mistake, or maybe this is not a + +6 +00:00:12,830 --> 00:00:16,800 +mistake at all, it is actually okay to add people to a project that is late. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/27 - Classic Mistakes Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/27 - Classic Mistakes Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..53c2485 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/27 - Classic Mistakes Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,39 @@ +1 +00:00:00,060 --> 00:00:02,719 +You probably got this one right. The right answer is that + +2 +00:00:02,719 --> 00:00:05,330 +this is a people mistake. And despite the fact that this is + +3 +00:00:05,330 --> 00:00:07,550 +an easy answer, I just want to make sure to stress + +4 +00:00:07,550 --> 00:00:10,800 +once more. Because this is a very classic mistake. And one that + +5 +00:00:10,800 --> 00:00:14,070 +can have dire consequences. You should never add people, to a + +6 +00:00:14,070 --> 00:00:18,430 +late project. Because in 99.9% of the cases, that's only going to make + +7 +00:00:18,430 --> 00:00:21,390 +things worse. Why? Because these people have to be brought up to + +8 +00:00:21,390 --> 00:00:25,590 +speed, and also because having more also makes the communication more difficult, + +9 +00:00:25,590 --> 00:00:27,690 +the meetings more difficult and so on. So in + +10 +00:00:27,690 --> 00:00:29,980 +short, do not add people to a late project. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/3 - Requirements Engineering - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/3 - Requirements Engineering - lang_en_vs4.srt new file mode 100644 index 0000000..c541e70 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/3 - Requirements Engineering - lang_en_vs4.srt @@ -0,0 +1,175 @@ +1 +00:00:00,230 --> 00:00:03,200 +So, let's start with requirements engineering, which is the + +2 +00:00:03,200 --> 00:00:06,560 +field within software engineering that deals with establishing the + +3 +00:00:06,560 --> 00:00:09,400 +needs of stakeholders that are to be solved by + +4 +00:00:09,400 --> 00:00:13,480 +the software. So why is this phase so important? + +5 +00:00:13,480 --> 00:00:16,350 +In general, the cost of correcting an error depends + +6 +00:00:16,350 --> 00:00:19,060 +on the number of subsequent decisions that are based + +7 +00:00:19,060 --> 00:00:22,160 +on it. Therefore, errors made in understanding requirements have + +8 +00:00:22,160 --> 00:00:25,670 +the potential for greatest cost because many other design decisions + +9 +00:00:25,670 --> 00:00:29,020 +depend on them and many other follow up decisions depend on them. + +10 +00:00:29,020 --> 00:00:31,510 +In fact, if we look at this diagram, which is again a + +11 +00:00:31,510 --> 00:00:35,210 +qualitative diagram, where we have the cost of error correction over the + +12 +00:00:35,210 --> 00:00:38,780 +phase in which the error is discovered. We can see that if we + +13 +00:00:38,780 --> 00:00:42,420 +discover an error in requirements it's going to cost us one. If + +14 +00:00:42,420 --> 00:00:45,020 +we find it in in design it's going to cost us five and + +15 +00:00:45,020 --> 00:00:47,410 +so on and so forth. And the cost grows dramatically as we + +16 +00:00:47,410 --> 00:00:50,960 +go from the requirements phase to the maintenance phase. Why? Because of course + +17 +00:00:50,960 --> 00:00:53,092 +if we discover a problem here we're left to undo a + +18 +00:00:53,092 --> 00:00:55,536 +lot of the decision that we had made before to correct the + +19 +00:00:55,536 --> 00:00:58,019 +error. Whereas if we find an error here we can correct it + +20 +00:00:58,019 --> 00:01:01,380 +right away and we don't affect the subsequent phases. So how can + +21 +00:01:01,380 --> 00:01:03,540 +we collect the right requirements. Traditional + +22 +00:01:03,540 --> 00:01:05,310 +requirements in engineering does so through + +23 +00:01:05,310 --> 00:01:08,930 +a set of steps. The first step is elicitation which is the + +24 +00:01:08,930 --> 00:01:12,840 +collection of requirements from stake holders and other sources and can be + +25 +00:01:12,840 --> 00:01:15,890 +done in a variety of ways, we will discuss some of them. + +26 +00:01:15,890 --> 00:01:19,280 +The second is requirement analysis which involved the study and + +27 +00:01:19,280 --> 00:01:23,200 +deeper understanding of the collective requirements. The third step is this + +28 +00:01:23,200 --> 00:01:26,760 +specification of requirements, in which the collective requirements are suitably + +29 +00:01:26,760 --> 00:01:30,730 +represented, organized and save so that they can be shared. Also + +30 +00:01:30,730 --> 00:01:32,530 +in his case, there are many ways to do this, + +31 +00:01:32,530 --> 00:01:34,350 +and we will see some of this ways when we talk + +32 +00:01:34,350 --> 00:01:37,550 +about the requirements engineering in the dedicated lesson. Once the + +33 +00:01:37,550 --> 00:01:40,970 +requirements have been specified, they can be validated to make sure + +34 +00:01:40,970 --> 00:01:44,420 +that they're complete, consistent, no redundant and so on. So + +35 +00:01:44,420 --> 00:01:48,460 +that they've satisfied a set of importance properties, for requirements. + +36 +00:01:48,460 --> 00:01:52,410 +Finally, the fifth step is requirements management which accounts for + +37 +00:01:52,410 --> 00:01:56,100 +changes to requirements during the lifetime of the project. And here + +38 +00:01:56,100 --> 00:01:58,330 +I talked about steps, kind of giving the impression that + +39 +00:01:58,330 --> 00:02:01,310 +we're just going from the first step to the fifth one + +40 +00:02:01,310 --> 00:02:03,300 +and that this is sort of a linear process. In + +41 +00:02:03,300 --> 00:02:05,990 +reality, as we will see, this is more of an iterative + +42 +00:02:05,990 --> 00:02:09,690 +process in which will go and cover the different phases in an + +43 +00:02:09,690 --> 00:02:12,560 +iterative fashion. We will discuss extensively + +44 +00:02:12,560 --> 00:02:15,453 +requirements engineering in our second mini-course. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/4 - Design - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/4 - Design - lang_en_vs4.srt new file mode 100644 index 0000000..5ddb4d1 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/4 - Design - lang_en_vs4.srt @@ -0,0 +1,103 @@ +1 +00:00:00,290 --> 00:00:02,900 +Now let's discuss the next phase of software development, + +2 +00:00:02,900 --> 00:00:06,080 +which is software design. Software design is the phase + +3 +00:00:06,080 --> 00:00:09,030 +where software requirements are analyzed in order to produce + +4 +00:00:09,030 --> 00:00:11,500 +a description of the internal structure and organization of + +5 +00:00:11,500 --> 00:00:13,900 +the system. And this description will serve as the + +6 +00:00:13,900 --> 00:00:17,550 +basis for the construction of the actual system. Traditionally, + +7 +00:00:17,550 --> 00:00:20,020 +the software design phase consists of a series of + +8 +00:00:20,020 --> 00:00:25,360 +design activities. Which normally consists of the architectural design phase, + +9 +00:00:25,360 --> 00:00:27,880 +the abstract specification, interface design, + +10 +00:00:27,880 --> 00:00:30,010 +component design, data structure and + +11 +00:00:30,010 --> 00:00:33,230 +algorithm design. And notice that this is just a possible list + +12 +00:00:33,230 --> 00:00:35,820 +of activities. But you can also characterize design activities in + +13 +00:00:35,820 --> 00:00:38,550 +many different ways. And if you're looking at different books, and + +14 +00:00:38,550 --> 00:00:41,800 +different sources, you might find different activities described. But the + +15 +00:00:41,800 --> 00:00:44,500 +core idea, the important point is that we go from sort + +16 +00:00:44,500 --> 00:00:46,940 +of a high-level view of the system, which is the + +17 +00:00:46,940 --> 00:00:50,770 +architectural design, to a low-level view, which is the algorithm design. + +18 +00:00:50,770 --> 00:00:53,100 +And these activities result in a set of design + +19 +00:00:53,100 --> 00:00:56,810 +products, which describe various characteristics of the system. For + +20 +00:00:56,810 --> 00:00:59,770 +example, they describe the architecture of the system, so + +21 +00:00:59,770 --> 00:01:02,890 +how the system is decomposed and organized into components, the + +22 +00:01:02,890 --> 00:01:06,630 +interfaces between these components. They also describe these components + +23 +00:01:06,630 --> 00:01:09,030 +into a level of details that is suitable for + +24 +00:01:09,030 --> 00:01:12,470 +allowing their construction. We will discuss the details of + +25 +00:01:12,470 --> 00:01:16,130 +software design and talk extensively about these different actives and + +26 +00:01:16,130 --> 00:01:19,200 +these different products in the third mini course of this class. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/5 - Implementation - lang_en_vs5.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/5 - Implementation - lang_en_vs5.srt new file mode 100644 index 0000000..465ae1b --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/5 - Implementation - lang_en_vs5.srt @@ -0,0 +1,103 @@ +1 +00:00:00,150 --> 00:00:02,719 +After we have designed our system we can implement + +2 +00:00:02,719 --> 00:00:05,900 +it. In the implementation phase what we do is basically + +3 +00:00:05,900 --> 00:00:08,410 +taking care of realizing the design of the system + +4 +00:00:08,410 --> 00:00:11,920 +that we just created and create an actual software system. + +5 +00:00:11,920 --> 00:00:15,530 +There are four fundamental principles, four pillars that can + +6 +00:00:15,530 --> 00:00:18,470 +affect the way in which software is constructed. The first + +7 +00:00:18,470 --> 00:00:21,900 +one is the reduction of complexity. This aims to build + +8 +00:00:21,900 --> 00:00:25,160 +software that is easier to understand and use. The second + +9 +00:00:25,160 --> 00:00:28,400 +pillar is the anticipation of diversity. Which takes into + +10 +00:00:28,400 --> 00:00:31,720 +account that software construction might change in various way over + +11 +00:00:31,720 --> 00:00:35,220 +time. That is that software evolves. In many cases, + +12 +00:00:35,220 --> 00:00:38,270 +it evolves in unexpected ways. And therefore, we have to + +13 +00:00:38,270 --> 00:00:41,680 +be able to anticipate some of these changes. The + +14 +00:00:41,680 --> 00:00:45,390 +third pillar is the structuring for validation. Also called design + +15 +00:00:45,390 --> 00:00:47,550 +for testability. And what this means is that we + +16 +00:00:47,550 --> 00:00:50,760 +want to build software so that it is easily testable + +17 +00:00:50,760 --> 00:00:54,890 +during the subsequent validation and verification activities. Finally, and + +18 +00:00:54,890 --> 00:00:58,040 +this is especially true within specific organizations and or + +19 +00:00:58,040 --> 00:01:00,770 +domains. It is important that the software conforms to + +20 +00:01:00,770 --> 00:01:04,330 +a set of internal or external standards. And some examples + +21 +00:01:04,330 --> 00:01:06,730 +of this might be, for example, for internal standards, + +22 +00:01:06,730 --> 00:01:10,680 +coding standards within an organization, or naming standards within an + +23 +00:01:10,680 --> 00:01:13,320 +organization. As for external standards, if for example you + +24 +00:01:13,320 --> 00:01:15,780 +are developing some medical software. There are some regulations and + +25 +00:01:15,780 --> 00:01:17,930 +some standards that you have to adhere to in + +26 +00:01:17,930 --> 00:01:20,060 +order for your software to be valid in that domain. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/6 - Verification & Validation - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/6 - Verification & Validation - lang_en_vs4.srt new file mode 100644 index 0000000..df504a2 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/6 - Verification & Validation - lang_en_vs4.srt @@ -0,0 +1,123 @@ +1 +00:00:00,120 --> 00:00:03,550 +After we have built our system, verification and validation + +2 +00:00:03,550 --> 00:00:05,970 +is that phase of software development that aims to + +3 +00:00:05,970 --> 00:00:09,000 +check that the software system meets its specification and + +4 +00:00:09,000 --> 00:00:12,800 +fulfills its intended purpose. More precisely, we can look + +5 +00:00:12,800 --> 00:00:16,250 +at verification and validation independently. And validation is the + +6 +00:00:16,250 --> 00:00:19,100 +activity that answers the question did we build the + +7 +00:00:19,100 --> 00:00:21,420 +right system. Did we build the system that the + +8 +00:00:21,420 --> 00:00:26,030 +customer wants? That will make the customer happy. Whereas verification + +9 +00:00:26,030 --> 00:00:28,730 +answers a different question which is did we build the system + +10 +00:00:28,730 --> 00:00:31,410 +right. So given a description of the system that is the one + +11 +00:00:31,410 --> 00:00:34,280 +that we derived from the customer through the collection of requirements + +12 +00:00:34,280 --> 00:00:37,130 +and then design and so on, did we build a system that + +13 +00:00:37,130 --> 00:00:41,150 +actually implements the specification that we defined? And when we look + +14 +00:00:41,150 --> 00:00:44,600 +at verification there's many, many ways of doing verification and in fact + +15 +00:00:44,600 --> 00:00:48,430 +in the mini course number four we will cover verification extensively. The + +16 +00:00:48,430 --> 00:00:51,100 +only thing I want to mention here is the fact that verification + +17 +00:00:51,100 --> 00:00:54,110 +can be performed at different levels. In particular, it can be + +18 +00:00:54,110 --> 00:00:57,810 +performed at the unit level in which we test that the individual + +19 +00:00:57,810 --> 00:01:01,520 +units work as a expected. Can be performed in the integration level + +20 +00:01:01,520 --> 00:01:05,525 +in which what we test is the interaction between the different units. + +21 +00:01:05,525 --> 00:01:07,630 +So we want to make sure that the different modules talk + +22 +00:01:07,630 --> 00:01:10,720 +to each other in the right way. And finally, there is system + +23 +00:01:10,720 --> 00:01:13,440 +testing in which we test the system as a whole and we + +24 +00:01:13,440 --> 00:01:16,170 +want to make sure that all the system, all the different pieces + +25 +00:01:16,170 --> 00:01:18,010 +of the system work together in the right + +26 +00:01:18,010 --> 00:01:20,160 +way. And this is also the level at which + +27 +00:01:20,160 --> 00:01:22,360 +then we will apply validation and some other + +28 +00:01:22,360 --> 00:01:25,770 +testing techniques like stress testing or robustness testing and + +29 +00:01:25,770 --> 00:01:29,890 +so on. And as I said I'm not going to say anything more on this topic because + +30 +00:01:29,890 --> 00:01:32,760 +we will cover verification, and validation, and testing in + +31 +00:01:32,760 --> 00:01:35,667 +particular in great details in mini course number four. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/7 - Maintenance - lang_en_vs5.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/7 - Maintenance - lang_en_vs5.srt new file mode 100644 index 0000000..e3d95bf --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/7 - Maintenance - lang_en_vs5.srt @@ -0,0 +1,167 @@ +1 +00:00:00,012 --> 00:00:03,482 +As we discussed before software development efforts normally result + +2 +00:00:03,482 --> 00:00:06,127 +in the delivery of a software product that satisfies + +3 +00:00:06,127 --> 00:00:09,879 +the user requirements. So normally our software development organization + +4 +00:00:09,879 --> 00:00:13,127 +will release this application to its final users, however, once + +5 +00:00:13,127 --> 00:00:16,090 +the software is in operation many things can happen. + +6 +00:00:16,090 --> 00:00:18,950 +So, for example, the environment might change. There might be + +7 +00:00:18,950 --> 00:00:21,940 +new libraries. There might be new systems in which + +8 +00:00:21,940 --> 00:00:25,070 +our software has to operate. Or they may be future + +9 +00:00:25,070 --> 00:00:27,950 +requests, so the users may find out that, guess what, + +10 +00:00:27,950 --> 00:00:30,370 +they want to do something different with the problem that + +11 +00:00:30,370 --> 00:00:32,835 +we gave them. Or, again, and this is one of + +12 +00:00:32,835 --> 00:00:35,970 +the most common occurrences, users might find problems with the + +13 +00:00:35,970 --> 00:00:38,307 +software and may file bug reports and send the bug + +14 +00:00:38,307 --> 00:00:42,090 +reports back to the software developer. These are the reasons + +15 +00:00:42,090 --> 00:00:46,420 +why software maintenance is a necessary phase in software development. + +16 +00:00:46,420 --> 00:00:50,190 +Software maintenance is the activity that sustains the software product + +17 +00:00:50,190 --> 00:00:53,780 +as it evolves throughout its life cycle, specifically + +18 +00:00:53,780 --> 00:00:57,350 +in response to bug reports, feature requests and + +19 +00:00:57,350 --> 00:01:00,890 +environment changes. Development organisations perform three kinds of + +20 +00:01:00,890 --> 00:01:04,450 +maintenance activities: corrective maintenance to eliminate problems with the + +21 +00:01:04,450 --> 00:01:07,740 +code, perfective maintenance to accommodate feature request, and + +22 +00:01:07,740 --> 00:01:09,730 +in some cases just to improve the software, for + +23 +00:01:09,730 --> 00:01:12,230 +example, to make it more efficient, and finally, + +24 +00:01:12,230 --> 00:01:15,650 +adaptive maintenance, to take care of the environment changes. + +25 +00:01:15,650 --> 00:01:18,470 +And after this activities have been performed, the software developer + +26 +00:01:18,470 --> 00:01:21,540 +will produce a new version of the application, will release it + +27 +00:01:21,540 --> 00:01:24,150 +and the cycle will continue through out the lifetime of + +28 +00:01:24,150 --> 00:01:27,440 +the software. That's why maintenance is a fundamental activity and a + +29 +00:01:27,440 --> 00:01:30,420 +very expensive one. And one of the reasons why maintenance + +30 +00:01:30,420 --> 00:01:34,080 +is expensive, that I want to mention now, is regression testing. + +31 +00:01:34,080 --> 00:01:37,180 +During maintenance every time you modify your application you have + +32 +00:01:37,180 --> 00:01:41,120 +to regression test the application, where regression testing is the activity + +33 +00:01:41,120 --> 00:01:44,010 +of retesting software after it has been modified to make sure + +34 +00:01:44,010 --> 00:01:47,320 +that the changes you perform to the software work as expected, + +35 +00:01:47,320 --> 00:01:51,540 +and that your changes did not introduce any unforseen effect. I'm + +36 +00:01:51,540 --> 00:01:53,630 +pretty sure that you're familiar with the case of a new + +37 +00:01:53,630 --> 00:01:56,000 +version of the software being released and just a couple of + +38 +00:01:56,000 --> 00:01:59,260 +days later another version being released to fix some problems that + +39 +00:01:59,260 --> 00:02:02,000 +occor with the new version. These problems is what we call + +40 +00:02:02,000 --> 00:02:04,640 +regression errors and they're what regression + +41 +00:02:04,640 --> 00:02:06,560 +testing targets and tries to eliminate + +42 +00:02:06,560 --> 00:02:09,240 +before the new version of the software is released into the world. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/8 - Software Phases Quiz - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/8 - Software Phases Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..e3fe74b --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/8 - Software Phases Quiz - lang_en_vs4.srt @@ -0,0 +1,47 @@ +1 +00:00:00,070 --> 00:00:02,590 +Okay. Now before we jump into the next + +2 +00:00:02,590 --> 00:00:04,780 +topic, I just want to take a very quick and + +3 +00:00:04,780 --> 00:00:06,630 +simple quiz just to make sure that you + +4 +00:00:06,630 --> 00:00:09,236 +guys paid attention to what I just discussed. So + +5 +00:00:09,236 --> 00:00:10,820 +I want to ask you what are the traditional + +6 +00:00:10,820 --> 00:00:13,200 +software phases. Requirements engineering, + +7 +00:00:13,200 --> 00:00:16,079 +design, abstraction, implementation, verification and + +8 +00:00:16,079 --> 00:00:18,020 +validation. Or maybe design, + +9 +00:00:18,020 --> 00:00:20,830 +optimization, implementation verification and validation + +10 +00:00:20,830 --> 00:00:22,448 +and maintenance. Or requirements + +11 +00:00:22,448 --> 00:00:24,892 +engineering, design, implementation, verification and + +12 +00:00:24,892 --> 00:00:26,290 +validation, and maintenance. diff --git a/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/9 - Software Phases Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/9 - Software Phases Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..ecb7a35 --- /dev/null +++ b/usth/ICT2.7/P1L2 Life Cycle Models Subtitles/9 - Software Phases Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,15 @@ +1 +00:00:00,190 --> 00:00:04,000 +And the answer is the third one. The traditional software phases which are the + +2 +00:00:04,000 --> 00:00:05,960 +ones that we just discussed are requirements + +3 +00:00:05,960 --> 00:00:08,820 +engineering, design, implementation, verification + +4 +00:00:08,820 --> 00:00:10,630 +and validation, and maintenance. diff --git a/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/1 - Lesson Overview - lang_en_vs5.srt b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/1 - Lesson Overview - lang_en_vs5.srt new file mode 100644 index 0000000..afc573d --- /dev/null +++ b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/1 - Lesson Overview - lang_en_vs5.srt @@ -0,0 +1,39 @@ +1 +00:00:00,650 --> 00:00:07,470 +Hi, and welcome to the first of several lessons on tools of the trade. I'm + +2 +00:00:07,470 --> 00:00:12,200 +very excited about these lessons, because I believe that tools are a cornerstone + +3 +00:00:12,200 --> 00:00:14,390 +of the software engineering discipline, and it + +4 +00:00:14,390 --> 00:00:17,570 +is of paramount importance to know and + +5 +00:00:17,570 --> 00:00:20,330 +use them. In this lesson, we will + +6 +00:00:20,330 --> 00:00:25,530 +talk about integrated development environments, normally called IDEs. + +7 +00:00:25,530 --> 00:00:29,780 +And these are software applications that support developers in many of their + +8 +00:00:29,780 --> 00:00:36,870 +everyday tasks, such as writing, compiling, and debugging code. And to make the + +9 +00:00:36,870 --> 00:00:42,470 +discussion more concrete we will focus on a specific IDE, Eclipse. We will + +10 +00:00:42,470 --> 00:00:47,250 +first present Eclipse, and then get some hands-on experience through a demo. diff --git a/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/2 - Eclipse Introduction - lang_en_vs5.srt b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/2 - Eclipse Introduction - lang_en_vs5.srt new file mode 100644 index 0000000..1d0ff56 --- /dev/null +++ b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/2 - Eclipse Introduction - lang_en_vs5.srt @@ -0,0 +1,91 @@ +1 +00:00:00,160 --> 00:00:02,750 +As I just told you, tools are fundamental in + +2 +00:00:02,750 --> 00:00:06,050 +software engineering. And I will stress this concept over and + +3 +00:00:06,050 --> 00:00:08,240 +over, throughout the class. And today we're going to talk + +4 +00:00:08,240 --> 00:00:11,310 +about a tool that is especially important, which is integrated + +5 +00:00:11,310 --> 00:00:15,060 +development environments, or IDEs. And you're probably familiar with + +6 +00:00:15,060 --> 00:00:18,060 +IDEs. So IDEs are environments that give you support for + +7 +00:00:18,060 --> 00:00:21,580 +your development activities. For example, for writing code, editing code, + +8 +00:00:21,580 --> 00:00:25,320 +compiling code, and so on. And we will focus specifically + +9 +00:00:25,320 --> 00:00:28,890 +on one particular IDE, which is called Eclipse. And + +10 +00:00:28,890 --> 00:00:31,450 +what I'm showing here is the two splash screens for + +11 +00:00:31,450 --> 00:00:35,350 +two versions of eclipse, Helios and Kepler. Eclipse is an + +12 +00:00:35,350 --> 00:00:39,200 +open, extensible development environment that was initially created by IBM + +13 +00:00:39,200 --> 00:00:41,510 +and is now managed by the Eclipse Foundation. And of + +14 +00:00:41,510 --> 00:00:43,840 +course, there are many other great IDEs such as for + +15 +00:00:43,840 --> 00:00:47,310 +example, Microsoft Visual Studio or Netbeans. We will be using + +16 +00:00:47,310 --> 00:00:50,830 +Eclipse because it is open and because it is multi-platform, + +17 +00:00:50,830 --> 00:00:52,390 +which means that you can use Eclipse + +18 +00:00:52,390 --> 00:00:55,140 +no matter what operating system we're using. + +19 +00:00:55,140 --> 00:00:59,030 +So if we consider the most commonly used operating system, such as Mac + +20 +00:00:59,030 --> 00:01:02,780 +OS, Windows, Linux, Eclipse runs on any + +21 +00:01:02,780 --> 00:01:04,769 +of these environments. Therefore, no matter what + +22 +00:01:04,769 --> 00:01:06,490 +you're using, you'll be able to install + +23 +00:01:06,490 --> 00:01:08,560 +Eclipse, run Eclipse, and follow the class. diff --git a/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/3 - IDE Overview - lang_en_vs6.srt b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/3 - IDE Overview - lang_en_vs6.srt new file mode 100644 index 0000000..e2b63b3 --- /dev/null +++ b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/3 - IDE Overview - lang_en_vs6.srt @@ -0,0 +1,143 @@ +1 +00:00:00,130 --> 00:00:05,680 +So, now let's look in a little more detail to what is an IDE. An IDE is a + +2 +00:00:05,680 --> 00:00:09,790 +software application that supports software developers in many of + +3 +00:00:09,790 --> 00:00:13,840 +their everyday tasks. It has many useful features. Most IDEs + +4 +00:00:13,840 --> 00:00:16,790 +provide views that can be used to navigate, project + +5 +00:00:16,790 --> 00:00:20,140 +resources from different perspectives. For example, you might want to + +6 +00:00:20,140 --> 00:00:22,390 +look at your code differently when you're writing code, + +7 +00:00:22,390 --> 00:00:25,950 +and when you're debugging. They also normally provide an intelligent + +8 +00:00:25,950 --> 00:00:29,380 +source code editor. For example, an editor that will allow you + +9 +00:00:29,380 --> 00:00:32,110 +to browse the documentation when you're writing a code that + +10 +00:00:32,110 --> 00:00:35,780 +uses a specific method, or that will give you autocompletion when + +11 +00:00:35,780 --> 00:00:37,990 +you start writing the name of an object and you want to + +12 +00:00:37,990 --> 00:00:40,820 +get the methods for that object. And all of these things + +13 +00:00:40,820 --> 00:00:43,420 +can be very useful while you're developing and can save you a + +14 +00:00:43,420 --> 00:00:47,750 +lot of time. Modern IDE's will also normally give you support for + +15 +00:00:47,750 --> 00:00:49,540 +version control systems that then you + +16 +00:00:49,540 --> 00:00:52,490 +can use for softer configuration management. + +17 +00:00:52,490 --> 00:00:55,720 +And we're going to discuss in detail version control systems in + +18 +00:00:55,720 --> 00:00:58,380 +the next tools of the trade lesson, and we're also + +19 +00:00:58,380 --> 00:01:01,135 +going to see how it can be integrated within an IDE. + +20 +00:01:01,135 --> 00:01:04,730 +IDEs also give you builders so they give you build automation + +21 +00:01:04,730 --> 00:01:08,070 +tools, they give you runtime support. So that you can + +22 +00:01:08,070 --> 00:01:10,960 +run your projects from within the IDE and, for example, + +23 +00:01:10,960 --> 00:01:14,550 +observe some aspects of the execution. In addition to giving + +24 +00:01:14,550 --> 00:01:17,562 +you support for the runtime, they give you support for testing. + +25 +00:01:17,562 --> 00:01:21,267 +Many IDEs allow you to run tests from within + +26 +00:01:21,267 --> 00:01:23,520 +the IDE and to check the results of the tests + +27 +00:01:23,520 --> 00:01:26,300 +from within the IDE. Not only that. Normally, after you + +28 +00:01:26,300 --> 00:01:28,210 +run your tests, if there are some test cases that + +29 +00:01:28,210 --> 00:01:31,500 +fail, you can also use your IDEs to do debugging. + +30 +00:01:31,500 --> 00:01:35,620 +Many IDEs include graphical debuggers. Debuggers will allow you to + +31 +00:01:35,620 --> 00:01:39,400 +navigate through the code, set which points, stop and restart + +32 +00:01:39,400 --> 00:01:43,160 +the execution. Inspect variables, and do all of the activities + +33 +00:01:43,160 --> 00:01:46,320 +that help debugging. And, to help you be more efficient + +34 +00:01:46,320 --> 00:01:49,440 +and more effective when you do debugging. And into addition to + +35 +00:01:49,440 --> 00:01:52,760 +all these features that are listed here IDEs can normally provide + +36 +00:01:52,760 --> 00:01:56,650 +you even more features through a mechanishm that is called plugins. diff --git a/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/4 - Plug-Ins - lang_en_vs5.srt b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/4 - Plug-Ins - lang_en_vs5.srt new file mode 100644 index 0000000..040293e --- /dev/null +++ b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/4 - Plug-Ins - lang_en_vs5.srt @@ -0,0 +1,99 @@ +1 +00:00:00,110 --> 00:00:03,134 +In fact most IDEs are extensible through the use of + +2 +00:00:03,134 --> 00:00:06,158 +plug-ins. And by the way, note that plug-ins might be + +3 +00:00:06,158 --> 00:00:09,326 +called differently on different platforms. For example, if you're using + +4 +00:00:09,326 --> 00:00:12,970 +a Microsoft Visual Studio, plug-ins are normally called add-ins, but + +5 +00:00:12,970 --> 00:00:15,598 +the concept is more or less the same. So, what + +6 +00:00:15,598 --> 00:00:18,555 +is a plug-in? Well, let's imagine our IDE to be + +7 +00:00:18,555 --> 00:00:22,320 +this box. A plug-in is additional functionality that you can + +8 +00:00:22,320 --> 00:00:25,430 +actually plug into this box so that this box starts + +9 +00:00:25,430 --> 00:00:28,830 +offering more features to the user. For example, you + +10 +00:00:28,830 --> 00:00:32,850 +can add to Eclipse the Checkstyle plug-in. Which, paraphrasing the + +11 +00:00:32,850 --> 00:00:35,950 +Checkstyle website, helps you ensure that your Java code + +12 +00:00:35,950 --> 00:00:38,890 +complies with a set of coding standards by inspecting the + +13 +00:00:38,890 --> 00:00:41,690 +code and pointing out items that deviate from a + +14 +00:00:41,690 --> 00:00:44,870 +defined set of coding rules. Again, this is a functionality + +15 +00:00:44,870 --> 00:00:47,330 +the core of Eclipse doesn't have. You can add + +16 +00:00:47,330 --> 00:00:50,600 +the Checkstyle plug-in, and this functionality will become available in + +17 +00:00:50,600 --> 00:00:54,840 +the IDE. Another example of plug-in is the EGit plug-in which + +18 +00:00:54,840 --> 00:00:58,660 +adds support for the Git version control system in Eclipse. And + +19 +00:00:58,660 --> 00:01:01,290 +actually this is something that we'll cover in detail, we'll have + +20 +00:01:01,290 --> 00:01:04,150 +a demo, and we will actually use it throughout the class, so + +21 +00:01:04,150 --> 00:01:07,018 +I'm not going to say anything more about the EGit plug-in for + +22 +00:01:07,018 --> 00:01:09,300 +now. But again, what the plug-in will do is to add + +23 +00:01:09,300 --> 00:01:13,220 +the Git functionality to Eclipse. A functionality that is not in + +24 +00:01:13,220 --> 00:01:16,110 +the core of Eclipse and that is available to the user after + +25 +00:01:16,110 --> 00:01:17,181 +you add the plug-in. diff --git a/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/5 - Eclipse Demo: Create Java Project - lang_en_vs5.srt b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/5 - Eclipse Demo: Create Java Project - lang_en_vs5.srt new file mode 100644 index 0000000..8788858 --- /dev/null +++ b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/5 - Eclipse Demo: Create Java Project - lang_en_vs5.srt @@ -0,0 +1,323 @@ +1 +00:00:00,070 --> 00:00:02,550 +In the rest of this lesson we're going to look at eclipse and + +2 +00:00:02,550 --> 00:00:05,290 +try to get more familiar with eclipse in a hands on manner + +3 +00:00:05,290 --> 00:00:07,550 +through a demo. In the demo we will cover some of the + +4 +00:00:07,550 --> 00:00:11,040 +basic aspects of eclipse like how to run eclipse, how to select + +5 +00:00:11,040 --> 00:00:14,400 +their workspace, how to create a project, how to create the class + +6 +00:00:14,400 --> 00:00:18,240 +within the project and so on. I'll also cover some more advanced + +7 +00:00:18,240 --> 00:00:21,610 +aspects, like how to create builders, run your project within Eclipse, and + +8 +00:00:21,610 --> 00:00:25,800 +how to use their Eclipse debugger. So let's get to the demo. + +9 +00:00:25,800 --> 00:00:28,220 +So let's start Eclipse. Eclipse is going to ask me + +10 +00:00:28,220 --> 00:00:31,600 +for the location of my workspace and in this + +11 +00:00:31,600 --> 00:00:34,530 +case, I selected a suitable directory and you can + +12 +00:00:34,530 --> 00:00:38,480 +also use that checkbox on the left to avoid Eclipse + +13 +00:00:38,480 --> 00:00:40,640 +for asking you again about where to put the + +14 +00:00:40,640 --> 00:00:43,860 +workspace. And the workspace is basically the place the + +15 +00:00:43,860 --> 00:00:48,310 +directory. Where, Eclipse will place all of your projects. + +16 +00:00:48,310 --> 00:00:50,830 +So, now when you start Eclipse, if it's the first + +17 +00:00:50,830 --> 00:00:53,480 +time you might get this Welcome screen. It's not going to happen + +18 +00:00:53,480 --> 00:00:57,500 +again on subsequent executions, but I just wanted to make sure + +19 +00:00:57,500 --> 00:01:00,210 +that I covered all the bases. And so, whatcha want to + +20 +00:01:00,210 --> 00:01:03,360 +do here is to basically go to the java perspective + +21 +00:01:03,360 --> 00:01:06,760 +which you can do by clicking over there or you can + +22 +00:01:06,760 --> 00:01:09,240 +also use the menus. So in this case we will have + +23 +00:01:09,240 --> 00:01:12,810 +to go to Window, open Perspective, and if the Perspective is + +24 +00:01:12,810 --> 00:01:15,660 +not here, you'll have to click on Other. And at this point, + +25 +00:01:15,660 --> 00:01:18,030 +that you can click on Java Perspective, then you + +26 +00:01:18,030 --> 00:01:21,680 +click okay. And the perspective is basically, the visual work + +27 +00:01:21,680 --> 00:01:24,810 +space where you will be operating. So, after we selected + +28 +00:01:24,810 --> 00:01:29,350 +perspective, we can actually close the welcome screen. And here, + +29 +00:01:29,350 --> 00:01:32,000 +you see that you have this different areas and on + +30 +00:01:32,000 --> 00:01:34,930 +the left You have the package explorer. This is the + +31 +00:01:34,930 --> 00:01:37,650 +area where your packages will be, you've got a task list, + +32 +00:01:37,650 --> 00:01:41,280 +and an outline on the right which we'll cover later. + +33 +00:01:41,280 --> 00:01:44,870 +And then you have underneath, the bottom, a problems, java + +34 +00:01:44,870 --> 00:01:48,330 +doc and declaration views and we will see some of + +35 +00:01:48,330 --> 00:01:51,320 +these views in actions later. And here in the center + +36 +00:01:51,320 --> 00:01:54,290 +you have the area. Which is called a code editor, + +37 +00:01:54,290 --> 00:01:58,360 +which is where you'll be writing, editing, and modifying, basically, + +38 +00:01:58,360 --> 00:02:00,440 +your code. This is where most of the action takes + +39 +00:02:00,440 --> 00:02:03,140 +place. So let's start by creating a Java project. And + +40 +00:02:03,140 --> 00:02:06,950 +to do that we can use either the context menu, or + +41 +00:02:06,950 --> 00:02:09,560 +you can just use the menu, select new Java project. + +42 +00:02:09,560 --> 00:02:12,390 +You'll be greeted by this, wizard, and. And at this + +43 +00:02:12,390 --> 00:02:15,500 +point in the wizard, you can select the name of + +44 +00:02:15,500 --> 00:02:19,100 +your project. I'm just going to call it a very simple way + +45 +00:02:19,100 --> 00:02:21,990 +my project. And I going to use the default location for + +46 +00:02:21,990 --> 00:02:24,070 +the project, as you can see it will be placed + +47 +00:02:24,070 --> 00:02:27,440 +in the work space that I selected before. I'm going to + +48 +00:02:27,440 --> 00:02:32,080 +also use the default. Java Runtime Environment, which is Java 1.7 + +49 +00:02:32,080 --> 00:02:36,250 +in this case. I'm going to keep the selected default layout + +50 +00:02:36,250 --> 00:02:39,120 +and the, then I'm going to go to the next step. Here, + +51 +00:02:39,120 --> 00:02:42,380 +we're first presented with the location of the source code for + +52 +00:02:42,380 --> 00:02:46,840 +our project. The default is a directory SRC in my project + +53 +00:02:46,840 --> 00:02:49,320 +and for the output file, the directory bin. So repeat, we're now + +54 +00:02:49,320 --> 00:02:52,410 +going to change that. Here in case you need other projects to + +55 +00:02:52,410 --> 00:02:55,240 +build your own, then you can specify them here. Here we + +56 +00:02:55,240 --> 00:02:57,570 +are building a simple project, so there's no need for that. + +57 +00:02:57,570 --> 00:03:00,890 +And here we can specify which libraries our project requires. As + +58 +00:03:00,890 --> 00:03:03,880 +you can see, the Java library's already specified. And you can + +59 +00:03:03,880 --> 00:03:07,840 +also add other jars, which can even be External jars. And + +60 +00:03:07,840 --> 00:03:11,840 +finally this is the tab that allows you to specify which + +61 +00:03:11,840 --> 00:03:14,300 +part of you project. So how your project will be exported, + +62 +00:03:14,300 --> 00:03:16,760 +so lets not worry about that for now. Lets click finish. + +63 +00:03:16,760 --> 00:03:19,300 +And as you can see here on the package explorer, my + +64 +00:03:19,300 --> 00:03:22,920 +project appeared. So now we can open the project by clicking + +65 +00:03:22,920 --> 00:03:24,920 +on the triangle right next to it, and as you can + +66 +00:03:24,920 --> 00:03:28,250 +see there is the SRC directory, where my source code will go, + +67 +00:03:28,250 --> 00:03:31,760 +and there's also an indication that we're using the JRE, so that's + +68 +00:03:31,760 --> 00:03:35,800 +the Java system directory within our project. And this is just for people + +69 +00:03:35,800 --> 00:03:38,860 +who are interested in what happens you know, under the hood. So + +70 +00:03:38,860 --> 00:03:41,840 +if you don't care about that, you can just skip this part. So + +71 +00:03:41,840 --> 00:03:45,200 +basically here I'm showing you how we can go to the directory + +72 +00:03:45,200 --> 00:03:49,250 +where the project was created. We can see the bin and src directories. + +73 +00:03:49,250 --> 00:03:52,020 +And there's also some other files here that you can + +74 +00:03:52,020 --> 00:03:54,780 +see these 'dot' files that you will not normally, see. And + +75 +00:03:54,780 --> 00:03:57,870 +those are kind of bookkeeping files. So these are files that + +76 +00:03:57,870 --> 00:04:02,280 +contain information about your project and that are created automatically by + +77 +00:04:02,280 --> 00:04:05,860 +Eclipse. And, for example, will have various indication about the + +78 +00:04:05,860 --> 00:04:09,580 +configuration of the project, some settings and the class path for + +79 +00:04:09,580 --> 00:04:11,880 +the project. And, as I said, you don't have to worry + +80 +00:04:11,880 --> 00:04:14,490 +about this if you just want to go Eclipse as you're never + +81 +00:04:14,490 --> 00:04:16,551 +going to mess with the command line. diff --git a/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/6 - Eclipse Demo: Create a Class - lang_en_vs6.srt b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/6 - Eclipse Demo: Create a Class - lang_en_vs6.srt new file mode 100644 index 0000000..3bd4f11 --- /dev/null +++ b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/6 - Eclipse Demo: Create a Class - lang_en_vs6.srt @@ -0,0 +1,135 @@ +1 +00:00:00,130 --> 00:00:02,420 +So now that we know, we saw what happens under + +2 +00:00:02,420 --> 00:00:04,570 +the hood, and as I said, don't worry about it if + +3 +00:00:04,570 --> 00:00:06,689 +you don't care about that part. Now we can go back + +4 +00:00:06,689 --> 00:00:09,850 +to Eclipse, and we can start creating a package. A package + +5 +00:00:09,850 --> 00:00:13,125 +is basically a way of organizing your classes into a + +6 +00:00:13,125 --> 00:00:17,015 +hierarchy. In this case, I'm going to specify the package name as + +7 +00:00:17,015 --> 00:00:21,350 +edu.gatech, which means that I'm creating really two packages, a package + +8 +00:00:21,350 --> 00:00:25,480 +gatech inside package edu. And I can start creating classes inside + +9 +00:00:25,480 --> 00:00:28,770 +my packages. So here, I can use the contextual menu, select + +10 +00:00:28,770 --> 00:00:32,055 +New>Class, and I'll get another wizard that will allow me to + +11 +00:00:32,055 --> 00:00:35,160 +specify the name of the class. I'm not very creative here, + +12 +00:00:35,160 --> 00:00:38,250 +so I'm just going to call it Hello World. There's many other parameters + +13 +00:00:38,250 --> 00:00:41,710 +you can set, and in particular, you can define whether you + +14 +00:00:41,710 --> 00:00:45,450 +want a main method in your class. Where having a main + +15 +00:00:45,450 --> 00:00:48,460 +method means that your class can be the main class in + +16 +00:00:48,460 --> 00:00:50,850 +your project, can be the one that is run when you run + +17 +00:00:50,850 --> 00:00:54,340 +your project. After we click the button, the Finish button, we, + +18 +00:00:54,340 --> 00:00:56,859 +we get the class. So we also get template code for the + +19 +00:00:56,859 --> 00:00:59,604 +class, as you can see here, so we go to the editor + +20 +00:00:59,604 --> 00:01:02,120 +function, you can see that there is a to do. Where you + +21 +00:01:02,120 --> 00:01:05,019 +have to put your code, and here we are simply, basically printing, + +22 +00:01:05,019 --> 00:01:08,370 +you know, the typical first program. We just going to print Hello World + +23 +00:01:08,370 --> 00:01:11,180 +in Java. And something you can note is that as we are + +24 +00:01:11,180 --> 00:01:16,370 +typing, Eclipse gives us a auto complete suggestions, which is very helpful. + +25 +00:01:16,370 --> 00:01:19,650 +For example, in case you don't remember the exact syntax, + +26 +00:01:19,650 --> 00:01:22,190 +or the method, or you don't remember the parameters of the + +27 +00:01:22,190 --> 00:01:24,470 +method. Which is, you know, often the case especially where you + +28 +00:01:24,470 --> 00:01:27,590 +work with large libraries. So having that feature can really, really + +29 +00:01:27,590 --> 00:01:30,050 +help you. So now if we want to run our code + +30 +00:01:30,050 --> 00:01:33,380 +we can either click on the button up here, or we + +31 +00:01:33,380 --> 00:01:37,960 +can right-click in the Call window and select Run As Java + +32 +00:01:37,960 --> 00:01:41,370 +Application. And if we do that, Eclipse will run our tool, + +33 +00:01:41,370 --> 00:01:45,650 +and it will create, as you can see here, a console view that basically contains + +34 +00:01:45,650 --> 00:01:49,790 +the textual output of my program. And as expected, the output is Hello World. diff --git a/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/7 - Eclipse Demo: Run Configuration - lang_en_vs6.srt b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/7 - Eclipse Demo: Run Configuration - lang_en_vs6.srt new file mode 100644 index 0000000..ad54f06 --- /dev/null +++ b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/7 - Eclipse Demo: Run Configuration - lang_en_vs6.srt @@ -0,0 +1,115 @@ +1 +00:00:00,140 --> 00:00:02,660 +So now that we have run our program, let's see what + +2 +00:00:02,660 --> 00:00:05,660 +happens exactly when you run a program within Eclipse. And to + +3 +00:00:05,660 --> 00:00:08,410 +do that I'm going to use the menu over here which is + +4 +00:00:08,410 --> 00:00:12,500 +the Run menu and I'm going to select Run Configurations, and this + +5 +00:00:12,500 --> 00:00:15,190 +brings up a window where you can change or run configurations. + +6 +00:00:15,190 --> 00:00:17,200 +Well first of all, you can see that here on the + +7 +00:00:17,200 --> 00:00:22,260 +left under Java application. Eclipse automatically created a Hello World run + +8 +00:00:22,260 --> 00:00:25,300 +configuration for our program. And this is where you can configure + +9 +00:00:25,300 --> 00:00:28,370 +the different parameters for your execution. For example, + +10 +00:00:28,370 --> 00:00:30,520 +you can select the main class. So here + +11 +00:00:30,520 --> 00:00:34,745 +it's, obviously, edu.gatech.HelloWorld. You can define different program + +12 +00:00:34,745 --> 00:00:36,920 +arguments. We don't have any for now. You can + +13 +00:00:36,920 --> 00:00:39,480 +also pass arguments to the virtual machine. You + +14 +00:00:39,480 --> 00:00:41,960 +can define which Java runtime environment you want to + +15 +00:00:41,960 --> 00:00:47,720 +use, Classpath and other environmental options. So let's + +16 +00:00:47,720 --> 00:00:50,650 +now try to pass some arguments to our program. + +17 +00:00:50,650 --> 00:00:54,390 +So for example here, I am just going to write George as + +18 +00:00:54,390 --> 00:00:58,450 +a possible parameter. I say Apply so that modify the configuration and + +19 +00:00:58,450 --> 00:01:01,510 +if i run the program of course, the output is not changing + +20 +00:01:01,510 --> 00:01:04,440 +because my program does not use the argument. But, let's see if + +21 +00:01:04,440 --> 00:01:07,060 +we do use the argument, what happens. So I'm going to slightly + +22 +00:01:07,060 --> 00:01:10,030 +modify the final program so that now, instead of printing hello + +23 +00:01:10,030 --> 00:01:13,420 +world, it will print hello followed by the first argument that I + +24 +00:01:13,420 --> 00:01:15,700 +will pass to the program. And if I do that, and I + +25 +00:01:15,700 --> 00:01:19,420 +go and I run the program, what I get is exactly what I + +26 +00:01:19,420 --> 00:01:23,420 +was expecting, which is Hello George. So this is the way in which you + +27 +00:01:23,420 --> 00:01:26,120 +can pass arguments to your execution, which + +28 +00:01:26,120 --> 00:01:27,640 +is something that might come in handy + +29 +00:01:27,640 --> 00:01:30,390 +for some other projects. When you need to run some code with an argument. diff --git a/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/8 - Eclipse Demo: Debugging - lang_en_vs5.srt b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/8 - Eclipse Demo: Debugging - lang_en_vs5.srt new file mode 100644 index 0000000..025c2ba --- /dev/null +++ b/usth/ICT2.7/P1L3 Integrated Development Environment Subtitles/8 - Eclipse Demo: Debugging - lang_en_vs5.srt @@ -0,0 +1,275 @@ +1 +00:00:00,160 --> 00:00:03,090 +Now let's look at how we can do debugging within + +2 +00:00:03,090 --> 00:00:06,240 +Eclipse. I created a new file called AddNumbers which I'm + +3 +00:00:06,240 --> 00:00:10,770 +showing here. It takes two numbers, parses them into integers, + +4 +00:00:10,770 --> 00:00:14,870 +adds them and prints the sum, supposedly, of the two numbers. + +5 +00:00:14,870 --> 00:00:17,450 +Now we look at the run configuration for this program, + +6 +00:00:17,450 --> 00:00:19,670 +and here you can see that we're passing two arguments, + +7 +00:00:19,670 --> 00:00:22,060 +two and five, to the program. So now let's run + +8 +00:00:22,060 --> 00:00:25,468 +our program and see what happens. And the result says that + +9 +00:00:25,468 --> 00:00:28,150 +2 plus 5 is equal to 10, which is not + +10 +00:00:28,150 --> 00:00:31,030 +exactly correct. So we need to debug our program. We + +11 +00:00:31,030 --> 00:00:33,310 +need to figure out what's wrong with the program, why + +12 +00:00:33,310 --> 00:00:37,140 +the wrong result was, produced. So we're going to add a break + +13 +00:00:37,140 --> 00:00:40,260 +point here by double-clicking here on the side of the + +14 +00:00:40,260 --> 00:00:42,940 +code. And the break point is basically a place where I'm + +15 +00:00:42,940 --> 00:00:46,240 +telling my debugger to stop during the execution because I + +16 +00:00:46,240 --> 00:00:50,750 +want to inspect the state of the program. So to start + +17 +00:00:50,750 --> 00:00:54,690 +debugging, we select Debug as Java Application from the Context + +18 +00:00:54,690 --> 00:00:58,170 +menu, similar to what we were doing for running the program. + +19 +00:00:58,170 --> 00:01:00,190 +And as you can see, this asks us whether we want + +20 +00:01:00,190 --> 00:01:03,720 +to pass to the debug perspective, which is a, a perspective + +21 +00:01:03,720 --> 00:01:07,110 +specifically designed for debugging. We say yes. And as you + +22 +00:01:07,110 --> 00:01:10,750 +see here, it shows us, it's like a different, set of + +23 +00:01:10,750 --> 00:01:13,310 +views, so we can see the code down here with an + +24 +00:01:13,310 --> 00:01:16,100 +indication of where the execution is. And of course the execution + +25 +00:01:16,100 --> 00:01:18,610 +stopped at the break point, which is exactly where + +26 +00:01:18,610 --> 00:01:21,850 +we told the debugger to stop. So let's look at + +27 +00:01:21,850 --> 00:01:24,400 +some of the other views in this perspective. The view + +28 +00:01:24,400 --> 00:01:27,370 +here on the right-hand side, for example, shows the variables + +29 +00:01:27,370 --> 00:01:30,720 +in scope and the break points that are currently active + +30 +00:01:30,720 --> 00:01:33,240 +for the debugging session. This is where the editor is + +31 +00:01:33,240 --> 00:01:36,710 +at. The outline of the program and the console at + +32 +00:01:36,710 --> 00:01:41,520 +the bottom. So now let's execute one line by clicking + +33 +00:01:41,520 --> 00:01:45,400 +on the Step Over button here at the top, and this will + +34 +00:01:45,400 --> 00:01:49,150 +execute the line that is currently highlighted and therefore it will move to + +35 +00:01:49,150 --> 00:01:51,500 +the next line. And as you can see, one nice feature is that + +36 +00:01:51,500 --> 00:01:54,760 +if I move the mouse over a variable, I can see the value + +37 +00:01:54,760 --> 00:01:57,710 +of the variable. And the same thing I can do if I look + +38 +00:01:57,710 --> 00:02:00,690 +at the variables windows here on the right. If I click it, it + +39 +00:02:00,690 --> 00:02:03,960 +will tell me what is the value of the variable, and in case + +40 +00:02:03,960 --> 00:02:07,410 +of more complex variables you can even expand it and get more details. + +41 +00:02:07,410 --> 00:02:10,870 +So now let's step over another line by clicking again this button, + +42 +00:02:10,870 --> 00:02:13,180 +and as you can see now we get to the line that + +43 +00:02:13,180 --> 00:02:16,410 +is actually performing the sum, supposedly, so now let's do the same + +44 +00:02:16,410 --> 00:02:19,100 +thing that we did before, and let's mouse over b, and we can + +45 +00:02:19,100 --> 00:02:22,150 +see that the value of b is five, as expected. So now + +46 +00:02:22,150 --> 00:02:27,080 +let's step over this line as well, and execute the actual sum. And + +47 +00:02:27,080 --> 00:02:29,730 +doing the mouseover thing, we can see that the value of sum + +48 +00:02:29,730 --> 00:02:33,000 +is ten, which is not right, of course. In fact, if we check + +49 +00:02:33,000 --> 00:02:35,590 +a gain we can see that value of A is two. The + +50 +00:02:35,590 --> 00:02:39,130 +value of B is five and therefore it's clear that there's something + +51 +00:02:39,130 --> 00:02:41,780 +wrong going on here, and at this point we can notice that + +52 +00:02:41,780 --> 00:02:44,030 +here we are doing multiplication instead + +53 +00:02:44,030 --> 00:02:46,010 +of addition. And therefore that's what the + +54 +00:02:46,010 --> 00:02:49,260 +error is. And this is clearly a very simple case. Right? A + +55 +00:02:49,260 --> 00:02:51,440 +case in which probably you just needed to look at the code and + +56 +00:02:51,440 --> 00:02:54,150 +you didn't need the debugger. But you probably got the idea right? + +57 +00:02:54,150 --> 00:02:58,055 +So this can be extremely useful when you're debugging, when you're studying more + +58 +00:02:58,055 --> 00:03:01,533 +complex programs. If you want to stop the debugger because you're + +59 +00:03:01,533 --> 00:03:04,557 +done with your debugging session as in this case, you can + +60 +00:03:04,557 --> 00:03:07,518 +either click here on the Terminate button or you can also + +61 +00:03:07,518 --> 00:03:11,109 +just simply tell the debugger to continue the execution, to resume + +62 +00:03:11,109 --> 00:03:15,140 +the execution until the program terminates naturally. So, in this case, + +63 +00:03:15,140 --> 00:03:17,520 +we're going to click here just to show what happens. And what + +64 +00:03:17,520 --> 00:03:20,230 +happens is that, you know, the execution will just continue until + +65 +00:03:20,230 --> 00:03:23,690 +the program exits. So now let's say that we want to fix + +66 +00:03:23,690 --> 00:03:27,740 +this problem that we just discovered. So we replace the multiplication + +67 +00:03:27,740 --> 00:03:30,600 +with an addition, we save the program, and we execute the + +68 +00:03:30,600 --> 00:03:33,860 +program again by clicking on this button. And at this point, + +69 +00:03:33,860 --> 00:03:37,320 +unsurprisingly, we get the right result as shown in the console. diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/1 - Lesson Overview - lang_en_vs5.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/1 - Lesson Overview - lang_en_vs5.srt new file mode 100644 index 0000000..936e3db --- /dev/null +++ b/usth/ICT2.7/P1L4 Version Control Subtitles/1 - Lesson Overview - lang_en_vs5.srt @@ -0,0 +1,43 @@ +1 +00:00:00,440 --> 00:00:06,190 +Hi and welcome to the second lesson on tools of the trade. In the + +2 +00:00:06,190 --> 00:00:09,710 +previous lesson we talked about IDEs. Integrated + +3 +00:00:09,710 --> 00:00:13,300 +Development Environments and in particular we discussed + +4 +00:00:13,300 --> 00:00:16,460 +the eclipse ID. Today we're going to + +5 +00:00:16,460 --> 00:00:19,780 +talk about another fundamental type of tools + +6 +00:00:19,780 --> 00:00:22,840 +in the software engineering arena. Version control + +7 +00:00:22,840 --> 00:00:26,140 +systems. And these are also called, revision + +8 +00:00:26,140 --> 00:00:30,620 +or source control systems. In particular, we will focus on a + +9 +00:00:30,620 --> 00:00:36,320 +specific version control system called git. And as we did for eclipse, + +10 +00:00:36,320 --> 00:00:40,510 +we will first present git from a conceptual standpoint. And then + +11 +00:00:40,510 --> 00:00:44,200 +we will do a demo. To get some hands-on experience with GIT. diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/10 - Introduction to GIT - lang_en_vs6.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/10 - Introduction to GIT - lang_en_vs6.srt new file mode 100644 index 0000000..201c7a5 --- /dev/null +++ b/usth/ICT2.7/P1L4 Version Control Subtitles/10 - Introduction to GIT - lang_en_vs6.srt @@ -0,0 +1,79 @@ +1 +00:00:00,240 --> 00:00:04,160 +One good representative of distributed version control systems, is + +2 +00:00:04,160 --> 00:00:08,320 +GIT. A distributed version control system that was initially designed + +3 +00:00:08,320 --> 00:00:11,297 +and developed by Linus Torvalds. I'm pretty sure you + +4 +00:00:11,297 --> 00:00:14,140 +know who Linus Torvalds is. He's basically this guy who + +5 +00:00:14,140 --> 00:00:17,070 +started and created the Linux operating system. And Linus + +6 +00:00:17,070 --> 00:00:20,140 +was unhappy with the existing version control systems, and wanted + +7 +00:00:20,140 --> 00:00:22,610 +a different one. He wanted to use it for maintaining + +8 +00:00:22,610 --> 00:00:25,330 +the Linux kernel. In particular, he wanted one with some + +9 +00:00:25,330 --> 00:00:28,550 +key characteristics. For example, the fact that it was distributed. He + +10 +00:00:28,550 --> 00:00:30,470 +wanted it to be fast. He wanted it to have a + +11 +00:00:30,470 --> 00:00:33,660 +simple design. And he wanted to have a strong support for + +12 +00:00:33,660 --> 00:00:37,370 +parallel branches, because many people were contributing to the kernel at the + +13 +00:00:37,370 --> 00:00:41,620 +same time. And therefore there many different branches of development. And + +14 +00:00:41,620 --> 00:00:45,120 +finally, he wanted for the virtual control system to be able to + +15 +00:00:45,120 --> 00:00:48,070 +handle large projects. As the Linux kernel is, and to do + +16 +00:00:48,070 --> 00:00:50,480 +it in an efficient way. So if you want to get an idea + +17 +00:00:50,480 --> 00:00:54,210 +of how popular GIT is today, there was a survey performed across the + +18 +00:00:54,210 --> 00:00:58,330 +Eclipse IDE users, and it showed that in 2013 GIT was used by + +19 +00:00:58,330 --> 00:01:02,950 +about 30% of the developers. So the, it had a 30% adoption rate. + +20 +00:01:02,950 --> 00:01:06,430 +So we will use a GIT as a version control system for the class. diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/11 - Installing GIT - lang_en_vs5.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/11 - Installing GIT - lang_en_vs5.srt new file mode 100644 index 0000000..38eedc0 --- /dev/null +++ b/usth/ICT2.7/P1L4 Version Control Subtitles/11 - Installing GIT - lang_en_vs5.srt @@ -0,0 +1,63 @@ +1 +00:00:00,120 --> 00:00:03,020 +As we did for Eclipse, and IDEs in general, we want + +2 +00:00:03,020 --> 00:00:05,133 +to start a GIT in a hands on way. So we're going + +3 +00:00:05,133 --> 00:00:08,425 +to start by seeing how to install GIT. And GIT is also + +4 +00:00:08,425 --> 00:00:12,440 +multiplatform, so you can install it no matter what operating system you + +5 +00:00:12,440 --> 00:00:15,980 +are using, unless of course you are using some arcane operating system. + +6 +00:00:15,980 --> 00:00:18,530 +But if you are using Linux, for instance, there should be a + +7 +00:00:18,530 --> 00:00:22,608 +package available that can install GIT for your specific distribution. If you're + +8 +00:00:22,608 --> 00:00:25,460 +using Mac OS, GIT is also available as part of XCode and + +9 +00:00:25,460 --> 00:00:29,270 +also as an independent package. Finally, if you're using Windows, GIT is + +10 +00:00:29,270 --> 00:00:33,090 +available as a package with an installer. In general, you can go + +11 +00:00:33,090 --> 00:00:37,290 +here to get information about how to get GIT, where to download + +12 +00:00:37,290 --> 00:00:39,975 +it, how to install it, and so on. So, now what I'd + +13 +00:00:39,975 --> 00:00:42,312 +like for you to do is to go, get GIT, install it, + +14 +00:00:42,312 --> 00:00:45,469 +in case you don't have it installed already on your machine. And + +15 +00:00:45,469 --> 00:00:48,253 +after that, you should be able to run GIT from the command + +16 +00:00:48,253 --> 00:00:51,120 +line. And, that's exactly what we're going to do through a demo. diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/12 - GIT Workflow - lang_en_vs5.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/12 - GIT Workflow - lang_en_vs5.srt new file mode 100644 index 0000000..84f0f2e --- /dev/null +++ b/usth/ICT2.7/P1L4 Version Control Subtitles/12 - GIT Workflow - lang_en_vs5.srt @@ -0,0 +1,507 @@ +1 +00:00:00,070 --> 00:00:02,100 +But before jumping into the demo I would like + +2 +00:00:02,100 --> 00:00:05,370 +to give a high level overview of the GIT workflow, + +3 +00:00:05,370 --> 00:00:08,420 +which will help you better, following the demo. So let + +4 +00:00:08,420 --> 00:00:12,480 +me start by representing four fundamental elements in the GIT + +5 +00:00:12,480 --> 00:00:15,640 +workflow which are these four: the workspace which is your + +6 +00:00:15,640 --> 00:00:19,980 +local directory. The index, also called the stage, and we'll + +7 +00:00:19,980 --> 00:00:22,470 +see in a minute what the index is. Then, we + +8 +00:00:22,470 --> 00:00:25,380 +have the local repository. We'll also refer to this as + +9 +00:00:25,380 --> 00:00:27,910 +HEAD in the, when we explain the different commands + +10 +00:00:27,910 --> 00:00:31,340 +and then, the word flow. And finally, the remote repository. + +11 +00:00:31,340 --> 00:00:34,600 +If you consider a file in your work space it + +12 +00:00:34,600 --> 00:00:37,860 +can be in three possible states. It can be committed + +13 +00:00:37,860 --> 00:00:40,170 +which means that the data, the latest changes to the + +14 +00:00:40,170 --> 00:00:45,030 +file are safely stored here. It could be modified, which + +15 +00:00:45,030 --> 00:00:47,840 +is the case of the file being changed and no, + +16 +00:00:47,840 --> 00:00:50,710 +none of these changes being saved to the local repository + +17 +00:00:50,710 --> 00:00:54,440 +so locally modified or it can be staged. And + +18 +00:00:54,440 --> 00:00:58,270 +stage means that the file is basically part of this + +19 +00:00:58,270 --> 00:01:01,620 +index. And what that means, that it's been tagged + +20 +00:01:01,620 --> 00:01:04,890 +to be considered in the next commit. And I know + +21 +00:01:04,890 --> 00:01:08,070 +that this is not all 100% intuitive, so let's + +22 +00:01:08,070 --> 00:01:10,860 +look at that again by considering the actual workflow and + +23 +00:01:10,860 --> 00:01:12,680 +let's see what happens when you issue the different + +24 +00:01:12,680 --> 00:01:16,060 +commands in git. So the first command that you normally + +25 +00:01:16,060 --> 00:01:18,520 +run in case you, you're getting access to a remote + +26 +00:01:18,520 --> 00:01:21,940 +repository, is the git clone command. And the git clone, + +27 +00:01:21,940 --> 00:01:24,880 +followed by the url for that repository, will create a + +28 +00:01:24,880 --> 00:01:28,580 +local copy of the repository in your workspace. And of + +29 +00:01:28,580 --> 00:01:30,310 +course, you don't have to do this step if you're + +30 +00:01:30,310 --> 00:01:34,380 +creating the repository yourself. The next command that we already + +31 +00:01:34,380 --> 00:01:38,170 +saw is the command add. And what the command add + +32 +00:01:38,170 --> 00:01:41,130 +does is to add a file that is in the + +33 +00:01:41,130 --> 00:01:44,630 +workspace to this index. And we say that after that, the + +34 +00:01:44,630 --> 00:01:48,700 +file is staged. So it's marked to be committed, but not + +35 +00:01:48,700 --> 00:01:53,350 +yet committed. And here I'm just mentioning this minus u option. + +36 +00:01:53,350 --> 00:01:56,330 +If you specify the minus u option, you will also consider deleted + +37 +00:01:56,330 --> 00:01:58,820 +files File, but let's not get there for now, we'll talk + +38 +00:01:58,820 --> 00:02:01,240 +about that when we do the demo. As I said, if you + +39 +00:02:01,240 --> 00:02:03,720 +add the file, it just gets added to this index but + +40 +00:02:03,720 --> 00:02:06,430 +is not actually committed, so what you need to do, is to + +41 +00:02:06,430 --> 00:02:10,389 +commit the file, so when you execute git commit, all the + +42 +00:02:10,389 --> 00:02:13,970 +files that are staged, that are released it here, their changes + +43 +00:02:13,970 --> 00:02:17,080 +will be committed to the local repository. So your files, as + +44 +00:02:17,080 --> 00:02:18,970 +I was saying, they can be in three states. They will + +45 +00:02:18,970 --> 00:02:21,820 +go from the modified state to the stage state when you + +46 +00:02:21,820 --> 00:02:24,200 +execute the app. And then from the stage state to the + +47 +00:02:24,200 --> 00:02:27,510 +committed state when you perform a GIT Commit. Okay, so at + +48 +00:02:27,510 --> 00:02:31,780 +this point your changes are safely stored in the local repository. + +49 +00:02:31,780 --> 00:02:34,370 +Notice that you can also perform these two steps at + +50 +00:02:34,370 --> 00:02:38,150 +once by executing a Commit -a. So if you have + +51 +00:02:38,150 --> 00:02:40,920 +a set of modified files, and all these files are + +52 +00:02:40,920 --> 00:02:44,550 +already part of the repository, so they're already known to diversion + +53 +00:02:44,550 --> 00:02:47,540 +control system, you can simply execute a commit -a. + +54 +00:02:47,540 --> 00:02:50,040 +And what the commit -a command will do, it + +55 +00:02:50,040 --> 00:02:53,080 +will stage your file and then commit them. All at + +56 +00:02:53,080 --> 00:02:56,650 +once. So it's a convenient shortcut. Of course, as I said, + +57 +00:02:56,650 --> 00:02:58,710 +this will not work if the file is a new file. + +58 +00:02:58,710 --> 00:03:00,730 +So if a file is a new file, you have to manually add + +59 +00:03:00,730 --> 00:03:04,620 +it. Otherwise commit -a will just stage and commit at once. + +60 +00:03:04,620 --> 00:03:07,400 +As we discussed when we looked at the diffence between centralized + +61 +00:03:07,400 --> 00:03:10,520 +and decentralized version console system. We saw that in the case + +62 +00:03:10,520 --> 00:03:13,930 +of the decentralized, there is a local repository which is this one. + +63 +00:03:13,930 --> 00:03:17,190 +And then you have to explicitly push your changes to a remote + +64 +00:03:17,190 --> 00:03:21,850 +repository, and this is exactly what the git push command does. It pushes + +65 +00:03:21,850 --> 00:03:25,930 +your changes that are in the local repository to the remote repository + +66 +00:03:25,930 --> 00:03:28,160 +so at this point all of your changes will be + +67 +00:03:28,160 --> 00:03:31,680 +visible to anyone who has access to the remote repository. + +68 +00:03:31,680 --> 00:03:33,710 +Now, let's see the opposite flow so how does it + +69 +00:03:33,710 --> 00:03:36,640 +work when you're actually getting files from the repository instead + +70 +00:03:36,640 --> 00:03:39,650 +of committing files to the repository. So the first command + +71 +00:03:39,650 --> 00:03:43,280 +I want to mention is the get fetch command and + +72 +00:03:43,280 --> 00:03:46,900 +what the get fetch command does is to get files from + +73 +00:03:46,900 --> 00:03:50,680 +the remote repositories to your local repository, but not yet to + +74 +00:03:50,680 --> 00:03:53,890 +your working directory. And we will see what is the usefullness of + +75 +00:03:53,890 --> 00:03:56,900 +doing this operation. Of having the files all in the local respository, + +76 +00:03:56,900 --> 00:03:59,380 +but not in your local directory. So, what that means, just to + +77 +00:03:59,380 --> 00:04:01,360 +make sure that we're on the same page. Is that you + +78 +00:04:01,360 --> 00:04:05,620 +will not see these files when you workspace. You will still have + +79 +00:04:05,620 --> 00:04:09,030 +your local files here. So this is sort of a physical distinction. + +80 +00:04:09,030 --> 00:04:12,060 +In order to get your data files from the local repositories to + +81 +00:04:12,060 --> 00:04:14,470 +your workspace you have to issue another command. Which is + +82 +00:04:14,470 --> 00:04:18,250 +the command git merge. Git merge will take the changes in + +83 +00:04:18,250 --> 00:04:21,870 +local repository and get them to your local workspace. So at + +84 +00:04:21,870 --> 00:04:25,460 +this point your files will be updated. To what is in + +85 +00:04:25,460 --> 00:04:27,730 +the remote reposity. Or at least what was in the + +86 +00:04:27,730 --> 00:04:30,810 +remote reposity at the time of the fetch. SImilarly to what + +87 +00:04:30,810 --> 00:04:34,340 +happened for the add and commit. There's a shortcut which is + +88 +00:04:34,340 --> 00:04:37,230 +the command git pull. So in case you want to get + +89 +00:04:37,230 --> 00:04:40,590 +the changes directly. To your work space with a single + +90 +00:04:40,590 --> 00:04:44,120 +command, you can issue a git pull command and what will + +91 +00:04:44,120 --> 00:04:46,560 +happen, is that the changes will get collected from the + +92 +00:04:46,560 --> 00:04:49,810 +remote repository and they will go to your local repository and + +93 +00:04:49,810 --> 00:04:51,990 +to your work space, at once. So this has the + +94 +00:04:51,990 --> 00:04:55,820 +same affect as performing a git fetch and a git merge. + +95 +00:04:55,820 --> 00:04:59,160 +So if we can do everything in one command, why, + +96 +00:04:59,160 --> 00:05:03,290 +why we want to fetch and berch as two separate operations? + +97 +00:05:03,290 --> 00:05:05,920 +So one of the reason is because this allows us + +98 +00:05:05,920 --> 00:05:09,410 +to compare files before we actually get the latest version + +99 +00:05:09,410 --> 00:05:12,600 +of the files. In particular, I can run the command + +100 +00:05:12,600 --> 00:05:17,310 +git diff head to get the difference between my local files, + +101 +00:05:17,310 --> 00:05:20,330 +the files in my working directory, and the files in + +102 +00:05:20,330 --> 00:05:22,800 +my local repository. So what I can do, I can + +103 +00:05:22,800 --> 00:05:25,550 +fetch the files from the remote repository, and once I + +104 +00:05:25,550 --> 00:05:29,260 +fetch these files. I can run a git diff head and + +105 +00:05:29,260 --> 00:05:32,620 +check what the differences are. And based on the differences decide + +106 +00:05:32,620 --> 00:05:35,554 +whether I want to merge or not. So while we are talking about + +107 +00:05:35,554 --> 00:05:37,890 +git diff, there is something else that you can use with the + +108 +00:05:37,890 --> 00:05:41,060 +diff command. So what you can do, you can run git diff + +109 +00:05:41,060 --> 00:05:44,930 +without further specifying head. In this case, what the command tell you + +110 +00:05:44,930 --> 00:05:48,310 +is the difference between the files that you have in your work + +111 +00:05:48,310 --> 00:05:51,780 +space and the ones that are staged for a commit. So basically, + +112 +00:05:51,780 --> 00:05:54,630 +what it will be telling you, is that what you could still + +113 +00:05:54,630 --> 00:05:58,300 +add to the stage for the further commit, and that you + +114 +00:05:58,300 --> 00:06:01,230 +haven't already. So what local changes will not make it to the + +115 +00:06:01,230 --> 00:06:04,440 +next commit, basically. And this you can use, for example, as + +116 +00:06:04,440 --> 00:06:07,450 +a sanity check before doing a commit to make sure all the + +117 +00:06:07,450 --> 00:06:09,980 +local changes that you have, and that you want to commit, + +118 +00:06:09,980 --> 00:06:13,230 +are actually staged and therefore will be considered. So now we will + +119 +00:06:13,230 --> 00:06:16,930 +cover all of the commands that we saw here. In our practical + +120 +00:06:16,930 --> 00:06:20,560 +demo. But please feel free to refer back to this Git Workflow + +121 +00:06:20,560 --> 00:06:23,570 +to get a kind of a high level vision. Or maybe you want to keep it next to + +122 +00:06:23,570 --> 00:06:26,110 +you, because this really gives you the overall structure + +123 +00:06:26,110 --> 00:06:28,450 +and the overall view of what happens when you + +124 +00:06:28,450 --> 00:06:31,160 +run the different commands. And it also helps you + +125 +00:06:31,160 --> 00:06:34,840 +visualize The different elements that are relevant when you're + +126 +00:06:34,840 --> 00:06:37,970 +using GIT. So the workspace, once more, the index + +127 +00:06:37,970 --> 00:06:40,790 +or stage, the local repository, and the remote repository. diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/13 - GIT Demo: Intro to Git - lang_en_vs5.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/13 - GIT Demo: Intro to Git - lang_en_vs5.srt new file mode 100644 index 0000000..d3b3a24 --- /dev/null +++ b/usth/ICT2.7/P1L4 Version Control Subtitles/13 - GIT Demo: Intro to Git - lang_en_vs5.srt @@ -0,0 +1,1095 @@ +1 +00:00:00,120 --> 00:00:02,170 +In this first part of the git demo, we will + +2 +00:00:02,170 --> 00:00:05,080 +call it the basics of git. So for example, how to + +3 +00:00:05,080 --> 00:00:08,280 +introduce yourself to git, how to create a repository, how to + +4 +00:00:08,280 --> 00:00:12,450 +commit changes and get changes from the repository, and so on. + +5 +00:00:12,450 --> 00:00:15,140 +So after you installed git you should have the git tool + +6 +00:00:15,140 --> 00:00:18,150 +available on the command line, so you can run the command + +7 +00:00:18,150 --> 00:00:21,110 +git and, if you just execute git you will get the + +8 +00:00:21,110 --> 00:00:25,930 +usage information for git, with the most commonly used git commands. + +9 +00:00:25,930 --> 00:00:28,940 +And to find information on any command, you can simply + +10 +00:00:28,940 --> 00:00:32,310 +type git help and the name of the command. For + +11 +00:00:32,310 --> 00:00:35,240 +example, lets try to write git help init. And that + +12 +00:00:35,240 --> 00:00:38,960 +brings up the git manual page for git init, which describes + +13 +00:00:38,960 --> 00:00:41,590 +the command, the synopsis, and so on. Now, lets get + +14 +00:00:41,590 --> 00:00:45,970 +started with using git by introducing ourselves to git, which is + +15 +00:00:45,970 --> 00:00:47,830 +the first thing we need to do. To do that + +16 +00:00:47,830 --> 00:00:51,310 +we use the git config command, in particular we are going to + +17 +00:00:51,310 --> 00:00:54,170 +write to the git config minus, minus global + +18 +00:00:54,170 --> 00:00:56,440 +user dot name. Which means we are telling it + +19 +00:00:56,440 --> 00:00:59,900 +our user name. We'll specify our user name which + +20 +00:00:59,900 --> 00:01:02,970 +in this case is George P. Burdell. You could + +21 +00:01:02,970 --> 00:01:04,970 +also provide your email address in the same + +22 +00:01:04,970 --> 00:01:09,370 +way. So you still use the git config --global + +23 +00:01:09,370 --> 00:01:12,750 +command. But in this case you will write user.email + +24 +00:01:12,750 --> 00:01:16,580 +as the property. And then you'll specify a suitable + +25 +00:01:16,580 --> 00:01:19,670 +email address. In this case, the email address of George P. + +26 +00:01:19,670 --> 00:01:23,780 +Burdell. We will now look at some commonly used commands that to + +27 +00:01:23,780 --> 00:01:27,210 +create and maintain a local repository. Let's first create a + +28 +00:01:27,210 --> 00:01:30,510 +new project and call it my project. So, to do that we + +29 +00:01:30,510 --> 00:01:32,790 +are simply going to create a directory and then we're going + +30 +00:01:32,790 --> 00:01:35,520 +to move into that directory. Now, if we try to call the + +31 +00:01:35,520 --> 00:01:39,000 +git status command at this point to see what's the state of + +32 +00:01:39,000 --> 00:01:41,990 +my project, of course git doesn't know anything about this project, right? + +33 +00:01:41,990 --> 00:01:44,360 +So, you will get an error. It will tell you that, basically, + +34 +00:01:44,360 --> 00:01:47,080 +we're not in a git repository. So how do we create a git + +35 +00:01:47,080 --> 00:01:50,090 +repository? How do we make this? A Git repository, but we do it + +36 +00:01:50,090 --> 00:01:53,560 +by calling git init and the output will tell you that the + +37 +00:01:53,560 --> 00:01:56,580 +repository was initialized. If we check the status again, you will see + +38 +00:01:56,580 --> 00:01:59,790 +that now Git recognizes the repository and will tell you that there is + +39 +00:01:59,790 --> 00:02:01,160 +nothing to commit because, of course, + +40 +00:02:01,160 --> 00:02:03,190 +the repository is completely empty. So let's + +41 +00:02:03,190 --> 00:02:07,380 +just create a new, empty file. Which we're going to call REAME. So + +42 +00:02:07,380 --> 00:02:10,008 +now if you run git status, as you can see, git will + +43 +00:02:10,008 --> 00:02:13,250 +tell you there is a file that's called README, but it's untracked. + +44 +00:02:13,250 --> 00:02:15,600 +Now what that means is that the file not staged, if you + +45 +00:02:15,600 --> 00:02:18,710 +remember our lesson. So what we need to do, we first need + +46 +00:02:18,710 --> 00:02:22,040 +to tell git that, you know, this needs to be considered. And + +47 +00:02:22,040 --> 00:02:25,690 +the way we do that, is by calling the git at command + +48 +00:02:25,690 --> 00:02:28,880 +and then we specify README as the argument for the command. If + +49 +00:02:28,880 --> 00:02:33,090 +we call again, Git status. Now, as you can see, Git knows + +50 +00:02:33,090 --> 00:02:35,780 +that there is a new file called README, because the file + +51 +00:02:35,780 --> 00:02:38,390 +is staged. So Git is aware of the fact that this + +52 +00:02:38,390 --> 00:02:41,490 +file has to be committed. So, to commit a file, + +53 +00:02:41,490 --> 00:02:45,410 +we simply execute git commit, which will open a text editor, which + +54 +00:02:45,410 --> 00:02:48,500 +can be different, depending on what is your environment, and here + +55 +00:02:48,500 --> 00:02:50,980 +we need to add a comment to be added to the commit. + +56 +00:02:50,980 --> 00:02:54,760 +So here we simply write in Added README file, then we + +57 +00:02:54,760 --> 00:02:58,170 +can close and save And this will add the file to the + +58 +00:02:58,170 --> 00:03:01,310 +Git repository. The local Git repository of course. At this + +59 +00:03:01,310 --> 00:03:04,220 +point, if we ran Git status again to see where we are. + +60 +00:03:04,220 --> 00:03:06,400 +You can see that Git tells you that there is nothing + +61 +00:03:06,400 --> 00:03:08,660 +to commit. Because of course the only file that we have, is + +62 +00:03:08,660 --> 00:03:13,070 +committed to the repository. Now, let's make some changes to our + +63 +00:03:13,070 --> 00:03:17,270 +README file. I'm just going to add some text here. Once more, we + +64 +00:03:17,270 --> 00:03:20,050 +can run git status, and at this point, git knows about + +65 +00:03:20,050 --> 00:03:23,430 +this file. So, it will know that README file has been modified. + +66 +00:03:23,430 --> 00:03:25,280 +Remember that before, it was telling you that it was a new + +67 +00:03:25,280 --> 00:03:28,310 +file, now it knows that there was a different version in the + +68 +00:03:28,310 --> 00:03:31,430 +repository. So something we can do, at this point, for example, is + +69 +00:03:31,430 --> 00:03:34,820 +to check the differences. Between this file and the committed one by + +70 +00:03:34,820 --> 00:03:38,040 +executing get diff readme and if you look at the output of + +71 +00:03:38,040 --> 00:03:42,320 +the get diff command here, you can see that this line, readme + +72 +00:03:42,320 --> 00:03:45,170 +file content was added and you'll see that it was added because + +73 +00:03:45,170 --> 00:03:48,610 +there's a plus sign before that line. In case of deletion of lines, + +74 +00:03:48,610 --> 00:03:51,460 +you'll see a minusm sign there. So at this point, if we + +75 +00:03:51,460 --> 00:03:54,950 +want to commit our file, remember that we'll always have to tell git + +76 +00:03:54,950 --> 00:03:58,070 +that we want to stage the file before committing it. Otherwise, it + +77 +00:03:58,070 --> 00:04:01,420 +will be ignored by the commit operation. So to tell git, that the + +78 +00:04:01,420 --> 00:04:04,140 +file has to be staged, we will, can use the usual git + +79 +00:04:04,140 --> 00:04:07,140 +add command. But if you remember the lesson, we can also use a + +80 +00:04:07,140 --> 00:04:10,150 +shortcut. So you, we don't really have to do this in two steps. + +81 +00:04:10,150 --> 00:04:13,730 +We can simply say, git commit -a, and this will tell git to + +82 +00:04:13,730 --> 00:04:17,120 +commit all of the files that git knows about, which in this + +83 +00:04:17,120 --> 00:04:19,959 +case is only the written file of course. Something else that we can + +84 +00:04:19,959 --> 00:04:22,950 +do, is that we can also provide the right away message for + +85 +00:04:22,950 --> 00:04:26,140 +the commit, without having to open an editor. So, to do that we + +86 +00:04:26,140 --> 00:04:29,760 +can specify the -n option. And at this point a we can + +87 +00:04:29,760 --> 00:04:34,050 +just put a in double quotes our content we press enter and as + +88 +00:04:34,050 --> 00:04:36,690 +you can see it will notify us that one file was changed + +89 +00:04:36,690 --> 00:04:38,850 +and in particular it will also tell you that there was an a + +90 +00:04:38,850 --> 00:04:41,470 +insertion again if we run git status you will see that + +91 +00:04:41,470 --> 00:04:44,800 +there is nothing else to commit. So now lets imagine that + +92 +00:04:44,800 --> 00:04:48,390 +you want to see the version history for your repository. You + +93 +00:04:48,390 --> 00:04:51,760 +can do that by running the git log command. So if + +94 +00:04:51,760 --> 00:04:54,560 +you run that, it will show you all the different commits + +95 +00:04:54,560 --> 00:04:57,990 +For your repository. And each commit has got a commit ID, as + +96 +00:04:57,990 --> 00:05:01,010 +you can see here and the one down here is + +97 +00:05:01,010 --> 00:05:04,740 +the first commit, where as the one above is the second commit. + +98 +00:05:04,740 --> 00:05:07,670 +And as you can see, we'll also show you the comments associated + +99 +00:05:07,670 --> 00:05:11,070 +with each commit. And in case you wanted to see the changes introduced + +100 +00:05:11,070 --> 00:05:14,500 +by a commit. You can use that git show command, and you + +101 +00:05:14,500 --> 00:05:18,220 +can provide the commit ID for the commit that you're interested in. + +102 +00:05:18,220 --> 00:05:20,600 +And you don't really need to provide the whole ID, you can + +103 +00:05:20,600 --> 00:05:23,600 +provide the first four or more characters. So that's what we're going to + +104 +00:05:23,600 --> 00:05:26,540 +do here. So we're going to specify the second commit, and when we + +105 +00:05:26,540 --> 00:05:31,120 +execute the command it will show use the changes introduced by that commit. + +106 +00:05:31,120 --> 00:05:33,550 +To fetch a repository from a remote server, you can + +107 +00:05:33,550 --> 00:05:36,350 +use the git clone command. So you will write git clone + +108 +00:05:36,350 --> 00:05:39,140 +and then specify the URL. For the remote repository. Here + +109 +00:05:39,140 --> 00:05:44,260 +we are using the SSH protocal and there are different protocals + +110 +00:05:44,260 --> 00:05:46,680 +that can be used, so the remote repository can be + +111 +00:05:46,680 --> 00:05:49,800 +made available in different ways. As you can see, when you + +112 +00:05:49,800 --> 00:05:54,050 +clone the project, the project is cloned into the local directory. + +113 +00:05:54,050 --> 00:05:57,180 +If you wanted to import the project under a different name. + +114 +00:05:57,180 --> 00:05:59,790 +You could just specify the name that you want for the + +115 +00:05:59,790 --> 00:06:03,110 +Local Directory. For example, in this case, myproject2. And, + +116 +00:06:03,110 --> 00:06:06,630 +so here you'll get the project in my local work space + +117 +00:06:06,630 --> 00:06:09,530 +with the name that I specified. So, let's go inside one + +118 +00:06:09,530 --> 00:06:12,020 +of these two projects that have the same content because they're + +119 +00:06:12,020 --> 00:06:14,930 +coming from the repository. If you want to see the details + +120 +00:06:14,930 --> 00:06:18,550 +of the server you can use the remote command and specify + +121 +00:06:18,550 --> 00:06:22,230 +the flag -v. And here we'll show you what is the remote + +122 +00:06:22,230 --> 00:06:25,560 +repository now let's go ahead to make some changes to the project + +123 +00:06:25,560 --> 00:06:28,820 +for example let's add a file. So I'm just going to create this + +124 +00:06:28,820 --> 00:06:31,230 +empty file which I am going to call new file I'm going to + +125 +00:06:31,230 --> 00:06:34,890 +add it to my index so that it gets committed. Later on and + +126 +00:06:34,890 --> 00:06:37,650 +then I'm going to run git commit to actually commit it to the + +127 +00:06:37,650 --> 00:06:41,570 +local repository. And I'm going to specify the comment for the commit right + +128 +00:06:41,570 --> 00:06:44,120 +away here from the command line. So when we do that the + +129 +00:06:44,120 --> 00:06:47,680 +file gets added to my local repository. And if we want to double + +130 +00:06:47,680 --> 00:06:50,690 +check that, we can run git log. And if you look at + +131 +00:06:50,690 --> 00:06:53,360 +the last commit at the top, you can see that it's telling + +132 +00:06:53,360 --> 00:06:56,980 +me that the new file was added to the repository, showing the + +133 +00:06:56,980 --> 00:06:59,940 +comment that I added. But this is just for the local repository, + +134 +00:06:59,940 --> 00:07:03,100 +so I need to use the git push command to push it + +135 +00:07:03,100 --> 00:07:06,250 +to the remote repository. And at this point, when I run that, + +136 +00:07:06,250 --> 00:07:09,890 +my local changes will be committed. To the remote repository. So now + +137 +00:07:09,890 --> 00:07:13,110 +let's go to the other copy of the project that we created. + +138 +00:07:13,110 --> 00:07:16,660 +The one under directory myproject2. If you remember this project was + +139 +00:07:16,660 --> 00:07:19,610 +linked up to the same remote project. But of course, if we run + +140 +00:07:19,610 --> 00:07:22,720 +get log here, we don't see this latest change that we made, because + +141 +00:07:22,720 --> 00:07:25,970 +we didn't synchronize this local copy with the remote copy. And so we + +142 +00:07:25,970 --> 00:07:28,530 +just have these files, the README and ,Five that worked there before. + +143 +00:07:28,530 --> 00:07:30,720 +So what we need to do is that we need to pull the + +144 +00:07:30,720 --> 00:07:34,180 +changes from the remote repository using git pull, and when we do that, + +145 +00:07:34,180 --> 00:07:38,130 +that will actually pull these changes and therefore, create the new files that + +146 +00:07:38,130 --> 00:07:41,340 +we created in the other directory. And if we run git log now, + +147 +00:07:41,340 --> 00:07:43,790 +you can see that now we have the new entry. The comment at + +148 +00:07:43,790 --> 00:07:46,920 +the top, that says this new file was added and of course, this + +149 +00:07:46,920 --> 00:07:49,880 +is just an example, so we had two copies of the project on the + +150 +00:07:49,880 --> 00:07:52,990 +same machine and for the same user, so the normal users scenario for + +151 +00:07:52,990 --> 00:07:56,230 +this, it will be that, each user will have their local copy, but this + +152 +00:07:56,230 --> 00:07:59,220 +should have given you the idea of how, git allows you to work + +153 +00:07:59,220 --> 00:08:03,210 +on some local file. Commit them and push them to a remote repository and + +154 +00:08:03,210 --> 00:08:06,680 +other users to get your changes, do further changes push + +155 +00:08:06,680 --> 00:08:08,860 +them as well and then, you know, they will allow you + +156 +00:08:08,860 --> 00:08:10,890 +to get their changes, and so on and so forth. So + +157 +00:08:10,890 --> 00:08:15,540 +really allows this collaboration between different users and keeping track + +158 +00:08:15,540 --> 00:08:18,730 +of all the changes made by the different users. So now + +159 +00:08:18,730 --> 00:08:21,860 +let's look at some more advanced concept, which are the concept + +160 +00:08:21,860 --> 00:08:25,600 +of branching, and merging. So what branching means is basically is + +161 +00:08:25,600 --> 00:08:28,540 +to make a copy, to create a branch of the current + +162 +00:08:28,540 --> 00:08:32,070 +project so that we can work on that copy indpendently from the + +163 +00:08:32,070 --> 00:08:34,740 +other copy, from the other branch. And then we can decide whether + +164 +00:08:34,740 --> 00:08:37,190 +we want to keep, both branches, or we want to merge them at + +165 +00:08:37,190 --> 00:08:40,510 +some point. And you can of course have multiple branches, not just two. + +166 +00:08:40,510 --> 00:08:43,558 +And the reason why this is particularly useful is because in many + +167 +00:08:43,558 --> 00:08:46,790 +cases if you think, about the way we develop software in general, + +168 +00:08:46,790 --> 00:08:50,030 +we work with artifacts. We might have the need to create kind + +169 +00:08:50,030 --> 00:08:53,910 +of a separate copy of your work space. To do some experiments for example. + +170 +00:08:53,910 --> 00:08:54,940 +So you want to change something in + +171 +00:08:54,940 --> 00:08:56,250 +the code, you're not really sure it's going to + +172 +00:08:56,250 --> 00:08:57,650 +work and you don't want to touch + +173 +00:08:57,650 --> 00:08:59,500 +your main copy. So that's the perfect application + +174 +00:08:59,500 --> 00:09:00,830 +for branching. If you want to do + +175 +00:09:00,830 --> 00:09:02,710 +something like that...you want to experiment or do + +176 +00:09:02,710 --> 00:09:04,800 +some modifications that you're not sure about, + +177 +00:09:04,800 --> 00:09:06,820 +you will branch your code, you will do + +178 +00:09:06,820 --> 00:09:08,230 +the changes...and then if you're happy with + +179 +00:09:08,230 --> 00:09:09,890 +the changes, you will merge that branch + +180 +00:09:09,890 --> 00:09:13,250 +with the original one, or worse if you're not happy with the changes you will + +181 +00:09:13,250 --> 00:09:16,680 +just throw away that branch. So this is just one possible use of branch but + +182 +00:09:16,680 --> 00:09:18,950 +it's one of the main uses of that. So in all let's see how that + +183 +00:09:18,950 --> 00:09:21,070 +can be done with git. So first of all if you + +184 +00:09:21,070 --> 00:09:24,740 +want to see which branches are currently present in your project, you can + +185 +00:09:24,740 --> 00:09:28,260 +simply execute git branch, and in this case, you can see + +186 +00:09:28,260 --> 00:09:31,090 +that there's only one branch, which is called master, and the star + +187 +00:09:31,090 --> 00:09:33,940 +there indicates that this is our current branch. So how do + +188 +00:09:33,940 --> 00:09:37,210 +we create a new branch? So we simply run the command + +189 +00:09:37,210 --> 00:09:41,010 +git branch and specify a name for the new branch, for example we'll + +190 +00:09:41,010 --> 00:09:44,110 +call it newBranch, to make it very explicit. At this point, + +191 +00:09:44,110 --> 00:09:46,940 +if we run git branch of course, we will have + +192 +00:09:46,940 --> 00:09:50,410 +a new branch plus master will still be our current branch. So + +193 +00:09:50,410 --> 00:09:52,780 +if you want to switch to the new branch, we will use + +194 +00:09:52,780 --> 00:09:56,510 +the git checkout command and specify the name of the branch that + +195 +00:09:56,510 --> 00:10:00,220 +we want to become our current branch. So when we run that, + +196 +00:10:00,220 --> 00:10:02,780 +git will tell us that we switched to the new branch. And + +197 +00:10:02,780 --> 00:10:05,920 +if we run git branch you will see that now the star + +198 +00:10:05,920 --> 00:10:09,130 +is next to newBranch because that's our current branch. There is a + +199 +00:10:09,130 --> 00:10:12,834 +shortcut for these two commands. If you run the command git + +200 +00:10:12,834 --> 00:10:17,240 +checkout specify the -b flag and then the name of + +201 +00:10:17,240 --> 00:10:19,790 +the new branch it will do both things at the same + +202 +00:10:19,790 --> 00:10:22,910 +time. It will create the new branch called testing in this + +203 +00:10:22,910 --> 00:10:25,760 +case, and then it will switch to new branch and then + +204 +00:10:25,760 --> 00:10:28,860 +it will tell you after executing the command. So now if + +205 +00:10:28,860 --> 00:10:31,290 +we look at the git branch output, you can see that + +206 +00:10:31,290 --> 00:10:35,090 +there is three branches and we are currently on the testing branch. + +207 +00:10:35,090 --> 00:10:37,300 +So now let's create a new file and just call it test + +208 +00:10:37,300 --> 00:10:41,180 +file, put some content in there, save it, we edit and commit it. + +209 +00:10:47,380 --> 00:10:50,280 +And as you can see, now in this current branch, we have our + +210 +00:10:50,280 --> 00:10:53,430 +testFile. So now let's switch to a different branch. So let's go back + +211 +00:10:53,430 --> 00:10:57,550 +to the master branch using the usual git checkout command. So now if + +212 +00:10:57,550 --> 00:11:00,310 +we do an ls, if we check the content of the current directory, + +213 +00:11:00,310 --> 00:11:03,140 +we can see that the testFile is not there, because of course, it's + +214 +00:11:03,140 --> 00:11:06,070 +not in this branch. so now let's assume that we are happy with + +215 +00:11:06,070 --> 00:11:09,260 +the testFile that we created, with the modification that we made on the + +216 +00:11:09,260 --> 00:11:13,080 +branch. And so we want to merge that branch with our master branch. + +217 +00:11:13,080 --> 00:11:16,180 +To do that we can call the git merge command and + +218 +00:11:16,180 --> 00:11:19,260 +we'll specify the branch that we want to merge with the current + +219 +00:11:19,260 --> 00:11:23,030 +one. So we will specify testing in this case. That will merge + +220 +00:11:23,030 --> 00:11:26,260 +the testing branch with the current branch, which is the master. Which + +221 +00:11:26,260 --> 00:11:29,200 +means that now the testfile is in my current working directory, + +222 +00:11:29,200 --> 00:11:32,180 +is in my current, Current branch. And if I run the branch, + +223 +00:11:32,180 --> 00:11:35,590 +you'll see that the testing branch is obviously still there, so let's + +224 +00:11:35,590 --> 00:11:38,370 +assume that we want to delete the testing branch at this point + +225 +00:11:38,370 --> 00:11:41,220 +because we don't need it anymore. We could simply execute + +226 +00:11:41,220 --> 00:11:44,940 +the branch -d which stands for -delete, specify + +227 +00:11:44,940 --> 00:11:47,670 +the name of the branch and this will eliminate that + +228 +00:11:47,670 --> 00:11:51,670 +branch as confirmed by running the command git branch or the + +229 +00:11:51,670 --> 00:11:55,030 +testing branch no longer shows up. So, something that might + +230 +00:11:55,030 --> 00:11:57,200 +happen when you merge a branch is, is that you + +231 +00:11:57,200 --> 00:12:00,000 +might have conflicts For example, in case you change the, + +232 +00:12:00,000 --> 00:12:03,600 +the same file into different branches. So, let's see an example + +233 +00:12:03,600 --> 00:12:06,730 +of that. So, we're going to check which branches we have, + +234 +00:12:06,730 --> 00:12:09,260 +so we have two branches, in this case, master and newBranch + +235 +00:12:09,260 --> 00:12:14,040 +Our current branch is master. Let's open this file called new + +236 +00:12:14,040 --> 00:12:19,310 +file and, add some content there. So now let's commit + +237 +00:12:19,310 --> 00:12:21,890 +this changes to the get to the local repository. Now + +238 +00:12:21,890 --> 00:12:24,600 +let's switch to the other branch and if you remember we + +239 +00:12:24,600 --> 00:12:26,900 +do this by running git checkout and the name of the + +240 +00:12:26,900 --> 00:12:29,150 +branch. And at this point we do the same operation here. + +241 +00:12:29,150 --> 00:12:32,090 +So we take this file and we change it here to. In this + +242 +00:12:32,090 --> 00:12:34,740 +case we have content that reflects the fact that we are. In the + +243 +00:12:34,740 --> 00:12:38,790 +new branch just for convenience. At this point, we also can move the + +244 +00:12:38,790 --> 00:12:41,870 +file here. The comment here is, of course, that this is the new + +245 +00:12:41,870 --> 00:12:44,800 +file in the new branch. So, at this point, what we have here + +246 +00:12:44,800 --> 00:12:47,980 +is that we have this file called newfile that has been modified + +247 +00:12:47,980 --> 00:12:51,320 +independently both in the master branch and in the new branch. So we + +248 +00:12:51,320 --> 00:12:55,090 +have a conflict. Right? So, now, let's switch back to the master branch. + +249 +00:12:55,090 --> 00:12:57,720 +So now, let's say we want to merge the two branches. So + +250 +00:12:57,720 --> 00:13:00,490 +since we are in master, we want to say that when I + +251 +00:13:00,490 --> 00:13:03,970 +merge the new branch into the current one. And when we run + +252 +00:13:03,970 --> 00:13:07,540 +that, we get an auto merging conflict. So at this point what + +253 +00:13:07,540 --> 00:13:10,390 +we can do, is that we can manually fix the conflict by + +254 +00:13:10,390 --> 00:13:13,910 +opening the new file. So the file that was showing the conflict. + +255 +00:13:13,910 --> 00:13:16,860 +So here you can see the kind of of information that you get + +256 +00:13:16,860 --> 00:13:20,340 +in the conflicted file. So it's telling you basically that there is + +257 +00:13:20,340 --> 00:13:23,760 +in the head which is the, the master this conflict. Which is new + +258 +00:13:23,760 --> 00:13:26,830 +file in master. Which is the content that we added of course. And + +259 +00:13:26,830 --> 00:13:30,190 +then you know, under, you know, the separator you can see the content + +260 +00:13:30,190 --> 00:13:32,650 +that was added in the new branch. Which is the contents in new + +261 +00:13:32,650 --> 00:13:35,990 +file, in new branch. So basically, what this is showing you is the + +262 +00:13:35,990 --> 00:13:39,150 +parts of the file that are conflicting. In this case, we only have + +263 +00:13:39,150 --> 00:13:41,990 +one line, is basically the whole file into two versions and you can + +264 +00:13:41,990 --> 00:13:45,460 +decide which version you want to keep or how you want to merge in + +265 +00:13:45,460 --> 00:13:48,260 +general, the two pieces. So here, let's assume that we + +266 +00:13:48,260 --> 00:13:52,140 +want to keep the content from the master. So what we're + +267 +00:13:52,140 --> 00:13:54,510 +going to do is we're going to elimate the annotations + +268 +00:13:54,510 --> 00:13:57,500 +and we're going to eliminate the additional content. We save this + +269 +00:13:57,500 --> 00:13:59,680 +file. So at this point what we need to do + +270 +00:13:59,680 --> 00:14:04,040 +is simply to commit the modified file (the merge file) and we + +271 +00:14:04,040 --> 00:14:07,440 +do that in the normal way. We call git add, specifying + +272 +00:14:07,440 --> 00:14:11,180 +the file, so git add newfile. Then we run git commit + +273 +00:14:11,180 --> 00:14:15,630 +newfile, and we specify in the comment for clarity that this is the merged file, + +274 +00:14:15,630 --> 00:14:19,530 +so that we performed a merge. And at this point we are done with our merge. diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/14 - GIT Demo: Git + Eclipse - lang_en_vs5.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/14 - GIT Demo: Git + Eclipse - lang_en_vs5.srt new file mode 100644 index 0000000..b95877b --- /dev/null +++ b/usth/ICT2.7/P1L4 Version Control Subtitles/14 - GIT Demo: Git + Eclipse - lang_en_vs5.srt @@ -0,0 +1,307 @@ +1 +00:00:00,140 --> 00:00:02,580 +Now that we saw some of the git basic + +2 +00:00:02,580 --> 00:00:05,689 +functionalities in practice, let's go a step further. If + +3 +00:00:05,689 --> 00:00:08,420 +you remember I mentioned before that many of these + +4 +00:00:08,420 --> 00:00:12,250 +version control systems are actually integrated into IDE's. So + +5 +00:00:12,250 --> 00:00:14,540 +what were going to look at next is what happens + +6 +00:00:14,540 --> 00:00:17,500 +if we put together git and eclipse. And the + +7 +00:00:17,500 --> 00:00:20,960 +result is egit, or EGit is a plug in + +8 +00:00:20,960 --> 00:00:25,520 +for the eclipse IDE that adds git functionality to eclipse. + +9 +00:00:25,520 --> 00:00:27,880 +So let's see how that works in practice. So + +10 +00:00:27,880 --> 00:00:31,400 +support for git is available in many IDE's including + +11 +00:00:31,400 --> 00:00:33,920 +Eclipse. And if you want to get github + +12 +00:00:33,920 --> 00:00:38,620 +for Eclipse, you should go to eclipse.github.com and you can + +13 +00:00:38,620 --> 00:00:41,445 +download the plugin. So this bring us to the + +14 +00:00:41,445 --> 00:00:44,530 +plugin page and you can use the provided URL + +15 +00:00:44,530 --> 00:00:47,060 +and directions to install the plugin. In this case + +16 +00:00:47,060 --> 00:00:49,945 +we're going to copy this address. So we're going to + +17 +00:00:49,945 --> 00:00:54,110 +Eclipse, Help, Install new software. We can click on Add + +18 +00:00:54,110 --> 00:00:56,810 +to add a new site from which to get software. We + +19 +00:00:56,810 --> 00:00:59,110 +paste the location that we just copied here. And we + +20 +00:00:59,110 --> 00:01:02,842 +can give it a descriptive name. In this case I'll just + +21 +00:01:02,842 --> 00:01:06,645 +call it Eclipse Git plugin. Then when I click okay, + +22 +00:01:06,645 --> 00:01:09,720 +Eclipse will go, and look for plugins. And as you can + +23 +00:01:09,720 --> 00:01:12,510 +see, there are two options. We can select both of them, + +24 +00:01:12,510 --> 00:01:15,180 +and click on next. You can see that the Eclipse identified + +25 +00:01:15,180 --> 00:01:18,330 +a few dependencies. You can click next and accept them. You can + +26 +00:01:18,330 --> 00:01:21,540 +accept the terms and conditions for the plug in, and then just + +27 +00:01:21,540 --> 00:01:25,730 +finish. And at this point, Eclipse will install the plugin, which might + +28 +00:01:25,730 --> 00:01:28,610 +take a little bit of time. So we're just going to speed it up. + +29 +00:01:28,610 --> 00:01:31,110 +And when Eclipse is done, you will get this prompt that will + +30 +00:01:31,110 --> 00:01:33,670 +tell you that you need to restart Eclipse for the plugin to + +31 +00:01:33,670 --> 00:01:36,990 +be actually installed. And at this point, you want to click yes. And + +32 +00:01:36,990 --> 00:01:40,550 +when Eclipse restarts. You'll have your plugin. We're going to go to the git + +33 +00:01:40,550 --> 00:01:44,030 +repository perspective that we can select here. And when we click + +34 +00:01:44,030 --> 00:01:47,160 +OK, you can see that our display will change. And since + +35 +00:01:47,160 --> 00:01:49,360 +we don't have any repository yet, we are provided with the + +36 +00:01:49,360 --> 00:01:53,620 +possibility of adding an existing local git repository, cloning a git repository + +37 +00:01:53,620 --> 00:01:56,330 +or creating a new local git repository. We're going to add an + +38 +00:01:56,330 --> 00:01:59,800 +existing local repository. This is the one that we created earlier, + +39 +00:01:59,800 --> 00:02:02,170 +so we'll select it and click finish, and you can see + +40 +00:02:02,170 --> 00:02:05,660 +that my project is now added to this set of git repositories. + +41 +00:02:05,660 --> 00:02:09,240 +Now let's check out the project from the repository by selecting import + +42 +00:02:09,240 --> 00:02:12,530 +project. And here you can import something as an existing project, you + +43 +00:02:12,530 --> 00:02:15,300 +can use a new project wizard, and in this case I chose + +44 +00:02:15,300 --> 00:02:18,680 +the option of importing as a general project. Then I click Next and + +45 +00:02:18,680 --> 00:02:20,870 +as you can see, I have the project name up there and + +46 +00:02:20,870 --> 00:02:24,630 +I can click Finish. So now, if I go to the resource perspective + +47 +00:02:24,630 --> 00:02:27,740 +by clicking here, I can see that the project has been added + +48 +00:02:27,740 --> 00:02:30,760 +to my set of projects. And I can see all the files within + +49 +00:02:30,760 --> 00:02:33,440 +the project, particularly, if I click on the README, you can see + +50 +00:02:33,440 --> 00:02:36,190 +that we have the Readme file that we created before. Same thing for + +51 +00:02:36,190 --> 00:02:38,930 +the test file. One thing I can do at this point, it + +52 +00:02:38,930 --> 00:02:41,070 +to execute different git commands, perform + +53 +00:02:41,070 --> 00:02:43,430 +different git operations by using the team + +54 +00:02:43,430 --> 00:02:47,010 +submenu in the contactual menu. And here there are several things + +55 +00:02:47,010 --> 00:02:50,650 +I can do including some advanced commands. And just to give it a + +56 +00:02:50,650 --> 00:02:53,200 +shot, I am going to try to click show local history, and this + +57 +00:02:53,200 --> 00:02:56,180 +shows the history of the file. For example it shows the author and + +58 +00:02:56,180 --> 00:02:59,200 +it shows when he was created, when he was authored. Lets make + +59 +00:02:59,200 --> 00:03:02,810 +some changes to this file by adding some new content. Okay. I saved + +60 +00:03:02,810 --> 00:03:05,160 +the file and now I can see that error that indicates that my + +61 +00:03:05,160 --> 00:03:08,620 +file was locally changed. So now if I go to the team menu, + +62 +00:03:08,620 --> 00:03:11,380 +you can see that I have the option to add to the index, + +63 +00:03:11,380 --> 00:03:14,686 +to stage the file. And now I got this new label that star + +64 +00:03:14,686 --> 00:03:17,980 +that shows the files added to the index. And now at this point, + +65 +00:03:17,980 --> 00:03:21,270 +I can go to the team menu again and I can actually commit + +66 +00:03:21,270 --> 00:03:25,480 +the file by selecting the corresponding entry. This allows me to enter + +67 +00:03:25,480 --> 00:03:28,390 +the commit message, exactly in the same way which I could do + +68 +00:03:28,390 --> 00:03:31,250 +that from the command line with the textual editor. And after I + +69 +00:03:31,250 --> 00:03:34,050 +put the comment there, I can actually commit. And now if we + +70 +00:03:34,050 --> 00:03:36,320 +look at the history view, we can see here that we have + +71 +00:03:36,320 --> 00:03:38,960 +a new version for the file that we just modified. And we + +72 +00:03:38,960 --> 00:03:42,250 +can also see the commit comment. And, at this point, if we + +73 +00:03:42,250 --> 00:03:46,450 +had remote repository we could push our changes to that remote repository + +74 +00:03:46,450 --> 00:03:49,330 +as well. Again, using the team submenu and + +75 +00:03:49,330 --> 00:03:52,170 +the contextual menu. And, speaking of remote repositories, what we + +76 +00:03:52,170 --> 00:03:55,230 +are going to see next is how to use GitHub + +77 +00:03:55,230 --> 00:03:58,640 +repositories which are remote repositories that are hosted on GitHub. diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/15 - GIT Demo: Github - lang_en_vs3.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/15 - GIT Demo: Github - lang_en_vs3.srt new file mode 100644 index 0000000..5e842d7 --- /dev/null +++ b/usth/ICT2.7/P1L4 Version Control Subtitles/15 - GIT Demo: Github - lang_en_vs3.srt @@ -0,0 +1,239 @@ +1 +00:00:00,120 --> 00:00:02,820 +In the interview that we did at the beginning of the class, + +2 +00:00:02,820 --> 00:00:08,430 +we talked with John about GitHub, where GitHub is a Git hosting website, and + +3 +00:00:08,430 --> 00:00:11,390 +John told you all about it. For this class, we will be + +4 +00:00:11,390 --> 00:00:16,350 +using GitHub as our Git hosting. Let's see how GitHub works in practice and + +5 +00:00:16,350 --> 00:00:19,450 +let's see some of the common features offered by GitHub. + +6 +00:00:19,450 --> 00:00:24,010 +This is what we'll do in the third part of this Git demo. What I'm showing here + +7 +00:00:24,010 --> 00:00:28,550 +is the GitHub website and as I said, GitHub is a Git hosting website and + +8 +00:00:28,550 --> 00:00:32,950 +you can create an account on GitHub by simply signing up on the website. And + +9 +00:00:32,950 --> 00:00:36,100 +because we already have an account that we're simply going to sign in + +10 +00:00:36,100 --> 00:00:40,570 +to see what kind of functionality GitHub offers. And we're going to specify our + +11 +00:00:40,570 --> 00:00:44,190 +username and password. And as you can see on the GitHub website, + +12 +00:00:44,190 --> 00:00:47,695 +you can use this menu up on the right to create a new repository or + +13 +00:00:47,695 --> 00:00:51,500 +change the account settings. Let's click on our user profile. And + +14 +00:00:51,500 --> 00:00:54,270 +here we can see some statistics for our user. For + +15 +00:00:54,270 --> 00:00:59,190 +example, we can see statistic about our contributions and our repositories. So + +16 +00:00:59,190 --> 00:01:02,560 +now if we go to the Repositories view, we can create a new repository. + +17 +00:01:02,560 --> 00:01:07,117 +We give it a name. Let's call it myrepo. We can provide the description for + +18 +00:01:07,117 --> 00:01:11,680 +the repository. If we want, we can initialize the repository by adding a README + +19 +00:01:11,680 --> 00:01:15,860 +file. And even though we are not doing it right now, if you can see up here, + +20 +00:01:15,860 --> 00:01:19,820 +you can also add a license here on the right and it allows you + +21 +00:01:19,820 --> 00:01:24,831 +to choose from a set of predefined licenses. And you can also a .gitignore file, + +22 +00:01:24,831 --> 00:01:28,410 +which, in case you don't know what that is, it's a very convenient file that + +23 +00:01:28,410 --> 00:01:32,740 +will automatically exclude from the repositories file that should not be added. + +24 +00:01:32,740 --> 00:01:35,690 +So if you remember in the lesson we said there are things that you should not + +25 +00:01:35,690 --> 00:01:39,263 +add to the repositories. For example, derived files. So + +26 +00:01:39,263 --> 00:01:42,360 +here, using this menu, you can pick the type of project that you have. + +27 +00:01:42,360 --> 00:01:47,740 +For example, Java project or PHP project or many other kinds of projects. And + +28 +00:01:47,740 --> 00:01:50,510 +the GitHub will automatically add that file for you. + +29 +00:01:50,510 --> 00:01:53,680 +But let's skip that for now and simply create our repository. And + +30 +00:01:53,680 --> 00:01:58,000 +that creates a repository that contains the README file because that's what we + +31 +00:01:58,000 --> 00:02:02,580 +decided to do. And it also allows you to edit the README file by clicking on it. + +32 +00:02:02,580 --> 00:02:05,560 +It will bring up an editor and here you can write, you know, + +33 +00:02:05,560 --> 00:02:08,949 +for example, initial readme for your project. Then you can add your + +34 +00:02:08,949 --> 00:02:13,070 +commit message up there and then you can commit the changes to your README file. + +35 +00:02:13,070 --> 00:02:18,212 +The site also provides many other features, like, for example, creating issues, + +36 +00:02:18,212 --> 00:02:22,030 +pull requests, adding and editing a wiki, and also, you know, + +37 +00:02:22,030 --> 00:02:25,740 +defining other characteristics and settings for the repository. Now, if we go to + +38 +00:02:25,740 --> 00:02:30,500 +the repository, you can see that we also get the HTTPS link for the repository. + +39 +00:02:30,500 --> 00:02:35,870 +So this is the URL that you can use to clone your repository. If you remember, + +40 +00:02:35,870 --> 00:02:39,250 +with a git clone command, that's the URL that you can specify. So + +41 +00:02:39,250 --> 00:02:43,480 +let's try to do that and clone that repository. So we're going to copy this URL. + +42 +00:02:43,480 --> 00:02:48,300 +To do that, we're going to execute git clone and specify the URL that we + +43 +00:02:48,300 --> 00:02:52,310 +just copied. And you can see that the project was created, was cloned locally. + +44 +00:02:52,310 --> 00:02:55,760 +And if we go under myrepo, which is the name of the repository, you can see that + +45 +00:02:55,760 --> 00:02:59,570 +the README file that we created on GitHub is here. So if we create a new file, + +46 +00:02:59,570 --> 00:03:03,340 +which we're going to call again, newFile just to be clear. And then we + +47 +00:03:03,340 --> 00:03:07,920 +can add it, commit it, specifying as usual a commit message. So at this point, + +48 +00:03:07,920 --> 00:03:11,940 +we can push our locked out changes to the remote GitHub repository. And + +49 +00:03:11,940 --> 00:03:14,340 +because the GitHub repository is password protected, + +50 +00:03:14,340 --> 00:03:17,660 +we have to specify our login and password. And of course, if you + +51 +00:03:17,660 --> 00:03:21,770 +pass the wrong password, GitHub is not going to let you in. So let's try again. + +52 +00:03:21,770 --> 00:03:25,110 +Let's try to get the password right this time. I'm going to specify again, + +53 +00:03:25,110 --> 00:03:31,130 +my login and my password. At this point, the push is successful and + +54 +00:03:31,130 --> 00:03:35,220 +my changes are actually pushed to the master, which is the GitHub repository. + +55 +00:03:35,220 --> 00:03:39,020 +To double check that, let's go back to the GitHub repository and as you can see, + +56 +00:03:39,020 --> 00:03:42,470 +that the file that we added, newFile, is there as expected. And of course, + +57 +00:03:42,470 --> 00:03:45,880 +there's many more things that you can do on the GitHub website, so + +58 +00:03:45,880 --> 00:03:48,410 +I strongly encourage you to go and try out things. But + +59 +00:03:48,410 --> 00:03:51,980 +the key message here is that the GitHub is a Git hosting website where you + +60 +00:03:51,980 --> 00:03:54,990 +can get an account and create your remote repositories. diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/16 - GIT Recap - lang_en_vs5.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/16 - GIT Recap - lang_en_vs5.srt new file mode 100644 index 0000000..b35fc59 --- /dev/null +++ b/usth/ICT2.7/P1L4 Version Control Subtitles/16 - GIT Recap - lang_en_vs5.srt @@ -0,0 +1,35 @@ +1 +00:00:00,110 --> 00:00:02,212 +Now that we are done with our demo, I just want + +2 +00:00:02,212 --> 00:00:05,910 +to go through a quick GIT recap to remind you of the + +3 +00:00:05,910 --> 00:00:08,720 +main commands that we saw, and what they do. And you can + +4 +00:00:08,720 --> 00:00:11,290 +also use these as sort of a reference when you work with + +5 +00:00:11,290 --> 00:00:13,940 +GIT. And by the way, if you look around and you do + +6 +00:00:13,940 --> 00:00:16,960 +a search, you can see that there's tons of examples on the + +7 +00:00:16,960 --> 00:00:22,170 +web of GitHub tutorials, videos, examples, manuals. So feel free to + +8 +00:00:22,170 --> 00:00:25,910 +explore. And I'm actually going to put some references to tutorials and + +9 +00:00:25,910 --> 00:00:29,100 +videos that I found particularly useful in the notes for the class. diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/17 - GIT Recap: Local Repositories - lang_en_vs5.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/17 - GIT Recap: Local Repositories - lang_en_vs5.srt new file mode 100644 index 0000000..c29fae8 --- /dev/null +++ b/usth/ICT2.7/P1L4 Version Control Subtitles/17 - GIT Recap: Local Repositories - lang_en_vs5.srt @@ -0,0 +1,163 @@ +1 +00:00:00,100 --> 00:00:02,460 +So, let me start by recapping some of the operations that + +2 +00:00:02,460 --> 00:00:06,000 +we can perform on local repositories. I'm just going to list them + +3 +00:00:06,000 --> 00:00:09,240 +here and go through them by separating them into three main + +4 +00:00:09,240 --> 00:00:12,930 +categories. The first one is commands that, to create a repository and + +5 +00:00:12,930 --> 00:00:15,470 +notice that not all of these are git commands, that for + +6 +00:00:15,470 --> 00:00:18,710 +example, to create the repository, we would normally want to. Create a + +7 +00:00:18,710 --> 00:00:21,560 +directory, which is exactly what we did in our demo. We want + +8 +00:00:21,560 --> 00:00:25,310 +to go to that directory and then execute the git init statement, + +9 +00:00:25,310 --> 00:00:29,110 +which initializes that directory as a git repository. The second + +10 +00:00:29,110 --> 00:00:32,530 +category includes commands that we'll use to modify the content of + +11 +00:00:32,530 --> 00:00:35,280 +the repository. We saw that we can use git add + +12 +00:00:35,280 --> 00:00:39,190 +to add a specific file or a complete directory to our + +13 +00:00:39,190 --> 00:00:41,650 +index. So to the list of files that will be + +14 +00:00:41,650 --> 00:00:44,510 +committed, that will be considered in the next commit. Then we + +15 +00:00:44,510 --> 00:00:47,620 +can use commit to actually commit the changes that we + +16 +00:00:47,620 --> 00:00:50,374 +made to those files to our local repository, and we can + +17 +00:00:50,374 --> 00:00:54,030 +also use git move and git rm or git remove + +18 +00:00:54,030 --> 00:00:57,420 +to move files around and to remove files. Finally, the + +19 +00:00:57,420 --> 00:01:00,270 +third category is the category of commands that we can + +20 +00:01:00,270 --> 00:01:04,950 +use to inspect the concrete repository. And this set includes git + +21 +00:01:04,950 --> 00:01:06,960 +log, that we can use to see the log of + +22 +00:01:06,960 --> 00:01:09,970 +the repository, git status, that can give us important information + +23 +00:01:09,970 --> 00:01:12,810 +about the status of the file center repository. Git diff, + +24 +00:01:12,810 --> 00:01:15,500 +that we can use to see the differences between for example, + +25 +00:01:15,500 --> 00:01:19,160 +our local files. And the remote files. And finally git + +26 +00:01:19,160 --> 00:01:23,270 +show, that will show us information about our last commit. What + +27 +00:01:23,270 --> 00:01:25,940 +we committed, what were the changes and so on. And again, + +28 +00:01:25,940 --> 00:01:29,290 +we saw most or all of these commands in our demo. + +29 +00:01:29,290 --> 00:01:31,920 +So let me also remind you of a possible workflow. Which + +30 +00:01:31,920 --> 00:01:34,350 +again, we already saw but it's always good to go through + +31 +00:01:34,350 --> 00:01:37,670 +it once more. And remember that this is just an example. + +32 +00:01:37,670 --> 00:01:40,520 +It's just a possible workflow. You can do many different things, + +33 +00:01:40,520 --> 00:01:43,210 +you can have many different workflows with git. This is just + +34 +00:01:43,210 --> 00:01:45,980 +up to illustrate some of the things that you can do. So, + +35 +00:01:45,980 --> 00:01:49,430 +you might do some local editing. Execute git status to see what + +36 +00:01:49,430 --> 00:01:53,020 +files you changed. Then you might run a git diff on the + +37 +00:01:53,020 --> 00:01:56,230 +files to see what are these changes. And then you can run + +38 +00:01:56,230 --> 00:01:59,460 +git commit -a to commit your changes. And in case you + +39 +00:01:59,460 --> 00:02:02,520 +want to specify the commit message right away without having to go + +40 +00:02:02,520 --> 00:02:06,040 +through an editor, you can also add the -m parameter and + +41 +00:02:06,040 --> 00:02:08,110 +specify the message here on the same line. diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/18 - GIT Recap: Remote Repositories - lang_en_vs3.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/18 - GIT Recap: Remote Repositories - lang_en_vs3.srt new file mode 100644 index 0000000..9afccc9 --- /dev/null +++ b/usth/ICT2.7/P1L4 Version Control Subtitles/18 - GIT Recap: Remote Repositories - lang_en_vs3.srt @@ -0,0 +1,59 @@ +1 +00:00:00,110 --> 00:00:02,960 +SImilarly, let's go through some commands that you can run on + +2 +00:00:02,960 --> 00:00:07,150 +remote repositories. First command is the command to copy a repository, + +3 +00:00:07,150 --> 00:00:10,840 +which is git clone in which you get a remote repository and you make a lot of + +4 +00:00:10,840 --> 00:00:14,850 +copy in your working directory. The repository can be specified as a URL. + +5 +00:00:14,850 --> 00:00:18,230 +It can be a local file, it can be specified using the HTTP or + +6 +00:00:18,230 --> 00:00:21,070 +the SSH protocol, and there's also other ways to do it. + +7 +00:00:21,070 --> 00:00:25,300 +This creates a complete local copy of the repository, as it says, and links it + +8 +00:00:25,300 --> 00:00:29,030 +to the remote repository, which is what is called the origin. And if you want, + +9 +00:00:29,030 --> 00:00:33,400 +you could also actually link to the repository, later. Then the normal way of + +10 +00:00:33,400 --> 00:00:37,800 +receiving changes from a repository is to perform a git pull command. And we saw + +11 +00:00:37,800 --> 00:00:42,345 +that you can also perform the same operation through two commands, get fetch and + +12 +00:00:42,345 --> 00:00:47,210 +git merge. In case you want to inspect the changes before actually merging them, + +13 +00:00:47,210 --> 00:00:49,550 +before actually getting them in your local copy. And + +14 +00:00:49,550 --> 00:00:52,940 +if you want to send changes that you have in your local repository to + +15 +00:00:52,940 --> 00:00:55,680 +a remote repository, you will use the git push command. diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/19 - GitHub Setup Assignment - lang_en_vs2.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/19 - GitHub Setup Assignment - lang_en_vs2.srt new file mode 100644 index 0000000..9dec29b --- /dev/null +++ b/usth/ICT2.7/P1L4 Version Control Subtitles/19 - GitHub Setup Assignment - lang_en_vs2.srt @@ -0,0 +1,15 @@ +1 +00:00:00,160 --> 00:00:03,095 +This is ultimately pretty simple. All you need to do is visit + +2 +00:00:03,095 --> 00:00:08,720 +github.com/join and set up a free GitHub account. If you already have a GitHub, + +3 +00:00:08,720 --> 00:00:11,870 +account you can sign in using your existing account. If you want to + +4 +00:00:11,870 --> 00:00:14,550 +use a separate identity for the class, feel free to set up a second one. diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/19 - GitHub Setup Assignment - lang_pt_vs1.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/19 - GitHub Setup Assignment - lang_pt_vs1.srt new file mode 100644 index 0000000..6dc6f48 --- /dev/null +++ b/usth/ICT2.7/P1L4 Version Control Subtitles/19 - GitHub Setup Assignment - lang_pt_vs1.srt @@ -0,0 +1,19 @@ +1 +00:00:00,160 --> 00:00:03,095 +Na verdade é muito simples. +Só tens que ir a + +2 +00:00:03,095 --> 00:00:08,720 +github.com/join e criar uma conta grátis +no GitHub. Se já tiveres uma conta GitHub, + +3 +00:00:08,720 --> 00:00:11,870 +podes entrar com a tua conta. +Se quiseres + +4 +00:00:11,870 --> 00:00:14,550 +criar uma diferente para o curso, +podes criar uma segunda sem problemas. diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/2 - Interview with John Britton - lang_en_vs5.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/2 - Interview with John Britton - lang_en_vs5.srt new file mode 100644 index 0000000..999833f --- /dev/null +++ b/usth/ICT2.7/P1L4 Version Control Subtitles/2 - Interview with John Britton - lang_en_vs5.srt @@ -0,0 +1,435 @@ +1 +00:00:00,170 --> 00:00:02,630 +>> And I thought that the best way to break the ice on version + +2 +00:00:02,630 --> 00:00:04,970 +control systems and Git and some other + +3 +00:00:04,970 --> 00:00:07,939 +related concepts was to interview John Britton who + +4 +00:00:07,939 --> 00:00:11,840 +works with GitHub. So let's go and see what John has to say about + +5 +00:00:11,840 --> 00:00:14,120 +Git, about version control systems in general, + +6 +00:00:14,120 --> 00:00:17,809 +and about GitHub. John is in Tapei, if I'm not wrong. + +7 +00:00:17,809 --> 00:00:18,610 +>> That's correct. + +8 +00:00:18,610 --> 00:00:20,320 +>> Okay so we're, you know we couldn't + +9 +00:00:20,320 --> 00:00:22,570 +go there so we're interviewing him remotely. And I + +10 +00:00:22,570 --> 00:00:25,490 +want, I just want to thank you so much and John for agreeing to talk to us. + +11 +00:00:25,490 --> 00:00:27,940 +>> Thank you very much for having me it was my pleasure. + +12 +00:00:27,940 --> 00:00:30,560 +>> And, I'm just going to ask, a few + +13 +00:00:30,560 --> 00:00:32,938 +general questions because John is an expert on, + +14 +00:00:32,938 --> 00:00:36,270 +Git and GitHub. John is a developer and + +15 +00:00:36,270 --> 00:00:38,550 +a community builder is active in both the + +16 +00:00:38,550 --> 00:00:42,200 +open source and the open education areas. And + +17 +00:00:42,200 --> 00:00:44,860 +as an educational liaison we have, is working + +18 +00:00:44,860 --> 00:00:47,580 +to improve Computer Science education by bringing the + +19 +00:00:47,580 --> 00:00:51,460 +principles of open source into the classroom. And + +20 +00:00:51,460 --> 00:00:53,160 +I'm going to start with an general question, + +21 +00:00:53,160 --> 00:00:55,320 +which is what is a version control system? + +22 +00:00:55,320 --> 00:00:57,960 +>> So, a version control system is + +23 +00:00:57,960 --> 00:01:00,360 +a tool that software developers use. Anybody + +24 +00:01:00,360 --> 00:01:02,560 +who's doing you know, working with digital + +25 +00:01:02,560 --> 00:01:06,540 +assets, digital projects can also use for + +26 +00:01:06,540 --> 00:01:11,320 +keeping track of, you know, revisions of your project, and when I say revisions, I + +27 +00:01:11,320 --> 00:01:16,850 +mean essentially snapshots of your project over time. So you can imagine doing + +28 +00:01:16,850 --> 00:01:19,720 +some work and then every so often, be it, every couple of + +29 +00:01:19,720 --> 00:01:23,799 +hours, every couple of days, saving a permanent snapshot of your project. + +30 +00:01:24,880 --> 00:01:26,650 +>> Why is this useful? I understand that + +31 +00:01:26,650 --> 00:01:28,720 +it is nice to take a snapshot of your + +32 +00:01:28,720 --> 00:01:30,070 +project, but what did you do with the + +33 +00:01:30,070 --> 00:01:33,420 +snapshot afterwards? I think the most immediately obvious benefit + +34 +00:01:33,420 --> 00:01:36,340 +to having snapshots of your project to keeping + +35 +00:01:36,340 --> 00:01:38,280 +revisions is that you can go back. If you + +36 +00:01:38,280 --> 00:01:40,190 +have ever worked on a project and got to + +37 +00:01:40,190 --> 00:01:41,940 +a point where you solved a bunch of your + +38 +00:01:41,940 --> 00:01:45,330 +problems, and there is just one more step to do. And + +39 +00:01:45,330 --> 00:01:47,640 +you start working on trying to solve that last step, and + +40 +00:01:47,640 --> 00:01:51,350 +you break things, you make it worse then it was an + +41 +00:01:51,350 --> 00:01:54,420 +hour ago. At that point its easier to just go back + +42 +00:01:54,420 --> 00:01:56,780 +to what you had then trying to figure out what you + +43 +00:01:56,780 --> 00:01:59,320 +broke. So you can always go back in time, and the + +44 +00:01:59,320 --> 00:02:02,660 +other big one is being able to collaborate with multiple people, + +45 +00:02:02,660 --> 00:02:07,450 +so its pretty seldom these days that you. Work on a production + +46 +00:02:07,450 --> 00:02:09,860 +totally on your own. It's most common to work in, you + +47 +00:02:09,860 --> 00:02:12,993 +know, in teams and small groups. And so, using a revision + +48 +00:02:12,993 --> 00:02:16,340 +control system allows you to collaborate with other people. And make + +49 +00:02:16,340 --> 00:02:19,060 +sure that you don't step on each other's toes as you're working. + +50 +00:02:19,060 --> 00:02:21,310 +>> Alright, that's great, because those are exactly some of the + +51 +00:02:21,310 --> 00:02:25,250 +topics that we're going to cover in the lesson. And so since we're + +52 +00:02:25,250 --> 00:02:28,470 +going to talk about the specifics of version control system which is + +53 +00:02:28,470 --> 00:02:32,660 +Git and you're definitely an expert in, in Git. So what would + +54 +00:02:32,660 --> 00:02:36,510 +you say is specifically special about Git? What characterizes it + +55 +00:02:36,510 --> 00:02:39,940 +and how does it compare to other version control systems. + +56 +00:02:39,940 --> 00:02:43,140 +>> So if any of you have used version control systems before, you + +57 +00:02:43,140 --> 00:02:47,850 +may have heard of something like subversion, CVS, or maybe a commercial solution + +58 +00:02:47,850 --> 00:02:53,550 +like ProForce. I think the main important characteristics of Git are first that + +59 +00:02:53,550 --> 00:02:56,050 +it's open source. And the second, + +60 +00:02:56,050 --> 00:02:59,030 +that it's a distributed version control system. + +61 +00:02:59,030 --> 00:03:00,430 +So what that means, the distributed version + +62 +00:03:00,430 --> 00:03:04,260 +control system is essentially a system for tracking + +63 +00:03:04,260 --> 00:03:07,700 +revisions of your software that doesn't have any + +64 +00:03:07,700 --> 00:03:11,730 +central repository. So the biggest characteristic is that + +65 +00:03:11,730 --> 00:03:14,520 +I can do my work and you can also work on the same project at + +66 +00:03:14,520 --> 00:03:16,900 +the same time without communicating with each other + +67 +00:03:16,900 --> 00:03:19,650 +and without communicating to a central system. + +68 +00:03:19,650 --> 00:03:24,190 +>> Okay, great. And so now that we saw what Git is, what is + +69 +00:03:24,190 --> 00:03:26,050 +GitHub and how does it fit into + +70 +00:03:26,050 --> 00:03:29,320 +this picture of the distributed, revision control system? + +71 +00:03:29,320 --> 00:03:34,800 +>> So GitHub is, the world's largest code host, and we essentially have a + +72 +00:03:34,800 --> 00:03:36,940 +website where you can collaborate with people + +73 +00:03:36,940 --> 00:03:39,950 +when you're writing code. There's two ways you + +74 +00:03:39,950 --> 00:03:43,650 +can use GitHub. You can use it publicly for open source and you can use + +75 +00:03:43,650 --> 00:03:49,660 +it in private within your team, or your company, or within your class. And, Git + +76 +00:03:49,660 --> 00:03:53,960 +Hub started out just as a way to host your Git repositories. But it's + +77 +00:03:53,960 --> 00:03:56,000 +actually grown into quite a bit more. It's + +78 +00:03:56,000 --> 00:03:59,820 +an entire collaboration system around your code. + +79 +00:03:59,820 --> 00:04:00,580 +>> How many users do you have? + +80 +00:04:00,580 --> 00:04:03,620 +>> I would say that we're approaching five million. + +81 +00:04:03,620 --> 00:04:05,570 +I don't know the exact number. We're definitely more + +82 +00:04:05,570 --> 00:04:08,080 +than four million right now. But yeah, I'd say + +83 +00:04:08,080 --> 00:04:10,330 +somewhere, somewhere close to between four and five million. + +84 +00:04:10,330 --> 00:04:14,750 +>> So that's a lot space I'd guess. Terabytes of disk + +85 +00:04:14,750 --> 00:04:15,840 +space, I would imagine. + +86 +00:04:15,840 --> 00:04:19,170 +>> There are a lot of GIT repositories on, on our servers. + +87 +00:04:19,170 --> 00:04:21,180 +>> Something else you want to say? I + +88 +00:04:21,180 --> 00:04:23,920 +guess that the when taking about GitHub there's one + +89 +00:04:23,920 --> 00:04:26,110 +thing that you kind of can't leave out and + +90 +00:04:26,110 --> 00:04:28,670 +that's that's a feature that's called a pull request. + +91 +00:04:28,670 --> 00:04:31,090 +So when you're using GitHub, you can share + +92 +00:04:31,090 --> 00:04:34,940 +your Git repository, do some work, and actually do + +93 +00:04:34,940 --> 00:04:37,880 +do a code review. Of proposed changes which + +94 +00:04:37,880 --> 00:04:39,770 +is what we call a pull request on github.com. + +95 +00:04:39,770 --> 00:04:42,790 +Essentially what it lets you do is have a discussion + +96 +00:04:42,790 --> 00:04:46,320 +about a set of proposed changes and leave feedback in + +97 +00:04:46,320 --> 00:04:48,870 +line with the code. You could say for example, this + +98 +00:04:48,870 --> 00:04:51,670 +method needs to be re-factored or I think I found if + +99 +00:04:51,670 --> 00:04:54,830 +off by one error here, just different kinds of feedback + +100 +00:04:54,830 --> 00:04:59,120 +so that before you totally integrate some proposed changes. You have, + +101 +00:04:59,120 --> 00:05:01,180 +kind of a conversation about what your code. And I + +102 +00:05:01,180 --> 00:05:03,050 +think that's really valuable when you are working in a team. + +103 +00:05:03,050 --> 00:05:05,510 +>> Thank you, John, that was very informative and + +104 +00:05:05,510 --> 00:05:07,440 +thanks again for taking the time to talk to us. + +105 +00:05:07,440 --> 00:05:10,160 +>> No problem, thanks for having me. I'll talk to you soon. + +106 +00:05:10,160 --> 00:05:13,990 +>> Let's thank again John for enlightening us + +107 +00:05:13,990 --> 00:05:17,350 +on some aspects of version control systems, Git and + +108 +00:05:17,350 --> 00:05:19,410 +GitHub. And now, let's go over some of the + +109 +00:05:19,410 --> 00:05:21,650 +topics that we discussed with John to recap them. diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/3 - Version Control System Introduction - lang_en_vs5.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/3 - Version Control System Introduction - lang_en_vs5.srt new file mode 100644 index 0000000..be0515b --- /dev/null +++ b/usth/ICT2.7/P1L4 Version Control Subtitles/3 - Version Control System Introduction - lang_en_vs5.srt @@ -0,0 +1,207 @@ +1 +00:00:00,160 --> 00:00:02,080 +So first of all, what is a version + +2 +00:00:02,080 --> 00:00:05,550 +control system? A version control system or VCS, + +3 +00:00:05,550 --> 00:00:07,670 +is a system that allows you to manage + +4 +00:00:07,670 --> 00:00:11,180 +multiple revisions of the same unit of information. For + +5 +00:00:11,180 --> 00:00:14,330 +example of documents, of source files or any + +6 +00:00:14,330 --> 00:00:17,380 +other item of that sort. And as the graphical + +7 +00:00:17,380 --> 00:00:21,240 +depiction shows, a VCS allows a multiple actors. + +8 +00:00:21,240 --> 00:00:25,020 +Here we have four, to cooperate and share files. + +9 +00:00:25,020 --> 00:00:26,980 +Now, let's drill into this concept in a little + +10 +00:00:26,980 --> 00:00:29,720 +more detail. And let's do that by discussing why + +11 +00:00:29,720 --> 00:00:32,870 +is VCS useful, especially in the context of software + +12 +00:00:32,870 --> 00:00:35,790 +engineering and of software development. So first of all, + +13 +00:00:35,790 --> 00:00:39,570 +using a version control system enforces discipline, because it + +14 +00:00:39,570 --> 00:00:43,030 +manages the process by which the control of items + +15 +00:00:43,030 --> 00:00:46,720 +passes from one person to another. Another important aspect + +16 +00:00:46,720 --> 00:00:51,170 +of VCS is that it allows you for archiving versions. + +17 +00:00:51,170 --> 00:00:54,330 +So you can store subsequent versions of source controlled + +18 +00:00:54,330 --> 00:00:57,450 +items into a VCS. And not only you can + +19 +00:00:57,450 --> 00:01:00,450 +store versions, you can also maintain a lot of + +20 +00:01:00,450 --> 00:01:03,480 +interesting and important historical information + +21 +00:01:03,480 --> 00:01:05,810 +about these versions. For example, + +22 +00:01:05,810 --> 00:01:08,070 +a VCL will store information such as, who is + +23 +00:01:08,070 --> 00:01:11,270 +the author for this specific version stored in the system. + +24 +00:01:11,270 --> 00:01:13,820 +Or, for another example, on what day and what + +25 +00:01:13,820 --> 00:01:16,260 +time that version was stored. And a lot of other + +26 +00:01:16,260 --> 00:01:19,240 +interesting information about the specific version of the + +27 +00:01:19,240 --> 00:01:21,600 +item. Information that you can then retrieve and for + +28 +00:01:21,600 --> 00:01:25,040 +example, use to compare versions. Obviously, the fact of + +29 +00:01:25,040 --> 00:01:27,970 +having a central repository in which all these items + +30 +00:01:27,970 --> 00:01:31,350 +are stored enables collaboration, so people can more easily + +31 +00:01:31,350 --> 00:01:35,510 +share data, share files, share documents through the use + +32 +00:01:35,510 --> 00:01:37,950 +of VCS. And I'm sure that you all had + +33 +00:01:37,950 --> 00:01:41,320 +the experience of deleting a file by mistake or + +34 +00:01:41,320 --> 00:01:43,860 +modifying a file in the wrong way, or in the + +35 +00:01:43,860 --> 00:01:47,830 +most common case of changing something in your code for instance. + +36 +00:01:47,830 --> 00:01:50,490 +And breaking something and not being able to go back + +37 +00:01:50,490 --> 00:01:53,630 +to a version that was working. Not remembering, for example, what + +38 +00:01:53,630 --> 00:01:56,130 +is that you changed that broke the code. In all + +39 +00:01:56,130 --> 00:01:59,850 +these cases a version control system can be extremely useful because + +40 +00:01:59,850 --> 00:02:03,330 +it will allow you to recover from this accidental deletions + +41 +00:02:03,330 --> 00:02:06,690 +or edits. And for example, to go back of yesterdays version + +42 +00:02:06,690 --> 00:02:09,949 +that was working perfectly, and also to compare, for example, yesterdays + +43 +00:02:09,949 --> 00:02:12,920 +version with today version and see what is that you changed. + +44 +00:02:12,920 --> 00:02:16,000 +Finally, a version control system will normally also allow you to + +45 +00:02:16,000 --> 00:02:20,460 +conserve and save disk space on both the source control client + +46 +00:02:20,460 --> 00:02:23,880 +and on the server. Why? Well, for instance because it's centralizing + +47 +00:02:23,880 --> 00:02:26,570 +the management of the version. So instead of having many copies + +48 +00:02:26,570 --> 00:02:29,480 +spread around, you'll have only one central point where these copies + +49 +00:02:29,480 --> 00:02:32,240 +are stored or a few points where these copies are stored. + +50 +00:02:32,240 --> 00:02:34,330 +In addition, version control system often + +51 +00:02:34,330 --> 00:02:37,470 +uses efficient algorithms to store these changes. + +52 +00:02:37,470 --> 00:02:41,310 +And therefore, you can keep many versions without taking up too much space. diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/4 - VCS Quiz - lang_en_vs4.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/4 - VCS Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..26d9c55 --- /dev/null +++ b/usth/ICT2.7/P1L4 Version Control Subtitles/4 - VCS Quiz - lang_en_vs4.srt @@ -0,0 +1,31 @@ +1 +00:00:00,100 --> 00:00:02,430 +Now before we continue, and we look at more details + +2 +00:00:02,430 --> 00:00:04,400 +of version control systems, I want to ask you a + +3 +00:00:04,400 --> 00:00:07,230 +quick question about VCS. I want to know whether you + +4 +00:00:07,230 --> 00:00:10,190 +have used a version control system before, and if so, + +5 +00:00:10,190 --> 00:00:12,090 +which one or which ones. I'm going to list in + +6 +00:00:12,090 --> 00:00:15,260 +here some of the most commonly used version control systems, + +7 +00:00:15,260 --> 00:00:18,840 +like CVS, Subversion, GIT, and I'm also allowing you to + +8 +00:00:18,840 --> 00:00:22,640 +specify other VCS in case you have used different ones. diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/5 - VCS Quiz Solution - lang_en_vs7.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/5 - VCS Quiz Solution - lang_en_vs7.srt new file mode 100644 index 0000000..1a380a5 --- /dev/null +++ b/usth/ICT2.7/P1L4 Version Control Subtitles/5 - VCS Quiz Solution - lang_en_vs7.srt @@ -0,0 +1,11 @@ +1 +00:00:00,130 --> 00:00:03,030 +And of course there's no right answer for this. I just wanted to collect some + +2 +00:00:03,030 --> 00:00:05,020 +statistics. To see what kind of previous + +3 +00:00:05,020 --> 00:00:07,100 +experience you have with this kind of systems. diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/6 - Essential Actions - lang_en_vs5.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/6 - Essential Actions - lang_en_vs5.srt new file mode 100644 index 0000000..5159d9b --- /dev/null +++ b/usth/ICT2.7/P1L4 Version Control Subtitles/6 - Essential Actions - lang_en_vs5.srt @@ -0,0 +1,79 @@ +1 +00:00:00,140 --> 00:00:02,220 +What I want to do next, is to look at how + +2 +00:00:02,220 --> 00:00:05,780 +version control systems actually work. We saw what they are. We + +3 +00:00:05,780 --> 00:00:08,130 +saw why they are useful. But how do they actually work? + +4 +00:00:08,130 --> 00:00:11,460 +And we're going to do that by starting from some essential + +5 +00:00:11,460 --> 00:00:15,400 +actions that version control systems perform. The first one is the + +6 +00:00:15,400 --> 00:00:18,920 +addition of files. So, when you use a version control system, + +7 +00:00:18,920 --> 00:00:22,280 +you can add a file to the repository. And at that + +8 +00:00:22,280 --> 00:00:25,400 +point the file will be accessible to other people who have access + +9 +00:00:25,400 --> 00:00:28,640 +to the repository. And now the fundamental action is commit. + +10 +00:00:28,640 --> 00:00:31,230 +When you change a file, a file that is already in + +11 +00:00:31,230 --> 00:00:33,610 +the repository, when you make some local changes to a + +12 +00:00:33,610 --> 00:00:36,430 +file that is already in the repository, you want then to + +13 +00:00:36,430 --> 00:00:39,460 +commit your changes to the central repository, so they can + +14 +00:00:39,460 --> 00:00:43,990 +become visible to all of the other users on the repository. Finally, + +15 +00:00:43,990 --> 00:00:47,770 +another fundamental action is the action of updating a file. If + +16 +00:00:47,770 --> 00:00:50,650 +we have a repository and someone else can modify the files + +17 +00:00:50,650 --> 00:00:52,800 +in the repository, I want to be able to get + +18 +00:00:52,800 --> 00:00:55,550 +the changes that other people made to the files in the + +19 +00:00:55,550 --> 00:00:58,980 +repository. And these are just three of the basic actions, but + +20 +00:00:58,980 --> 00:01:01,870 +there are many, many more. And we'll see several of those. diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/7 - Example Workflow - lang_en_vs5.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/7 - Example Workflow - lang_en_vs5.srt new file mode 100644 index 0000000..c2f58df --- /dev/null +++ b/usth/ICT2.7/P1L4 Version Control Subtitles/7 - Example Workflow - lang_en_vs5.srt @@ -0,0 +1,111 @@ +1 +00:00:00,160 --> 00:00:02,830 +Before looking at additional actions, though, I would like to + +2 +00:00:02,830 --> 00:00:06,770 +see what is the basic workflow in a version control system + +3 +00:00:06,770 --> 00:00:09,370 +using the three actions that we just saw. And to + +4 +00:00:09,370 --> 00:00:11,760 +do that I'm going to use two of our friends, Brad + +5 +00:00:11,760 --> 00:00:14,590 +and Janet. So we have Janet here, Brad, and a + +6 +00:00:14,590 --> 00:00:18,440 +VCS that they are using. Now imagine that Janet creates a + +7 +00:00:18,440 --> 00:00:23,020 +file called foo.txt and puts some information in the file. + +8 +00:00:23,020 --> 00:00:25,250 +At that point she might want to add the file to + +9 +00:00:25,250 --> 00:00:28,340 +the repository and to commit it so that her changes + +10 +00:00:28,340 --> 00:00:31,210 +and the file get to the central repository. And when she + +11 +00:00:31,210 --> 00:00:33,900 +adds and commit, that's exactly what will happen, in foo + +12 +00:00:33,900 --> 00:00:36,870 +will be come available here, and will be accessible to the + +13 +00:00:36,870 --> 00:00:40,330 +other users. In this case it'll be accessible to Brad. + +14 +00:00:40,330 --> 00:00:44,190 +If Brett were to run an update command, what will happen + +15 +00:00:44,190 --> 00:00:47,800 +is that the file foo.txt will be copied on the local + +16 +00:00:47,800 --> 00:00:50,460 +work space of Brad and Brad will be able to access + +17 +00:00:50,460 --> 00:00:52,980 +the file. At this point Brad might want to modify + +18 +00:00:52,980 --> 00:00:57,110 +the file, for example add something to this existing file. + +19 +00:00:57,110 --> 00:00:59,410 +After doing that, he also may want to share the + +20 +00:00:59,410 --> 00:01:02,900 +updated file with Janet. To do that, he will commit the + +21 +00:01:02,900 --> 00:01:06,070 +file and the result will be exactly the same of + +22 +00:01:06,070 --> 00:01:09,470 +when Janet committed her file. That the updated file will + +23 +00:01:09,470 --> 00:01:11,890 +be sent to the repository and the repository will store + +24 +00:01:11,890 --> 00:01:15,570 +that information and make it available for other users. So now, + +25 +00:01:15,570 --> 00:01:18,290 +if Janet performs an update, she will get the + +26 +00:01:18,290 --> 00:01:21,860 +new version of foo.txt with the additional information that was + +27 +00:01:21,860 --> 00:01:24,950 +added by Brad. And we will see all of this + +28 +00:01:24,950 --> 00:01:27,350 +in action in our next demo in a few minutes. diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/8 - "Don'ts" in VCS - lang_en_vs5.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/8 - "Don'ts" in VCS - lang_en_vs5.srt new file mode 100644 index 0000000..f5d27fb --- /dev/null +++ b/usth/ICT2.7/P1L4 Version Control Subtitles/8 - "Don'ts" in VCS - lang_en_vs5.srt @@ -0,0 +1,175 @@ +1 +00:00:00,100 --> 00:00:02,020 +Before getting to the demo, I want to say a few + +2 +00:00:02,020 --> 00:00:06,550 +more things. In particular, I discuss the main don'ts in VCS. So, + +3 +00:00:06,550 --> 00:00:09,110 +what are some things that you don't want to do, and + +4 +00:00:09,110 --> 00:00:12,687 +you should not do, when you're using a version control system? And + +5 +00:00:12,687 --> 00:00:15,382 +I'm going to mention two, in particular, because these are two + +6 +00:00:15,382 --> 00:00:18,028 +that I witnessed several times when I was teaching this class and + +7 +00:00:18,028 --> 00:00:21,820 +also when collaborating with other people. So, there are two kinds + +8 +00:00:21,820 --> 00:00:25,460 +of resources that you don't want to add to a VCS normally. + +9 +00:00:25,460 --> 00:00:29,070 +One is derived files. For example an executable that is + +10 +00:00:29,070 --> 00:00:31,930 +derived by compiling a set of source files, where the + +11 +00:00:31,930 --> 00:00:34,480 +source files all already in the repository. At that point, + +12 +00:00:34,480 --> 00:00:37,680 +there is no reason to also add the executable file in + +13 +00:00:37,680 --> 00:00:41,150 +the repository. So in general, any executable file should not + +14 +00:00:41,150 --> 00:00:44,570 +be added to repository. The second class of files that I + +15 +00:00:44,570 --> 00:00:47,760 +want to mention is these bulky binary files. If you + +16 +00:00:47,760 --> 00:00:50,600 +have one such file, it is normally not a good idea + +17 +00:00:50,600 --> 00:00:53,430 +to store them under a version control system, to store them + +18 +00:00:53,430 --> 00:00:56,670 +in the repository. There might be exceptions to these rules, but in + +19 +00:00:56,670 --> 00:00:59,070 +general, these are the kind of files that you want to + +20 +00:00:59,070 --> 00:01:02,540 +keep local, and you don't want to put in the VCS repository. + +21 +00:01:02,540 --> 00:01:06,500 +Another typical mistake, and that happens all the time, especially to + +22 +00:01:06,500 --> 00:01:10,650 +novice users of VCS. Is that you get your file from VCS + +23 +00:01:10,650 --> 00:01:13,120 +and so you get your local copy of the file that + +24 +00:01:13,120 --> 00:01:16,270 +was in the VCS, and you want to make some changes, and + +25 +00:01:16,270 --> 00:01:20,090 +before making the changes you decided, no, no let me actually save + +26 +00:01:20,090 --> 00:01:22,410 +a local copy of the file, and I'm going to work on + +27 +00:01:22,410 --> 00:01:24,950 +that one. Or let me save it before I modify it, or + +28 +00:01:24,950 --> 00:01:28,350 +let take a snap shot of a whole tree of files. Just because + +29 +00:01:28,350 --> 00:01:30,830 +I don't really trust the fact that VCS is going to be + +30 +00:01:30,830 --> 00:01:33,170 +able to help and is going to be able to recover from possible + +31 +00:01:33,170 --> 00:01:36,980 +mistakes. Never ever do that. I have seen that done many times, + +32 +00:01:36,980 --> 00:01:41,570 +and it always leads to disasters. First of all it is useless, and + +33 +00:01:41,570 --> 00:01:44,000 +second it's risky. Because then what happens is that at + +34 +00:01:44,000 --> 00:01:46,610 +the time in which you have to turn in your assignment, + +35 +00:01:46,610 --> 00:01:48,330 +in the case you are doing an assignment, but even in + +36 +00:01:48,330 --> 00:01:50,740 +more serious situation, when you have to turn in your code, + +37 +00:01:50,740 --> 00:01:54,620 +for example to your colleagues. You always end up being confused + +38 +00:01:54,620 --> 00:01:59,010 +about which is the version that you're really using. So absolutely + +39 +00:01:59,010 --> 00:02:03,262 +no local copies. No local redundancy when you're using a version + +40 +00:02:03,262 --> 00:02:06,798 +control system. Trust the version control system, and trust the version + +41 +00:02:06,798 --> 00:02:09,280 +control system to be able to manage your versions. You + +42 +00:02:09,280 --> 00:02:13,350 +can always save it, commit it, retrieve previous versions, and you'll + +43 +00:02:13,350 --> 00:02:15,530 +be able to do everything that you can do by copying + +44 +00:02:15,530 --> 00:02:19,240 +the file yourself, and even more. So again, try the VCS. diff --git a/usth/ICT2.7/P1L4 Version Control Subtitles/9 - Two Main Types of VCS - lang_en_vs5.srt b/usth/ICT2.7/P1L4 Version Control Subtitles/9 - Two Main Types of VCS - lang_en_vs5.srt new file mode 100644 index 0000000..3c6eba4 --- /dev/null +++ b/usth/ICT2.7/P1L4 Version Control Subtitles/9 - Two Main Types of VCS - lang_en_vs5.srt @@ -0,0 +1,163 @@ +1 +00:00:00,160 --> 00:00:01,970 +Something else I want to mention is that there + +2 +00:00:01,970 --> 00:00:05,460 +are many different version control systems but we can classify + +3 +00:00:05,460 --> 00:00:09,250 +them normally in two main types: centralized VCS's and + +4 +00:00:09,250 --> 00:00:13,230 +decentralized VCS's. So what is the difference between these two? + +5 +00:00:13,230 --> 00:00:16,750 +Let's use again our friends Janet and Brett. + +6 +00:00:16,750 --> 00:00:19,510 +In the case of a centralized version control system + +7 +00:00:19,510 --> 00:00:22,290 +there is a single centralized, as the name says, + +8 +00:00:22,290 --> 00:00:25,230 +repository. On which they are commiting their files. So when + +9 +00:00:25,230 --> 00:00:27,290 +Janet commits a file. The file will go from + +10 +00:00:27,290 --> 00:00:30,390 +her local working directory to the repository, and the same + +11 +00:00:30,390 --> 00:00:33,520 +will happen to Brett. The decentralized system is a little + +12 +00:00:33,520 --> 00:00:37,310 +more interesting because in this case, they will both have + +13 +00:00:37,310 --> 00:00:40,790 +sort of a local repository in which they can commit + +14 +00:00:40,790 --> 00:00:43,970 +their changes. So they can commit changes without the other + +15 +00:00:43,970 --> 00:00:47,940 +users of the VCS being able to see these changes. + +16 +00:00:47,940 --> 00:00:50,300 +And when they're happy with the version. And when they're + +17 +00:00:50,300 --> 00:00:53,900 +ready to release the version, they can push it to a central + +18 +00:00:53,900 --> 00:00:56,840 +repository. And at that point, it will become available to the other + +19 +00:00:56,840 --> 00:01:01,100 +users of the repository. To the other users of the VCS. There + +20 +00:01:01,100 --> 00:01:02,870 +are several advantages in a distributive + +21 +00:01:02,870 --> 00:01:04,300 +system. I'm just going to mention a few, + +22 +00:01:04,300 --> 00:01:07,520 +because there are really many. One is the fact of having this + +23 +00:01:07,520 --> 00:01:10,570 +local version. If you used VCS before, I'm sure you've been in + +24 +00:01:10,570 --> 00:01:13,280 +the situation in which you want to kind of take a snapshot + +25 +00:01:13,280 --> 00:01:15,820 +of what you have. But you don't want that snapshot to be available + +26 +00:01:15,820 --> 00:01:18,200 +to the other users. Because it's still not ready to be + +27 +00:01:18,200 --> 00:01:21,240 +released, to be looked up. If you're using a centralized system, + +28 +00:01:21,240 --> 00:01:23,140 +there's really no way you can do that, unless you make + +29 +00:01:23,140 --> 00:01:25,150 +a local copy, which is something we said you don't want + +30 +00:01:25,150 --> 00:01:28,625 +to do. With a distributor, with a decentralized VCS you can + +31 +00:01:28,625 --> 00:01:32,444 +commit your local changes here, in your local repository, and you + +32 +00:01:32,444 --> 00:01:37,030 +can push them to the central repository only when you're ready. + +33 +00:01:37,030 --> 00:01:40,870 +Another big advantage, is that you can use multiple remote repository. + +34 +00:01:40,870 --> 00:01:43,210 +In fact, centralized is not the right name for this + +35 +00:01:43,210 --> 00:01:45,980 +one. This is just a remote repository, and I can have + +36 +00:01:45,980 --> 00:01:48,910 +more than one. For example, Brad might want to push + +37 +00:01:48,910 --> 00:01:52,150 +to another remote repository. As well. For instance, this could be + +38 +00:01:52,150 --> 00:01:55,940 +a repository where the files are accessible for wider distribution. + +39 +00:01:55,940 --> 00:01:59,620 +Imagine developing a software system in which a team is sharing + +40 +00:01:59,620 --> 00:02:02,930 +internal versions, and then only some of these versions are actually + +41 +00:02:02,930 --> 00:02:06,080 +pushed to the repository that is seeable to the whole world. diff --git a/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/1 - Gathering Requirements - lang_en_vs3.srt b/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/1 - Gathering Requirements - lang_en_vs3.srt new file mode 100644 index 0000000..c01c859 --- /dev/null +++ b/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/1 - Gathering Requirements - lang_en_vs3.srt @@ -0,0 +1,63 @@ +1 +00:00:00,270 --> 00:00:02,969 +Gathering requirements is one of the most difficult tasks a software + +2 +00:00:02,969 --> 00:00:07,010 +engineer faces. In industry, you may gather requirements from end users, + +3 +00:00:07,010 --> 00:00:09,580 +external clients, or from co-workers in other areas of your own + +4 +00:00:09,580 --> 00:00:14,320 +company. Occasionally, you may receive a well documented set of requirements. + +5 +00:00:14,320 --> 00:00:16,970 +However, in most cases, you will need to glean the requirements + +6 +00:00:16,970 --> 00:00:20,230 +from conversations with the prospective clients, and distill them down into + +7 +00:00:20,230 --> 00:00:23,150 +something actionable on your own. Suppose a teacher came to you + +8 +00:00:23,150 --> 00:00:25,310 +with a request for a piece of software their students could + +9 +00:00:25,310 --> 00:00:28,500 +use to find out the average length of the sentences in + +10 +00:00:28,500 --> 00:00:31,390 +their essays. What questions come into mind to help you figure + +11 +00:00:31,390 --> 00:00:34,620 +out the full requirements for this project. Write down a list + +12 +00:00:34,620 --> 00:00:37,630 +of at least ten questions that might help you determine them. + +13 +00:00:37,630 --> 00:00:40,240 +Please take the time to do this before moving on. There's + +14 +00:00:40,240 --> 00:00:42,670 +no penalty for looking ahead, but if you skip this exercise + +15 +00:00:42,670 --> 00:00:44,920 +you'll cheat yourself out of the benefits of brainstorming and getting + +16 +00:00:44,920 --> 00:00:48,190 +your mind around the project before being bombarded by more information. diff --git a/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/2 - Choosing Good Questions - lang_en_vs3.srt b/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/2 - Choosing Good Questions - lang_en_vs3.srt new file mode 100644 index 0000000..a834b21 --- /dev/null +++ b/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/2 - Choosing Good Questions - lang_en_vs3.srt @@ -0,0 +1,15 @@ +1 +00:00:00,150 --> 00:00:03,400 +Now that you've written some of your own questions, consider the following + +2 +00:00:03,400 --> 00:00:07,120 +three. Which is the most likely to be useful for determining the detailed + +3 +00:00:07,120 --> 00:00:11,730 +requirements? Maybe, what OSes should it run on? Or maybe, how will the + +4 +00:00:11,730 --> 00:00:16,210 +user specify input? Or finally, how many lines of code should it take? diff --git a/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/3 - Choosing Good Questions Solution - lang_en_vs3.srt b/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/3 - Choosing Good Questions Solution - lang_en_vs3.srt new file mode 100644 index 0000000..3c29d6b --- /dev/null +++ b/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/3 - Choosing Good Questions Solution - lang_en_vs3.srt @@ -0,0 +1,55 @@ +1 +00:00:00,450 --> 00:00:03,260 +The last question is almost never a reasonable one. For one + +2 +00:00:03,260 --> 00:00:05,660 +thing, the client should not need to know or care about + +3 +00:00:05,660 --> 00:00:08,412 +how many lines of code make up the program's source code. + +4 +00:00:08,412 --> 00:00:09,910 +In forming requirements, you should avoid + +5 +00:00:09,910 --> 00:00:11,940 +implementation specific questions that do not + +6 +00:00:11,940 --> 00:00:15,290 +directly interface with the user. The first question is very relevant + +7 +00:00:15,290 --> 00:00:18,830 +in some situations. For example, a graphic sentence with video game or + +8 +00:00:18,830 --> 00:00:21,630 +performance is key. However, you should not write any operating system + +9 +00:00:21,630 --> 00:00:25,620 +specific code unless absolutely needed, and should strive to make your code + +10 +00:00:25,620 --> 00:00:28,070 +platform independent whenever possible. The + +11 +00:00:28,070 --> 00:00:30,990 +second question, however, is very relevant. + +12 +00:00:30,990 --> 00:00:32,870 +Now that you've thought a bit about what you might ask of + +13 +00:00:32,870 --> 00:00:35,810 +the client requesting this program, let's watch Alvin, one of Udasea's + +14 +00:00:35,810 --> 00:00:39,850 +engineers, asking his own questions. He'll be speaking with Lauren, the client. diff --git a/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/4 - Requirements Interview - lang_en_vs3.srt b/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/4 - Requirements Interview - lang_en_vs3.srt new file mode 100644 index 0000000..74a0b79 --- /dev/null +++ b/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/4 - Requirements Interview - lang_en_vs3.srt @@ -0,0 +1,323 @@ +1 +00:00:00,430 --> 00:00:01,050 +Hi, I'm Lauren. + +2 +00:00:01,050 --> 00:00:01,990 +>> Hi, I'm Alvin. + +3 +00:00:01,990 --> 00:00:06,470 +>> I'm an instructor at a university nearby and I've been noticing that when + +4 +00:00:06,470 --> 00:00:09,700 +my students write their essays, they have + +5 +00:00:09,700 --> 00:00:13,100 +very long, very wordy sentences and I would + +6 +00:00:13,100 --> 00:00:17,600 +like to develop some kind of tool that they can use to keep track of + +7 +00:00:17,600 --> 00:00:20,440 +this and maybe perfect their writing style. + +8 +00:00:20,440 --> 00:00:21,410 +Do you think that's something you could do? + +9 +00:00:21,410 --> 00:00:25,850 +>> I think so. Let's start by helping me get acquainted with the students + +10 +00:00:25,850 --> 00:00:29,620 +in the class. So how many students do we have in this class typically? + +11 +00:00:29,620 --> 00:00:34,000 +>> Usually about 45 per unit, but I can have up to six units a semester. + +12 +00:00:34,000 --> 00:00:36,420 +>> 45 students, and six sections per + +13 +00:00:36,420 --> 00:00:39,220 +semester. That's a farily reasonable size. So, + +14 +00:00:39,220 --> 00:00:42,790 +do you know anything about what the students are using as far as computers go? + +15 +00:00:42,790 --> 00:00:46,640 +>> I don't know what kind of computers they're using. And they + +16 +00:00:46,640 --> 00:00:50,960 +could be, I don't know, anywhere from having no tech experience to + +17 +00:00:50,960 --> 00:00:52,200 +being pretty proficient. + +18 +00:00:52,200 --> 00:00:54,930 +>> Do you know anything about how + +19 +00:00:54,930 --> 00:00:57,350 +familiar the students are with computers in general? + +20 +00:00:57,350 --> 00:00:59,540 +>> I'm sure we have some people on the low end that have + +21 +00:00:59,540 --> 00:01:01,430 +never done any type of programming, and + +22 +00:01:01,430 --> 00:01:03,680 +then some people who are pretty self-sufficient. + +23 +00:01:03,680 --> 00:01:07,210 +>> Okay, and I guess my last question related to + +24 +00:01:07,210 --> 00:01:10,170 +the students is, what is the students actually submitting to you. + +25 +00:01:10,170 --> 00:01:14,080 +>> They've been sending just raw text files via email to me. + +26 +00:01:14,080 --> 00:01:16,660 +>> So from the sounds of things + +27 +00:01:16,660 --> 00:01:19,140 +we have a fairly broad, I guess base + +28 +00:01:19,140 --> 00:01:23,100 +of students to work with, both in technical proficiency + +29 +00:01:23,100 --> 00:01:27,180 +as well as their operating system environments potentially. + +30 +00:01:27,180 --> 00:01:29,420 +So I think what we'll probably do to start + +31 +00:01:29,420 --> 00:01:33,270 +off with is make a command line, Java + +32 +00:01:33,270 --> 00:01:36,760 +based tool. That the students can run and we'll + +33 +00:01:36,760 --> 00:01:39,910 +give them a fair amount of you know, documentation + +34 +00:01:39,910 --> 00:01:41,690 +on how to use the tool. And I expect + +35 +00:01:41,690 --> 00:01:45,090 +that there will be a lot of little error conditions that may happen + +36 +00:01:45,090 --> 00:01:49,320 +that we want to produce a reasonably friendly message were anything to go wrong. + +37 +00:01:49,320 --> 00:01:50,480 +>> Yeah. That'd be great. + +38 +00:01:50,480 --> 00:01:54,750 +>> So, a little bit more, I guess about + +39 +00:01:54,750 --> 00:01:58,539 +the actual essay itself, its submission, what constitutes a word? + +40 +00:01:59,820 --> 00:02:03,190 +>> I really only care about the longer words, so, is there a + +41 +00:02:03,190 --> 00:02:06,140 +way that we can only count words that are maybe above three letters? + +42 +00:02:06,140 --> 00:02:06,830 +>> I think + +43 +00:02:06,830 --> 00:02:08,508 +that's something we can do. And I think + +44 +00:02:08,508 --> 00:02:10,030 +that because you seem a little bit unsure + +45 +00:02:10,030 --> 00:02:11,540 +we might be able to have that be + +46 +00:02:11,540 --> 00:02:13,820 +a little bit more flexible than we otherwise would. + +47 +00:02:13,820 --> 00:02:14,500 +>> Great. + +48 +00:02:14,500 --> 00:02:18,330 +>> What does a sentence mean to you? Is it kind of flexible? + +49 +00:02:18,330 --> 00:02:21,280 +>> I would say anything that ends in a period or + +50 +00:02:21,280 --> 00:02:25,870 +even a question mark. Maybe even an exclamation mark. or, something + +51 +00:02:25,870 --> 00:02:28,760 +even, maybe even with a comma or semi-colon. I really only + +52 +00:02:28,760 --> 00:02:32,370 +care about the sentences that aren't gramatically correct and are too long. + +53 +00:02:32,370 --> 00:02:35,180 +>> I think we can probably make that a little bit more flexible too + +54 +00:02:35,180 --> 00:02:37,520 +so that way, you can kind of say we're going to, or you want to include them. + +55 +00:02:37,520 --> 00:02:38,020 +>> Mm-hm. + +56 +00:02:38,020 --> 00:02:41,786 +>> So maybe, sounds like you are little bit on the fence + +57 +00:02:41,786 --> 00:02:45,100 +about whether or not say, a comma should be considered a sentence. + +58 +00:02:45,100 --> 00:02:45,130 +>> Mm. + +59 +00:02:45,130 --> 00:02:46,370 +>> Entirely on its own or not. So we + +60 +00:02:46,370 --> 00:02:49,830 +can probably make that a little bit configurable as well. + +61 +00:02:51,880 --> 00:02:56,510 +And so, just to confirm the actual end result to + +62 +00:02:56,510 --> 00:02:59,870 +the student is the average number of words per sentence? + +63 +00:02:59,870 --> 00:03:01,610 +>> Yeah, yeah that'd be fine. + +64 +00:03:01,610 --> 00:03:07,430 +>> Okay, overall to start off with, looks like we have some + +65 +00:03:07,430 --> 00:03:10,280 +sort of customization of the word length that we want to look for. + +66 +00:03:10,280 --> 00:03:10,780 +>> Mm-hm. Yeah. + +67 +00:03:12,000 --> 00:03:14,650 +>> We have some kind of variability in + +68 +00:03:14,650 --> 00:03:17,880 +what we want to have as acceptable sentence structure. + +69 +00:03:17,880 --> 00:03:24,570 +So, periods, question marks, semicolons, things like that. And, the end result + +70 +00:03:24,570 --> 00:03:27,260 +to the student is if we're successful, they'll get the average number of + +71 +00:03:27,260 --> 00:03:31,060 +words per sentence. Otherwise we tell them something a little bit helpful to + +72 +00:03:31,060 --> 00:03:33,240 +kind of put them on the right track to use the tool correctly. + +73 +00:03:33,240 --> 00:03:34,620 +>> Yeah that's the error codes right? + +74 +00:03:35,850 --> 00:03:38,150 +>> Hopefully not error codes but something a little bit nicer. + +75 +00:03:38,150 --> 00:03:39,800 +>> [LAUGH] Okay. + +76 +00:03:39,800 --> 00:03:41,150 +>> So I think I have enough to + +77 +00:03:41,150 --> 00:03:43,440 +get started and produce something that's you know, + +78 +00:03:43,440 --> 00:03:47,150 +a reasonable I guess, rough draft. Of something + +79 +00:03:47,150 --> 00:03:48,700 +that you can use to help your class out. + +80 +00:03:48,700 --> 00:03:49,590 +>> Great. Thank you. + +81 +00:03:49,590 --> 00:03:50,240 +>> Thank you. diff --git a/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/5 - Average Sentence Length Requirements - lang_en_vs3.srt b/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/5 - Average Sentence Length Requirements - lang_en_vs3.srt new file mode 100644 index 0000000..afd49e1 --- /dev/null +++ b/usth/ICT2.7/P1L5 Requirements Gathering Subtitles/5 - Average Sentence Length Requirements - lang_en_vs3.srt @@ -0,0 +1,83 @@ +1 +00:00:00,340 --> 00:00:02,300 +You've heard Alvin come up with several conclusions for how to + +2 +00:00:02,300 --> 00:00:04,510 +set up the program. And we're going to ask that you follow his + +3 +00:00:04,510 --> 00:00:07,590 +instincts. We'll spell that out here in a little more technical details + +4 +00:00:07,590 --> 00:00:11,030 +so that everyone is working from the same basic starting point. The + +5 +00:00:11,030 --> 00:00:13,770 +program must be written in Java and must not make you any + +6 +00:00:13,770 --> 00:00:16,730 +nonstandard Java libraries. You will be tested on a machine with the + +7 +00:00:16,730 --> 00:00:21,060 +vanilla installation of Java 1.6. Your program must compile on the command + +8 +00:00:21,060 --> 00:00:25,360 +line using the Java C command without any additional options. All code + +9 +00:00:25,360 --> 00:00:27,530 +required to execute the program that is not part of the + +10 +00:00:27,530 --> 00:00:31,950 +standard JDK, must be included as source code with your program. + +11 +00:00:31,950 --> 00:00:34,380 +Your program should be an application. That is, it should have + +12 +00:00:34,380 --> 00:00:37,160 +a main method and should be executable from the command line using + +13 +00:00:37,160 --> 00:00:40,100 +the Java command. The user should be able to provide a + +14 +00:00:40,100 --> 00:00:42,450 +file path to the file they wish to be analyzed as a + +15 +00:00:42,450 --> 00:00:45,880 +command line argument. User should be able to specify which delimiters + +16 +00:00:45,880 --> 00:00:50,570 +count as sentence separators, using the flag -d, defaulting to Lauren's initial + +17 +00:00:50,570 --> 00:00:53,930 +thoughts on what should be used as delimiters. The user should be + +18 +00:00:53,930 --> 00:00:58,170 +able to specify a lower limit for word length, using the flag -l, + +19 +00:00:58,170 --> 00:01:02,100 +defaulting to Lauren's guess at what value might be good. Finally, the program's + +20 +00:01:02,100 --> 00:01:03,710 +output should be the average sentence + +21 +00:01:03,710 --> 00:01:05,720 +length. Rounded down to the nearest integer. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/1 - Lesson Overview - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/1 - Lesson Overview - lang_en_vs4.srt new file mode 100644 index 0000000..27581a6 --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/1 - Lesson Overview - lang_en_vs4.srt @@ -0,0 +1,55 @@ +1 +00:00:00,340 --> 00:00:05,670 +Hello and welcome to the second part of our software engineering course. In the + +2 +00:00:05,670 --> 00:00:09,030 +previous mini-course, we discussed some basic principles + +3 +00:00:09,030 --> 00:00:12,430 +behind software engineering. We provided an overview of + +4 +00:00:12,430 --> 00:00:15,790 +several software process models and we introduced + +5 +00:00:15,790 --> 00:00:18,530 +some important tools that can help developers + +6 +00:00:18,530 --> 00:00:21,363 +increase their productivity. In this mini-course, we + +7 +00:00:21,363 --> 00:00:25,740 +will focus on requirement and prototyping. More precisely, + +8 +00:00:25,740 --> 00:00:28,840 +we will discuss in depth requirements + +9 +00:00:28,840 --> 00:00:32,400 +engineering activities. We will also discuss + +10 +00:00:32,400 --> 00:00:34,950 +techniques to perform a system analysis + +11 +00:00:34,950 --> 00:00:38,720 +and design in an object-oriented fashion. So, + +12 +00:00:38,720 --> 00:00:42,250 +let's start the first lesson of this mini-course, which is about the use + +13 +00:00:42,250 --> 00:00:45,230 +of engineering techniques to understand and + +14 +00:00:45,230 --> 00:00:48,450 +specify the purpose of a software system. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/10 - Completeness Quiz - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/10 - Completeness Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..1ab5b4a --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/10 - Completeness Quiz - lang_en_vs4.srt @@ -0,0 +1,15 @@ +1 +00:00:00,130 --> 00:00:03,060 +So now that we saw which of these requirements are pertinent and + +2 +00:00:03,060 --> 00:00:06,520 +which ones are not, can we consider the above list of requirements + +3 +00:00:06,520 --> 00:00:09,710 +of the list of these requirements marked here as a complete list + +4 +00:00:09,710 --> 00:00:13,254 +of requirements for a gym? And you have two options, yes or no. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/11 - Completeness Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/11 - Completeness Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..2ddc7e9 --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/11 - Completeness Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,23 @@ +1 +00:00:00,160 --> 00:00:02,060 +And the answer is clearly no. + +2 +00:00:02,060 --> 00:00:05,060 +Obviously, there are many missing requirements here. + +3 +00:00:05,060 --> 00:00:07,910 +For example, requirements about registration for the + +4 +00:00:07,910 --> 00:00:11,560 +customers, requirements about fitness program creation, membership + +5 +00:00:11,560 --> 00:00:15,481 +types, and so on. Plus, we are also missing all of the nonfunctional + +6 +00:00:15,481 --> 00:00:19,270 +requirements, which we haven't seen yet, but that we will discuss in a bit. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/12 - Irrelevant Requirements Quiz - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/12 - Irrelevant Requirements Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..5b5fe86 --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/12 - Irrelevant Requirements Quiz - lang_en_vs4.srt @@ -0,0 +1,43 @@ +1 +00:00:00,140 --> 00:00:02,400 +In the previous quiz, we saw that some of the requirements + +2 +00:00:02,400 --> 00:00:04,920 +that they put in the list were not pertinent. They were + +3 +00:00:04,920 --> 00:00:08,590 +irrelevant. So let me ask you. Why can irrelevant requirements be + +4 +00:00:08,590 --> 00:00:12,170 +harmful? Why is that a problem to have irrelevant requirements? So + +5 +00:00:12,170 --> 00:00:15,060 +here, I'm giving you four possible answers. And I'd like for + +6 +00:00:15,060 --> 00:00:18,150 +you to mark all that apply. Can irrelevant requirements be harmful + +7 +00:00:18,150 --> 00:00:21,210 +because they may lead to missing functionality in the final product. + +8 +00:00:21,210 --> 00:00:23,390 +Because they can introduce inconsistency. Because + +9 +00:00:23,390 --> 00:00:25,410 +they can waste the project resources. + +10 +00:00:25,410 --> 00:00:28,170 +Or because they may introduce bugs in the software system. And + +11 +00:00:28,170 --> 00:00:30,680 +as I said, more than one can be a valid reason. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/13 - Irrelevant Requirements Quiz Solution - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/13 - Irrelevant Requirements Quiz Solution - lang_en_vs5.srt new file mode 100644 index 0000000..f1c51c1 --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/13 - Irrelevant Requirements Quiz Solution - lang_en_vs5.srt @@ -0,0 +1,63 @@ +1 +00:00:00,200 --> 00:00:02,920 +So let's go through the list. Definitely irrelevant requirements + +2 +00:00:02,920 --> 00:00:06,370 +cannot lead to missing functionality in the final product, because + +3 +00:00:06,370 --> 00:00:10,730 +irrelevant requirements actually refer to unneeded functionality in the system. + +4 +00:00:10,730 --> 00:00:13,030 +So functionality that is put in the requirements, but it + +5 +00:00:13,030 --> 00:00:15,120 +is not really needed. So we're not going to mark + +6 +00:00:15,120 --> 00:00:19,400 +this one. Indeed, irrelevant requirements can introduce inconsistencies. So they + +7 +00:00:19,400 --> 00:00:22,490 +could be irrelevant requirements that not only are not pertinent + +8 +00:00:22,490 --> 00:00:25,620 +but they are inconsistent with some of the pertinent requirements. + +9 +00:00:25,620 --> 00:00:29,220 +They can also waste project resources, because if we spend time + +10 +00:00:29,220 --> 00:00:31,920 +designing and then implementing the parts of the system that we + +11 +00:00:31,920 --> 00:00:35,410 +refer to these irrelevant requirements, of course, we are wasting project + +12 +00:00:35,410 --> 00:00:38,570 +resources. And I will not mark the last one because there's really + +13 +00:00:38,570 --> 00:00:42,220 +no correlation between any irrelevant requirements and bugs in the software + +14 +00:00:42,220 --> 00:00:45,350 +system. Of course, by implementing the part of the system that refers + +15 +00:00:45,350 --> 00:00:47,960 +to an irrelevant requirement you might introduce a bug. But that's + +16 +00:00:47,960 --> 00:00:51,020 +not necessarily the case, and there really no correlation between the two. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/14 - Best Practices - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/14 - Best Practices - lang_en_vs5.srt new file mode 100644 index 0000000..7497280 --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/14 - Best Practices - lang_en_vs5.srt @@ -0,0 +1,83 @@ +1 +00:00:00,150 --> 00:00:02,290 +But we collect requirements all the time, right? Every + +2 +00:00:02,290 --> 00:00:04,960 +time we build a software system. So how do people + +3 +00:00:04,960 --> 00:00:08,320 +cope with these difficulties? What are the best practices? + +4 +00:00:08,320 --> 00:00:12,950 +In practice, developers or analysts usually identify a whole bunch + +5 +00:00:12,950 --> 00:00:16,590 +of requirements. Sometimes the easiest and most obvious ones. They + +6 +00:00:16,590 --> 00:00:19,370 +bring those to the stakeholders, and the stakeholders have to + +7 +00:00:19,370 --> 00:00:23,100 +read the requirements, understand them, and if they agree, sign + +8 +00:00:23,100 --> 00:00:25,580 +off on them. And the problem is that in general, + +9 +00:00:25,580 --> 00:00:28,910 +these requirements documents are difficult to read. They are long, they + +10 +00:00:28,910 --> 00:00:32,470 +are often unstructured. They typically contain a lot of information. And + +11 +00:00:32,470 --> 00:00:35,310 +in general, they are not exactly a pleasant read. So what + +12 +00:00:35,310 --> 00:00:39,710 +happens is that often the stakeholders are short on time, overwhelmed + +13 +00:00:39,710 --> 00:00:42,380 +by the amount of information they're given and so they give + +14 +00:00:42,380 --> 00:00:44,800 +in to the pressure and sign. And this is a bit + +15 +00:00:44,800 --> 00:00:47,300 +of a dramatization clearly but it's clear that what we are + +16 +00:00:47,300 --> 00:00:50,640 +looking at is not an ideal scenario. Clearly this is not + +17 +00:00:50,640 --> 00:00:53,810 +the way to identify the real purpose of a software system to + +18 +00:00:53,810 --> 00:00:57,920 +collect good requirements. And since one of the major causes for project + +19 +00:00:57,920 --> 00:01:02,130 +failure is the inadequacy of requirements, we should really avoid this kind + +20 +00:01:02,130 --> 00:01:03,590 +of scenario. We should follow a + +21 +00:01:03,590 --> 00:01:06,810 +rigorous and effective requirements engineering process instead. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/15 - RE Definition Breakdown - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/15 - RE Definition Breakdown - lang_en_vs4.srt new file mode 100644 index 0000000..bcc06a5 --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/15 - RE Definition Breakdown - lang_en_vs4.srt @@ -0,0 +1,207 @@ +1 +00:00:00,130 --> 00:00:02,540 +But how can we do that? How can we identify the purpose + +2 +00:00:02,540 --> 00:00:06,080 +of the system and collect good requirements? To answer that question, let me + +3 +00:00:06,080 --> 00:00:07,800 +give you another definition of requirements + +4 +00:00:07,800 --> 00:00:09,590 +engineering. And this one is a classical + +5 +00:00:09,590 --> 00:00:13,010 +one, one that summarizes what we discussed so far, and then we can + +6 +00:00:13,010 --> 00:00:16,180 +use as some sort of reference. And it is a little long. + +7 +00:00:16,180 --> 00:00:18,710 +Definitely longer than the one that we saw at the beginning. But it's + +8 +00:00:18,710 --> 00:00:21,840 +an important one and it contains a lot of very relevant points. So, + +9 +00:00:21,840 --> 00:00:25,210 +we're going to go through it and highlight these points. So the definition says, + +10 +00:00:25,210 --> 00:00:28,970 +that the requirements engineering is a set of activities concerned + +11 +00:00:28,970 --> 00:00:32,990 +with identifying and communicating the purpose of a software intensive + +12 +00:00:32,990 --> 00:00:35,770 +system and the context in which it will be used. + +13 +00:00:35,770 --> 00:00:38,570 +And this is exactly what we said at the beginning. But + +14 +00:00:38,570 --> 00:00:40,940 +something we can highlight in here, is the fact that + +15 +00:00:40,940 --> 00:00:44,210 +we're talking about a set of activities. So, what that means + +16 +00:00:44,210 --> 00:00:46,800 +is that requirements engineering is not just a phase or + +17 +00:00:46,800 --> 00:00:51,050 +a stage. It also says that it's about identifying and communicating. + +18 +00:00:51,050 --> 00:00:53,720 +And what that is telling us is that communication is + +19 +00:00:53,720 --> 00:00:56,670 +as important as the analysis. So, it's important to be + +20 +00:00:56,670 --> 00:00:59,990 +able to communicate these requirements not only to collect them. + +21 +00:00:59,990 --> 00:01:02,018 +And we will discuss many reasons why that is the + +22 +00:01:02,018 --> 00:01:05,880 +case. It explicitly talks about purpose. So that allows me + +23 +00:01:05,880 --> 00:01:10,310 +to stress, once more, that quality means fitness-for-purpose. We cannot + +24 +00:01:10,310 --> 00:01:14,410 +say anything about quality unless we understand the purpose. And + +25 +00:01:14,410 --> 00:01:16,210 +the last thing I want to point out in this first + +26 +00:01:16,210 --> 00:01:18,420 +part of the definition is the use of the term + +27 +00:01:18,420 --> 00:01:21,060 +context. This is also something else that we mentioned at + +28 +00:01:21,060 --> 00:01:24,890 +the beginning, that designers, analysts, need to know how and + +29 +00:01:24,890 --> 00:01:28,015 +where the system will be used. Without this information, you + +30 +00:01:28,015 --> 00:01:30,455 +cannot really understand what the system should do and you + +31 +00:01:30,455 --> 00:01:33,280 +cannot really build the system. So now, let's continue and + +32 +00:01:33,280 --> 00:01:35,755 +read the second part of the definition that says, hence. + +33 +00:01:35,755 --> 00:01:41,550 +Requirements engineering acts as the bridge between the real-world needs of + +34 +00:01:41,550 --> 00:01:45,315 +users, customers, and other constituencies affected by a + +35 +00:01:45,315 --> 00:01:49,440 +software system and the capabilities and opportunities afforded + +36 +00:01:49,440 --> 00:01:52,870 +by software-intensive technologies. This is a long sentence, + +37 +00:01:52,870 --> 00:01:55,030 +but also here, we can point out a + +38 +00:01:55,030 --> 00:01:57,670 +few interesting and relevant points. Let me start + +39 +00:01:57,670 --> 00:02:00,612 +by highlighting two parts. Real-world needs, and the + +40 +00:02:00,612 --> 00:02:04,150 +capabilities, and opportunities. So, what are these two + +41 +00:02:04,150 --> 00:02:07,000 +parts telling us? They are telling us that requirements + +42 +00:02:07,000 --> 00:02:09,949 +are partly about what is needed, the real-world needs + +43 +00:02:09,949 --> 00:02:13,520 +of all these stakeholders. But they're also partly about what + +44 +00:02:13,520 --> 00:02:16,100 +is possible, what we can actually build. We need + +45 +00:02:16,100 --> 00:02:19,260 +to compromise between these two things. And, finally, I would + +46 +00:02:19,260 --> 00:02:23,000 +like to point out this term constituencies, which indicates + +47 +00:02:23,000 --> 00:02:26,220 +that we need to identify all of the stakeholders, not + +48 +00:02:26,220 --> 00:02:29,130 +just the customer and the users, so anybody who is + +49 +00:02:29,130 --> 00:02:32,040 +affected by a software system. It is very important to + +50 +00:02:32,040 --> 00:02:35,130 +consider all of these actors. Otherwise, again, + +51 +00:02:35,130 --> 00:02:37,530 +we'll be missing requirements, we'll be missing + +52 +00:02:37,530 --> 00:02:41,120 +part of the purpose of the system and we will build a suboptimal system. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/16 - Defining Requirements - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/16 - Defining Requirements - lang_en_vs4.srt new file mode 100644 index 0000000..2c8dde2 --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/16 - Defining Requirements - lang_en_vs4.srt @@ -0,0 +1,219 @@ +1 +00:00:00,220 --> 00:00:02,120 +So at this point, we have talked quite a bit about + +2 +00:00:02,120 --> 00:00:03,800 +requirements engineering, but we haven't + +3 +00:00:03,800 --> 00:00:06,450 +really discussed what are requirements exactly. + +4 +00:00:06,450 --> 00:00:08,880 +So what is a requirement? To define that I am going + +5 +00:00:08,880 --> 00:00:11,860 +to use this diagram which is a classical one. So you might + +6 +00:00:11,860 --> 00:00:14,980 +have seen it before. So, discussing this diagram allows me to + +7 +00:00:14,980 --> 00:00:18,720 +point out a few interesting things about requirements and define them + +8 +00:00:18,720 --> 00:00:21,660 +in a better way. At a high level this diagram contains + +9 +00:00:21,660 --> 00:00:24,780 +two main parts, the domain of the machine, which is the hardware, + +10 +00:00:24,780 --> 00:00:27,670 +operating system, libraries and so on, on which the + +11 +00:00:27,670 --> 00:00:30,860 +software will run. And the domain of the application, which + +12 +00:00:30,860 --> 00:00:33,510 +is a world in which the software will operate. + +13 +00:00:33,510 --> 00:00:36,690 +And the machine domain is characterized by computers, which are + +14 +00:00:36,690 --> 00:00:39,980 +the hardware devices, and programs, which is the software + +15 +00:00:39,980 --> 00:00:43,430 +that runs on these devices. The application domain, conversely, is + +16 +00:00:43,430 --> 00:00:47,370 +characterized by domain properties, which are things that are true + +17 +00:00:47,370 --> 00:00:50,330 +of the world anyways, whether I'm building my system or + +18 +00:00:50,330 --> 00:00:53,510 +not, and requirements, which are things in the world we + +19 +00:00:53,510 --> 00:00:56,220 +would like to achieve by delivering the system that we are + +20 +00:00:56,220 --> 00:00:59,400 +building. Basically, to put it in a different way, the former, + +21 +00:00:59,400 --> 00:01:02,950 +the domain properties, represents the assumptions that we make on the + +22 +00:01:02,950 --> 00:01:06,740 +domain. And the latter, the requirements, are the actual requirements + +23 +00:01:06,740 --> 00:01:09,660 +that we aim to collect. So we have something here, right, + +24 +00:01:09,660 --> 00:01:13,380 +at the intersection of this application domain and this machine domain. + +25 +00:01:13,380 --> 00:01:15,570 +And what is that? And this is what we normally call + +26 +00:01:15,570 --> 00:01:19,225 +the specification, which is a description, often a formal description, + +27 +00:01:19,225 --> 00:01:22,120 +of what the system that we are building should do to + +28 +00:01:22,120 --> 00:01:25,520 +meet the requirements. So this is a bridge between these two + +29 +00:01:25,520 --> 00:01:29,380 +domains. And as the graphical depiction shows, the specification is written + +30 +00:01:29,380 --> 00:01:33,220 +in terms of shared phenomena. Things that are observable in both + +31 +00:01:33,220 --> 00:01:35,980 +the machine domain and the application domain. And just to make + +32 +00:01:35,980 --> 00:01:37,540 +things a little more concrete, I want to give you a + +33 +00:01:37,540 --> 00:01:41,180 +couple of examples of what these phenomena, these shared phenomena, are. + +34 +00:01:41,180 --> 00:01:43,350 +And we can think about two main kinds of phenomena. + +35 +00:01:43,350 --> 00:01:46,080 +The first one are events in the real world that the + +36 +00:01:46,080 --> 00:01:50,140 +machine can directly sense. For example, a button being pushed or + +37 +00:01:50,140 --> 00:01:53,910 +a sensor being activated. These are events that happen here, but + +38 +00:01:53,910 --> 00:01:56,500 +that the machine can detect. So they're events that can + +39 +00:01:56,500 --> 00:01:59,650 +be used to define the specification. And the second type of + +40 +00:01:59,650 --> 00:02:02,890 +phenomena are actions in the real world that the machine can + +41 +00:02:02,890 --> 00:02:06,380 +directly cause. For example, an image appearing on a screen or + +42 +00:02:06,380 --> 00:02:09,300 +a device being turned on and off. Again, this is something + +43 +00:02:09,300 --> 00:02:12,460 +that the machine can make happen and then can have manifestation in + +44 +00:02:12,460 --> 00:02:15,520 +the real world. And again this is therefore something on which + +45 +00:02:15,520 --> 00:02:17,720 +the specification can predicate, something that + +46 +00:02:17,720 --> 00:02:19,750 +we can describe in our specification. + +47 +00:02:19,750 --> 00:02:22,860 +And this is sort of a philosophical discussion, but even if + +48 +00:02:22,860 --> 00:02:26,210 +you don't care about the philosophical discussion, the one take away point + +49 +00:02:26,210 --> 00:02:28,800 +that I would like for you to get from this discussion is + +50 +00:02:28,800 --> 00:02:31,392 +the fact that when writing a specification you have to be aware + +51 +00:02:31,392 --> 00:02:34,860 +of the fact that you're talking about shared phenomena. Events in the real + +52 +00:02:34,860 --> 00:02:39,100 +world that the machine can sense and actions in the real world that the + +53 +00:02:39,100 --> 00:02:43,048 +machine can cause. So this is what the specification is about, a bridge between + +54 +00:02:43,048 --> 00:02:44,760 +these two worlds that define what the + +55 +00:02:44,760 --> 00:02:47,170 +system should do to satisfy the requirements. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/17 - Defining Requirements Quiz - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/17 - Defining Requirements Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..343e3cb --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/17 - Defining Requirements Quiz - lang_en_vs4.srt @@ -0,0 +1,79 @@ +1 +00:00:00,180 --> 00:00:01,780 +Since we just discussed application + +2 +00:00:01,780 --> 00:00:04,770 +domain, machine domain, and the specificiation, + +3 +00:00:04,770 --> 00:00:07,760 +let's make sure that these concepts are well understood. To do that, + +4 +00:00:07,760 --> 00:00:09,740 +I'm going to use a quiz, and I would like for you + +5 +00:00:09,740 --> 00:00:12,590 +to refer to the figure that we just discussed that I'm also + +6 +00:00:12,590 --> 00:00:16,050 +reproducing here on a small scale on the right. And then + +7 +00:00:16,050 --> 00:00:19,080 +referring to the figure, you should indicate for each of the items + +8 +00:00:19,080 --> 00:00:22,140 +that I'm going to show you here shortly. Whether they belong to + +9 +00:00:22,140 --> 00:00:25,360 +the machine domain. In this case, we're going to put a one next + +10 +00:00:25,360 --> 00:00:28,150 +to the icon. The application domain, in this case you should + +11 +00:00:28,150 --> 00:00:31,410 +put two. Or their intersection, and in this case you should + +12 +00:00:31,410 --> 00:00:34,100 +put three. So this is the lists of items. So let + +13 +00:00:34,100 --> 00:00:37,750 +me read it. An algorithm sorts a list of books in alphabetical + +14 +00:00:37,750 --> 00:00:41,070 +order by the first author's name. A notification of the arrival + +15 +00:00:41,070 --> 00:00:44,380 +of a message appears on a smart watch. An employee wants to + +16 +00:00:44,380 --> 00:00:47,150 +organize a meeting with a set of colleagues. And finally, a + +17 +00:00:47,150 --> 00:00:50,690 +user clicks a link on a web page. So again, put 1, + +18 +00:00:50,690 --> 00:00:55,740 +2, or 3 here in these lots, depending on whether you think that these items + +19 +00:00:55,740 --> 00:00:57,840 +belong to the machine domain, the application + +20 +00:00:57,840 --> 00:01:00,910 +domain, or their intersection. So, their specification, here. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/18 - Defining Requirements Quiz Solution - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/18 - Defining Requirements Quiz Solution - lang_en_vs5.srt new file mode 100644 index 0000000..7fcbd53 --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/18 - Defining Requirements Quiz Solution - lang_en_vs5.srt @@ -0,0 +1,103 @@ +1 +00:00:00,200 --> 00:00:03,460 +So let's look at each one of these items individually, starting from + +2 +00:00:03,460 --> 00:00:06,260 +the first one. And here this item has to do with how + +3 +00:00:06,260 --> 00:00:08,250 +the machine stores the information and + +4 +00:00:08,250 --> 00:00:10,240 +how the corresponding algorithm is written. + +5 +00:00:10,240 --> 00:00:12,920 +But it has no bearing in the real world. That is, in + +6 +00:00:12,920 --> 00:00:15,720 +the application domain. Therefore this. Definitely + +7 +00:00:15,720 --> 00:00:17,200 +belongs to the machine domain, and + +8 +00:00:17,200 --> 00:00:19,610 +we're going to put a one here. What about a notification of + +9 +00:00:19,610 --> 00:00:21,980 +the arrival of a message on a smart watch? This is an + +10 +00:00:21,980 --> 00:00:25,170 +event that is generated within the machine, but it has an effect, + +11 +00:00:25,170 --> 00:00:28,480 +an observable effect, in this case, in the real world as well. + +12 +00:00:28,480 --> 00:00:31,780 +Therefore, we're going to mark this as three. So this is an + +13 +00:00:31,780 --> 00:00:33,460 +event. This is something that belongs + +14 +00:00:33,460 --> 00:00:35,160 +to the intersection between the application + +15 +00:00:35,160 --> 00:00:37,480 +domain and the machine domain. So it's something that could be in + +16 +00:00:37,480 --> 00:00:40,730 +the specification. Now what about an employee that wants to organize a + +17 +00:00:40,730 --> 00:00:43,850 +meeting with a set of colleagues? This is an event that belongs + +18 +00:00:43,850 --> 00:00:46,460 +to the application domain because it is a fact that it's true + +19 +00:00:46,460 --> 00:00:50,290 +that exists. In the real world independently from the existence of a machine. + +20 +00:00:50,290 --> 00:00:52,380 +Therefore, we're going to mark this as two. + +21 +00:00:52,380 --> 00:00:54,890 +Finally, the event of a user clicking on a + +22 +00:00:54,890 --> 00:00:58,950 +link on a web page is an event that occurs in the real world but that has an + +23 +00:00:58,950 --> 00:01:01,932 +effect also within the machine and, therefore, we're + +24 +00:01:01,932 --> 00:01:04,920 +going to mark this as three, something that happens + +25 +00:01:04,920 --> 00:01:07,730 +at the intersection. between these two domains, and once + +26 +00:01:07,730 --> 00:01:10,060 +more, something that could be in a specification. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/19 - Functional and Nonfunctional Requirements - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/19 - Functional and Nonfunctional Requirements - lang_en_vs4.srt new file mode 100644 index 0000000..1cff519 --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/19 - Functional and Nonfunctional Requirements - lang_en_vs4.srt @@ -0,0 +1,139 @@ +1 +00:00:00,188 --> 00:00:02,360 +Among the requirement that we can collect from the application + +2 +00:00:02,360 --> 00:00:05,030 +domain, we need to distinguish between two main types. And you've + +3 +00:00:05,030 --> 00:00:06,540 +probably heard about these ones. + +4 +00:00:06,540 --> 00:00:09,650 +Functional requirments and non-functional requiremnts. Functional + +5 +00:00:09,650 --> 00:00:13,020 +requiremetns have to do with the functionality of the system, with + +6 +00:00:13,020 --> 00:00:16,660 +what the system does with the computation. For example the elevator + +7 +00:00:16,660 --> 00:00:19,660 +shall take people to the floor they select. That's a functional + +8 +00:00:19,660 --> 00:00:22,650 +requirement, that has to do with the functionality of the system. + +9 +00:00:22,650 --> 00:00:25,550 +Or for a very simple one, the system has to output + +10 +00:00:25,550 --> 00:00:27,620 +the square root of the number past as + +11 +00:00:27,620 --> 00:00:29,910 +an input. So these kind of requirements have in + +12 +00:00:29,910 --> 00:00:33,630 +general well defined satisfaction criteria. So, for example, if + +13 +00:00:33,630 --> 00:00:35,420 +for the latter one that we mentioned it is + +14 +00:00:35,420 --> 00:00:37,560 +pretty clear how to check whether the output + +15 +00:00:37,560 --> 00:00:39,784 +is actually the square root of the number passed + +16 +00:00:39,784 --> 00:00:43,535 +in input. Non-functional requirements, conversely, refer to a system's + +17 +00:00:43,535 --> 00:00:46,800 +non-functional properties, systems qualities. + +18 +00:00:46,800 --> 00:00:50,120 +Such as security, accuracy, performance, + +19 +00:00:50,120 --> 00:00:52,220 +cost. Or, you know, usability, + +20 +00:00:52,220 --> 00:00:55,910 +adaptability, interoperability, reusability and so + +21 +00:00:55,910 --> 00:00:58,850 +on. So, all these qualities the don't necessarily have to + +22 +00:00:58,850 --> 00:01:02,520 +do with the functionality. And, unlike functional requirements, non functional + +23 +00:01:02,520 --> 00:01:06,060 +requirements Do not always have clear satisfaction criteria. For example, + +24 +00:01:06,060 --> 00:01:08,670 +if we say that the elevator must be fast, that's + +25 +00:01:08,670 --> 00:01:10,640 +a non-functional requrement. Right? It has to do with the + +26 +00:01:10,640 --> 00:01:13,030 +speed of the elevator, which is a quality of the + +27 +00:01:13,030 --> 00:01:15,535 +elevator. But, it, it's not clear how such a requirement + +28 +00:01:15,535 --> 00:01:17,980 +could be satisfied. How could we tell whether the elevator + +29 +00:01:17,980 --> 00:01:20,000 +is fast or not. So, what we need to do + +30 +00:01:20,000 --> 00:01:22,390 +in these cases Is that we need to refine these + +31 +00:01:22,390 --> 00:01:25,300 +requirements so that they become verifiable. For the example that + +32 +00:01:25,300 --> 00:01:27,360 +I just mentioned, for instance, we might say that the + +33 +00:01:27,360 --> 00:01:30,730 +elevator must reach the requested floor in less than 30 + +34 +00:01:30,730 --> 00:01:33,190 +seconds from the moment when the floor button is pushed. + +35 +00:01:33,190 --> 00:01:36,030 +This is still a non-functional requirment, but is a verifiable one. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/2 - Interview with Jane Cleland-Huang - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/2 - Interview with Jane Cleland-Huang - lang_en_vs5.srt new file mode 100644 index 0000000..2a1bc1c --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/2 - Interview with Jane Cleland-Huang - lang_en_vs5.srt @@ -0,0 +1,411 @@ +1 +00:00:00,270 --> 00:00:02,800 +As we did for other lessons, before starting this + +2 +00:00:02,800 --> 00:00:06,150 +lesson on requirements engineering, I want to ask a world + +3 +00:00:06,150 --> 00:00:10,210 +expert on this topic a few questions. I'm here with + +4 +00:00:10,210 --> 00:00:14,150 +Jane Cleland-Huang, a professor at the DePaul University. And Jane + +5 +00:00:14,150 --> 00:00:16,500 +is a world expert in the area of requirements + +6 +00:00:16,500 --> 00:00:19,830 +engineering, which is the theme of this lesson. So I'm + +7 +00:00:19,830 --> 00:00:22,220 +talking to Jane who is currently in Chicago and I + +8 +00:00:22,220 --> 00:00:25,380 +want to. Ask her a few questions about requirements engineering. + +9 +00:00:25,380 --> 00:00:26,530 +So hi Jane how are you? + +10 +00:00:26,530 --> 00:00:27,990 +>> Fine. Thank you Alex. + +11 +00:00:27,990 --> 00:00:29,480 +>> And thank you so much for agreeing to + +12 +00:00:29,480 --> 00:00:31,960 +be interviewed for our course, I'm sure the students + +13 +00:00:31,960 --> 00:00:34,080 +will really benefit from this. And let me start + +14 +00:00:34,080 --> 00:00:37,240 +with the first question which is what are software requirements? + +15 +00:00:37,240 --> 00:00:40,900 +>> That's an interesting question. And software requirements + +16 +00:00:40,900 --> 00:00:44,220 +basically provide us a description of what a + +17 +00:00:44,220 --> 00:00:47,520 +system has to do. So, typically they describe + +18 +00:00:47,520 --> 00:00:50,550 +the functionality of the features. That the system has + +19 +00:00:50,550 --> 00:00:54,420 +to deliver in order to satisfy its stakeholders. + +20 +00:00:54,420 --> 00:00:59,010 +And we usually talk about the requirement specification + +21 +00:00:59,010 --> 00:01:01,050 +in terms of what the system's going to + +22 +00:01:01,050 --> 00:01:04,010 +do. And we describe it sometimes formally in + +23 +00:01:04,010 --> 00:01:07,300 +terms of set of shall statements, that the + +24 +00:01:07,300 --> 00:01:09,110 +system shall do this or shall do that. + +25 +00:01:09,110 --> 00:01:12,330 +Or we can use various templates to specify + +26 +00:01:12,330 --> 00:01:16,120 +both textural requirements. But requirements can also be represented + +27 +00:01:16,120 --> 00:01:20,790 +informally in, in the form of user stories, or use cases, or more + +28 +00:01:20,790 --> 00:01:26,180 +formally in the form of state transition diagrams and even in kind of + +29 +00:01:26,180 --> 00:01:32,260 +formal specifications. Especially for critical parts of safety critical systems. + +30 +00:01:32,260 --> 00:01:34,180 +>> And another should discuss what the + +31 +00:01:34,180 --> 00:01:37,230 +requirements are. What is the requirements engineering? + +32 +00:01:37,230 --> 00:01:41,180 +>> So, that's also an interesting question because if you notice + +33 +00:01:41,180 --> 00:01:45,330 +it's it's engineering and I'm sure in the + +34 +00:01:45,330 --> 00:01:47,750 +other parts of the software engineering process that + +35 +00:01:47,750 --> 00:01:51,130 +you're discussing in your course. Parts such as + +36 +00:01:51,130 --> 00:01:55,200 +testing or coding. They don't have the word engineering + +37 +00:01:55,200 --> 00:01:56,930 +there and I think one of the reasons + +38 +00:01:56,930 --> 00:02:00,310 +requirements engineering has that term is because it covers + +39 +00:02:00,310 --> 00:02:03,570 +a number of different activities. So it includes + +40 +00:02:03,570 --> 00:02:07,390 +things such as working with stakeholders to elicit or + +41 +00:02:07,390 --> 00:02:10,620 +to proactively discover what their requirements of the + +42 +00:02:10,620 --> 00:02:14,440 +system are. Analyzing those requirements so that we + +43 +00:02:14,440 --> 00:02:17,380 +understand the tradeoffs. So you might have different + +44 +00:02:17,380 --> 00:02:21,170 +stakeholders that care about different things, and it + +45 +00:02:21,170 --> 00:02:26,086 +might not be possible to deliver all of those things, so we have to analyze the + +46 +00:02:26,086 --> 00:02:29,140 +feasibility of the requirements, explore the tradeoffs, emerge + +47 +00:02:29,140 --> 00:02:32,550 +conflicts. And then of course the specification part, + +48 +00:02:32,550 --> 00:02:34,930 +which we talked about a little bit already, + +49 +00:02:34,930 --> 00:02:37,340 +and the validation, so did we in fact get + +50 +00:02:37,340 --> 00:02:40,480 +the requirements right? Did we build a system + +51 +00:02:40,480 --> 00:02:43,490 +that actually matches our, our requirements. And then on + +52 +00:02:43,490 --> 00:02:46,960 +into the requirements management process. And the requirements + +53 +00:02:46,960 --> 00:02:50,860 +management process. Kind of like goes through things like + +54 +00:02:50,860 --> 00:02:55,010 +change management. So what if customer or stakeholders + +55 +00:02:55,010 --> 00:02:57,630 +need the system to change? How do we manage + +56 +00:02:57,630 --> 00:03:00,180 +changing requirements? And I think this is one of + +57 +00:03:00,180 --> 00:03:03,230 +the reasons that we've coined the term engineering because + +58 +00:03:03,230 --> 00:03:06,490 +that it's, has to be a systematic process which + +59 +00:03:06,490 --> 00:03:09,550 +extends across. The whole of this is life cycle. + +60 +00:03:09,550 --> 00:03:12,890 +>> And I guess my last question here is + +61 +00:03:12,890 --> 00:03:15,100 +so now that we heard about software requirements and + +62 +00:03:15,100 --> 00:03:18,790 +about software requirements engineering, why is requirements engineering so + +63 +00:03:18,790 --> 00:03:20,770 +important? So what happens if we don't do it right? + +64 +00:03:20,770 --> 00:03:22,620 +>> Well, I'm sure that, you know, + +65 +00:03:22,620 --> 00:03:24,880 +many people have probably read the kind of + +66 +00:03:24,880 --> 00:03:28,560 +report like Spanish report, and other reports of failed + +67 +00:03:28,560 --> 00:03:31,900 +project, and things like that, and are aware that + +68 +00:03:31,900 --> 00:03:35,280 +one of the major reasons for projects failing + +69 +00:03:35,280 --> 00:03:37,360 +is because we didn't get the requirements right + +70 +00:03:37,360 --> 00:03:40,110 +in the first place. So if we don't understand + +71 +00:03:40,110 --> 00:03:42,970 +the requirements then we're simply going to build the + +72 +00:03:42,970 --> 00:03:47,960 +wrong system. Getting requirements right includes all sorts of + +73 +00:03:47,960 --> 00:03:52,900 +things such as finding the right group of stakeholders so we don't exclude major + +74 +00:03:52,900 --> 00:03:56,940 +groups of stakeholders. Understanding the requirements correctly. + +75 +00:03:56,940 --> 00:03:59,910 +There will be many, many different examples of + +76 +00:03:59,910 --> 00:04:02,310 +projects that have failed. For example, in + +77 +00:04:02,310 --> 00:04:06,500 +America the healthcare.gov failure, and while we cannot + +78 +00:04:06,500 --> 00:04:09,540 +put the blame squarely in the area + +79 +00:04:09,540 --> 00:04:13,040 +of requirements, because obviously the project was challenged + +80 +00:04:13,040 --> 00:04:15,650 +for a number of different reasons. But + +81 +00:04:15,650 --> 00:04:21,070 +clearly it underperformed in many respects related to + +82 +00:04:21,070 --> 00:04:25,740 +security, performance, and reliability and these are all + +83 +00:04:25,740 --> 00:04:28,300 +parts of the requirements process. Things that should + +84 +00:04:28,300 --> 00:04:30,000 +have been discovered and the system should have + +85 +00:04:30,000 --> 00:04:32,914 +been built in order to meet those requirements, + +86 +00:04:32,914 --> 00:04:36,240 +getting the requirements right in the first place. + +87 +00:04:36,240 --> 00:04:38,110 +Puts us, a project on the right foot. + +88 +00:04:38,110 --> 00:04:41,430 +And so that gives us a much better chance + +89 +00:04:41,430 --> 00:04:44,940 +of delivering to the customer what they need. And + +90 +00:04:44,940 --> 00:04:49,130 +designing a solution that really meets those requirements. So, + +91 +00:04:49,130 --> 00:04:52,800 +it's a critical part of the overall software engineering success. + +92 +00:04:52,800 --> 00:04:56,441 +>> Okay. So that's critical. I mean, we better get our requirements right. + +93 +00:04:56,441 --> 00:04:56,987 +>> Yeah. + +94 +00:04:56,987 --> 00:04:57,733 +>> That's, that's the message. + +95 +00:04:57,733 --> 00:04:57,743 +>> Yeah. + +96 +00:04:57,743 --> 00:05:00,822 +>> Okay. Well, thank you so much Jane, for taking + +97 +00:05:00,822 --> 00:05:03,435 +the time off your busy schedule to speak with us. + +98 +00:05:03,435 --> 00:05:07,150 +I'm sure. The students really appreciate this, and we'll talk to you soon. + +99 +00:05:07,150 --> 00:05:08,480 +>> Bye Alex, thank you. + +100 +00:05:08,480 --> 00:05:10,890 +>> Bye, Jane, bye bye. Jane gave + +101 +00:05:10,890 --> 00:05:13,410 +us an interesting perspective on requirements engineering + +102 +00:05:13,410 --> 00:05:15,410 +and its importance. Let's now start our + +103 +00:05:15,410 --> 00:05:18,050 +lesson with a general definition of requirements engineering. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/20 - User and System Requirements - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/20 - User and System Requirements - lang_en_vs4.srt new file mode 100644 index 0000000..2da3f58 --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/20 - User and System Requirements - lang_en_vs4.srt @@ -0,0 +1,111 @@ +1 +00:00:00,180 --> 00:00:03,170 +Another important distinction, when talking about requirements, is that + +2 +00:00:03,170 --> 00:00:07,220 +between user and system requirements. So, let's start with defining + +3 +00:00:07,220 --> 00:00:10,540 +user requirements. Those are requirements that are written for the + +4 +00:00:10,540 --> 00:00:13,400 +customers and they're often in natural language and they don't + +5 +00:00:13,400 --> 00:00:16,190 +contain technical details. And the reason for that is + +6 +00:00:16,190 --> 00:00:19,740 +that their purpose is to allow customers, stakeholders, to check + +7 +00:00:19,740 --> 00:00:22,210 +that the system will do what they intended. So it's + +8 +00:00:22,210 --> 00:00:25,470 +a way for the analyst, the developers, to communicate with + +9 +00:00:25,470 --> 00:00:28,460 +the customers, with the stakeholders. System requirements, on the + +10 +00:00:28,460 --> 00:00:32,560 +other hand, are written for developers. Contain detailed functional and + +11 +00:00:32,560 --> 00:00:35,330 +non functional requirements. Which we just discussed, and which + +12 +00:00:35,330 --> 00:00:39,860 +are clearly and more rigourously specified than the user requirements. + +13 +00:00:39,860 --> 00:00:42,130 +And the reason for this difference is that the + +14 +00:00:42,130 --> 00:00:45,410 +purpose of the system requirements is to tell developers what + +15 +00:00:45,410 --> 00:00:47,870 +to build. They must contain enough details so the + +16 +00:00:47,870 --> 00:00:50,480 +developers can take them and use them to design and + +17 +00:00:50,480 --> 00:00:52,530 +then develop a system. Just to give you a concrete + +18 +00:00:52,530 --> 00:00:55,750 +example, here I'm showing you a user requirement that just says + +19 +00:00:55,750 --> 00:00:59,510 +that the software must provide a means of representing and accessing + +20 +00:00:59,510 --> 00:01:03,940 +external files created by other tools, and the corresponding system requirement. + +21 +00:01:03,940 --> 00:01:05,700 +And as you can see, even if we don't read the + +22 +00:01:05,700 --> 00:01:09,380 +whole requirements. The former is an informal and high level description + +23 +00:01:09,380 --> 00:01:12,210 +of a piece of functionality, whereas the latter describes the same + +24 +00:01:12,210 --> 00:01:15,940 +functionality but in a much more extensive and rigorous way. As + +25 +00:01:15,940 --> 00:01:18,760 +I said, this is something that the developers can use to + +26 +00:01:18,760 --> 00:01:21,820 +design and then build a system whereas this is something that + +27 +00:01:21,820 --> 00:01:25,590 +can be used to communicate. With the stakeholders, with a non-technical + +28 +00:01:25,590 --> 00:01:29,490 +audience. And we need to define both because they serve different purposes. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/21 - Requirements Quiz - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/21 - Requirements Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..4b416e8 --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/21 - Requirements Quiz - lang_en_vs4.srt @@ -0,0 +1,43 @@ +1 +00:00:00,160 --> 00:00:02,940 +After all these talking about requirements, let's have a small quiz, I + +2 +00:00:02,940 --> 00:00:04,019 +want to ask you which of the + +3 +00:00:04,019 --> 00:00:07,840 +following requirements are non-functional requirements? And here + +4 +00:00:07,840 --> 00:00:10,860 +I'm listing the requirements, the first one says at the BowlingAlley program + +5 +00:00:10,860 --> 00:00:13,420 +keeps track of the score during a game, the second one is that + +6 +00:00:13,420 --> 00:00:16,720 +the WordCount program should be able to process large files. The third + +7 +00:00:16,720 --> 00:00:19,580 +one is that the Login program for a website. Should be secure, and + +8 +00:00:19,580 --> 00:00:22,880 +finally the last one says that the vending machine program should take coins + +9 +00:00:22,880 --> 00:00:25,430 +as an input from the user. So, I want you to mark all + +10 +00:00:25,430 --> 00:00:27,590 +the ones that are non-functional requirements, that + +11 +00:00:27,590 --> 00:00:29,640 +don't refer to the functionality of the system. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/22 - Requirements Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/22 - Requirements Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..e957484 --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/22 - Requirements Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,63 @@ +1 +00:00:00,120 --> 00:00:03,710 +So, the first requirement clearly refers to some specific functionality of + +2 +00:00:03,710 --> 00:00:07,230 +the Bowling Alley system, because it talks about what the system has + +3 +00:00:07,230 --> 00:00:10,420 +to do from a functional standpoint. So, it's definitely not a non-functional + +4 +00:00:10,420 --> 00:00:13,400 +requirement. On the other hand, the fact that the Word Count system + +5 +00:00:13,400 --> 00:00:16,320 +should be able to process large files, is telling us something not + +6 +00:00:16,320 --> 00:00:19,580 +about the functionality of the system, but rather about its qualities. The + +7 +00:00:19,580 --> 00:00:21,600 +fact that it has to be scalable, that it has to be + +8 +00:00:21,600 --> 00:00:25,190 +efficient and so we can consider this to be a non-functional requirement. + +9 +00:00:25,190 --> 00:00:27,010 +Similarly, the fact that the Login program for a + +10 +00:00:27,010 --> 00:00:29,390 +website should be secure is definitely telling us something + +11 +00:00:29,390 --> 00:00:31,800 +about the quality of the system that has little + +12 +00:00:31,800 --> 00:00:34,026 +to do with its functionality. And so this is + +13 +00:00:34,026 --> 00:00:36,680 +also a non-functional requirement. Finally, the fact that the + +14 +00:00:36,680 --> 00:00:38,980 +Vending Machine program should take coins as an input + +15 +00:00:38,980 --> 00:00:41,010 +from the user is telling us something about the + +16 +00:00:41,010 --> 00:00:44,100 +functionality of the program and therefore, is a functional requirement. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/23 - Requirement Origins - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/23 - Requirement Origins - lang_en_vs4.srt new file mode 100644 index 0000000..6fe4931 --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/23 - Requirement Origins - lang_en_vs4.srt @@ -0,0 +1,71 @@ +1 +00:00:00,130 --> 00:00:01,880 +Now that we know what the requirements are and + +2 +00:00:01,880 --> 00:00:05,520 +their main types, let's discuss where requirements come from and + +3 +00:00:05,520 --> 00:00:08,610 +there are many possible sources for requirements so I'm + +4 +00:00:08,610 --> 00:00:10,610 +going to list here the main ones. The first one are + +5 +00:00:10,610 --> 00:00:14,440 +clearly stakeholders, anybody who is effected by the system + +6 +00:00:14,440 --> 00:00:18,830 +and its functionality. Customers, users, and so on. The second + +7 +00:00:18,830 --> 00:00:22,610 +typical social requirement is the application domain. For example, + +8 +00:00:22,610 --> 00:00:25,380 +the fact that my software is running within a bank, + +9 +00:00:25,380 --> 00:00:27,930 +or within a school. Why is the application domain a + +10 +00:00:27,930 --> 00:00:31,410 +social requirement? Well, because there are constraints that are characteristics + +11 +00:00:31,410 --> 00:00:34,140 +of the application domain that will affect the functionality of + +12 +00:00:34,140 --> 00:00:37,130 +the system. For a simple example, just think about regulations. + +13 +00:00:37,130 --> 00:00:40,400 +So banking regulations and school regulations in these cases. Those + +14 +00:00:40,400 --> 00:00:43,120 +are things that might affect the functionality of my system + +15 +00:00:43,120 --> 00:00:45,570 +and, therefore, that may become part of my requirements. And, + +16 +00:00:45,570 --> 00:00:50,120 +finally, documentation can be an additional source of requirements. For example, + +17 +00:00:50,120 --> 00:00:54,110 +notes, papers, manuals, books. So everything that refers to + +18 +00:00:54,110 --> 00:00:56,610 +the functionality of the system that we're going to build. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/24 - Elicitation Problems - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/24 - Elicitation Problems - lang_en_vs4.srt new file mode 100644 index 0000000..2d81db7 --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/24 - Elicitation Problems - lang_en_vs4.srt @@ -0,0 +1,179 @@ +1 +00:00:00,190 --> 00:00:03,440 +Unfortunately, extracting requirements from these sources is not + +2 +00:00:03,440 --> 00:00:06,220 +a straightforward task, as there are many issues involved + +3 +00:00:06,220 --> 00:00:09,470 +with the requirements elicitation. One first problem is the + +4 +00:00:09,470 --> 00:00:13,930 +thin spread of domain knowledge. Knowledge is rarely available + +5 +00:00:13,930 --> 00:00:15,970 +in an explicit form, that is, it is + +6 +00:00:15,970 --> 00:00:20,310 +almost never written down. Moreover, knowledge is often distributed + +7 +00:00:20,310 --> 00:00:23,410 +across many sources. For example, in the graphical depiction + +8 +00:00:23,410 --> 00:00:25,590 +here, to find out that this is the purpose + +9 +00:00:25,590 --> 00:00:28,240 +of the project. The developer, the analyist, needs to talk + +10 +00:00:28,240 --> 00:00:30,870 +to a lot of different people. And, to make things even + +11 +00:00:30,870 --> 00:00:34,400 +worse. There are often conflicts between the knowledge gathered from + +12 +00:00:34,400 --> 00:00:37,610 +different sources. A second issue is the fact that the knowledge + +13 +00:00:37,610 --> 00:00:41,090 +is often tacit. What is also called the say, do + +14 +00:00:41,090 --> 00:00:44,052 +problem. In the example shown here. For instance. We have a + +15 +00:00:44,052 --> 00:00:47,650 +customer that is describing to the analyst. The way in which + +16 +00:00:47,650 --> 00:00:51,060 +he accomplishes a task. So it performs these three steps and + +17 +00:00:51,060 --> 00:00:54,300 +reaches the goal. Whereas in practice, the actual way in + +18 +00:00:54,300 --> 00:00:57,530 +which this task accomplished is by going through a larger number + +19 +00:00:57,530 --> 00:00:59,880 +of steps to get to the same goal. So the point + +20 +00:00:59,880 --> 00:01:02,650 +here is that, even if the knowledge were more concentrated, so + +21 +00:01:02,650 --> 00:01:05,660 +not as spread as in this example. People simply find + +22 +00:01:05,660 --> 00:01:08,680 +it hard to describe knowledge that they regularly use. So it + +23 +00:01:08,680 --> 00:01:11,740 +is hard to make this knowledge explicit, to pass this knowledge + +24 +00:01:11,740 --> 00:01:13,130 +to someone else. Yet another + +25 +00:01:13,130 --> 00:01:16,690 +problem is limited observability. Identifying requirements + +26 +00:01:16,690 --> 00:01:20,570 +through observation is often difficult as the problem owners might be + +27 +00:01:20,570 --> 00:01:23,550 +too busy to perform the task that we need to observe. + +28 +00:01:23,550 --> 00:01:25,750 +Or they might be doing a lot of other things together + +29 +00:01:25,750 --> 00:01:27,980 +with the task that we need to observe, so that becomes + +30 +00:01:27,980 --> 00:01:31,530 +confusing. That introduces noise. Moreover, even when this is not the + +31 +00:01:31,530 --> 00:01:34,460 +case, the presence of an observer might change their problem. It + +32 +00:01:34,460 --> 00:01:38,020 +is very typical for human subjects to improve or modify an + +33 +00:01:38,020 --> 00:01:41,760 +aspect of their behavior, which is being experimentally measured in response + +34 +00:01:41,760 --> 00:01:44,110 +to the fact that they know that they're being studied. You know + +35 +00:01:44,110 --> 00:01:47,110 +that somebody's studying you and you change the way in which you behave. + +36 +00:01:47,110 --> 00:01:50,910 +A typical issue. Finally, the information that we collect might be biased. + +37 +00:01:50,910 --> 00:01:54,270 +For several reasons. People might not feel free to tell you what you + +38 +00:01:54,270 --> 00:01:57,030 +need to know. Or, people might not want to tell you what + +39 +00:01:57,030 --> 00:02:00,240 +you need to know. For example, in all the common cases in which + +40 +00:02:00,240 --> 00:02:03,870 +the outcome might effect them, people might provide you a different picture + +41 +00:02:03,870 --> 00:02:06,770 +from the real one. In order to influence you. So, they might have + +42 +00:02:06,770 --> 00:02:08,820 +a hidden agenda, and mislead you, either + +43 +00:02:08,820 --> 00:02:11,860 +consciously or unconsciously. So, all these issues + +44 +00:02:11,860 --> 00:02:14,370 +add to the complexity of collecting requirements, + +45 +00:02:14,370 --> 00:02:16,522 +of identifying the purpose of a system. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/25 - Traditional Techniques - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/25 - Traditional Techniques - lang_en_vs5.srt new file mode 100644 index 0000000..cc58665 --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/25 - Traditional Techniques - lang_en_vs5.srt @@ -0,0 +1,207 @@ +1 +00:00:00,140 --> 00:00:02,930 +To cover the intrinsic problem of eliciting requirements, + +2 +00:00:02,930 --> 00:00:05,670 +many different techniques have been proposed. So here + +3 +00:00:05,670 --> 00:00:08,260 +I list some of most traditional techniques for + +4 +00:00:08,260 --> 00:00:11,290 +requirement elicitation and as I present those, please keep + +5 +00:00:11,290 --> 00:00:13,140 +in mind that these techniques can be used + +6 +00:00:13,140 --> 00:00:17,230 +separately or combined. A first technique is called background + +7 +00:00:17,230 --> 00:00:20,740 +reading. And, this technique involves collecting information by + +8 +00:00:20,740 --> 00:00:24,840 +reading existing documents such as company reports, organizational charts, + +9 +00:00:24,840 --> 00:00:29,280 +policy manuals, job descriptions, documentation of existing systems and so + +10 +00:00:29,280 --> 00:00:32,400 +on. And, this technique is especially appropriate when one Is + +11 +00:00:32,400 --> 00:00:35,370 +not familiar with your organization for which the requirements are + +12 +00:00:35,370 --> 00:00:38,950 +being collected. So you want to get some background before interviewing + +13 +00:00:38,950 --> 00:00:41,240 +actual people. And one of the main imitations of these + +14 +00:00:41,240 --> 00:00:43,930 +kinds of approaches is that written documents might be out + +15 +00:00:43,930 --> 00:00:46,320 +of sync and they often are out of sync with + +16 +00:00:46,320 --> 00:00:49,970 +reality. Tend to be long winded. It may contain many irrelevant + +17 +00:00:49,970 --> 00:00:51,850 +details, so you may have to look at a lot + +18 +00:00:51,850 --> 00:00:54,810 +of materials to extract enough information. The hard data and + +19 +00:00:54,810 --> 00:00:58,650 +samples techniques consist in deciding which hard data we want + +20 +00:00:58,650 --> 00:01:01,680 +to collect and choosing the sample of the population for which + +21 +00:01:01,680 --> 00:01:04,750 +to collect such data and hard data includes facts and + +22 +00:01:04,750 --> 00:01:09,790 +figures such as forms, invoices, financial information, survey results, marketing + +23 +00:01:09,790 --> 00:01:12,300 +data, and so on. And the sampling of this data + +24 +00:01:12,300 --> 00:01:15,170 +can be done in different ways. For example, the typical ways + +25 +00:01:15,170 --> 00:01:19,200 +to do random selection. Interviews are another typical approach for + +26 +00:01:19,200 --> 00:01:21,870 +requirement solicitation, and this is the approach that we use for + +27 +00:01:21,870 --> 00:01:24,910 +the first project in this course, for instance. Interviews can be + +28 +00:01:24,910 --> 00:01:27,720 +structured in which case there is an agenda of fairly open + +29 +00:01:27,720 --> 00:01:30,450 +questions or they can be open ended in which case there + +30 +00:01:30,450 --> 00:01:32,770 +is no preset agenda and the interview is more of a + +31 +00:01:32,770 --> 00:01:36,500 +conversation. On the positive side, interviews can collect a rich set + +32 +00:01:36,500 --> 00:01:40,260 +of information because they allow for uncovering opinions as well as + +33 +00:01:40,260 --> 00:01:43,230 +hard facts. Moreover, they can probe in depth through follow + +34 +00:01:43,230 --> 00:01:46,790 +up questions. On the more negative side, interviewing requires special + +35 +00:01:46,790 --> 00:01:50,400 +skills that are difficult to master and require experience. And + +36 +00:01:50,400 --> 00:01:52,890 +it is not enough to collect a lot of information. If + +37 +00:01:52,890 --> 00:01:55,520 +this information is hard to analyze or even irrelevant, it + +38 +00:01:55,520 --> 00:01:58,250 +might become useless. So you need to know how to conduct + +39 +00:01:58,250 --> 00:02:01,180 +an interview in order to take advantage of these techniques. + +40 +00:02:01,180 --> 00:02:05,440 +Surveys can also be extremely useful for gathering new requirements because + +41 +00:02:05,440 --> 00:02:08,550 +they can quickly collect information from a large number + +42 +00:02:08,550 --> 00:02:11,520 +of people. Moreover, they can be administered remotely. For + +43 +00:02:11,520 --> 00:02:13,610 +example, by email, through the web. On the other + +44 +00:02:13,610 --> 00:02:16,750 +hand, surveys tend to severely constrain the information that + +45 +00:02:16,750 --> 00:02:19,430 +the user can provide and might miss opportunities to + +46 +00:02:19,430 --> 00:02:24,460 +collect unforeseen, relevant information. Finally, meetings are generally used + +47 +00:02:24,460 --> 00:02:27,690 +for summarization of findings and collection of feedback, so as + +48 +00:02:27,690 --> 00:02:30,500 +to confirm or refute what has been learned. So the + +49 +00:02:30,500 --> 00:02:32,660 +only additional thing I want to mention about meetings + +50 +00:02:32,660 --> 00:02:34,920 +is the fact that it is fundamental that have clearly + +51 +00:02:34,920 --> 00:02:37,970 +stated objectives and are planned carefully. This is something that + +52 +00:02:37,970 --> 00:02:40,730 +should be quite obvious, but doesn't always happen in practice. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/26 - Other Techniques - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/26 - Other Techniques - lang_en_vs5.srt new file mode 100644 index 0000000..f29fb9c --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/26 - Other Techniques - lang_en_vs5.srt @@ -0,0 +1,71 @@ +1 +00:00:00,070 --> 00:00:02,370 +So just for completeness, I want to mention some other + +2 +00:00:02,370 --> 00:00:05,340 +techniques besides the traditional ones that we just saw that + +3 +00:00:05,340 --> 00:00:07,880 +can be used for requirements solicitation. And these other + +4 +00:00:07,880 --> 00:00:10,740 +techniques can be divided in three main groups. There are + +5 +00:00:10,740 --> 00:00:14,820 +collaborative techniques that were created to support incremental development + +6 +00:00:14,820 --> 00:00:18,850 +of complex systems with large diverse user populations. An example + +7 +00:00:18,850 --> 00:00:21,130 +of such techniques which is widely used and you + +8 +00:00:21,130 --> 00:00:25,120 +might know is brainstorming. There are also social approaches and + +9 +00:00:25,120 --> 00:00:28,140 +these are approaches, techniques that exploit the social + +10 +00:00:28,140 --> 00:00:31,520 +sciences to better collect information from the stakeholders and + +11 +00:00:31,520 --> 00:00:34,310 +the environment. And among those I just want to mention + +12 +00:00:34,310 --> 00:00:36,730 +ethnographic techniques which are based on the idea of + +13 +00:00:36,730 --> 00:00:40,100 +collecting information on the participants by observing them + +14 +00:00:40,100 --> 00:00:44,660 +in their original environment. Finally cognitive techniques, leverage cognitive + +15 +00:00:44,660 --> 00:00:48,490 +science approaches to discover expert knowledge for example they + +16 +00:00:48,490 --> 00:00:51,260 +can be used to understand the problem solving methods. + +17 +00:00:51,260 --> 00:00:54,000 +And in case you're interested in finding out more about this and + +18 +00:00:54,000 --> 00:00:57,580 +other techniques, I'm providing some references in the notes for the lesson. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/27 - Modeling Requirements - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/27 - Modeling Requirements - lang_en_vs4.srt new file mode 100644 index 0000000..d4ade17 --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/27 - Modeling Requirements - lang_en_vs4.srt @@ -0,0 +1,223 @@ +1 +00:00:00,220 --> 00:00:03,550 +Once we collected the required knowledge on the requirements for + +2 +00:00:03,550 --> 00:00:06,120 +the system that we're developing, we need to model it in + +3 +00:00:06,120 --> 00:00:08,430 +a structured and clear way, so that it can be + +4 +00:00:08,430 --> 00:00:12,100 +analyzed and refined. And there are really tons of ways to + +5 +00:00:12,100 --> 00:00:15,840 +do that, depending on your focus and objectives. More specifically, + +6 +00:00:15,840 --> 00:00:18,940 +when modeling requirements you need to decide what you want to + +7 +00:00:18,940 --> 00:00:21,710 +model and how you want to model it. So let's look + +8 +00:00:21,710 --> 00:00:25,390 +at these two aspects independently. What you decide to model depends + +9 +00:00:25,390 --> 00:00:28,270 +on where your emphasis is. That is on which + +10 +00:00:28,270 --> 00:00:31,390 +aspects of the requirements you want to focus. For + +11 +00:00:31,390 --> 00:00:34,880 +example if your emphasis is on the characteristics of + +12 +00:00:34,880 --> 00:00:37,970 +the enterprise of the company that you are analyzing you + +13 +00:00:37,970 --> 00:00:40,240 +may want to model goals and objectives of the + +14 +00:00:40,240 --> 00:00:44,380 +company, or its organizational structure, its task and dependencies + +15 +00:00:44,380 --> 00:00:47,040 +and so on. Conversely, if your focus is on + +16 +00:00:47,040 --> 00:00:50,500 +information and behaviors, you might want to concentrate on aspects + +17 +00:00:50,500 --> 00:00:53,800 +such as the structure of information, various behavioral views + +18 +00:00:53,800 --> 00:00:55,480 +some of which we will see in the next + +19 +00:00:55,480 --> 00:00:59,650 +lesson, or maybe time or sequencing requirements. Finally, if + +20 +00:00:59,650 --> 00:01:02,750 +you're mostly interested in the quality aspects of your + +21 +00:01:02,750 --> 00:01:06,790 +system, you will focus on the various non-functional properties + +22 +00:01:06,790 --> 00:01:09,070 +of the software that are relevant in the context + +23 +00:01:09,070 --> 00:01:13,570 +considered. For example reliability, robustness, security, and so on. + +24 +00:01:13,570 --> 00:01:15,550 +You will just pick the ones that are relevant for + +25 +00:01:15,550 --> 00:01:18,540 +your context. And as we said, there's a second dimension. + +26 +00:01:18,540 --> 00:01:21,050 +After you have decided what to model in your system, + +27 +00:01:21,050 --> 00:01:23,480 +you have to decide how you want to model it. + +28 +00:01:23,480 --> 00:01:25,860 +So I want to show here some options for modeling + +29 +00:01:25,860 --> 00:01:30,380 +enterprises, information, and quality aspects. And as you can see + +30 +00:01:30,380 --> 00:01:34,100 +here for each type of information there are many possible + +31 +00:01:34,100 --> 00:01:36,840 +models that we can use to represent it. And all + +32 +00:01:36,840 --> 00:01:38,750 +these models have advantages and + +33 +00:01:38,750 --> 00:01:41,400 +disadvantages, different levels of formality and + +34 +00:01:41,400 --> 00:01:44,000 +different focus. Something else that I want to point out + +35 +00:01:44,000 --> 00:01:47,145 +about these models is the fact that these models are often + +36 +00:01:47,145 --> 00:01:50,980 +orthogonal to one another, especially if we consider models in different + +37 +00:01:50,980 --> 00:01:54,620 +categories. So what that means is that they're complimentary rather than + +38 +00:01:54,620 --> 00:01:58,310 +mutually exclusive. Different models can be used to provide views + +39 +00:01:58,310 --> 00:02:01,290 +of the requirements from different perspectives, and we will not see + +40 +00:02:01,290 --> 00:02:03,700 +most of these models in this course, but I wanted to + +41 +00:02:03,700 --> 00:02:06,550 +list them anyways to give you an idea of how many + +42 +00:02:06,550 --> 00:02:09,490 +there are and how vast is this area. As far + +43 +00:02:09,490 --> 00:02:11,540 +as we are concerned in the course and for the + +44 +00:02:11,540 --> 00:02:14,660 +projects we will express requirements using one of two main + +45 +00:02:14,660 --> 00:02:19,010 +ways. Using natural language, that is informal specifications and using + +46 +00:02:19,010 --> 00:02:22,600 +UML diagrams, which is graphical models. And we will introduce + +47 +00:02:22,600 --> 00:02:25,840 +UML and the most important diagrams in the next lesson. + +48 +00:02:25,840 --> 00:02:27,330 +And the only other type of models that I want + +49 +00:02:27,330 --> 00:02:31,610 +to mentions explicitly are goal models because they're extremely popular. + +50 +00:02:31,610 --> 00:02:34,930 +So the main idea with goal models is it start with the main goal of + +51 +00:02:34,930 --> 00:02:36,990 +the system and then keep refining it + +52 +00:02:36,990 --> 00:02:39,654 +by decomposing it in sub-goals. So it's kind + +53 +00:02:39,654 --> 00:02:41,610 +of a very natural way of progressing. + +54 +00:02:41,610 --> 00:02:44,210 +And you continue this refinement until you get + +55 +00:02:44,210 --> 00:02:47,150 +to goals that can be operationalized, and represent + +56 +00:02:47,150 --> 00:02:49,380 +the basic units of functionality of the system. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/28 - Analyzing Requirements - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/28 - Analyzing Requirements - lang_en_vs4.srt new file mode 100644 index 0000000..c7d4899 --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/28 - Analyzing Requirements - lang_en_vs4.srt @@ -0,0 +1,155 @@ +1 +00:00:00,250 --> 00:00:01,940 +Now we are at the point in which we + +2 +00:00:01,940 --> 00:00:05,590 +have collected and modeled our requirements. So the next thing + +3 +00:00:05,590 --> 00:00:08,310 +that we can do is to analyze the requirements to + +4 +00:00:08,310 --> 00:00:11,720 +identify possible problems, and specifically there are three types of + +5 +00:00:11,720 --> 00:00:14,646 +analysis that we can perform. The first type of analysis + +6 +00:00:14,646 --> 00:00:16,820 +is verification. So in this case we're talking about the + +7 +00:00:16,820 --> 00:00:19,700 +requirements verification. And in verification + +8 +00:00:19,700 --> 00:00:21,990 +developers will study the requirements + +9 +00:00:21,990 --> 00:00:25,270 +to check whether they're correct, whether they accurately reflect the + +10 +00:00:25,270 --> 00:00:28,710 +customer needs as perceived by the developer. Developers can + +11 +00:00:28,710 --> 00:00:32,170 +also check the completeness of the requirements, check whether there + +12 +00:00:32,170 --> 00:00:34,510 +are any missing pieces in the requirements as we + +13 +00:00:34,510 --> 00:00:37,710 +discussed earlier. They can check whether the requirements are pertinent, + +14 +00:00:37,710 --> 00:00:41,260 +or contain irrelevant information, like the one shown here. + +15 +00:00:41,260 --> 00:00:44,670 +And they can also check whether they're consistent, unambiguous, testable + +16 +00:00:44,670 --> 00:00:46,920 +and so on, so all those properties that should + +17 +00:00:46,920 --> 00:00:50,380 +be satisfied for the requirements. A second type of analysis + +18 +00:00:50,380 --> 00:00:53,670 +that is typically performed on requirements is validation. And + +19 +00:00:53,670 --> 00:00:56,290 +the goal of validation is to assess whether the collected + +20 +00:00:56,290 --> 00:00:59,870 +requirements define the system that the stakeholders really want. + +21 +00:00:59,870 --> 00:01:02,330 +So the focus here is on the stakeholders. And in + +22 +00:01:02,330 --> 00:01:05,670 +some cases, stakeholders can check the requirements directly if + +23 +00:01:05,670 --> 00:01:08,910 +the requirements are expressed in a notation that they understand. + +24 +00:01:08,910 --> 00:01:11,120 +Or they might check them by discussing them with the + +25 +00:01:11,120 --> 00:01:15,490 +developers. Another possibility is that stakeholders asses the requirements by + +26 +00:01:15,490 --> 00:01:18,400 +interacting with a prototype of the system, in case + +27 +00:01:18,400 --> 00:01:21,690 +the requirements engineering process that is being used involves + +28 +00:01:21,690 --> 00:01:25,300 +early prototyping. And finally surveys, testing, and other techniques + +29 +00:01:25,300 --> 00:01:28,400 +can also be used to validate requirements. A final type + +30 +00:01:28,400 --> 00:01:30,780 +of analysis that we can perform on requirements is + +31 +00:01:30,780 --> 00:01:34,430 +risk analysis. And risk analysis aims to identify and + +32 +00:01:34,430 --> 00:01:37,680 +analyze the main risks involved with the development of + +33 +00:01:37,680 --> 00:01:40,560 +the system being considered. And if some requirements are deemed + +34 +00:01:40,560 --> 00:01:43,320 +to be too risky, like in this case, this might result in + +35 +00:01:43,320 --> 00:01:47,880 +changes in the requirements model to eliminate or address those risks. And note + +36 +00:01:47,880 --> 00:01:49,950 +that all these analysis activities can + +37 +00:01:49,950 --> 00:01:52,390 +be performed in many different ways depending + +38 +00:01:52,390 --> 00:01:53,990 +on the modeling languages chosen to + +39 +00:01:53,990 --> 00:01:56,150 +represent the requirements and on the context. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/29 - Requirements Prioritization - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/29 - Requirements Prioritization - lang_en_vs5.srt new file mode 100644 index 0000000..09978d7 --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/29 - Requirements Prioritization - lang_en_vs5.srt @@ -0,0 +1,59 @@ +1 +00:00:00,140 --> 00:00:04,010 +Why collecting, modeling, and analyzing requirements? We might realize + +2 +00:00:04,010 --> 00:00:07,310 +that the resources available for the project are not enough + +3 +00:00:07,310 --> 00:00:10,000 +to satisfy all of them. For example, there's not + +4 +00:00:10,000 --> 00:00:13,450 +enough time, not enough money, not enough manpower. And therefore, + +5 +00:00:13,450 --> 00:00:15,590 +there are some requirements that we won't be able + +6 +00:00:15,590 --> 00:00:19,760 +to satisfy. In these cases, we must prioritize our requirements, + +7 +00:00:19,760 --> 00:00:22,310 +by classifying them in one of three classes. The + +8 +00:00:22,310 --> 00:00:25,270 +first class is mandatory requirements, and these are the requirements + +9 +00:00:25,270 --> 00:00:29,770 +we must satisfy. Then there are the nice to have requirements that are the + +10 +00:00:29,770 --> 00:00:32,170 +ones that we will satisfy if resources + +11 +00:00:32,170 --> 00:00:34,740 +allow. And finally, there are the superfluous + +12 +00:00:34,740 --> 00:00:36,440 +requirements, and those are the requirements that + +13 +00:00:36,440 --> 00:00:37,770 +we're going to keep around, but that we're + +14 +00:00:37,770 --> 00:00:40,010 +going to postpone. For example, we might decide + +15 +00:00:40,010 --> 00:00:41,770 +to satisfy them in the next release. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/3 - General RE Definition - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/3 - General RE Definition - lang_en_vs4.srt new file mode 100644 index 0000000..34ec511 --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/3 - General RE Definition - lang_en_vs4.srt @@ -0,0 +1,103 @@ +1 +00:00:00,360 --> 00:00:03,900 +Basically, and roughly speaking, requirements engineering, which is + +2 +00:00:03,900 --> 00:00:06,630 +also called in short, RE, is the process + +3 +00:00:06,630 --> 00:00:10,520 +of establishing the services that the customer requires + +4 +00:00:10,520 --> 00:00:13,530 +from the software system. In addition to that, requirements + +5 +00:00:13,530 --> 00:00:16,360 +engineering also has to do with the constraints + +6 +00:00:16,360 --> 00:00:19,900 +under which the system operates and is developed. Requirements + +7 +00:00:19,900 --> 00:00:22,770 +engineering is a very important activity for several + +8 +00:00:22,770 --> 00:00:25,450 +reasons. In particular, as we also saw in earlier + +9 +00:00:25,450 --> 00:00:29,860 +lessons, many errors are made in requirement specifications. So many + +10 +00:00:29,860 --> 00:00:33,100 +errors are made because we don't do requirements engineering in + +11 +00:00:33,100 --> 00:00:35,670 +the right way. And many of these errors are not + +12 +00:00:35,670 --> 00:00:38,340 +being detected early. But they could be if we were + +13 +00:00:38,340 --> 00:00:41,350 +to do RE in the right way. And, unfortunately, not + +14 +00:00:41,350 --> 00:00:45,510 +detecting these errors can dramatically increase software costs. So that's + +15 +00:00:45,510 --> 00:00:48,250 +the reason why requirements engineering is important, and why it + +16 +00:00:48,250 --> 00:00:50,730 +is important to do it in the right way. The final + +17 +00:00:50,730 --> 00:00:53,660 +result of the requirements engineering process is a software + +18 +00:00:53,660 --> 00:00:58,230 +requirements specification that we also called SRS. We will discuss + +19 +00:00:58,230 --> 00:01:01,060 +SRS later in more details and also when we talk + +20 +00:01:01,060 --> 00:01:03,740 +about the projects for the course. For now, it is + +21 +00:01:03,740 --> 00:01:07,040 +enough to say that the software requirements specification and + +22 +00:01:07,040 --> 00:01:10,280 +the requirements engineering, in general, should focus on what the + +23 +00:01:10,280 --> 00:01:13,290 +proposed system is intended to do, and not on the + +24 +00:01:13,290 --> 00:01:16,280 +how it will do it. In fact, how the system + +25 +00:01:16,280 --> 00:01:18,450 +will do what it is required to do is something that we + +26 +00:01:18,450 --> 00:01:22,170 +will discuss when we talk about design of a system in later phases. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/30 - Requirements Prioritization Quiz - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/30 - Requirements Prioritization Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..9415793 --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/30 - Requirements Prioritization Quiz - lang_en_vs4.srt @@ -0,0 +1,79 @@ +1 +00:00:00,110 --> 00:00:03,090 +Now that we talked about requirements prioritization, let's try to see + +2 +00:00:03,090 --> 00:00:06,110 +how this might work in practice. Imagine that you have collected the + +3 +00:00:06,110 --> 00:00:09,560 +folowing set of five requirements for an ATM system, but only + +4 +00:00:09,560 --> 00:00:12,680 +have resources to satisfy two of them. Possibly three. I would like + +5 +00:00:12,680 --> 00:00:15,550 +for you to look at this list and suitablely prioritize the + +6 +00:00:15,550 --> 00:00:19,220 +requirements by marking them as mandatory, in this case you're going to put + +7 +00:00:19,220 --> 00:00:21,840 +an M in the space. Nice to have, in this case you're + +8 +00:00:21,840 --> 00:00:25,350 +going to put an N. Or superfluous, in this case you're going to put + +9 +00:00:25,350 --> 00:00:28,005 +an S. This is the set of requirements, the first one + +10 +00:00:28,005 --> 00:00:30,342 +says that the system shall check the PIN of the ATM + +11 +00:00:30,342 --> 00:00:33,863 +card before allowing the customer to perform an operation. The second + +12 +00:00:33,863 --> 00:00:37,575 +says that the system shall perform an additional biometric verification of + +13 +00:00:37,575 --> 00:00:40,881 +the customer identity for example a check of the customer's finger + +14 +00:00:40,881 --> 00:00:44,294 +prints before it allows the customer to perform an operation. Then + +15 +00:00:44,294 --> 00:00:47,466 +we have that the system shall allow customers to withdraw cash + +16 +00:00:47,466 --> 00:00:50,580 +using an ATM card. The system shall allow customer to deposit + +17 +00:00:50,580 --> 00:00:53,350 +money using an ATM card. And the system shall allow + +18 +00:00:53,350 --> 00:00:56,330 +customers to change the pin of their ATM card. So again, + +19 +00:00:56,330 --> 00:01:00,600 +mark those as mandatory, nice to have, or superfluous considering the + +20 +00:01:00,600 --> 00:01:04,170 +fact that you can satisfy only two, possibly three of them. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/31 - Requirements Prioritization Quiz Solution - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/31 - Requirements Prioritization Quiz Solution - lang_en_vs5.srt new file mode 100644 index 0000000..e2fd768 --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/31 - Requirements Prioritization Quiz Solution - lang_en_vs5.srt @@ -0,0 +1,119 @@ +1 +00:00:00,130 --> 00:00:02,640 +Looking at the requirements, and knowing that we have only two + +2 +00:00:02,640 --> 00:00:05,630 +that we can satisfy for sure, it makes sense to first mark + +3 +00:00:05,630 --> 00:00:09,080 +as mandatory the ability to withdraw cash, which is the most typical + +4 +00:00:09,080 --> 00:00:12,650 +use of an ATM machine. We are therefore going to mark this requirement + +5 +00:00:12,650 --> 00:00:15,260 +with an M, for mandatory. It also makes sense to mark as + +6 +00:00:15,260 --> 00:00:18,390 +mandatory the fact that the ATM system checks the PIN of the + +7 +00:00:18,390 --> 00:00:21,480 +card being used by the customer, as that's the typical level of + +8 +00:00:21,480 --> 00:00:23,680 +security that the customer would expect, + +9 +00:00:23,680 --> 00:00:25,760 +therefore we're going to mark as mandatory + +10 +00:00:25,760 --> 00:00:28,320 +also the first requirement here. And of course we + +11 +00:00:28,320 --> 00:00:31,930 +could also perform biometric verification, but based on our knowledge + +12 +00:00:31,930 --> 00:00:33,640 +of the domain, it seems like that should be + +13 +00:00:33,640 --> 00:00:37,410 +an additional verification, rather than the main and only verification + +14 +00:00:37,410 --> 00:00:40,170 +for the system. We will therefore mark it superfluous. + +15 +00:00:40,170 --> 00:00:42,720 +That is something that we can postpone until a later + +16 +00:00:42,720 --> 00:00:45,100 +release, the second requirement. Finally, + +17 +00:00:45,100 --> 00:00:46,740 +another typical operation that customers + +18 +00:00:46,740 --> 00:00:51,070 +perform at ATM machines is depositing. Whereas changing an ATM + +19 +00:00:51,070 --> 00:00:53,850 +card's PIN is not such a common operation. We'll therefore mark + +20 +00:00:53,850 --> 00:00:57,710 +it nice to have this fourth requirement and as superfluous, the + +21 +00:00:57,710 --> 00:01:00,420 +last one. So at the end, what we have is that + +22 +00:01:00,420 --> 00:01:03,540 +we have two mandatory requirements which are the two that we can + +23 +00:01:03,540 --> 00:01:06,280 +satisfy for sure. One, nice to have the requirement, which is + +24 +00:01:06,280 --> 00:01:09,960 +the possible third requirement which we might have time to satisfy. And + +25 +00:01:09,960 --> 00:01:12,980 +the other two that are marked as superfluous, as something that + +26 +00:01:12,980 --> 00:01:16,100 +we might do later, for example in a subsequent release. And of + +27 +00:01:16,100 --> 00:01:19,060 +course there is something subjective in these answers. But + +28 +00:01:19,060 --> 00:01:22,020 +again, based on our knowledge on our understanding of + +29 +00:01:22,020 --> 00:01:23,910 +the domain, these are the one that makes more + +30 +00:01:23,910 --> 00:01:26,640 +sense for an ATM system as we know it. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/32 - Requirements Engineering Process - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/32 - Requirements Engineering Process - lang_en_vs4.srt new file mode 100644 index 0000000..aa1ab28 --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/32 - Requirements Engineering Process - lang_en_vs4.srt @@ -0,0 +1,99 @@ +1 +00:00:00,180 --> 00:00:02,580 +Let's now put together all that we have discussed + +2 +00:00:02,580 --> 00:00:06,340 +and see how a requirements engineering process actually works. + +3 +00:00:06,340 --> 00:00:08,450 +So, first of all, we saw that requirements engineering + +4 +00:00:08,450 --> 00:00:12,080 +consists of three main steps. Elicitation of the requirements, + +5 +00:00:12,080 --> 00:00:15,450 +in which we extract requirements from various sources. Modeling + +6 +00:00:15,450 --> 00:00:17,880 +in which we represent the requirements using one or + +7 +00:00:17,880 --> 00:00:21,650 +more notations or formal reasons and analysis, in which + +8 +00:00:21,650 --> 00:00:25,230 +we identify possible issues with our requirements and there is + +9 +00:00:25,230 --> 00:00:27,870 +actually a 4th step that we kind of mention + +10 +00:00:27,870 --> 00:00:30,670 +but not explicitly. And this is the negotiation that can + +11 +00:00:30,670 --> 00:00:34,320 +happen between the stakeholders and the developers, during which + +12 +00:00:34,320 --> 00:00:38,400 +requirements are discussed and modified until an agreement is reached. + +13 +00:00:38,400 --> 00:00:40,000 +So if you want to think of this as a + +14 +00:00:40,000 --> 00:00:43,030 +process, so as a sequence of steps, we can see + +15 +00:00:43,030 --> 00:00:46,000 +that we start from elicitation. So we start by eliciting + +16 +00:00:46,000 --> 00:00:50,450 +an initial setup requirements. We negotiate and refine this set, + +17 +00:00:50,450 --> 00:00:53,820 +then we model the resulting requirements. And finally, we + +18 +00:00:53,820 --> 00:00:58,190 +analyze such requirements. However, the process doesn't really stop here. + +19 +00:00:58,190 --> 00:01:00,620 +Why? Well, because as a result of the analysis, + +20 +00:01:00,620 --> 00:01:03,230 +we might have to perform further elicitation. And so this + +21 +00:01:03,230 --> 00:01:05,850 +process is not really a sequential one, but rather + +22 +00:01:05,850 --> 00:01:09,340 +an iterative process. So, in practice, we continue to iterate + +23 +00:01:09,340 --> 00:01:12,700 +over these four steps gathering a better and better understanding + +24 +00:01:12,700 --> 00:01:15,560 +of the requirements at every iteration until we are happy + +25 +00:01:15,560 --> 00:01:18,080 +with the settle requirement that we gather and stop the process. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/33 - SRS - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/33 - SRS - lang_en_vs5.srt new file mode 100644 index 0000000..44076db --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/33 - SRS - lang_en_vs5.srt @@ -0,0 +1,183 @@ +1 +00:00:00,120 --> 00:00:01,800 +Before I conclude this lesson, I want to say + +2 +00:00:01,800 --> 00:00:06,150 +a few additional things about the Software Requirement Specification document + +3 +00:00:06,150 --> 00:00:08,510 +or the SRS. And I want to do that because this + +4 +00:00:08,510 --> 00:00:10,900 +is a very important document and some of the projects + +5 +00:00:10,900 --> 00:00:13,160 +actually require you to produce one. So why is + +6 +00:00:13,160 --> 00:00:16,760 +the Requirement Specification such an important document? That's because a + +7 +00:00:16,760 --> 00:00:20,840 +Software Requirement Specification document is an important fundamental way to + +8 +00:00:20,840 --> 00:00:25,310 +communicate. Requirements to others. For example they represent a common + +9 +00:00:25,310 --> 00:00:29,490 +ground between analysts and stakeholders. Note however, that different + +10 +00:00:29,490 --> 00:00:32,810 +projects might require different software requirement specifications so you + +11 +00:00:32,810 --> 00:00:35,560 +need to know your context. For example, the SRS + +12 +00:00:35,560 --> 00:00:38,140 +document that you have to create for a small project + +13 +00:00:38,140 --> 00:00:40,690 +performed by a few developers can in most cases. + +14 +00:00:40,690 --> 00:00:43,570 +Be a concise and informal one. Conversely the software + +15 +00:00:43,570 --> 00:00:47,000 +requirement specification for a multi-year project, involving a number + +16 +00:00:47,000 --> 00:00:50,480 +of developers can be a fairly complex and extensive document. + +17 +00:00:50,480 --> 00:00:52,000 +So again you have to be aware of your + +18 +00:00:52,000 --> 00:00:55,520 +context and build your software requirement specification accordingly. In + +19 +00:00:55,520 --> 00:00:58,536 +order to have a common format for the SRS + +20 +00:00:58,536 --> 00:01:01,380 +document, IEEE defined a standard that divides the document in + +21 +00:01:01,380 --> 00:01:04,349 +predefined sections. And in the context of this course, + +22 +00:01:04,349 --> 00:01:07,530 +we will use a simplified version of the IEEE + +23 +00:01:07,530 --> 00:01:11,400 +SRS format that includes three main sections. An introduction, + +24 +00:01:11,400 --> 00:01:15,540 +which discusses the purpose, context, and objectives of the project. + +25 +00:01:15,540 --> 00:01:18,500 +A user requirements definition, which contains the user + +26 +00:01:18,500 --> 00:01:22,690 +requirements. And the system requirements specification, which includes both + +27 +00:01:22,690 --> 00:01:26,800 +functional and non-functional requirements. And we provide more information + +28 +00:01:26,800 --> 00:01:29,430 +about this format when we discuss the projects. So + +29 +00:01:29,430 --> 00:01:31,140 +to conclude the lesson, I want to point + +30 +00:01:31,140 --> 00:01:33,670 +out and in some cases recap a few important + +31 +00:01:33,670 --> 00:01:37,150 +characteristics that requirements should have. First of all, requirements + +32 +00:01:37,150 --> 00:01:40,740 +should be simple. Not compound. Each requirement should express + +33 +00:01:40,740 --> 00:01:43,710 +one specific piece of functionality that the system + +34 +00:01:43,710 --> 00:01:47,000 +should provide. Requirements should be testable. We mentioned + +35 +00:01:47,000 --> 00:01:48,660 +this before, but I want to stress it + +36 +00:01:48,660 --> 00:01:51,820 +because it is a very important point. Untestable requirements + +37 +00:01:51,820 --> 00:01:53,850 +such as the system should be fast, are + +38 +00:01:53,850 --> 00:01:58,180 +useless. Requirements should be organized. Related requirements should be + +39 +00:01:58,180 --> 00:02:01,220 +grouped, more abstract requirements should contain more detailed + +40 +00:02:01,220 --> 00:02:05,400 +requirements, and priorities should be clearly indicated when present. + +41 +00:02:05,400 --> 00:02:07,532 +Finally, requirements should be numbered, so + +42 +00:02:07,532 --> 00:02:09,538 +that they can be traced. For example, + +43 +00:02:09,538 --> 00:02:11,430 +numbered requirements will allow you to trace + +44 +00:02:11,430 --> 00:02:14,510 +them to design. Implementation and testing elements + +45 +00:02:14,510 --> 00:02:17,350 +and items, which is something that you might have to do for one of + +46 +00:02:17,350 --> 00:02:20,680 +the projects. And that we will discuss in more detail in a later class. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/4 - Software Intensive Systems - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/4 - Software Intensive Systems - lang_en_vs5.srt new file mode 100644 index 0000000..28c70ad --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/4 - Software Intensive Systems - lang_en_vs5.srt @@ -0,0 +1,111 @@ +1 +00:00:00,100 --> 00:00:03,100 +In our initial definition of requirements engineering, we talked about + +2 +00:00:03,100 --> 00:00:06,130 +software systems. But what do we really mean when we + +3 +00:00:06,130 --> 00:00:09,980 +use the term software? Software is an abstract description of + +4 +00:00:09,980 --> 00:00:13,920 +a set of computations that becomes concrete, and therefore useful, only + +5 +00:00:13,920 --> 00:00:16,600 +when we run the software on some hardware, and that, + +6 +00:00:16,600 --> 00:00:19,310 +in the context of some human activity that it can + +7 +00:00:19,310 --> 00:00:22,530 +support. So what does that mean exactly? What that means + +8 +00:00:22,530 --> 00:00:25,235 +is that when we say software, what we really mean is + +9 +00:00:25,235 --> 00:00:28,790 +a software intensive system. That is, the combination + +10 +00:00:28,790 --> 00:00:31,930 +of 3 things, the software, the hardware on which + +11 +00:00:31,930 --> 00:00:34,610 +the software runs, and the context in which the + +12 +00:00:34,610 --> 00:00:37,470 +software is used. Just to illustrate, let me show + +13 +00:00:37,470 --> 00:00:40,010 +you this through a picture. What I'm showing here + +14 +00:00:40,010 --> 00:00:42,830 +is a customer, a user, that is using, is + +15 +00:00:42,830 --> 00:00:47,000 +accessing, an ATM machine. And this action involves several + +16 +00:00:47,000 --> 00:00:50,650 +things. There is the software that drives the logic + +17 +00:00:50,650 --> 00:00:53,410 +of the ATM machine. There is the hardware on + +18 +00:00:53,410 --> 00:00:57,280 +which the software runs. And there is the context + +19 +00:00:57,280 --> 00:00:59,850 +In which the software is used. And in this + +20 +00:00:59,850 --> 00:01:02,660 +case, the context is the bank. And only by + +21 +00:01:02,660 --> 00:01:06,105 +considering these 3 things together can we really understand + +22 +00:01:06,105 --> 00:01:09,510 +the functionality that is represented here. So the bottom + +23 +00:01:09,510 --> 00:01:12,690 +line here is that we usually take hardware and + +24 +00:01:12,690 --> 00:01:15,750 +context for granted in this equation. But they actually + +25 +00:01:15,750 --> 00:01:18,210 +need to be explicitly considered when building a + +26 +00:01:18,210 --> 00:01:20,770 +system. Otherwise, we might forget this is all + +27 +00:01:20,770 --> 00:01:23,850 +the functionality, and ultimately of the requirements. And + +28 +00:01:23,850 --> 00:01:25,640 +we might end up with the wrong system. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/5 - Software Quality - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/5 - Software Quality - lang_en_vs4.srt new file mode 100644 index 0000000..86db606 --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/5 - Software Quality - lang_en_vs4.srt @@ -0,0 +1,111 @@ +1 +00:00:00,170 --> 00:00:02,920 +So, let's see how this affects the concept of software + +2 +00:00:02,920 --> 00:00:05,620 +quality. Another way to express what we just said is + +3 +00:00:05,620 --> 00:00:08,220 +to say that the software runs on some hardware and + +4 +00:00:08,220 --> 00:00:11,750 +is developed for a purpose that is related to human + +5 +00:00:11,750 --> 00:00:14,870 +activities. And given this perspective, we can define what we + +6 +00:00:14,870 --> 00:00:18,440 +mean by software quality in this light. Software quality is + +7 +00:00:18,440 --> 00:00:22,290 +not just a function of the software. So, the software + +8 +00:00:22,290 --> 00:00:25,610 +itself does not define the quality of the overall system. + +9 +00:00:25,610 --> 00:00:28,880 +Rather, software quality is a function of both the + +10 +00:00:28,880 --> 00:00:32,259 +software and its purpose. Where purpose has to do with + +11 +00:00:32,259 --> 00:00:34,840 +the way in which the software will be used. So + +12 +00:00:34,840 --> 00:00:37,950 +a software system can be of low quality not only + +13 +00:00:37,950 --> 00:00:40,580 +because it does not work well. So, for example, not + +14 +00:00:40,580 --> 00:00:43,620 +only because it crashes. Of course, that's an issue. But + +15 +00:00:43,620 --> 00:00:47,000 +just as importantly, a software can also be of low + +16 +00:00:47,000 --> 00:00:50,720 +quality because it does not fulfill its purpose, and this + +17 +00:00:50,720 --> 00:00:53,960 +happens quite often. It is unfortunately not rare for + +18 +00:00:53,960 --> 00:00:57,310 +the software producers to have an inadequate understanding, or even + +19 +00:00:57,310 --> 00:01:00,450 +a complete misunderstanding of the purpose of the software, + +20 +00:01:00,450 --> 00:01:03,200 +of what the users want to do and will do + +21 +00:01:03,200 --> 00:01:05,770 +with it. Turning these around, we can therefore define + +22 +00:01:05,770 --> 00:01:09,890 +the quality of software in terms of fitness for purpose. + +23 +00:01:09,890 --> 00:01:12,990 +The more the software fulfills its purpose, the more + +24 +00:01:12,990 --> 00:01:16,040 +the software is on target, the higher is its quality. + +25 +00:01:16,040 --> 00:01:19,600 +And identifying the purpose of the software, so hitting + +26 +00:01:19,600 --> 00:01:23,550 +this target, is exactly the goal of requirements engineering. + +27 +00:01:23,550 --> 00:01:25,970 +And it is the reason why requirements engineering is + +28 +00:01:25,970 --> 00:01:29,370 +such a fundamental activity in the context of software engineering. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/6 - Identifying Purpose - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/6 - Identifying Purpose - lang_en_vs4.srt new file mode 100644 index 0000000..0accc39 --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/6 - Identifying Purpose - lang_en_vs4.srt @@ -0,0 +1,107 @@ +1 +00:00:00,050 --> 00:00:03,480 +And identifying the purpose of a softer system means + +2 +00:00:03,480 --> 00:00:06,980 +defining the requirements for the system. And if you have + +3 +00:00:06,980 --> 00:00:09,540 +ever done anything like that, for example, we did + +4 +00:00:09,540 --> 00:00:12,060 +it for the first project in the previous mini course, + +5 +00:00:12,060 --> 00:00:14,720 +you will know that it is an extremely hard + +6 +00:00:14,720 --> 00:00:17,760 +task. Identifying the purpose of the software and defining its + +7 +00:00:17,760 --> 00:00:21,600 +requirements is very, very hard. Why is it so hard? + +8 +00:00:21,600 --> 00:00:25,560 +First of all, the purpose of most systems is inherently, + +9 +00:00:25,560 --> 00:00:27,920 +extremely complex, so this has to do with the + +10 +00:00:27,920 --> 00:00:31,330 +sheer complexity of the purpose of the requirements. Just think + +11 +00:00:31,330 --> 00:00:34,810 +of how complex is the functionality provided by most systems. + +12 +00:00:34,810 --> 00:00:38,790 +Second, it is hard, very hard to extract from humans + +13 +00:00:38,790 --> 00:00:41,780 +this purpose and make it explicit. So, paraphrasing a + +14 +00:00:41,780 --> 00:00:45,130 +famous quote from the late Steve Jobs, often people don't + +15 +00:00:45,130 --> 00:00:47,475 +know what they want until you show it to them. + +16 +00:00:47,475 --> 00:00:50,490 +It's hard to figure out what people really want. Third, + +17 +00:00:50,490 --> 00:00:54,260 +requirements often change over time. Customers change their + +18 +00:00:54,260 --> 00:00:57,490 +mind. Designing and building a system raises new requirements. + +19 +00:00:57,490 --> 00:01:00,270 +So for many reasons requirements tend not to + +20 +00:01:00,270 --> 00:01:02,760 +be stable, tend to evolve. And that, of course, + +21 +00:01:02,760 --> 00:01:05,440 +makes it harder to collect them. Finally, for + +22 +00:01:05,440 --> 00:01:09,600 +any realistic system, there are many stakeholders and they + +23 +00:01:09,600 --> 00:01:12,990 +often have conflicting goals and requirements. And it + +24 +00:01:12,990 --> 00:01:15,900 +can be very hard to reconcile the possibly conflicting + +25 +00:01:15,900 --> 00:01:19,630 +requirements that might emerge in these cases. So for all these reasons, + +26 +00:01:19,630 --> 00:01:21,230 +it is very, very difficult to + +27 +00:01:21,230 --> 00:01:23,930 +perform requirements engineering in an effective way. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/7 - Completeness and Pertinence - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/7 - Completeness and Pertinence - lang_en_vs5.srt new file mode 100644 index 0000000..c0ce159 --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/7 - Completeness and Pertinence - lang_en_vs5.srt @@ -0,0 +1,103 @@ +1 +00:00:00,350 --> 00:00:03,610 +These issues and difficulties can result in requirements + +2 +00:00:03,610 --> 00:00:06,780 +that show various problems. Two particularly relevant and + +3 +00:00:06,780 --> 00:00:10,880 +common problems are completeness and pertinence. Or better, + +4 +00:00:10,880 --> 00:00:14,750 +the lack of completeness and pertinence. Completeness refers to + +5 +00:00:14,750 --> 00:00:17,560 +the fact that it is often extremely difficult + +6 +00:00:17,560 --> 00:00:20,370 +to identify all of the requirements. That is it + +7 +00:00:20,370 --> 00:00:22,890 +is very difficult to have a complete picture + +8 +00:00:22,890 --> 00:00:25,780 +of the purpose of the software. So what happens + +9 +00:00:25,780 --> 00:00:28,540 +is that incomplete requirements are collected and the software + +10 +00:00:28,540 --> 00:00:32,500 +is missing functionality that is important for the user. Pertinence + +11 +00:00:32,500 --> 00:00:34,720 +conversely has to do with the relevance of the + +12 +00:00:34,720 --> 00:00:38,770 +requirements. To avoid completeness problems developers often end up collecting + +13 +00:00:38,770 --> 00:00:42,640 +a lot of irrelevant when not conflicting requirements. In + +14 +00:00:42,640 --> 00:00:45,060 +these cases what can happen is that the software could + +15 +00:00:45,060 --> 00:00:47,120 +either end up being bloated that is it might + +16 +00:00:47,120 --> 00:00:51,290 +contain a needed functionality. The functionality represented by these extra + +17 +00:00:51,290 --> 00:00:54,120 +requirements or it might even be impossible to build the + +18 +00:00:54,120 --> 00:00:57,480 +software due to the conflicting additional requirements. And to make + +19 +00:00:57,480 --> 00:01:00,920 +things even worse collecting all of these requirements sometimes doesn't + +20 +00:01:00,920 --> 00:01:03,390 +even solve the completeness issue. So you might end up + +21 +00:01:03,390 --> 00:01:05,800 +with a set of requirements that is not only incomplete + +22 +00:01:05,800 --> 00:01:08,740 +but it also contains extra information that can be harmful + +23 +00:01:08,740 --> 00:01:11,450 +to the system. So again the bottom line is that + +24 +00:01:11,450 --> 00:01:14,310 +gathering an adequate, accurate, complete, + +25 +00:01:14,310 --> 00:01:16,500 +and pertinent set of requirements that + +26 +00:01:16,500 --> 00:01:20,100 +identify the purpose of a software system is an arduous task. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/8 - Pertinence Quiz - lang_en_vs5.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/8 - Pertinence Quiz - lang_en_vs5.srt new file mode 100644 index 0000000..a04a9a9 --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/8 - Pertinence Quiz - lang_en_vs5.srt @@ -0,0 +1,35 @@ +1 +00:00:00,100 --> 00:00:03,530 +Now that we talked about completeness and pertinence, let's consider an + +2 +00:00:03,530 --> 00:00:06,200 +information system for a gym. I'm going to give you a + +3 +00:00:06,200 --> 00:00:09,580 +list of possible requirements and I want you to mark in + +4 +00:00:09,580 --> 00:00:13,530 +that list all the requirements that you believe are pertinent. So let + +5 +00:00:13,530 --> 00:00:16,030 +me read the list. Members of the gym shall be able + +6 +00:00:16,030 --> 00:00:18,770 +to access their training programs. The system shall be able to + +7 +00:00:18,770 --> 00:00:21,894 +read member cards. The system shall be able to store members' + +8 +00:00:21,894 --> 00:00:25,150 +commute time. Personal trainers shall be able to add clients. And the + +9 +00:00:25,150 --> 00:00:27,570 +list of members shall be stored as a linked list. diff --git a/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/9 - Pertinence Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/9 - Pertinence Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..ee4f04f --- /dev/null +++ b/usth/ICT2.7/P2L1 Requirements Engineering Subtitles/9 - Pertinence Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,75 @@ +1 +00:00:00,190 --> 00:00:03,620 +So the first requirement is definitely pertinent. Members of the gym shall + +2 +00:00:03,620 --> 00:00:06,740 +be able to access their training programs. It's pretty normal for members of + +3 +00:00:06,740 --> 00:00:09,710 +the gym to have a training program. And therefore, the system should allow + +4 +00:00:09,710 --> 00:00:12,900 +them to access them. Similarly for the second one. The system shall be + +5 +00:00:12,900 --> 00:00:15,450 +able to read member cards. Normally when you get into a gym + +6 +00:00:15,450 --> 00:00:17,420 +if you have a member card, you'll have to either show it to + +7 +00:00:17,420 --> 00:00:21,010 +somebody, or nowadays swipe it, and so the system should be able to + +8 +00:00:21,010 --> 00:00:23,410 +recognize the customer given the card. + +9 +00:00:23,410 --> 00:00:25,710 +The third requirement is probably not pertinent, + +10 +00:00:25,710 --> 00:00:29,090 +because I cannot think of any meaningful case in which the system + +11 +00:00:29,090 --> 00:00:32,729 +should know what is the members' commute time. The fourth requirement, personal + +12 +00:00:32,729 --> 00:00:36,750 +trainers shall be able to add clients, is also probably pertinent. Assuming + +13 +00:00:36,750 --> 00:00:38,870 +that we have personal trainers in the gym, and they should be + +14 +00:00:38,870 --> 00:00:41,710 +able to get clients, to work with the clients of the gym, + +15 +00:00:41,710 --> 00:00:44,140 +and therefore, they should be able to add them as their clients + +16 +00:00:44,140 --> 00:00:47,620 +to the system. And finally, the last requirement, the list of members + +17 +00:00:47,620 --> 00:00:50,800 +shall be stores as a linked list. This is really something about + +18 +00:00:50,800 --> 00:00:54,130 +the how, more than the what. And therefore, for what we say before + +19 +00:00:54,130 --> 00:00:57,720 +is probably not a pertinent requirement, so we're not going to mark this one. 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. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/1 - Lesson Overview - lang_en_vs4.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/1 - Lesson Overview - lang_en_vs4.srt new file mode 100644 index 0000000..89008af --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/1 - Lesson Overview - lang_en_vs4.srt @@ -0,0 +1,47 @@ +1 +00:00:00,360 --> 00:00:02,910 +Hello, and welcome to the third part + +2 +00:00:02,910 --> 00:00:06,426 +of our software engineering course. In this mini-course, + +3 +00:00:06,426 --> 00:00:09,250 +we will discuss software design. We will + +4 +00:00:09,250 --> 00:00:13,170 +also introduce the Unified Software Process. And we + +5 +00:00:13,170 --> 00:00:15,730 +will work on a more complex project, + +6 +00:00:15,730 --> 00:00:18,330 +in which we will develop a distributed software + +7 +00:00:18,330 --> 00:00:22,960 +system that involves multiple different platforms. In + +8 +00:00:22,960 --> 00:00:25,730 +our first lesson of this mini-course, in particular, + +9 +00:00:25,730 --> 00:00:28,150 +we will talk about software architecture. A + +10 +00:00:28,150 --> 00:00:31,650 +software engineering discipline whose goal is to lay + +11 +00:00:31,650 --> 00:00:34,980 +the foundation on which to build successful + +12 +00:00:34,980 --> 00:00:38,130 +and long lasting software systems. So let's begin. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/10 - Architectural Recovery Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/10 - Architectural Recovery Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..bd45907 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/10 - Architectural Recovery Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,67 @@ +1 +00:00:00,120 --> 00:00:03,210 +The first sentence is definitely false. Prescriptive architecture + +2 +00:00:03,210 --> 00:00:06,530 +and descriptive architecture tend to diverge as systems evolve, + +3 +00:00:06,530 --> 00:00:08,960 +and sometimes, even when the system is first developed, + +4 +00:00:08,960 --> 00:00:10,680 +as we will see in some of the upcoming + +5 +00:00:10,680 --> 00:00:14,340 +examples. Conversely, the second sentence is true. By + +6 +00:00:14,340 --> 00:00:18,150 +adding unnecessary elements to the architecture, architectural drift can + +7 +00:00:18,150 --> 00:00:22,470 +transform an otherwise clean architecture into a complex sub-optimal, + +8 +00:00:22,470 --> 00:00:25,960 +and often ugly, architecture. The third sentence is false. + +9 +00:00:25,960 --> 00:00:30,540 +Architectural erosion and architectural drift are, indeed, different phenomena. + +10 +00:00:30,540 --> 00:00:32,940 +But they both result in a less than ideal, and + +11 +00:00:32,940 --> 00:00:36,160 +in some cases, highly degraded architecture. And the fourth + +12 +00:00:36,160 --> 00:00:39,600 +sentence is also false, as we discussed a minute ago. + +13 +00:00:39,600 --> 00:00:42,050 +Just tweaking at the code is very unlikely to + +14 +00:00:42,050 --> 00:00:44,930 +improve the code. Quite the opposite, actually. The best way + +15 +00:00:44,930 --> 00:00:48,420 +to repair a degraded architectural design is to first, understand + +16 +00:00:48,420 --> 00:00:51,110 +the current architecture, and then, try to fix it in + +17 +00:00:51,110 --> 00:00:52,280 +a more principled way. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/11 - Real World Example - lang_en_vs6.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/11 - Real World Example - lang_en_vs6.srt new file mode 100644 index 0000000..4e64d4a --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/11 - Real World Example - lang_en_vs6.srt @@ -0,0 +1,183 @@ +1 +00:00:00,210 --> 00:00:02,770 +Now to drive home some of the points that I just + +2 +00:00:02,770 --> 00:00:05,920 +made, I would like to show you a few real world examples + +3 +00:00:05,920 --> 00:00:09,150 +of architectures that kind of went astray. The first example I + +4 +00:00:09,150 --> 00:00:11,970 +want to use is an example from the Linux kernel. Actually, from + +5 +00:00:11,970 --> 00:00:15,260 +an earlier version of the Linux kernel. A research group studied + +6 +00:00:15,260 --> 00:00:17,020 +the documentation of Linux, and also + +7 +00:00:17,020 --> 00:00:19,440 +interviewed several Linux developers. And by + +8 +00:00:19,440 --> 00:00:21,710 +doing that, they were able to come up with a software + +9 +00:00:21,710 --> 00:00:25,260 +architecture of Linux at different levels of obstruction. So the one that + +10 +00:00:25,260 --> 00:00:27,365 +I'm showing you here on the left, is the + +11 +00:00:27,365 --> 00:00:31,120 +software architecture at the level of Linux's main subsystems. So + +12 +00:00:31,120 --> 00:00:34,540 +this is the prescriptive architecture of Linux at the level + +13 +00:00:34,540 --> 00:00:38,060 +of Linux's main subsystems. So the researchers, after identifying this + +14 +00:00:38,060 --> 00:00:40,420 +architecture, they showed it to the developers, and the + +15 +00:00:40,420 --> 00:00:43,180 +developers agreed that, that was indeed the architecture of the + +16 +00:00:43,180 --> 00:00:46,540 +system. The researchers then studied the source code of Linux + +17 +00:00:46,540 --> 00:00:50,380 +and reverse engineered its actual architecture. So the architecture as + +18 +00:00:50,380 --> 00:00:54,020 +implemented, it's descriptive architecture. And this one here, on the + +19 +00:00:54,020 --> 00:00:56,610 +right, is the result. And as you can see, they found + +20 +00:00:56,610 --> 00:01:00,940 +a number of differences or violations between the prescriptive architecture and + +21 +00:01:00,940 --> 00:01:04,080 +the descriptive architecture. In particular, if we look at this architecture, + +22 +00:01:04,080 --> 00:01:06,820 +we can see that pretty much everything talks to everything else, + +23 +00:01:06,820 --> 00:01:09,010 +which is, in general, not a good thing. And in addition + +24 +00:01:09,010 --> 00:01:11,890 +to that, there are also several things that don't really make + +25 +00:01:11,890 --> 00:01:15,630 +much sense. For example the library calls the file system and + +26 +00:01:15,630 --> 00:01:19,290 +also the network interface which doesn't make much sense. Another thing + +27 +00:01:19,290 --> 00:01:21,850 +that is kind of weird is the fact that file system + +28 +00:01:21,850 --> 00:01:25,250 +calls the kernel initialization code. Which is also a little bit + +29 +00:01:25,250 --> 00:01:28,100 +weird. So basically, the bottom line here is that not even + +30 +00:01:28,100 --> 00:01:32,020 +the developers realized how the actual architecture of the system was, + +31 +00:01:32,020 --> 00:01:35,170 +and how it was different from the architecture they have conceived. + +32 +00:01:35,170 --> 00:01:37,870 +And in fact another interesting thing here is the reaction of + +33 +00:01:37,870 --> 00:01:41,020 +the developers when they were shown the actual architecture. So basically + +34 +00:01:41,020 --> 00:01:44,110 +they justified the differences by saying things such as, well you + +35 +00:01:44,110 --> 00:01:47,120 +know it had to be done fast, and therefore I changed it + +36 +00:01:47,120 --> 00:01:50,110 +and then I didn't have time to go back and update the documentation + +37 +00:01:50,110 --> 00:01:52,800 +and things of this sort. And by the way these are exactly some + +38 +00:01:52,800 --> 00:01:55,640 +of the reasons that we mentioned early on in the lesson for the + +39 +00:01:55,640 --> 00:01:58,410 +discrepancy between prescriptive and descriptive software + +40 +00:01:58,410 --> 00:01:59,990 +architecture. So one last thing that I + +41 +00:01:59,990 --> 00:02:02,840 +want to mention here as an aside and we can get back to + +42 +00:02:02,840 --> 00:02:06,495 +that later is the fact that you can probably clearly show how representing + +43 +00:02:06,495 --> 00:02:10,880 +software architectures graphically can be extremely useful, because it allows + +44 +00:02:10,880 --> 00:02:14,140 +for easily seeing the structure of the system. Look at different + +45 +00:02:14,140 --> 00:02:17,140 +views identify problematic points and so on. And we will see + +46 +00:02:17,140 --> 00:02:19,740 +how that can be useful in many cases also later on. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/12 - More Examples - lang_en_vs6.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/12 - More Examples - lang_en_vs6.srt new file mode 100644 index 0000000..6f929eb --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/12 - More Examples - lang_en_vs6.srt @@ -0,0 +1,107 @@ +1 +00:00:00,180 --> 00:00:03,090 +As another example, I want to show you the architecture of the + +2 +00:00:03,090 --> 00:00:06,290 +iRods system. This is a data grid system that was built by + +3 +00:00:06,290 --> 00:00:09,720 +a biologist. And it's a system for storing and accessing big + +4 +00:00:09,720 --> 00:00:11,910 +data. So what I'm going to do, I'm going to do the same thing + +5 +00:00:11,910 --> 00:00:14,010 +that I did for the Linux system. I'm going to show you + +6 +00:00:14,010 --> 00:00:18,080 +here, on the left hand side, this clean prescriptive architecture for the + +7 +00:00:18,080 --> 00:00:21,000 +iRODS system. And I'm going to show you here on the right the + +8 +00:00:21,000 --> 00:00:22,660 +actual architecture of the system. The + +9 +00:00:22,660 --> 00:00:25,780 +descriptive architecture of iRODS. So here, + +10 +00:00:25,780 --> 00:00:27,640 +even if we don't go in and look at the details, you + +11 +00:00:27,640 --> 00:00:31,800 +can see very easily that the system is badly drifted and eroded + +12 +00:00:31,800 --> 00:00:34,500 +with respect to the way it was supposed to be. Continuing + +13 +00:00:34,500 --> 00:00:36,500 +with the examples. What I want to show you now is the + +14 +00:00:36,500 --> 00:00:39,980 +view of the complete architecture of HADOOP. As many of you probably + +15 +00:00:39,980 --> 00:00:44,210 +already know, HADOOP is an open source software framework for storage and + +16 +00:00:44,210 --> 00:00:47,990 +large scale processing of data sets. It's very broadly used. And here + +17 +00:00:47,990 --> 00:00:50,820 +is a picture of the architecture, and I hope you can see it + +18 +00:00:50,820 --> 00:00:54,290 +because the architecture is so complex and so broad and so + +19 +00:00:54,290 --> 00:00:57,050 +intertwined, and in order to be able to represent it here + +20 +00:00:57,050 --> 00:00:59,690 +in one page, I had to zoom out quite a bit. + +21 +00:00:59,690 --> 00:01:02,120 +But also in this case, you don't really have to look + +22 +00:01:02,120 --> 00:01:05,640 +at details. The important point here is that in this software architecture + +23 +00:01:05,640 --> 00:01:09,540 +61 out of the 67 components in the system have circular + +24 +00:01:09,540 --> 00:01:12,570 +dependencies. Which means that they depend on each other in a + +25 +00:01:12,570 --> 00:01:15,820 +circular way and this is normally not a good thing and also + +26 +00:01:15,820 --> 00:01:18,790 +in this case a few developers when shown the diagram had no + +27 +00:01:18,790 --> 00:01:22,120 +idea that the structure of the system was so complex and messy. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/13 - Final Example - lang_en_vs4.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/13 - Final Example - lang_en_vs4.srt new file mode 100644 index 0000000..4fab0c6 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/13 - Final Example - lang_en_vs4.srt @@ -0,0 +1,127 @@ +1 +00:00:00,220 --> 00:00:02,130 +I'm going to conclude this set of examples with + +2 +00:00:02,130 --> 00:00:04,750 +a system that you might also know, Bash. And in + +3 +00:00:04,750 --> 00:00:08,000 +case you don't, Bash is a Unix shell written as + +4 +00:00:08,000 --> 00:00:11,000 +a free software replacement for the traditional Bourne shell, also + +5 +00:00:11,000 --> 00:00:13,690 +called sh. So what I'm showing here is the + +6 +00:00:13,690 --> 00:00:17,950 +descriptive architecture of the command component of Bash. So, is + +7 +00:00:17,950 --> 00:00:22,170 +the architecture, as implemented, of the command component of Bash. + +8 +00:00:22,170 --> 00:00:25,390 +And the component is the one here sort of highlighted + +9 +00:00:25,390 --> 00:00:28,120 +in gray. And what you can see here, these names are + +10 +00:00:28,120 --> 00:00:31,640 +the sub components of the command component. And if we look at + +11 +00:00:31,640 --> 00:00:35,000 +this architecture, two design problems of the component can kind of jump + +12 +00:00:35,000 --> 00:00:37,870 +at us. The first one is the lack of cohesion within the + +13 +00:00:37,870 --> 00:00:40,830 +component. So, if you look here, you can see that only + +14 +00:00:40,830 --> 00:00:44,820 +a few connections exist between the sub-components. And having a low cohesion + +15 +00:00:44,820 --> 00:00:47,430 +is normally not a good thing for a design. The second thing + +16 +00:00:47,430 --> 00:00:50,860 +that we can note is the high coupling. The component has tons + +17 +00:00:50,860 --> 00:00:54,200 +of connections with other components. They're, these edges that are + +18 +00:00:54,200 --> 00:00:57,890 +leaving the components and going towards other parts of the system. + +19 +00:00:57,890 --> 00:01:01,190 +So basically, this component has low cohesion and high coupling, which + +20 +00:01:01,190 --> 00:01:04,730 +is exactly the opposite of how a good design should be. + +21 +00:01:04,730 --> 00:01:07,410 +Given the structure, it is clear that anytime you change + +22 +00:01:07,410 --> 00:01:09,970 +this component you might need to change a bunch of other + +23 +00:01:09,970 --> 00:01:13,440 +components in the system. And of course, when changing other components + +24 +00:01:13,440 --> 00:01:15,910 +in the system, you might also need to chance the command + +25 +00:01:15,910 --> 00:01:19,060 +component as well. And along similar lines, to understand this + +26 +00:01:19,060 --> 00:01:21,890 +component you probably need to look at many other parts of + +27 +00:01:21,890 --> 00:01:24,690 +the system, which is also less than ideal. And one + +28 +00:01:24,690 --> 00:01:27,580 +important point here is that with all these examples, I'm not + +29 +00:01:27,580 --> 00:01:30,500 +really trying to criticize any specific system, what I'm trying + +30 +00:01:30,500 --> 00:01:34,380 +to show instead, is how complex software architectures can be, and + +31 +00:01:34,380 --> 00:01:37,040 +how much they can degrade over time. And this is true + +32 +00:01:37,040 --> 00:01:39,660 +for most systems, not just the ones that I showed you. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/14 - Architectural Design Quiz - lang_en_vs4.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/14 - Architectural Design Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..e1e95e6 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/14 - Architectural Design Quiz - lang_en_vs4.srt @@ -0,0 +1,31 @@ +1 +00:00:00,110 --> 00:00:02,330 +At this point, we have seen some examples of + +2 +00:00:02,330 --> 00:00:05,070 +things that might go wrong with the software architecture. So + +3 +00:00:05,070 --> 00:00:07,220 +I'd like to ask you also to recap some of + +4 +00:00:07,220 --> 00:00:10,800 +the concepts that we've touched upon. What are ideal characteristics + +5 +00:00:10,800 --> 00:00:13,526 +of an architectural design? And I'm showing you three possibilities + +6 +00:00:13,526 --> 00:00:16,970 +here: scalability, low cohesion, and low coupling. And some of + +7 +00:00:16,970 --> 00:00:20,260 +these concepts we did not explicitly define, but we talked + +8 +00:00:20,260 --> 00:00:22,400 +about it when discussing the examples that we just saw. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/15 - Architectural Design Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/15 - Architectural Design Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..465687c --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/15 - Architectural Design Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,107 @@ +1 +00:00:00,110 --> 00:00:02,540 +So, let's look at these three characteristics one by + +2 +00:00:02,540 --> 00:00:06,660 +one. Scalability for software architecture is its ability to handle + +3 +00:00:06,660 --> 00:00:09,320 +the growth of the software system. For example, for a + +4 +00:00:09,320 --> 00:00:12,610 +web based system, scalability could be the ability to handle + +5 +00:00:12,610 --> 00:00:15,620 +a larger workload by adding new servers to the system. + +6 +00:00:15,620 --> 00:00:19,508 +Scalability is therefore an important characteristic of a software architecture, + +7 +00:00:19,508 --> 00:00:21,938 +especially for the kinds of systems that can grow over + +8 +00:00:21,938 --> 00:00:24,990 +time. So, we're going to mark it as an ideal characteristic. + +9 +00:00:24,990 --> 00:00:27,901 +Cohesion is a measure of how strongly related are + +10 +00:00:27,901 --> 00:00:30,920 +the elements of a module. Clearly, we should shoot + +11 +00:00:30,920 --> 00:00:33,760 +for high and not low cohesion when developing a + +12 +00:00:33,760 --> 00:00:37,100 +system. We want to develop modules whose elements cooperate to + +13 +00:00:37,100 --> 00:00:40,480 +provide the specific piece of functionality rather than modules + +14 +00:00:40,480 --> 00:00:43,410 +consisting of a bunch of elements that provide different + +15 +00:00:43,410 --> 00:00:47,040 +unrelated pieces of functionality. Therefor, low cohesion is definitely + +16 +00:00:47,040 --> 00:00:49,980 +not something that we want. We want high cohesion instead. + +17 +00:00:49,980 --> 00:00:53,040 +As for coupling, coupling is a concept related to cohesion + +18 +00:00:53,040 --> 00:00:55,070 +and is also a measure. In this case though, it + +19 +00:00:55,070 --> 00:00:58,130 +is a measure of how strongly related are the different + +20 +00:00:58,130 --> 00:01:01,830 +modules in a system. Low coupling, which is often correlated with + +21 +00:01:01,830 --> 00:01:05,570 +high cohesion, is an important and ideal characteristic of a + +22 +00:01:05,570 --> 00:01:08,660 +software architecture as it indicates that the different modules in + +23 +00:01:08,660 --> 00:01:12,220 +the system are independent from one another. Each module provides + +24 +00:01:12,220 --> 00:01:15,300 +a specific piece of functionality and it can provide it without + +25 +00:01:15,300 --> 00:01:17,530 +relying too much on other modules. + +26 +00:01:17,530 --> 00:01:19,960 +Basically, systems characterized by low coupling + +27 +00:01:19,960 --> 00:01:23,330 +and high cohesion, are systems that are easier to understand, and to maintain. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/16 - Architectural Elements - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/16 - Architectural Elements - lang_en_vs5.srt new file mode 100644 index 0000000..c8de83f --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/16 - Architectural Elements - lang_en_vs5.srt @@ -0,0 +1,115 @@ +1 +00:00:00,170 --> 00:00:02,770 +Now that we have discussed a few foundational aspects + +2 +00:00:02,770 --> 00:00:05,410 +of software architectures, and we have looked at some real + +3 +00:00:05,410 --> 00:00:07,900 +world examples that help us to illustrate some of these + +4 +00:00:07,900 --> 00:00:10,560 +points, to discuss some of these aspects. I want to + +5 +00:00:10,560 --> 00:00:13,730 +introduce and define the different elements that compose a software + +6 +00:00:13,730 --> 00:00:17,700 +architecture and also talk about architectural styles. So let's start + +7 +00:00:17,700 --> 00:00:20,190 +by discussing a software architecture's + +8 +00:00:20,190 --> 00:00:22,880 +elements. A software system's architecture + +9 +00:00:22,880 --> 00:00:26,690 +typically is not, and should not be, a uniform monolith. + +10 +00:00:26,690 --> 00:00:28,770 +On the contrary, an architecture should be a + +11 +00:00:28,770 --> 00:00:32,910 +composition and interplay of different elements. In particular, + +12 +00:00:32,910 --> 00:00:34,510 +as we quickly mentioned at the beginning of + +13 +00:00:34,510 --> 00:00:36,970 +the lesson, there are three main types of elements + +14 +00:00:36,970 --> 00:00:40,160 +in an architecture. Processing elements, data elements, and + +15 +00:00:40,160 --> 00:00:44,580 +interaction elements. Processing elements are those elements that implement + +16 +00:00:44,580 --> 00:00:48,260 +the business logic and perform transformations on data. + +17 +00:00:48,260 --> 00:00:51,760 +Data elements, also called information or state, are those + +18 +00:00:51,760 --> 00:00:54,180 +elements that contain the information that is used + +19 +00:00:54,180 --> 00:00:57,440 +and transformed by the processing elements. And finally, + +20 +00:00:57,440 --> 00:01:00,030 +the interaction elements are the glue that holds + +21 +00:01:00,030 --> 00:01:02,760 +the different pieces of the architecture together. Now, + +22 +00:01:02,760 --> 00:01:06,030 +the processing elements and the data are contained + +23 +00:01:06,030 --> 00:01:10,350 +into the system components, whereas the interaction elements + +24 +00:01:10,350 --> 00:01:13,900 +are maintained and controlled by the system connectors. + +25 +00:01:13,900 --> 00:01:17,100 +And components and connectors get all cooked together + +26 +00:01:17,100 --> 00:01:19,980 +into a systems configuration, which models + +27 +00:01:19,980 --> 00:01:22,940 +components, connectors and their relationships. So + +28 +00:01:22,940 --> 00:01:24,850 +now, let's look at components, connectors + +29 +00:01:24,850 --> 00:01:26,770 +and configurations in a little more detail. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/17 - Components, Connectors, and Configurations - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/17 - Components, Connectors, and Configurations - lang_en_vs5.srt new file mode 100644 index 0000000..5fc4df3 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/17 - Components, Connectors, and Configurations - lang_en_vs5.srt @@ -0,0 +1,111 @@ +1 +00:00:00,250 --> 00:00:02,350 +And let's start with software components. A + +2 +00:00:02,350 --> 00:00:06,700 +software component is an architectural entity that encapsulates + +3 +00:00:06,700 --> 00:00:09,940 +a subset of the system's functionality and or + +4 +00:00:09,940 --> 00:00:13,180 +the system's data. So basically components typically provide + +5 +00:00:13,180 --> 00:00:16,100 +application specific services. In addition to that, a + +6 +00:00:16,100 --> 00:00:19,650 +software component also restricts access to that subset + +7 +00:00:19,650 --> 00:00:23,570 +via an explicitly defined interface. And, in addition, + +8 +00:00:23,570 --> 00:00:25,610 +which I'm not showing here, a component + +9 +00:00:25,610 --> 00:00:28,010 +can also have explicitly defined dependencies + +10 +00:00:28,010 --> 00:00:30,990 +on its required execution environment. In complex + +11 +00:00:30,990 --> 00:00:33,680 +systems, interactions might become more important and + +12 +00:00:33,680 --> 00:00:36,220 +challenging than functionality. And this is why + +13 +00:00:36,220 --> 00:00:40,000 +connectors are very important architectural elements. A + +14 +00:00:40,000 --> 00:00:42,935 +software connector is an architectural building block + +15 +00:00:42,935 --> 00:00:46,990 +tasked with effecting and regulating interactions among + +16 +00:00:46,990 --> 00:00:50,980 +components. So basically, connectors typically provide application + +17 +00:00:50,980 --> 00:00:54,610 +independent interaction facilities. And it's worth noting here + +18 +00:00:54,610 --> 00:00:57,530 +that in many software systems, connectors might simply be + +19 +00:00:57,530 --> 00:01:01,140 +procedure calls or shared data accesses. So all constants + +20 +00:01:01,140 --> 00:01:03,589 +that we're familiar with. But consider that much more + +21 +00:01:03,589 --> 00:01:06,690 +sophisticated and complex connectors are also possible. And + +22 +00:01:06,690 --> 00:01:10,310 +components and connectors are composed in a specific way + +23 +00:01:10,310 --> 00:01:13,510 +in a given system architecture to accomplish that system's + +24 +00:01:13,510 --> 00:01:17,400 +objective And this is expressed through an architectural configuration. + +25 +00:01:17,400 --> 00:01:21,070 +More precisely, an architectural configuration, or topology, is a + +26 +00:01:21,070 --> 00:01:25,630 +set of specific associations between the components and connectors + +27 +00:01:25,630 --> 00:01:28,380 +of a software system's architecture. So now, let's look + +28 +00:01:28,380 --> 00:01:30,880 +at an example that brings all of this together. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/18 - Configuration Example - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/18 - Configuration Example - lang_en_vs5.srt new file mode 100644 index 0000000..775f11c --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/18 - Configuration Example - lang_en_vs5.srt @@ -0,0 +1,75 @@ +1 +00:00:00,180 --> 00:00:02,880 +What I'm showing here is what an architectural configuration of + +2 +00:00:02,880 --> 00:00:05,460 +a system might look like in practice. And as you + +3 +00:00:05,460 --> 00:00:08,560 +can see, the configuration includes a set of components, which + +4 +00:00:08,560 --> 00:00:12,200 +are these rectangles over here. The components have various kinds of + +5 +00:00:12,200 --> 00:00:15,460 +ports, which are the ones marked here on the components + +6 +00:00:15,460 --> 00:00:17,760 +with different graphical representations. And + +7 +00:00:17,760 --> 00:00:19,760 +the components communicate through various + +8 +00:00:19,760 --> 00:00:22,860 +types of connectors, which are the grey elements here which + +9 +00:00:22,860 --> 00:00:25,570 +as you can see are used to connect the different components. + +10 +00:00:25,570 --> 00:00:28,180 +And something else that you can notice by looking at + +11 +00:00:28,180 --> 00:00:30,720 +this configuration is the fact that you can also have + +12 +00:00:30,720 --> 00:00:34,980 +hierarchically decomposable components. For example, if you look at the strategy + +13 +00:00:34,980 --> 00:00:39,250 +analyzer component, you can see that it has three subcomponents: one, + +14 +00:00:39,250 --> 00:00:42,110 +two, and three and two internal connectors as part of + +15 +00:00:42,110 --> 00:00:44,832 +it. And it is worth recalling here that a component + +16 +00:00:44,832 --> 00:00:47,152 +diagram as we said when first discussed in UML in + +17 +00:00:47,152 --> 00:00:51,230 +the course, can also be used to represent an architectural configuration. + +18 +00:00:51,230 --> 00:00:52,920 +So sometimes you will see architectural + +19 +00:00:52,920 --> 00:00:56,250 +configurations represented as UML component diagrams. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/19 - Deployment Architectural Perspective - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/19 - Deployment Architectural Perspective - lang_en_vs5.srt new file mode 100644 index 0000000..1cc7d89 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/19 - Deployment Architectural Perspective - lang_en_vs5.srt @@ -0,0 +1,103 @@ +1 +00:00:00,180 --> 00:00:03,100 +A system cannot fulfill its purpose until it is + +2 +00:00:03,100 --> 00:00:06,727 +deployed. And deploying a system involves physically placing the + +3 +00:00:06,727 --> 00:00:09,960 +system's executable modules on the hardware devices on which + +4 +00:00:09,960 --> 00:00:12,490 +they are supposed to run. So when you do that, + +5 +00:00:12,490 --> 00:00:16,132 +you're basically mapping your components and connectors to specific + +6 +00:00:16,132 --> 00:00:19,810 +hardware elements. Here in this diagram, for instance, I'm + +7 +00:00:19,810 --> 00:00:22,160 +showing the same components that we saw in the + +8 +00:00:22,160 --> 00:00:25,400 +previous diagram, but we see them deployed on a laptop, + +9 +00:00:25,400 --> 00:00:28,620 +which is depicted here in this way, and on two + +10 +00:00:28,620 --> 00:00:32,820 +smartphones that are represented here, or PDAs, if you wish. + +11 +00:00:32,820 --> 00:00:34,730 +So why do we this, why do we create + +12 +00:00:34,730 --> 00:00:38,540 +a deployment perspective for our architecture? Well, because the deployment + +13 +00:00:38,540 --> 00:00:41,710 +view of an architecture can be critical in assessing whether + +14 +00:00:41,710 --> 00:00:44,920 +the system will be able to satisfy its requirement. Because + +15 +00:00:44,920 --> 00:00:47,860 +doing this mapping allows you to discover and assess other + +16 +00:00:47,860 --> 00:00:50,840 +characteristics of your system that you might not have considered + +17 +00:00:50,840 --> 00:00:53,440 +up to now. For instance, using a deployment view like this + +18 +00:00:53,440 --> 00:00:57,030 +one and knowing the characteristics of the hardware devices, one might + +19 +00:00:57,030 --> 00:01:00,056 +be able to assess the system in terms of available memory. + +20 +00:01:00,056 --> 00:01:02,610 +Is there going to be enough memory available to run the system, + +21 +00:01:02,610 --> 00:01:06,140 +for example, on this device? Power consumption. Is the power consumption + +22 +00:01:06,140 --> 00:01:09,270 +profile going to be larger than what the device can handle? + +23 +00:01:09,270 --> 00:01:12,580 +Or again the required network bandwidth. Does the system have enough + +24 +00:01:12,580 --> 00:01:16,170 +network bandwidth to enable the required interactions? And so on. So all + +25 +00:01:16,170 --> 00:01:19,140 +of these characteristics, all of these qualities, you can assess when + +26 +00:01:19,140 --> 00:01:22,730 +you do this final mapping of the components to the hardware elements. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/2 - Interview with Nenad Medvidovic - lang_en_vs6.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/2 - Interview with Nenad Medvidovic - lang_en_vs6.srt new file mode 100644 index 0000000..40fa57c --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/2 - Interview with Nenad Medvidovic - lang_en_vs6.srt @@ -0,0 +1,499 @@ +1 +00:00:00,220 --> 00:00:02,900 +Because the topic of today's lecture is software architecture, + +2 +00:00:02,900 --> 00:00:05,390 +it seemed appropriate to start the lesson by asking a + +3 +00:00:05,390 --> 00:00:08,960 +world expert on this topic, what is software architecture, and + +4 +00:00:08,960 --> 00:00:11,570 +why it is important. To do that, let's fly to + +5 +00:00:11,570 --> 00:00:14,910 +California, and more precisely, Los Angeles, and visit Professor + +6 +00:00:14,910 --> 00:00:19,540 +Nenad Medvidovic. Hi, I'm here visiting Professor Nenad Medvidovic from + +7 +00:00:19,540 --> 00:00:22,310 +the University of Southern California. And Neno is one of + +8 +00:00:22,310 --> 00:00:25,250 +the world experts in software architecture, actually one of the + +9 +00:00:25,250 --> 00:00:28,300 +authors of, of a recent book which is, sort of the + +10 +00:00:28,300 --> 00:00:31,660 +book in software architecture. What I would like to discuss with + +11 +00:00:31,660 --> 00:00:34,500 +Neno is the concept of software architecture and its importance. Because + +12 +00:00:34,500 --> 00:00:37,520 +people are very familiar with the idea and the cost of the + +13 +00:00:37,520 --> 00:00:41,240 +design. And software architecture is something is very related to that, + +14 +00:00:41,240 --> 00:00:43,690 +but is less known. So I would like for Nenad to + +15 +00:00:43,690 --> 00:00:46,350 +elaborate on that, and tell us why is it important to + +16 +00:00:46,350 --> 00:00:49,880 +focus also on this specific you know, architectural aspects of the software. + +17 +00:00:49,880 --> 00:00:50,380 +>> When you + +18 +00:00:50,380 --> 00:00:53,220 +build any software system, even a simple, relatively simple + +19 +00:00:53,220 --> 00:00:56,840 +one. You're going to go through, a process of making + +20 +00:00:56,840 --> 00:01:00,070 +many, many design decisions. Hundreds or thousands sometimes even tens + +21 +00:01:00,070 --> 00:01:03,140 +of thousands of design decisions, so any program that you + +22 +00:01:03,140 --> 00:01:06,090 +write at some point you get to deciding what + +23 +00:01:06,090 --> 00:01:09,385 +the interface of a particular method is going to be. + +24 +00:01:09,385 --> 00:01:12,170 +Are you're going to put in a parameter that is + +25 +00:01:12,170 --> 00:01:15,530 +an integer or a float. When you're writing your routine + +26 +00:01:15,530 --> 00:01:17,400 +about some sort you have to decide whether you're + +27 +00:01:17,400 --> 00:01:18,900 +going to use a static data structure or a + +28 +00:01:18,900 --> 00:01:22,410 +dynamic data structure. All these things are design decisions. + +29 +00:01:22,410 --> 00:01:25,770 +Many of them however, will typically, in the average + +30 +00:01:25,770 --> 00:01:29,030 +case, not really impact the success of your system + +31 +00:01:29,030 --> 00:01:31,640 +and the long term well-being of your system. But + +32 +00:01:31,640 --> 00:01:35,390 +typically the things that software engineers start struggling with + +33 +00:01:35,390 --> 00:01:40,760 +are other design decisions. Design decisions that are the equivalent + +34 +00:01:40,760 --> 00:01:42,080 +of load baring walls in a building + +35 +00:01:42,080 --> 00:01:42,660 +>> Mm hm + +36 +00:01:42,660 --> 00:01:43,950 +>> These are the things that, if you + +37 +00:01:43,950 --> 00:01:45,960 +don't get them right, or if you compromise + +38 +00:01:45,960 --> 00:01:50,190 +them, will in fact potentially impact how the + +39 +00:01:50,190 --> 00:01:54,300 +system operates. They might result in failures of different + +40 +00:01:54,300 --> 00:01:56,780 +kinds. They may result in a system that + +41 +00:01:56,780 --> 00:01:59,460 +is not easily maintainable and so forth. In + +42 +00:01:59,460 --> 00:02:01,680 +a sense, to make a long story short, + +43 +00:02:01,680 --> 00:02:05,888 +architectural design decisions are really the principle design decisions + +44 +00:02:05,888 --> 00:02:07,900 +in your system. These are the things that are + +45 +00:02:07,900 --> 00:02:10,550 +very important. All of the other design decisions you + +46 +00:02:10,550 --> 00:02:13,520 +could sort of tag with being important, but they're + +47 +00:02:13,520 --> 00:02:17,730 +sort of below this very important or highly important threshold. + +48 +00:02:17,730 --> 00:02:21,400 +>> So if you need to change a low level design decision, sometimes + +49 +00:02:21,400 --> 00:02:23,970 +it's kind of easy to do. It might change a little structure. Is it + +50 +00:02:23,970 --> 00:02:27,140 +the case that you know, being the architecture is sort of the pillar of + +51 +00:02:27,140 --> 00:02:29,020 +the software, is that going to be much + +52 +00:02:29,020 --> 00:02:32,380 +more difficult to change an architectural decision? + +53 +00:02:32,380 --> 00:02:34,400 +And architecture is deemed to be you know, + +54 +00:02:34,400 --> 00:02:36,120 +say if you start with the wrong architecture the + +55 +00:02:36,120 --> 00:02:39,510 +software is going to, you know, necessarily be unsuccessful. + +56 +00:02:39,510 --> 00:02:41,320 +Or you can also do something that is better. + +57 +00:02:41,320 --> 00:02:46,070 +>> A system could be successful and very poorly architected. Just + +58 +00:02:46,070 --> 00:02:50,630 +like a building or an airplane or a car, any other + +59 +00:02:50,630 --> 00:02:54,700 +engineering artifact could be successful but poorly architected. So success we + +60 +00:02:54,700 --> 00:02:57,440 +can separated from this, but the, the point that you make in + +61 +00:02:57,440 --> 00:03:00,530 +asking this question is an important one. The + +62 +00:03:00,530 --> 00:03:04,260 +non-architectural design decisions, should be on the + +63 +00:03:04,260 --> 00:03:06,250 +average, there are exceptions and we need to + +64 +00:03:06,250 --> 00:03:09,580 +acknowledge that there is no one size fits all + +65 +00:03:09,580 --> 00:03:11,640 +type of solution for anything in software engineering + +66 +00:03:11,640 --> 00:03:15,060 +really. But on the average, the non-architectural design decisions, + +67 +00:03:15,060 --> 00:03:17,650 +should be much easier to make. So the + +68 +00:03:17,650 --> 00:03:22,600 +scale of the consequences of making such a change. + +69 +00:03:22,600 --> 00:03:25,880 +Really can vary from very minor, highly localized + +70 +00:03:25,880 --> 00:03:29,670 +to very important and sometimes, even system wide. + +71 +00:03:29,670 --> 00:03:33,570 +>> To conclude, I just like to ask you about some concept that is + +72 +00:03:33,570 --> 00:03:35,110 +we here about a lot. Which is + +73 +00:03:35,110 --> 00:03:37,430 +architectural erosion. Since, we're talking about in with + +74 +00:03:37,430 --> 00:03:39,760 +fine architecture and software evolution. So, what is, + +75 +00:03:39,760 --> 00:03:42,090 +exactly, an architectural erosion and why does that + +76 +00:03:42,090 --> 00:03:47,600 +happen? So, to go back to our non software metaphors. Imagine you buy a car. + +77 +00:03:47,600 --> 00:03:49,810 +And your car has four wheels, it has a steering wheel, it has + +78 +00:03:49,810 --> 00:03:53,700 +a nice chassis, it looks pretty nice. At one point, you end up + +79 +00:03:53,700 --> 00:03:54,950 +replacing its 150 horsepower engine with + +80 +00:03:54,950 --> 00:03:56,800 +a 250 horsepower engine because that's what + +81 +00:03:56,800 --> 00:04:01,510 +you want. And you start putting a spoiler on the back of the car + +82 +00:04:01,510 --> 00:04:04,680 +and then you replace the headlights. And then you replace the side view + +83 +00:04:04,680 --> 00:04:08,000 +mirrors with smaller ones because you want your car to be more aerodynamic. + +84 +00:04:08,000 --> 00:04:10,620 +And then you start tinkering with other things, like you cut the, maybe + +85 +00:04:10,620 --> 00:04:13,380 +the roof of the car because you want to turn it into a convertible, + +86 +00:04:13,380 --> 00:04:15,990 +et cetera. And in the end, what you have is + +87 +00:04:15,990 --> 00:04:19,810 +a car that is still your car. Looks very different, It's + +88 +00:04:19,810 --> 00:04:23,650 +structural and behavioral properties are very different And, what you + +89 +00:04:23,650 --> 00:04:27,260 +might find is that the car doesn't handle nearly as well. + +90 +00:04:27,260 --> 00:04:29,670 +For example, in a very sharp turn it might not + +91 +00:04:29,670 --> 00:04:31,910 +be able to negotiate a steep hill as well. Because you + +92 +00:04:31,910 --> 00:04:35,760 +pretty much changed it all along the way. Architectural erosion in + +93 +00:04:35,760 --> 00:04:38,620 +the case of a software system is the exact same thing + +94 +00:04:38,620 --> 00:04:41,480 +with one huge caveat. Very few, if any of us, + +95 +00:04:41,480 --> 00:04:44,970 +will ever put a new engine into our car or tinker + +96 +00:04:44,970 --> 00:04:47,390 +with the structural soundness of the car by cutting off the + +97 +00:04:47,390 --> 00:04:50,260 +roof etc. In a software system we do it all the + +98 +00:04:50,260 --> 00:04:53,530 +time. We'll add a feature. We'll change one bit of the + +99 +00:04:53,530 --> 00:04:57,088 +user interface here. We'll port it to a new platform, some + +100 +00:04:57,088 --> 00:05:00,990 +kind of a, a mobile platform, for example. And pretty soon, + +101 +00:05:00,990 --> 00:05:03,750 +what you end up with is really a software system that, + +102 +00:05:03,750 --> 00:05:06,990 +that is maybe a distant relative of your original + +103 +00:05:06,990 --> 00:05:10,500 +system. It is a mutant in many ways, because often + +104 +00:05:10,500 --> 00:05:12,986 +times these little tinkerings happen on a one off + +105 +00:05:12,986 --> 00:05:15,610 +basis. There is no over-arching vision of how you should + +106 +00:05:15,610 --> 00:05:19,060 +do this. So, you are basically going through a + +107 +00:05:19,060 --> 00:05:21,980 +subsequent set of steps where you are making locally optimal + +108 +00:05:21,980 --> 00:05:25,240 +decisions for any one of these changes and what + +109 +00:05:25,240 --> 00:05:29,140 +you might end up finding is that the globally optimal + +110 +00:05:29,140 --> 00:05:32,100 +behavior of the system is badly compromised. The structural + +111 +00:05:32,100 --> 00:05:34,952 +soundness in a sense of the system badly compromised. + +112 +00:05:34,952 --> 00:05:38,510 +The non-functional properties of the system could be seriously + +113 +00:05:38,510 --> 00:05:42,390 +affected. This is how security flaws creep into systems. This + +114 +00:05:42,390 --> 00:05:44,250 +is how reliability flaws. This is how we use + +115 +00:05:44,250 --> 00:05:48,420 +the usability of a system often times suffers. And most + +116 +00:05:48,420 --> 00:05:50,920 +importantly for software engineers, the people who actually build the + +117 +00:05:50,920 --> 00:05:54,950 +software, the maintainability of the system becomes a huge problem. + +118 +00:05:54,950 --> 00:05:59,130 +Because now you're looking at this thing, it's got all these various appendages, + +119 +00:05:59,130 --> 00:06:03,170 +its original design has pretty badly eroded and yet somehow you have to + +120 +00:06:03,170 --> 00:06:06,850 +figure out how to keep fixing it. Making sure that it operates in + +121 +00:06:06,850 --> 00:06:11,380 +a continuous fashion because many of these systems live for 20, 30, 40 years. + +122 +00:06:11,380 --> 00:06:13,840 +>> Thank you so much for your insight; it is a perfect + +123 +00:06:13,840 --> 00:06:16,500 +introduction for our lesson. So we'll get to the lesson now. And. + +124 +00:06:16,500 --> 00:06:17,920 +>> Thank you very much. + +125 +00:06:17,920 --> 00:06:18,300 +>> Thank you. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/20 - Architectural Styles - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/20 - Architectural Styles - lang_en_vs5.srt new file mode 100644 index 0000000..b4ee115 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/20 - Architectural Styles - lang_en_vs5.srt @@ -0,0 +1,111 @@ +1 +00:00:00,210 --> 00:00:01,569 +The last topic I want to cover in + +2 +00:00:01,569 --> 00:00:04,939 +this lesson is architectural styles. So, let's see + +3 +00:00:04,939 --> 00:00:07,400 +what those architectural styles are. There are certain + +4 +00:00:07,400 --> 00:00:10,240 +design choices that when applied in a given context + +5 +00:00:10,240 --> 00:00:14,420 +regularly result in solutions with superior properties. What + +6 +00:00:14,420 --> 00:00:17,290 +this means is that, compared to other possible alternatives, + +7 +00:00:17,290 --> 00:00:20,952 +these solutions are more elegant, effective, efficient, dependable, + +8 +00:00:20,952 --> 00:00:25,560 +evolve-able, scale-able, and so on. Architectural styles capture exactly + +9 +00:00:25,560 --> 00:00:28,490 +these solutions. They capture idioms that we can + +10 +00:00:28,490 --> 00:00:30,870 +use when designing a system. For a more formal + +11 +00:00:30,870 --> 00:00:34,160 +definition, let's look how Mary Shaw and David Garlan + +12 +00:00:34,160 --> 00:00:37,480 +define a architectural style. They say that an architectural + +13 +00:00:37,480 --> 00:00:40,000 +style defines a family of systems in terms + +14 +00:00:40,000 --> 00:00:43,550 +of a pattern of structural organization; a vocabulary of + +15 +00:00:43,550 --> 00:00:47,880 +components and connectors and constraints on how these components + +16 +00:00:47,880 --> 00:00:50,620 +and connectors can be combined. So in summary we + +17 +00:00:50,620 --> 00:00:53,650 +can say that an architectural style is a named collection + +18 +00:00:53,650 --> 00:00:57,680 +of architectural design decisions applicable in a given context. And I + +19 +00:00:57,680 --> 00:01:00,100 +want to stress that it is important to study and + +20 +00:01:00,100 --> 00:01:04,670 +know these architectural styles for several reasons. Because knowing them allows + +21 +00:01:04,670 --> 00:01:07,660 +us to avoid reinventing the wheel. It also allows us + +22 +00:01:07,660 --> 00:01:10,330 +to choose the right solution to a known problem and in + +23 +00:01:10,330 --> 00:01:12,910 +some cases it even allows us to move on and + +24 +00:01:12,910 --> 00:01:16,400 +discover even more advanced styles if we know the basic ones. + +25 +00:01:16,400 --> 00:01:19,340 +So we should be familiar with architectural styles, what + +26 +00:01:19,340 --> 00:01:22,000 +they are, and in which context they work, and + +27 +00:01:22,000 --> 00:01:23,800 +in which context they do not work. So as + +28 +00:01:23,800 --> 00:01:26,090 +to be able to apply them in the right situations. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/21 - Types of Architectural Styles - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/21 - Types of Architectural Styles - lang_en_vs5.srt new file mode 100644 index 0000000..05011c7 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/21 - Types of Architectural Styles - lang_en_vs5.srt @@ -0,0 +1,239 @@ +1 +00:00:00,130 --> 00:00:02,410 +So what does it mean to know architectural styles? There + +2 +00:00:02,410 --> 00:00:06,390 +are many many, many architectural styles. So we cannot cover them + +3 +00:00:06,390 --> 00:00:08,730 +all here. What I want to do instead is, I want to + +4 +00:00:08,730 --> 00:00:10,960 +mention a few of those. And then I want to go in + +5 +00:00:10,960 --> 00:00:13,300 +more depth, on one of them. So the first item I + +6 +00:00:13,300 --> 00:00:17,420 +want to mention is pipes and filters. And pipes and filters indicate + +7 +00:00:17,420 --> 00:00:21,110 +an architectural style in which a chain of processing elements, which + +8 +00:00:21,110 --> 00:00:25,410 +can be processes, threads, co-routines, is arranged so that the output + +9 +00:00:25,410 --> 00:00:28,420 +of each element is the input of the next one + +10 +00:00:28,420 --> 00:00:31,840 +and usually with some buffering in between consecutive elements. A + +11 +00:00:31,840 --> 00:00:34,120 +typical example of this, if you're familiar with Unix are + +12 +00:00:34,120 --> 00:00:37,900 +Unix pipes, that you can use to concatenate Unix commands. + +13 +00:00:37,900 --> 00:00:40,310 +Another style I want to mention is the event driven + +14 +00:00:40,310 --> 00:00:43,540 +one. An event driven system typically consists of event + +15 +00:00:43,540 --> 00:00:46,590 +emittors, like the alarm over here, and event consumers, like + +16 +00:00:46,590 --> 00:00:50,720 +the fire truck, down here, and consumers are notified when events + +17 +00:00:50,720 --> 00:00:53,810 +of interest occurr and have the responsibility of reacting + +18 +00:00:53,810 --> 00:00:56,676 +to those events. A typical example will be a GUI, + +19 +00:00:56,676 --> 00:00:59,950 +in which widgets generate events and listeners listen to those + +20 +00:00:59,950 --> 00:01:02,550 +events and react to them. For example, they react to + +21 +00:01:02,550 --> 00:01:05,060 +the push of a button. A very commonly used + +22 +00:01:05,060 --> 00:01:09,250 +architectural style is Publish-subscribe, represented by the paper boy. Over + +23 +00:01:09,250 --> 00:01:12,420 +here. And this is an architectural style in which senders + +24 +00:01:12,420 --> 00:01:15,870 +of messages, they're called publishers, do not send messages directly + +25 +00:01:15,870 --> 00:01:19,330 +to specific recievers. Instead, they publish messages with one + +26 +00:01:19,330 --> 00:01:22,530 +or more associated texts without knowledge of who will + +27 +00:01:22,530 --> 00:01:26,810 +receive such messages. Similarly subscribers will express interest in + +28 +00:01:26,810 --> 00:01:29,340 +one or more tags. And will only receive messages of + +29 +00:01:29,340 --> 00:01:32,095 +interest according to such tags. A typical example of + +30 +00:01:32,095 --> 00:01:35,240 +a publish-subscribe system, will be Twitter. And I'm pretty + +31 +00:01:35,240 --> 00:01:36,835 +sure that most of you are familiar with the + +32 +00:01:36,835 --> 00:01:41,170 +client-server architecture. In which computers in a network, assume one + +33 +00:01:41,170 --> 00:01:43,930 +of two roles. The server provides the resources and + +34 +00:01:43,930 --> 00:01:47,630 +functionality. And the client initiates contact with the server, + +35 +00:01:47,630 --> 00:01:50,920 +and requests the use of those resources and functionality. + +36 +00:01:50,920 --> 00:01:53,340 +Also in this case, a typical example would be + +37 +00:01:53,340 --> 00:01:56,470 +email, in which an email server provides email storage + +38 +00:01:56,470 --> 00:01:59,390 +and management capabilities, and an email client will use + +39 +00:01:59,390 --> 00:02:02,580 +those capabilities. You may also be familiar with peer-to-peer, + +40 +00:02:02,580 --> 00:02:06,530 +or P2P, systems. A P2P system is a type + +41 +00:02:06,530 --> 00:02:10,850 +of decentralized and distributed network system in which individual nodes + +42 +00:02:10,850 --> 00:02:14,220 +in the network, that are called peers, act as independent + +43 +00:02:14,220 --> 00:02:17,940 +agents that are both suppliers and consumers of resources. This + +44 +00:02:17,940 --> 00:02:20,700 +is in contrast to the centralized client-server model, where client + +45 +00:02:20,700 --> 00:02:23,660 +nodes interact with the central authority. And I'm not going to + +46 +00:02:23,660 --> 00:02:26,030 +say anything more about peer-to-peer, because I'm going to show you + +47 +00:02:26,030 --> 00:02:28,940 +two examples, of peer-to-peer systems in the rest of the + +48 +00:02:28,940 --> 00:02:32,040 +lesson. And you probably have at least heard of rest. + +49 +00:02:32,040 --> 00:02:33,990 +Which in this case is not an invitation to + +50 +00:02:33,990 --> 00:02:36,970 +relax as the graphic might indicate. But rather stands for + +51 +00:02:36,970 --> 00:02:41,400 +Representational State Transfer. REST is a hybrid architectural style + +52 +00:02:41,400 --> 00:02:45,150 +for distributed hypermedia systems, that is derived from several other + +53 +00:02:45,150 --> 00:02:48,210 +network based architectural styles. And that is characterized by + +54 +00:02:48,210 --> 00:02:51,970 +uniform connector interface, and even if I'm not going to say + +55 +00:02:51,970 --> 00:02:54,230 +anything else about the rest, I wanted to mention + +56 +00:02:54,230 --> 00:02:57,440 +it, because it is an extremely well known architectural style. + +57 +00:02:57,440 --> 00:02:59,300 +And the reason for this is that REST is + +58 +00:02:59,300 --> 00:03:03,310 +very widely used, because it is basically the architectural style + +59 +00:03:03,310 --> 00:03:06,050 +that governs the world wide web. So we use it + +60 +00:03:06,050 --> 00:03:08,330 +all the time when we browse the internet, for instance. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/22 - Architectural Styles Quiz - lang_en_vs4.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/22 - Architectural Styles Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..2e8c051 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/22 - Architectural Styles Quiz - lang_en_vs4.srt @@ -0,0 +1,27 @@ +1 +00:00:00,090 --> 00:00:02,630 +Consider now the following architectural styles + +2 +00:00:02,630 --> 00:00:04,356 +that we just saw: pipes and filters, + +3 +00:00:04,356 --> 00:00:09,310 +event-driven, publish-subscribe, client-server, peer-to-peer, and rest. + +4 +00:00:09,310 --> 00:00:11,150 +I'm showing you here, a list of + +5 +00:00:11,150 --> 00:00:15,220 +four different systems, and I would like for you to mark here which + +6 +00:00:15,220 --> 00:00:18,750 +architectural style, or styles, characterize Each of + +7 +00:00:18,750 --> 00:00:21,510 +these systems. Again, mark all that apply. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/23 - Architectural Styles Quiz Solution - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/23 - Architectural Styles Quiz Solution - lang_en_vs5.srt new file mode 100644 index 0000000..d48320b --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/23 - Architectural Styles Quiz Solution - lang_en_vs5.srt @@ -0,0 +1,79 @@ +1 +00:00:00,150 --> 00:00:02,680 +Okay, let's start with the Android Operating System. The Android + +2 +00:00:02,680 --> 00:00:07,170 +system, heavily based on the generation and handling of events, + +3 +00:00:07,170 --> 00:00:10,640 +so it is mostly an event driven system. However, it + +4 +00:00:10,640 --> 00:00:13,870 +also has some elements of publish, subscribe, in the way + +5 +00:00:13,870 --> 00:00:17,480 +elements in the system can register for elements of interest. + +6 +00:00:17,480 --> 00:00:20,570 +So we can mark both styles here. So what about + +7 +00:00:20,570 --> 00:00:23,449 +Skype? We haven't discussed Skype yet. So here we probably + +8 +00:00:23,449 --> 00:00:25,019 +had to take a little bit of a wild guess. + +9 +00:00:25,019 --> 00:00:27,068 +But as we will see in more detail in the + +10 +00:00:27,068 --> 00:00:29,736 +rest of the lesson. Skype is mainly a peer to + +11 +00:00:29,736 --> 00:00:34,035 +peer architecture, with some minimal elements of a client server + +12 +00:00:34,035 --> 00:00:37,770 +architecture. For example, when you start Skype and sign in + +13 +00:00:37,770 --> 00:00:40,420 +to a conceptually centralized server. So let's move to the + +14 +00:00:40,420 --> 00:00:42,930 +World Wide Web. As we just discussed, the Word Wide + +15 +00:00:42,930 --> 00:00:46,255 +Web is based on a rest architecture. And because rest + +16 +00:00:46,255 --> 00:00:50,170 +style, is a hybrid derived from other architectural styles, including the + +17 +00:00:50,170 --> 00:00:53,960 +client server architectural styles. Both of those styles apply here. + +18 +00:00:53,960 --> 00:00:57,465 +And finally Dropbox is by and large, a client server + +19 +00:00:57,465 --> 00:01:01,904 +architecture. As conceptually, we upload our documents to a Dropbox + +20 +00:01:01,904 --> 00:01:05,370 +central server, and get the files from the same server. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/24 - P2P Architectures - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/24 - P2P Architectures - lang_en_vs5.srt new file mode 100644 index 0000000..927c773 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/24 - P2P Architectures - lang_en_vs5.srt @@ -0,0 +1,39 @@ +1 +00:00:00,170 --> 00:00:02,110 +We're not going to be able to study indepth + +2 +00:00:02,110 --> 00:00:05,590 +any of the architectural styles that we just discussed. However, I + +3 +00:00:05,590 --> 00:00:08,790 +want to at least discuss two representative examples of P2P + +4 +00:00:08,790 --> 00:00:12,100 +architectures. Because, these are systems that you probably used, or at + +5 +00:00:12,100 --> 00:00:14,090 +least, you used one of them. And, they will allow + +6 +00:00:14,090 --> 00:00:17,590 +me to highlight some interesting points. So, as we just mentioned, + +7 +00:00:17,590 --> 00:00:22,450 +P2P systems are decentralized resource sharing and discovery systems. And the + +8 +00:00:22,450 --> 00:00:25,370 +two systems that I want to discuss, and that are representative + +9 +00:00:25,370 --> 00:00:29,630 +of this kind of architectures, are Napster and Skype. And you may or + +10 +00:00:29,630 --> 00:00:32,920 +may not be familiar with Napster, but I'm pretty sure that you know Skype. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/25 - Napster Example - lang_en_vs4.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/25 - Napster Example - lang_en_vs4.srt new file mode 100644 index 0000000..d3ab75b --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/25 - Napster Example - lang_en_vs4.srt @@ -0,0 +1,231 @@ +1 +00:00:00,160 --> 00:00:03,160 +So let's start by considering Napster. In it's first + +2 +00:00:03,160 --> 00:00:07,210 +incarnation, Napster was a peer-to-peer file sharing system. And + +3 +00:00:07,210 --> 00:00:10,200 +it was mostly used, actually, to illegally share mp3s. + +4 +00:00:10,200 --> 00:00:12,630 +Which is also why it got sued and later + +5 +00:00:12,630 --> 00:00:16,129 +on, it basically ceased operations. But nevertheless, I think + +6 +00:00:16,129 --> 00:00:19,710 +Napster is an interesting example of mixed architecture. And + +7 +00:00:19,710 --> 00:00:22,020 +I'm going to illustrate the way Napster works by showing + +8 +00:00:22,020 --> 00:00:25,820 +you, here, the basic configuration of Napster and the interactions + +9 +00:00:25,820 --> 00:00:28,950 +between its elements. So let's look at how such interaction + +10 +00:00:28,950 --> 00:00:32,250 +can take place for the three peers shown here. And + +11 +00:00:32,250 --> 00:00:34,430 +in this case Peer A and B are the only + +12 +00:00:34,430 --> 00:00:37,290 +ones really involved in the action. So let's look at + +13 +00:00:37,290 --> 00:00:40,700 +a typical sequence of events for the Napster system. We + +14 +00:00:40,700 --> 00:00:44,340 +have Peer A that will start by registering, here, with + +15 +00:00:44,340 --> 00:00:47,530 +the content directory. Peer B will also register with the + +16 +00:00:47,530 --> 00:00:50,970 +content directory. And when these two peers register, the content directory + +17 +00:00:50,970 --> 00:00:54,370 +will know what kind of content they can provide. Later on, + +18 +00:00:54,370 --> 00:00:57,660 +Peer A will request a song. And one first observation that + +19 +00:00:57,660 --> 00:01:00,550 +we can make, based on this interaction, is the fact that, + +20 +00:01:00,550 --> 00:01:03,900 +up to now, this is a purely client-server system. This is + +21 +00:01:03,900 --> 00:01:06,530 +the client. This is the client. And this is the server. + +22 +00:01:06,530 --> 00:01:10,320 +And the interaction is a typical client-server interaction. But now we're + +23 +00:01:10,320 --> 00:01:12,410 +at the point in which things start to change a little + +24 +00:01:12,410 --> 00:01:16,008 +bit. At this point, after Peer A has requested the song, + +25 +00:01:16,008 --> 00:01:18,820 +the peer and content directory will look up its + +26 +00:01:18,820 --> 00:01:22,730 +gigantic index and will see that Peer B actually has + +27 +00:01:22,730 --> 00:01:24,850 +the song that Peer A requested. So it will + +28 +00:01:24,850 --> 00:01:27,690 +send to Peer A a handle that Peer A can + +29 +00:01:27,690 --> 00:01:31,052 +use to connect directly to Peer B. So this + +30 +00:01:31,052 --> 00:01:34,540 +is where the system is no longer a client-server system. + +31 +00:01:34,540 --> 00:01:37,890 +Because at this point, the two peers are connected directly. + +32 +00:01:37,890 --> 00:01:41,000 +So at this point, we have a peer-to-peer interaction. And, + +33 +00:01:41,000 --> 00:01:43,770 +after getting the request from Peer A, then Peer B + +34 +00:01:43,770 --> 00:01:47,170 +will start sending the content to Peer A. And I said + +35 +00:01:47,170 --> 00:01:50,660 +earlier that one of the useful things about representing an + +36 +00:01:50,660 --> 00:01:52,440 +architecture and interaction within an + +37 +00:01:52,440 --> 00:01:54,580 +architecture graphically, is the fact that + +38 +00:01:54,580 --> 00:01:57,550 +it allows you to spot possible problems. And in this + +39 +00:01:57,550 --> 00:02:00,666 +case, by representing the Napster architecture in this way, and by + +40 +00:02:00,666 --> 00:02:03,300 +studying how things work, we can see that there's an + +41 +00:02:03,300 --> 00:02:06,010 +issue with the architecture of Napster that will not make this + +42 +00:02:06,010 --> 00:02:10,020 +architecture scale. As some of you might have already noticed, this peer + +43 +00:02:10,020 --> 00:02:13,720 +and content directory is a single point of failure, and is very + +44 +00:02:13,720 --> 00:02:17,230 +likely to cause problems when the number of peers grows too large. + +45 +00:02:17,230 --> 00:02:19,890 +Because at that point, there are going to be too many requests to + +46 +00:02:19,890 --> 00:02:22,840 +the peer and content directory, and the peer and content directory is + +47 +00:02:22,840 --> 00:02:25,460 +unlikely to be able to keep up with all the requests. So + +48 +00:02:25,460 --> 00:02:27,840 +some changes in the architecture will have to be made. In the + +49 +00:02:27,840 --> 00:02:31,310 +case of Napster, we didn't see this problem occurring because, as I said + +50 +00:02:31,310 --> 00:02:34,420 +earlier, Napster got sued and ceased operation before the problem + +51 +00:02:34,420 --> 00:02:37,650 +actually manifested. Now looking at the system for an architecture-style + +52 +00:02:37,650 --> 00:02:40,560 +perspective, we can see that Napster was a hybrid architecture + +53 +00:02:40,560 --> 00:02:43,920 +with both client-server and peer-to-peer elements. And something I would + +54 +00:02:43,920 --> 00:02:45,870 +like to stress here, is that this is not at + +55 +00:02:45,870 --> 00:02:49,400 +all uncommon. So in real world nontrivial architectures, it is + +56 +00:02:49,400 --> 00:02:52,470 +very common to see multiple styles used in the same + +57 +00:02:52,470 --> 00:02:56,209 +system. The next system that we will consider, Skype, is instead, + +58 +00:02:56,209 --> 00:02:59,885 +an example of a well-designed, almost purely peer-to-peer system. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/26 - Skype Example - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/26 - Skype Example - lang_en_vs5.srt new file mode 100644 index 0000000..2118c73 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/26 - Skype Example - lang_en_vs5.srt @@ -0,0 +1,287 @@ +1 +00:00:00,220 --> 00:00:03,040 +So even if you're too young to have used Napster, + +2 +00:00:03,040 --> 00:00:06,150 +I'm pretty sure that most of you know and use Skype, + +3 +00:00:06,150 --> 00:00:10,180 +a Voice Over IP and instant messaging service. Many of + +4 +00:00:10,180 --> 00:00:13,790 +you, however, probably don't know how Skype works. To understand that, + +5 +00:00:13,790 --> 00:00:16,360 +let's have a look at Skype's architecture, which I'm sketching + +6 +00:00:16,360 --> 00:00:19,890 +here, and which is a peer-to-peer architecture with a small twist. + +7 +00:00:19,890 --> 00:00:22,300 +So first of all, by looking at the architecture we can + +8 +00:00:22,300 --> 00:00:25,600 +see that whereas Napster was a client-server system with an element + +9 +00:00:25,600 --> 00:00:29,960 +of peer-to-peer, Skype is a much more decentralized system. Why + +10 +00:00:29,960 --> 00:00:31,940 +is that? Well, if we look here, we can see + +11 +00:00:31,940 --> 00:00:34,720 +that there is a login server -- this node over + +12 +00:00:34,720 --> 00:00:38,670 +here -- and that means that every Skype user has to register + +13 +00:00:38,670 --> 00:00:42,000 +with this centralized service. But that's the only interaction of + +14 +00:00:42,000 --> 00:00:44,930 +this kind within Skype. After you log in, all you + +15 +00:00:44,930 --> 00:00:47,580 +get is a connection through a super node like this + +16 +00:00:47,580 --> 00:00:50,760 +one. So, what are super nodes? Super nodes are highly reliable + +17 +00:00:50,760 --> 00:00:54,680 +nodes with high bandwidth that are not behind a firewall + +18 +00:00:54,680 --> 00:00:58,180 +and that runs Skype regularly, which means that nodes that shut + +19 +00:00:58,180 --> 00:01:01,540 +down Skype occasionally will not qualify as super nodes. And one + +20 +00:01:01,540 --> 00:01:04,239 +interesting thing about super nodes is that they're not owned by + +21 +00:01:04,239 --> 00:01:07,990 +Skype. They're just regular nodes that get promoted by Skype to + +22 +00:01:07,990 --> 00:01:11,500 +super nodes, and that know about each other. So basically Skype + +23 +00:01:11,500 --> 00:01:13,710 +has an algorithm that looks at the nodes in the system + +24 +00:01:13,710 --> 00:01:15,880 +and decides whether a node can be a super node or + +25 +00:01:15,880 --> 00:01:18,932 +not based on its characteristics. So now that we've discussed + +26 +00:01:18,932 --> 00:01:22,040 +super nodes, let's see what will happen if peer two wanted + +27 +00:01:22,040 --> 00:01:25,091 +to communicate with peer three. So let's represent this by + +28 +00:01:25,091 --> 00:01:27,956 +creating a dashed line between peer two and peer three. In + +29 +00:01:27,956 --> 00:01:30,980 +this case, peer two will contact this super node, which + +30 +00:01:30,980 --> 00:01:33,750 +is super node A. And super node A, based on its + +31 +00:01:33,750 --> 00:01:36,570 +knowledge of the Skype network and the position of the super + +32 +00:01:36,570 --> 00:01:40,930 +nodes, will contact and route the communication through super node C, + +33 +00:01:40,930 --> 00:01:44,100 +which will in turn route the communication to peer three. + +34 +00:01:44,100 --> 00:01:46,620 +And in that way peer two and peer three will be + +35 +00:01:46,620 --> 00:01:50,740 +able to communicate with each other. And this will happen just + +36 +00:01:50,740 --> 00:01:53,970 +as if peer two and peer three were connected directly, as + +37 +00:01:53,970 --> 00:01:57,760 +peers, even though the communication goes through two super nodes. Another + +38 +00:01:57,760 --> 00:02:00,470 +thing that is important to know about the behavior of Skype + +39 +00:02:00,470 --> 00:02:03,760 +is that, if the link between super nodes A and C + +40 +00:02:03,760 --> 00:02:05,950 +were to go down. So let's assume that there is a + +41 +00:02:05,950 --> 00:02:10,840 +problem with this link, then Skype will automatically, or automagically + +42 +00:02:10,840 --> 00:02:14,550 +reroute the communication through super node B, which will in + +43 +00:02:14,550 --> 00:02:17,950 +turn reroute it super node C, which will again reroute + +44 +00:02:17,950 --> 00:02:20,020 +to peer three. So peer two and three will still + +45 +00:02:20,020 --> 00:02:22,550 +be connected, but this time they will be going through + +46 +00:02:22,550 --> 00:02:25,620 +three super nodes. And just in case you wondered, this + +47 +00:02:25,620 --> 00:02:28,620 +is exactly what happens when you are talking over Skype. + +48 +00:02:28,620 --> 00:02:31,790 +The quality of the communication degrades, and you are reconnected. + +49 +00:02:31,790 --> 00:02:34,880 +So there is this rerouting going on through different nodes. So + +50 +00:02:34,880 --> 00:02:37,640 +although this architecture is more effective than the Napster's one, it + +51 +00:02:37,640 --> 00:02:40,640 +is not without problems. For example, you might remember that a + +52 +00:02:40,640 --> 00:02:44,640 +few years ago, Skype went down for about 36 hours. And + +53 +00:02:44,640 --> 00:02:47,880 +later on it was discovered that the cause was the algorithm + +54 +00:02:47,880 --> 00:02:51,460 +used by Skype to determine which nodes could be super nodes. + +55 +00:02:51,460 --> 00:02:54,330 +And remember, as I said, that one requirement for these nodes + +56 +00:02:54,330 --> 00:02:57,130 +is that have to up all the time. So what happened + +57 +00:02:57,130 --> 00:03:00,420 +is most of the super nodes were running on Windows machines, + +58 +00:03:00,420 --> 00:03:03,820 +and Microsoft pushed a critical patch that required a reboot to + +59 +00:03:03,820 --> 00:03:06,860 +be installed. So a large number of machines, and therefore a + +60 +00:03:06,860 --> 00:03:10,150 +large number of super nodes were down roughly at the same + +61 +00:03:10,150 --> 00:03:13,980 +time throughout the globe. And Skype's algorithm for determining super nodes + +62 +00:03:13,980 --> 00:03:17,230 +didn't have enough nodes to work with. So the whole system + +63 +00:03:17,230 --> 00:03:19,790 +crashed and burned. So the message I want to give here, + +64 +00:03:19,790 --> 00:03:22,340 +is that when you have a large peer to peer distributed + +65 +00:03:22,340 --> 00:03:24,650 +system, such as this one, such as Skype, + +66 +00:03:24,650 --> 00:03:27,200 +these kind of perfect storms can happen. Because you + +67 +00:03:27,200 --> 00:03:29,560 +are not really in control. Because the control + +68 +00:03:29,560 --> 00:03:33,170 +is distributed. So the algorithms become more complex. So + +69 +00:03:33,170 --> 00:03:35,140 +to wrap up our Skype example, in case + +70 +00:03:35,140 --> 00:03:37,280 +you are interested, Skype then fixed the issue by + +71 +00:03:37,280 --> 00:03:39,950 +changing the algorithm for identifying super nodes. And + +72 +00:03:39,950 --> 00:03:44,084 +more recently actually, Skype ditched peer-to-peer super nodes altogether. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/27 - Takeaway Message - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/27 - Takeaway Message - lang_en_vs5.srt new file mode 100644 index 0000000..9cd15c3 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/27 - Takeaway Message - lang_en_vs5.srt @@ -0,0 +1,131 @@ +1 +00:00:00,100 --> 00:00:02,620 +And I want to conclude this lesson with three takeaway + +2 +00:00:02,620 --> 00:00:06,190 +messages. The first one is that having an effective architecture is + +3 +00:00:06,190 --> 00:00:09,450 +fundamental in a software project. Or as I say here, + +4 +00:00:09,450 --> 00:00:13,050 +a great architecture is a ticket to a successful project. To + +5 +00:00:13,050 --> 00:00:15,290 +put it in a different way, although a great architecture + +6 +00:00:15,290 --> 00:00:17,940 +does not guarantee that your project will be successful, having a + +7 +00:00:17,940 --> 00:00:21,930 +poor architecture will make it much more difficult for your project + +8 +00:00:21,930 --> 00:00:25,280 +to be successful. The second message is that an architecture cannot + +9 +00:00:25,280 --> 00:00:28,120 +come about in a vacuum. You need to understand + +10 +00:00:28,120 --> 00:00:30,550 +the domain of the problem that you're trying to solve + +11 +00:00:30,550 --> 00:00:33,480 +in order to define an architectural solution that fits the + +12 +00:00:33,480 --> 00:00:37,220 +characteristics of the problem. So a great architecture reflects a + +13 +00:00:37,220 --> 00:00:40,500 +deep understanding of the problem domain. And finally, a great + +14 +00:00:40,500 --> 00:00:44,630 +architecture is likely to combine aspects of several simpler architectures. + +15 +00:00:44,630 --> 00:00:47,880 +It is typical for engineers to see problems that are + +16 +00:00:47,880 --> 00:00:50,590 +new, but such that parts of the problems have already + +17 +00:00:50,590 --> 00:00:53,540 +been solved by someone else. An effective engineer should + +18 +00:00:53,540 --> 00:00:56,270 +therefore, first of all, know what is out there, + +19 +00:00:56,270 --> 00:00:59,760 +know the solution space. Second, an engineer should understand + +20 +00:00:59,760 --> 00:01:02,420 +what has worked well and what has failed miserably in + +21 +00:01:02,420 --> 00:01:05,870 +similar occasions in the past. And finally, an effective + +22 +00:01:05,870 --> 00:01:10,100 +engineer should be able to suitably combine existing solutions appropriately + +23 +00:01:10,100 --> 00:01:12,870 +to come up with an effective overall solution for + +24 +00:01:12,870 --> 00:01:15,750 +the specific problem at hand. And this is just as + +25 +00:01:15,750 --> 00:01:18,960 +true in the context of software architectures. When defining a software + +26 +00:01:18,960 --> 00:01:22,330 +architecture, you should innovate only as much as you need to and + +27 +00:01:22,330 --> 00:01:24,850 +reuse as much as you can. As we said early in the + +28 +00:01:24,850 --> 00:01:27,770 +lesson, by doing so, that is, by innovating only as much as + +29 +00:01:27,770 --> 00:01:30,100 +you need to and reusing as much as you can, you will + +30 +00:01:30,100 --> 00:01:32,960 +be able to avoid reinventing the wheel. You will be able to + +31 +00:01:32,960 --> 00:01:37,320 +choose the right solution to known problems. And identify suitable solutions for + +32 +00:01:37,320 --> 00:01:40,925 +new problems. So ultimately, you will be able to realize an effective + +33 +00:01:40,925 --> 00:01:44,080 +software architecture that will help the success of your project. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/3 - What is Software Architecture? - lang_en_vs6.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/3 - What is Software Architecture? - lang_en_vs6.srt new file mode 100644 index 0000000..8689e43 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/3 - What is Software Architecture? - lang_en_vs6.srt @@ -0,0 +1,127 @@ +1 +00:00:00,140 --> 00:00:02,460 +After this interesting conversation with Neno, let me start + +2 +00:00:02,460 --> 00:00:06,060 +the lesson by defining what a software architecture is. + +3 +00:00:06,060 --> 00:00:07,600 +And to do that, I'm going to use two + +4 +00:00:07,600 --> 00:00:11,030 +seminal definitions. The first one is from Dewayne Perry + +5 +00:00:11,030 --> 00:00:13,990 +and Alex Wolf. And they define a software architecture + +6 +00:00:13,990 --> 00:00:17,940 +as elements, form and rationale. In this definition, the + +7 +00:00:17,940 --> 00:00:21,300 +elements are the what, which means the processes, data, + +8 +00:00:21,300 --> 00:00:25,430 +and connectors that compose a software architecture. The form + +9 +00:00:25,430 --> 00:00:27,780 +is the how, the set of properties of + +10 +00:00:27,780 --> 00:00:32,030 +in relationships among these elements. And, finally, the rationale + +11 +00:00:32,030 --> 00:00:35,390 +is the why, the justification for the elements and + +12 +00:00:35,390 --> 00:00:38,440 +their relationships. The second definition I want to use + +13 +00:00:38,440 --> 00:00:40,710 +is from Mary Shaw and David Garland. And + +14 +00:00:40,710 --> 00:00:43,480 +they defined a software architecture as a level of + +15 +00:00:43,480 --> 00:00:47,300 +design that involves four main things, a description of + +16 +00:00:47,300 --> 00:00:50,860 +elements from which these systems are built, the interactions + +17 +00:00:50,860 --> 00:00:54,800 +among those elements, the patterns that guide their composition, and + +18 +00:00:54,800 --> 00:00:58,320 +finally, the constraints on these patterns. As you can see, these + +19 +00:00:58,320 --> 00:01:01,420 +definitions are fairly similar and there are many more alternative + +20 +00:01:01,420 --> 00:01:04,870 +definitions of software architecture. In fact, if we try to search + +21 +00:01:04,870 --> 00:01:08,540 +the term software architecture, we get over two million entries. + +22 +00:01:08,540 --> 00:01:10,670 +And if we look at the images in the results of + +23 +00:01:10,670 --> 00:01:13,110 +the search this is what we get. And I like this + +24 +00:01:13,110 --> 00:01:16,120 +sort of graphical depiction because it gives you a clear idea + +25 +00:01:16,120 --> 00:01:19,300 +the software architecture are prevalent concept, given the number of + +26 +00:01:19,300 --> 00:01:22,600 +results. But they also show you clearly, that software architecture are + +27 +00:01:22,600 --> 00:01:25,550 +complex entities, if you look at some of these pictures. + +28 +00:01:25,550 --> 00:01:28,930 +And ultimately, they show that software architecture are presented in all + +29 +00:01:28,930 --> 00:01:31,700 +kinds of ways including in 3D, if you look at this + +30 +00:01:31,700 --> 00:01:34,970 +picture. We cannot clearly cover all of these definitions in one + +31 +00:01:34,970 --> 00:01:37,340 +lesson. So what I will do instead, is to introduce + +32 +00:01:37,340 --> 00:01:40,750 +a very general definition that encompasses most of the existing ones. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/4 - General Definition of SWA - lang_en_vs6.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/4 - General Definition of SWA - lang_en_vs6.srt new file mode 100644 index 0000000..13042a7 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/4 - General Definition of SWA - lang_en_vs6.srt @@ -0,0 +1,131 @@ +1 +00:00:00,110 --> 00:00:03,240 +I'm going to define a software systems architecture as + +2 +00:00:03,240 --> 00:00:07,660 +the set of principal design decisions about the system. Where + +3 +00:00:07,660 --> 00:00:10,950 +principal here, implies a degree of importance, that grants + +4 +00:00:10,950 --> 00:00:14,810 +a design decision architectural status. And the point here, as + +5 +00:00:14,810 --> 00:00:17,060 +we discussed with Neno early on, is that when + +6 +00:00:17,060 --> 00:00:20,210 +building a system, we make tons of design decisions, and + +7 +00:00:20,210 --> 00:00:22,470 +most of them do not affect the architecture of + +8 +00:00:22,470 --> 00:00:25,270 +the system. For example, the effect of choosing a for + +9 +00:00:25,270 --> 00:00:27,640 +loop, instead of a while loop, in the code, or the + +10 +00:00:27,640 --> 00:00:30,140 +fact of deciding that we are going to use data structure A + +11 +00:00:30,140 --> 00:00:33,620 +instead of data structure B. Some decisions however, do affect the + +12 +00:00:33,620 --> 00:00:37,470 +architecture of the system. And in some cases the distinction between these + +13 +00:00:37,470 --> 00:00:40,600 +two kinds of design decisions is clear. In some other cases + +14 +00:00:40,600 --> 00:00:43,340 +it is much fuzzier and it depends on the context. The + +15 +00:00:43,340 --> 00:00:46,000 +bottom line here, is that if you believe that something is + +16 +00:00:46,000 --> 00:00:50,380 +an important design decision, that becomes an architectural decision. That is a + +17 +00:00:50,380 --> 00:00:53,960 +decision that impacts a system's architecture. In this spirit, + +18 +00:00:53,960 --> 00:00:56,650 +we can see a software architecture as the blueprint + +19 +00:00:56,650 --> 00:00:58,390 +for a software system, that we can use to + +20 +00:00:58,390 --> 00:01:01,320 +construct and evolve the system. And the key point + +21 +00:01:01,320 --> 00:01:05,300 +about software architecture is that this blueprint encompasses every + +22 +00:01:05,300 --> 00:01:08,600 +facet of the system under development. It encompasses its + +23 +00:01:08,600 --> 00:01:11,540 +structure, of course, but not only. It also involves + +24 +00:01:11,540 --> 00:01:15,420 +the behavior of the system, the interactions within the system, + +25 +00:01:15,420 --> 00:01:18,880 +and the non-functional properties of the system. And we will see + +26 +00:01:18,880 --> 00:01:21,960 +how this happens in the rest of the lesson. Another important + +27 +00:01:21,960 --> 00:01:25,590 +point about software architecture is that there is a temporal aspect + +28 +00:01:25,590 --> 00:01:27,570 +to it. And the point here is that you don't build the + +29 +00:01:27,570 --> 00:01:30,660 +software architecture in a single shot, but you do it iteratively, + +30 +00:01:30,660 --> 00:01:34,100 +over time. So, basically, you go from having no architecture to + +31 +00:01:34,100 --> 00:01:37,330 +your final architecture. So, at any point in time, there is + +32 +00:01:37,330 --> 00:01:40,550 +a software architecture, but it will change over time. And this happens + +33 +00:01:40,550 --> 00:01:44,780 +because design decisions are made, unmade and changed over a system's lifetime. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/5 - Prescriptive vs Descriptive Architecture - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/5 - Prescriptive vs Descriptive Architecture - lang_en_vs5.srt new file mode 100644 index 0000000..11ecd46 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/5 - Prescriptive vs Descriptive Architecture - lang_en_vs5.srt @@ -0,0 +1,51 @@ +1 +00:00:00,120 --> 00:00:02,200 +We can look at the software architecture from two + +2 +00:00:02,200 --> 00:00:07,120 +main standpoints. There are prescriptive and descriptive software architectures. + +3 +00:00:07,120 --> 00:00:09,900 +So what does that mean? A prescriptive architecture captures + +4 +00:00:09,900 --> 00:00:12,620 +the design decisions that are made prior to the + +5 +00:00:12,620 --> 00:00:15,398 +system's construction. This is what we normally call the + +6 +00:00:15,398 --> 00:00:18,280 +as-conceived software architecture. Conversely, + +7 +00:00:18,280 --> 00:00:20,550 +a descriptive architecture describes how + +8 +00:00:20,550 --> 00:00:23,010 +the system has actually been built. So it's based + +9 +00:00:23,010 --> 00:00:25,860 +on observing the system as it is and extracting + +10 +00:00:25,860 --> 00:00:28,200 +the architecture from the observation. This is what we call + +11 +00:00:28,200 --> 00:00:31,890 +the as-implemented software architecture. And one key point here is + +12 +00:00:31,890 --> 00:00:35,780 +that often, these two architectures, the prescriptive and the descriptive + +13 +00:00:35,780 --> 00:00:39,290 +architectures end up being different. So let's see why that happens. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/6 - Architectural Evolution - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/6 - Architectural Evolution - lang_en_vs5.srt new file mode 100644 index 0000000..edcf77e --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/6 - Architectural Evolution - lang_en_vs5.srt @@ -0,0 +1,115 @@ +1 +00:00:00,090 --> 00:00:02,810 +To do that let's look at how architectural evolution + +2 +00:00:02,810 --> 00:00:06,880 +occurs in practice. Ideally when a system evolves, its prescriptive + +3 +00:00:06,880 --> 00:00:09,340 +architecture should be modified first. Just like when you + +4 +00:00:09,340 --> 00:00:12,170 +modify a building. You change the blueprint and then you + +5 +00:00:12,170 --> 00:00:13,940 +change the actual building. You don't go the other + +6 +00:00:13,940 --> 00:00:17,820 +way around. In software, unfortunately this rarely ever happens in + +7 +00:00:17,820 --> 00:00:21,706 +practice. In practice the system, and therefore it's descriptive + +8 +00:00:21,706 --> 00:00:25,150 +architecture are often directly modified. Like in this case that + +9 +00:00:25,150 --> 00:00:27,870 +I'm showing here. So what happens is that the architecture + +10 +00:00:27,870 --> 00:00:32,259 +as conceived does not change. Whereas the architecture as implemented, does + +11 +00:00:32,259 --> 00:00:35,600 +change. And therefore these two things start diverging. And this really + +12 +00:00:35,600 --> 00:00:38,720 +happens for a number of reasons. So I'm just going to list + +13 +00:00:38,720 --> 00:00:41,740 +a few of those reasons here. In some cases it + +14 +00:00:41,740 --> 00:00:45,620 +just happens for plain sloppiness. I need to make this modification + +15 +00:00:45,620 --> 00:00:47,290 +and I don't really want to go back and look at + +16 +00:00:47,290 --> 00:00:50,610 +the prescriptive architecture modified. I'm just going to make the change, and + +17 +00:00:50,610 --> 00:00:53,800 +maybe I'll fix the description later. And then you never really get + +18 +00:00:53,800 --> 00:00:56,950 +to it. In other cases you do this because of the perception + +19 +00:00:56,950 --> 00:01:00,290 +of short deadlines. If you have to do something by this afternoon, + +20 +00:01:00,290 --> 00:01:01,300 +you're not going through a four + +21 +00:01:01,300 --> 00:01:03,410 +month software architecture review, you normally just + +22 +00:01:03,410 --> 00:01:06,460 +get to it, and do it. In some cases a prescriptive architecture + +23 +00:01:06,460 --> 00:01:09,510 +is not even present, so there's a lack of documentation. So in these + +24 +00:01:09,510 --> 00:01:12,450 +cases, clearly, you cannot go and modify something that does not even + +25 +00:01:12,450 --> 00:01:15,880 +exist, and so you jump directly to the code and start modifying that. + +26 +00:01:15,880 --> 00:01:18,280 +And as I said there's many, many more + +27 +00:01:18,280 --> 00:01:21,080 +other reasons why that happen. But important point here is + +28 +00:01:21,080 --> 00:01:23,770 +that it does happen and it does happen often + +29 +00:01:23,770 --> 00:01:27,250 +and the result is that prescriptive and descriptive architectures diverge. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/7 - Architectural Degradation - lang_en_vs6.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/7 - Architectural Degradation - lang_en_vs6.srt new file mode 100644 index 0000000..2313f82 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/7 - Architectural Degradation - lang_en_vs6.srt @@ -0,0 +1,131 @@ +1 +00:00:00,150 --> 00:00:02,790 +And there are two important and related concepts that + +2 +00:00:02,790 --> 00:00:04,790 +have to do with the way software architecture + +3 +00:00:04,790 --> 00:00:08,109 +evolves. The first one is Architectural Drift, which is + +4 +00:00:08,109 --> 00:00:12,140 +the introduction of architectural design decisions that are orthogonal to + +5 +00:00:12,140 --> 00:00:15,870 +a system's prescriptive architecture. That is, they're not included + +6 +00:00:15,870 --> 00:00:20,080 +in, encompassed by, or implied by the prescriptive architecture. + +7 +00:00:20,080 --> 00:00:22,300 +And the result of Architectural Drift is that you + +8 +00:00:22,300 --> 00:00:25,220 +start from a clean architecture, like the one that I'm + +9 +00:00:25,220 --> 00:00:28,830 +showing here, and then you start adding pieces without following a clear plan. + +10 +00:00:28,830 --> 00:00:32,229 +Like, for example, here, we add an additional room here, but we don't really + +11 +00:00:32,229 --> 00:00:34,380 +do it in the right way so we need to add something else + +12 +00:00:34,380 --> 00:00:37,090 +to keep it stable. And then maybe we want some more room so we + +13 +00:00:37,090 --> 00:00:40,310 +add a tent. And then another side of the house, it doesn't really + +14 +00:00:40,310 --> 00:00:43,540 +follow the same architecture but it doesn't matter, we just put it there because + +15 +00:00:43,540 --> 00:00:46,690 +we want to expand. And maybe then we want to put something classic + +16 +00:00:46,690 --> 00:00:48,210 +there, even though it doesn't really fit + +17 +00:00:48,210 --> 00:00:50,520 +the overall design and the overall architecture. + +18 +00:00:50,520 --> 00:00:52,160 +So I think you get my point, the fact + +19 +00:00:52,160 --> 00:00:56,210 +that the architecture then becomes unnecessarily complex, hard to understand + +20 +00:00:56,210 --> 00:00:58,410 +and ultimately awkward, just like the one that I'm + +21 +00:00:58,410 --> 00:01:00,880 +showing here, that goes from the original building into this + +22 +00:01:00,880 --> 00:01:04,870 +final monstrosity. The second concept is Architectural Erosion, which + +23 +00:01:04,870 --> 00:01:08,560 +is the introduction of architectural design decisions that violate a + +24 +00:01:08,560 --> 00:01:12,070 +system prescriptive architecture. So in this case, that we were + +25 +00:01:12,070 --> 00:01:14,070 +introducing decisions that were orthogonal, + +26 +00:01:14,070 --> 00:01:15,580 +here, were introducing this decisions + +27 +00:01:15,580 --> 00:01:17,410 +that don't comply with the prescriptive + +28 +00:01:17,410 --> 00:01:20,140 +architecture. And the result of Architectural Erosion + +29 +00:01:20,140 --> 00:01:22,590 +is typically a poor architecture an + +30 +00:01:22,590 --> 00:01:24,550 +architecture that is going to have problems in + +31 +00:01:24,550 --> 00:01:27,040 +the future. So both Architectural Drift + +32 +00:01:27,040 --> 00:01:29,640 +and Architectural Erosion take you away in + +33 +00:01:29,640 --> 00:01:32,940 +different ways from what you think your software architecture is or should be. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/8 - Architectural Recovery - lang_en_vs4.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/8 - Architectural Recovery - lang_en_vs4.srt new file mode 100644 index 0000000..6104ae0 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/8 - Architectural Recovery - lang_en_vs4.srt @@ -0,0 +1,67 @@ +1 +00:00:00,180 --> 00:00:03,560 +And sometimes, architectural drift and erosion gets you so + +2 +00:00:03,560 --> 00:00:06,450 +far away from the point where your software architecture should + +3 +00:00:06,450 --> 00:00:10,476 +be, that your architecture is completely degraded. And at this + +4 +00:00:10,476 --> 00:00:13,290 +point, you have two main options. The first option is + +5 +00:00:13,290 --> 00:00:17,140 +to keep frantically tweaking the code. And this normally leads + +6 +00:00:17,140 --> 00:00:20,370 +to disaster. Why? Because you only make things worse. You + +7 +00:00:20,370 --> 00:00:22,570 +don't know exactly what you are changing and therefore, you're + +8 +00:00:22,570 --> 00:00:25,570 +basically stabbing in the dark, trying to fix your system. + +9 +00:00:25,570 --> 00:00:27,580 +The other possiblity is that you can try to + +10 +00:00:27,580 --> 00:00:29,830 +determine the software system architecture + +11 +00:00:29,830 --> 00:00:31,710 +from its implementation level artifacts, + +12 +00:00:31,710 --> 00:00:34,520 +so you try to derive what the architecture is + +13 +00:00:34,520 --> 00:00:36,610 +and try to fix it, once you have derived the + +14 +00:00:36,610 --> 00:00:39,266 +architecture. And this is what is normally called, architectural + +15 +00:00:39,266 --> 00:00:44,210 +recovery, determining a software architecture from an implementation and fixing + +16 +00:00:44,210 --> 00:00:46,410 +it. And as you can imagine, this is normally + +17 +00:00:46,410 --> 00:00:49,330 +a more recommended way to go than the first solution. diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/9 - Architectural Recovery Quiz - lang_en_vs4.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/9 - Architectural Recovery Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..0750374 --- /dev/null +++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/9 - Architectural Recovery Quiz - lang_en_vs4.srt @@ -0,0 +1,35 @@ +1 +00:00:00,120 --> 00:00:03,070 +Now that we discussed some important concepts about + +2 +00:00:03,070 --> 00:00:05,060 +software architectures, I would like for you to + +3 +00:00:05,060 --> 00:00:07,290 +tell me which of the following sentences is + +4 +00:00:07,290 --> 00:00:11,420 +true. Prescriptive architecture and descriptive architecture are typically the + +5 +00:00:11,420 --> 00:00:15,970 +same. Architectural drift results in unnecessarily complex architectures. + +6 +00:00:15,970 --> 00:00:20,320 +Architectural erosion is less problematic than architectural drift. And + +7 +00:00:20,320 --> 00:00:22,660 +the best way to improve a degraded architecture, + +8 +00:00:22,660 --> 00:00:25,250 +is to keep fixing the code until the system + +9 +00:00:25,250 --> 00:00:29,270 +starts looking and behaving as expected. Which of these sentences is true? diff --git a/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/1 - Introduction - lang_en.srt b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/1 - Introduction - lang_en.srt new file mode 100644 index 0000000..f6386ed --- /dev/null +++ b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/1 - Introduction - lang_en.srt @@ -0,0 +1,88 @@ +1 +00:00:00,430 --> 00:00:05,994 +Hello and welcome to a tale of analysis and design, featuring + +2 +00:00:05,994 --> 00:00:10,809 +Spencer Rugaber, as the librarian, and Alex Orso, + +3 +00:00:10,809 --> 00:00:15,779 +as the software engineer. [SOUND] + +4 +00:00:15,779 --> 00:00:21,520 +>> Hi! I'm here waiting for Spencer, my librarian friend. He needs some + +5 +00:00:21,520 --> 00:00:25,470 +help developing an information system for a library. So I asked him to write + +6 +00:00:25,470 --> 00:00:29,669 +down the requirements for the libra... Oh, [SOUND] that must be him. + +7 +00:00:29,669 --> 00:00:30,850 +>> Hello Alex. + +8 +00:00:30,850 --> 00:00:32,470 +>> Hey Spencer. How's it going? + +9 +00:00:32,470 --> 00:00:34,690 +>> Good. Did you get those requirements I emailed you? + +10 +00:00:34,690 --> 00:00:36,890 +>> Oh, you emailed them. Now let me check. + +11 +00:00:36,890 --> 00:00:38,780 +And, by the way, get some coffee for you here. + +12 +00:00:38,780 --> 00:00:39,880 +>> Thank you very much. + +13 +00:00:41,840 --> 00:00:46,790 +>> Oh yeah. They're right here. Let me see. Oh, good. Oh, yeah, + +14 +00:00:46,790 --> 00:00:50,580 +good. We have, what we need. So the, the way I like to do + +15 +00:00:50,580 --> 00:00:52,500 +this is. I like to start by + +16 +00:00:52,500 --> 00:00:55,430 +looking at the requirements and identifying the nouns + +17 +00:00:55,430 --> 00:00:57,530 +in the requirements, because those tell us + +18 +00:00:57,530 --> 00:01:00,080 +the kind of the relevant elements in the, + +19 +00:01:00,080 --> 00:01:03,360 +in the requirements. So if you don't mind we can start looking at those and + +20 +00:01:03,360 --> 00:01:07,070 +you can tell me you know, whether the ones that I am identifying make sense or not. + +21 +00:01:07,070 --> 00:01:07,920 +>> Sounds good. + +22 +00:01:07,920 --> 00:01:08,500 +>> All right. + diff --git a/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/10 - Debriefing - lang_en.srt b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/10 - Debriefing - lang_en.srt new file mode 100644 index 0000000..cc76d09 --- /dev/null +++ b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/10 - Debriefing - lang_en.srt @@ -0,0 +1,104 @@ +1 +00:00:00,210 --> 00:00:02,200 +>> So Spencer, now that we went through + +2 +00:00:02,200 --> 00:00:05,340 +this process and, I'd just like to hear + +3 +00:00:05,340 --> 00:00:07,090 +whether you enjoyed it, whether you think it + +4 +00:00:07,090 --> 00:00:09,640 +was useful. What are your thoughts? + +5 +00:00:09,640 --> 00:00:11,661 +>> Well, ti was very interesting. I not only + +6 +00:00:11,661 --> 00:00:16,541 +learned something about computers and about how you design information systems + +7 +00:00:16,541 --> 00:00:19,713 +in UML, but I, it was interesting. I also learned something + +8 +00:00:19,713 --> 00:00:25,290 +interesting about the library. And things that, that I knew but + +9 +00:00:25,290 --> 00:00:27,920 +I never really, explicitly written down. + +10 +00:00:27,920 --> 00:00:28,099 +>> Uh-huh. + +11 +00:00:28,099 --> 00:00:32,280 +>> Came up during the course of doing this. And I think I now + +12 +00:00:32,280 --> 00:00:35,800 +much better understand what this information system that you're + +13 +00:00:35,800 --> 00:00:38,590 +going to build for us, is really all about. + +14 +00:00:38,590 --> 00:00:40,480 +>> Okay, well, I mean, I'm very happy that you say + +15 +00:00:40,480 --> 00:00:43,040 +that, because I really believe that, you know, doing this kind + +16 +00:00:43,040 --> 00:00:46,870 +of analysis and design exercises really helps you figuring out whether + +17 +00:00:46,870 --> 00:00:50,480 +there's any issues with the requirements. So for example, you can find + +18 +00:00:50,480 --> 00:00:53,580 +out whether there's any missing information, or maybe conflicting + +19 +00:00:53,580 --> 00:00:56,820 +information. And I think that's exactly what happened today. + +20 +00:00:56,820 --> 00:01:01,120 +So I'm very glad to hear that it worked for you. That you enjoyed it. I hope you + +21 +00:01:01,120 --> 00:01:03,690 +enjoyed it as well. And I strongly encourage you + +22 +00:01:03,690 --> 00:01:06,000 +to do this kind of exercises for different kinds + +23 +00:01:06,000 --> 00:01:08,630 +of systems. So as you can become more familiar + +24 +00:01:08,630 --> 00:01:12,410 +with analysis and design techniques. So, any final thoughts? + +25 +00:01:12,410 --> 00:01:15,440 +>> I look forward to receiving your delivered software. + +26 +00:01:15,440 --> 00:01:16,440 +>> All right. Will do. + diff --git a/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/2 - Analyzing Requirements - lang_en.srt b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/2 - Analyzing Requirements - lang_en.srt new file mode 100644 index 0000000..909fb2d --- /dev/null +++ b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/2 - Analyzing Requirements - lang_en.srt @@ -0,0 +1,579 @@ +1 +00:00:00,220 --> 00:00:04,900 +Okay so let me start underlining these nouns, and I'll start + +2 +00:00:04,900 --> 00:00:07,810 +identifying the ones that are relevant, and I'll ask you some + +3 +00:00:07,810 --> 00:00:10,550 +questions or you can ask me questions if + +4 +00:00:10,550 --> 00:00:14,666 +you see something that doesn't make sense to you. Good enough. + +5 +00:00:14,666 --> 00:00:17,650 +>> okay, let's see, patron. It seems to + +6 +00:00:17,650 --> 00:00:19,670 +me that patron is definitely an important entity. + +7 +00:00:19,670 --> 00:00:20,808 +>> That's, that's what its all about. + +8 +00:00:20,808 --> 00:00:23,270 +>> Okay, all right, so actually, the way + +9 +00:00:23,270 --> 00:00:25,750 +I'm going to do this, I'm going to take all these relevant + +10 +00:00:25,750 --> 00:00:28,610 +entities and I'm going to start putting them into what I call a class + +11 +00:00:28,610 --> 00:00:32,450 +diagram. So you don't really need to know what that is exactly, but imagine + +12 +00:00:32,450 --> 00:00:37,150 +this being a, a diagram in which I'm drawing, I represent in all development + +13 +00:00:37,150 --> 00:00:42,260 +items as rectangles with a given name and, and then later on some attributes. + +14 +00:00:42,260 --> 00:00:42,660 +>> Okay. + +15 +00:00:42,660 --> 00:00:44,055 +>> Okay, and I'm, I'm just going to put + +16 +00:00:44,055 --> 00:00:45,600 +them there. So I'm going to start with patron. + +17 +00:00:45,600 --> 00:00:48,420 +I'm going to create one class for the + +18 +00:00:48,420 --> 00:00:50,250 +patron. I'm going to give it the name patron. + +19 +00:00:51,380 --> 00:00:54,120 +And by the way, assuming that you'd probably figure out, it's important that we + +20 +00:00:54,120 --> 00:00:57,430 +represent, we use the right names so that it's clear when we're looking at + +21 +00:00:57,430 --> 00:01:00,790 +the class diagram what we're referring to, so I'll just use the, the nouns + +22 +00:01:00,790 --> 00:01:06,520 +themselves as names. Okay, library card seems to be also a relevant element. + +23 +00:01:06,520 --> 00:01:08,072 +>> Every patron has a library card. + +24 +00:01:08,072 --> 00:01:09,530 +>> All right, perfect, so we'll just + +25 +00:01:09,530 --> 00:01:12,880 +create a library card here. And let's see. + +26 +00:01:12,880 --> 00:01:16,530 +As, as long as they're in the system. And I saw that there's a system + +27 +00:01:16,530 --> 00:01:19,000 +here, this concept of system, this concept + +28 +00:01:19,000 --> 00:01:22,076 +of library. And based on my experience, normally, + +29 +00:01:22,076 --> 00:01:26,574 +those are kind of in an overarching themes. So this is really what we are + +30 +00:01:26,574 --> 00:01:28,597 +modeling. So the only + +31 +00:01:28,597 --> 00:01:30,297 +thing that will make a difference is + +32 +00:01:30,297 --> 00:01:34,120 +if there were more than one library or more than one system. Is that the case? + +33 +00:01:34,120 --> 00:01:36,740 +>> We just want one system for our one library + +34 +00:01:36,740 --> 00:01:38,770 +>> Okay so, in this case I won't even represent + +35 +00:01:38,770 --> 00:01:41,540 +those because basically what I'm representing is the system and + +36 +00:01:41,540 --> 00:01:41,990 +the library. + +37 +00:01:41,990 --> 00:01:42,740 +>> I understand, I understand. + +38 +00:01:42,740 --> 00:01:44,420 + +39 +00:01:44,420 --> 00:01:48,350 +Okay and then, oh name, address and phone + +40 +00:01:48,350 --> 00:01:51,510 +number are interesting because these are important entities, + +41 +00:01:51,510 --> 00:01:53,180 +but this seems like, you know, they're not + +42 +00:01:53,180 --> 00:01:56,550 +entities in themselves, so they're more attributes + +43 +00:01:56,550 --> 00:01:58,070 +of something else. I would imagine that + +44 +00:01:58,070 --> 00:02:00,080 +this is the way you identify, or these + +45 +00:02:00,080 --> 00:02:01,860 +are elements that are important for the patron? + +46 +00:02:01,860 --> 00:02:04,880 +>> That's what we take down when we issue the cards. + +47 +00:02:04,880 --> 00:02:06,800 +>> Okay. Perfect. So, I'm going to + +48 +00:02:06,800 --> 00:02:09,710 +take those and make those attributes of the patron, which means + +49 +00:02:09,710 --> 00:02:12,350 +that I'm going to take the class that I created before, and I'm + +50 +00:02:12,350 --> 00:02:16,430 +just going to write them down here so that they're represented and, + +51 +00:02:16,430 --> 00:02:19,360 +and we know that these are kind of what characterizes the patron. + +52 +00:02:19,360 --> 00:02:20,070 +>> Gotcha. + +53 +00:02:20,070 --> 00:02:25,540 +>> Okay? And then, I guess similar consideration for the library + +54 +00:02:25,540 --> 00:02:28,750 +card number. So this is to be associated with the library card? + +55 +00:02:28,750 --> 00:02:29,902 +>> It's printed right on it. + +56 +00:02:29,902 --> 00:02:32,180 +>> All right, so we'll put this as + +57 +00:02:32,180 --> 00:02:38,130 +an attribute of the library card, then. And then, in addition, at any particular point + +58 +00:02:38,130 --> 00:02:43,630 +in time. Okay, so time seems to be a relevant entity right, + +59 +00:02:43,630 --> 00:02:47,880 +because time seems to occur several times in this description. For example, I + +60 +00:02:47,880 --> 00:02:53,940 +think you guys keep track of how long a book has been loaned, right? + +61 +00:02:53,940 --> 00:02:54,300 +>> Right. + +62 +00:02:54,300 --> 00:02:57,270 +>> And there's some time associated also here. + +63 +00:02:57,270 --> 00:02:58,380 +>> And a children's age. + +64 +00:02:58,380 --> 00:02:59,760 +>> Oh yeah. The children's age here that + +65 +00:02:59,760 --> 00:03:02,200 +I didn't see before. Yeah. So, what + +66 +00:03:02,200 --> 00:03:03,800 +I'm going to do, I'm going to represent this in + +67 +00:03:03,800 --> 00:03:05,520 +a sort of generic way, as a date. + +68 +00:03:05,520 --> 00:03:06,520 +>> Okay. + +69 +00:03:06,520 --> 00:03:08,380 +>> These are kind of, kind of classes, utility + +70 +00:03:08,380 --> 00:03:10,880 +classes we call them, that are normally in every system. + +71 +00:03:10,880 --> 00:03:10,970 +>> Okay. + +72 +00:03:10,970 --> 00:03:13,060 +>> So I'm just going to put it down here + +73 +00:03:13,060 --> 00:03:14,940 +as a utility class that will be used + +74 +00:03:14,940 --> 00:03:18,780 +by different elements in the diagram. Okay, so + +75 +00:03:18,780 --> 00:03:23,070 +I want to calculate the items. So the items also + +76 +00:03:23,070 --> 00:03:25,230 +I mean I for what I know about libraries they + +77 +00:03:25,230 --> 00:03:28,490 +seem to be pretty relevant elements, right? So these are all + +78 +00:03:28,490 --> 00:03:31,305 +>> This is what we check out, this is what we're for. + +79 +00:03:31,305 --> 00:03:34,459 +>> Okay, so then items definitely will become a + +80 +00:03:34,459 --> 00:03:37,349 +class, and then we have a due. Oh there's also + +81 +00:03:37,349 --> 00:03:39,730 +this concept of fines. I guess that seems to be + +82 +00:03:39,730 --> 00:03:42,330 +important. Right? You guys give fines to people who are late. + +83 +00:03:42,330 --> 00:03:42,700 +>> Right, right. + +84 +00:03:42,700 --> 00:03:49,160 +>> Right, collect fines and so on. So we create a fine class down here and + +85 +00:03:49,160 --> 00:03:54,150 +the children. So children are special customers, right? It's + +86 +00:03:55,240 --> 00:03:56,890 +their age makes a difference? Is that the way it works? + +87 +00:03:56,890 --> 00:03:58,950 +>> Right. They, they can only check out a few books. + +88 +00:03:58,950 --> 00:04:01,410 +>> Okay. So I'll create them a special + +89 +00:04:01,410 --> 00:04:03,170 +kind of case, a special kind of customer so + +90 +00:04:03,170 --> 00:04:06,000 +I just create here a class for children. And + +91 +00:04:06,000 --> 00:04:08,682 +I can see that they're categorized by their age. + +92 +00:04:08,682 --> 00:04:09,340 +>> Right. + +93 +00:04:09,340 --> 00:04:13,160 +>> So I'll just put the age here as an attribute of the child. + +94 +00:04:14,220 --> 00:04:15,712 +And, okay, so the next one is + +95 +00:04:15,712 --> 00:04:19,653 +restriction. And restriction is kind of tricky because just + +96 +00:04:19,653 --> 00:04:22,010 +to be sort of a general concept. I mean, + +97 +00:04:22,010 --> 00:04:24,915 +in a sense, all of those are restrictions, right? + +98 +00:04:24,915 --> 00:04:28,250 +>> Right, this is just another one of these requirements. + +99 +00:04:28,250 --> 00:04:31,180 +>> Oh, okay, so, so we don't need to represent it explicitly, right? + +100 +00:04:31,180 --> 00:04:31,430 +>> Right, right. + +101 +00:04:31,430 --> 00:04:34,390 +>> It's just telling us how the children, yeah, okay, right; this is + +102 +00:04:34,390 --> 00:04:39,151 +just another requirement, so I just won't consider that for now. And oh, + +103 +00:04:39,151 --> 00:04:43,444 +I see that these books and audio video materials, I guess these + +104 +00:04:43,444 --> 00:04:48,902 +are things that the patrons can check out, right? + +105 +00:04:48,902 --> 00:04:50,725 +>> Those are some of the items, right. + +106 +00:04:50,725 --> 00:04:53,770 +>> There are two + +107 +00:04:53,770 --> 00:04:56,380 +more down here, right? Reference books and magazines? + +108 +00:04:56,380 --> 00:04:57,990 +>> But, they can't be checked + +109 +00:04:57,990 --> 00:04:59,270 +out, but they're definitely in the library. + +110 +00:04:59,270 --> 00:05:01,338 +>> Okay, so then I'm going to represent all of those + +111 +00:05:01,338 --> 00:05:04,180 +actually, now. So, I'm going to have books, I'm going to have audio + +112 +00:05:04,180 --> 00:05:07,990 +video materials, reference books, and magazines. And + +113 +00:05:07,990 --> 00:05:12,150 +I'm just going to have those as classes. Then, + +114 +00:05:12,150 --> 00:05:14,060 +okay here we have week, and we + +115 +00:05:14,060 --> 00:05:16,630 +already represented this general concept of time, so + +116 +00:05:16,630 --> 00:05:23,270 +week will be represented by the date class as well. And oh, I see best sellers. + +117 +00:05:23,270 --> 00:05:27,520 +So best sellers are also, I guess, items that can be checked out, right? + +118 +00:05:27,520 --> 00:05:28,150 +>> Right. + +119 +00:05:28,150 --> 00:05:29,330 +>> Okay, so I'll + +120 +00:05:29,330 --> 00:05:32,900 +just represent those as a class as well and an additional item that + +121 +00:05:32,900 --> 00:05:38,480 +is relevant for the library. And the limit, this is also a time limit, right? + +122 +00:05:38,480 --> 00:05:39,150 +>> Right. + +123 +00:05:39,150 --> 00:05:41,500 +>> So it can also be represented with a, with a class. + +124 +00:05:43,860 --> 00:05:47,380 +Oh, here we have cents, and for cents, same consideration that made + +125 +00:05:47,380 --> 00:05:50,430 +for time. This is kind of the money, is a general concept + +126 +00:05:50,430 --> 00:05:54,240 +that in all currency, many, in many IT systems. So, I'm, I'm + +127 +00:05:54,240 --> 00:05:57,430 +going to just have a money class here, which is another utility class. + +128 +00:05:57,430 --> 00:05:57,740 +>> Okay + +129 +00:05:57,740 --> 00:06:04,000 +>> Okay, and, oh, here I have value, so value is a property. + +130 +00:06:04,000 --> 00:06:09,320 +Let me look again at the requirement. Oh, it's the value of the item. So value + +131 +00:06:09,320 --> 00:06:11,450 +I'm going to put in the item as an attribute. Okay? + +132 +00:06:11,450 --> 00:06:13,120 +>> Okay. That's how much it cost us. + +133 +00:06:13,120 --> 00:06:14,090 +>> Okay. Perfect. + +134 +00:06:14,090 --> 00:06:18,400 +>> Seems like we got them all. Right? Anything I forgot? + +135 +00:06:18,400 --> 00:06:19,640 +>> That looks like it. + +136 +00:06:19,640 --> 00:06:22,580 +>> Okay, so this one, what I'd like to do. We have a kind of + +137 +00:06:22,580 --> 00:06:26,890 +a first take, first cut at the class diagram. I'd like to kind of + +138 +00:06:26,890 --> 00:06:31,480 +move to that and go through the different classes with you. And I'll ask + +139 +00:06:31,480 --> 00:06:33,440 +you some questions again. And you can + +140 +00:06:33,440 --> 00:06:34,510 +tell me whether there is something that + +141 +00:06:34,510 --> 00:06:36,894 +jumps at you that's not right. And + +142 +00:06:36,894 --> 00:06:38,930 +then we're going to try to refine that. + +143 +00:06:38,930 --> 00:06:39,180 +>> Okay + +144 +00:06:39,180 --> 00:06:39,510 +>> Okay. + +145 +00:06:39,510 --> 00:06:39,800 +>> Sounds good. + diff --git a/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/3 - Refining Classes and Attributes - lang_en.srt b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/3 - Refining Classes and Attributes - lang_en.srt new file mode 100644 index 0000000..271c2fd --- /dev/null +++ b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/3 - Refining Classes and Attributes - lang_en.srt @@ -0,0 +1,535 @@ +1 +00:00:00,880 --> 00:00:03,920 +Okay, so this is our first, class diagram. + +2 +00:00:03,920 --> 00:00:06,260 +>> So, let me ask you something about. + +3 +00:00:06,260 --> 00:00:06,520 +>> Okay. + +4 +00:00:06,520 --> 00:00:08,930 +>> What we've done so far. I also sent, in what + +5 +00:00:08,930 --> 00:00:14,490 +I sent you, I also had some stories about how the actual + +6 +00:00:14,490 --> 00:00:16,400 +>> Library is used. You asked me to do + +7 +00:00:16,400 --> 00:00:18,950 +that and are we going to take, use that here? + +8 +00:00:20,160 --> 00:00:23,300 +>> Glad you asked actually. yeah. Those are, you know, what we call use + +9 +00:00:23,300 --> 00:00:25,940 +cases, or what we will use as scenarios kind of things that we will + +10 +00:00:25,940 --> 00:00:28,340 +use to derive use cases. And they're also a very good + +11 +00:00:28,340 --> 00:00:31,450 +way of extracting requirements. We're not going to look at them right + +12 +00:00:31,450 --> 00:00:33,890 +now because now, because we're more working on kind of the static + +13 +00:00:33,890 --> 00:00:37,860 +structure of the system. But after we're done with the class diagram, + +14 +00:00:37,860 --> 00:00:40,700 +you know, we will do it at a different time. But + +15 +00:00:40,700 --> 00:00:43,410 +we're going to use those to see how the + +16 +00:00:43,410 --> 00:00:45,850 +libraries actually use them, and see whether we can get more + +17 +00:00:45,850 --> 00:00:49,000 +information that we can use to refine our requirements based on that. + +18 +00:00:49,000 --> 00:00:49,770 +>> Okay. + +19 +00:00:49,770 --> 00:00:51,020 +>> Okay, + +20 +00:00:51,020 --> 00:00:52,940 +So, for now, we'll just focus in on the, + +21 +00:00:52,940 --> 00:00:54,630 +structure, but, just so you know, I'm, + +22 +00:00:54,630 --> 00:00:55,870 +I'm glad you sent them, because they were going + +23 +00:00:55,870 --> 00:00:57,380 +very useful as well. + +24 +00:00:59,410 --> 00:01:00,840 +Okay. So let's see. Well, first of all, let + +25 +00:01:00,840 --> 00:01:03,030 +me, seems like that this is already pretty crowded, + +26 +00:01:03,030 --> 00:01:06,770 +right? We have a number of, classes. So let's + +27 +00:01:06,770 --> 00:01:10,580 +see if there's, some class that may be superfluous and + +28 +00:01:10,580 --> 00:01:13,310 +we can model in a different way. So, for + +29 +00:01:13,310 --> 00:01:16,360 +example, you, while, while thinking of this I was thinking, + +30 +00:01:16,360 --> 00:01:19,450 +the library card, it doesn't really contain much + +31 +00:01:19,450 --> 00:01:22,736 +information, right? So is it basically just the number? + +32 +00:01:22,736 --> 00:01:23,948 + +33 +00:01:23,948 --> 00:01:30,760 +The card has a number on it. We have a separate vendor that does that for us so. + +34 +00:01:30,760 --> 00:01:30,810 +>> Oh. + +35 +00:01:30,810 --> 00:01:33,270 +>> We don't need, it doesn't need to be part of this system, + +36 +00:01:33,270 --> 00:01:35,450 +we just have to make sure that every patron has a library card. + +37 +00:01:35,450 --> 00:01:37,670 +>> Okay, so basically for you, in a sense, the library + +38 +00:01:37,670 --> 00:01:41,560 +card is just an ID that gets associated with a patron. + +39 +00:01:41,560 --> 00:01:42,120 +>> That's right. + +40 +00:01:42,120 --> 00:01:45,380 +>> So I think that the best way to represent this, I mean, unless you + +41 +00:01:45,380 --> 00:01:47,000 +need an entity because you are creating it + +42 +00:01:47,000 --> 00:01:49,160 +yourself, but it seems like you are not. + +43 +00:01:49,160 --> 00:01:52,710 +I would just remove this one and I would like to put this, + +44 +00:01:52,710 --> 00:01:56,020 +basically to take the library card number and add it to the pattern. + +45 +00:01:56,020 --> 00:01:57,100 +>> Okay, makes sense. + +46 +00:01:57,100 --> 00:02:03,000 +>> Okay, so I'll add it here. And as + +47 +00:02:03,000 --> 00:02:06,160 +an additional attribute. Okay, and it will eliminate this class. + +48 +00:02:06,160 --> 00:02:06,410 +>> Okay. + +49 +00:02:06,410 --> 00:02:07,580 +>> Okay. + +50 +00:02:09,690 --> 00:02:11,700 +Oh, and, wait a second, so I guess + +51 +00:02:11,700 --> 00:02:13,940 +also the child needs a library card number, right? + +52 +00:02:13,940 --> 00:02:18,320 +>> Child needs a library card number, but let me ask you about that. Is, + +53 +00:02:18,320 --> 00:02:22,050 +is child a separate class, or is it just another kind of patron? + +54 +00:02:22,050 --> 00:02:24,920 +>> Oh, I see, I see. Because, yeah, it + +55 +00:02:24,920 --> 00:02:28,490 +is sort of a special patron, right? And, so + +56 +00:02:28,490 --> 00:02:31,730 +maybe we should, maybe we should represent it as + +57 +00:02:31,730 --> 00:02:35,640 +a kind of a refinement of the patron. + +58 +00:02:35,640 --> 00:02:38,730 +Hm, but then that made me think. So what is + +59 +00:02:38,730 --> 00:02:42,510 +the only thing that characterizes children? Is it just the age? + +60 +00:02:42,510 --> 00:02:47,440 +>> Well, if they're, that they can't check out more than five books. + +61 +00:02:47,440 --> 00:02:48,890 +>> Okay. And the, and the only difference is the + +62 +00:02:48,890 --> 00:02:52,010 +fact that they are less than, you know, twelve years old. + +63 +00:02:52,010 --> 00:02:52,710 +>> Twelve or less, right. + +64 +00:02:52,710 --> 00:02:56,090 +>> Twelve or less. So, I guess, you know, I would probably + +65 +00:02:56,090 --> 00:03:01,120 +like to represent this by making the age explicit in the patron rather + +66 +00:03:01,120 --> 00:03:04,730 +than to represent it as a class. And I'll tell you why, + +67 +00:03:04,730 --> 00:03:08,300 +because one, one of the issues, and you know, that might happen + +68 +00:03:08,300 --> 00:03:13,070 +again, is that, basically, there are patrons that are children. And they're + +69 +00:03:13,070 --> 00:03:17,130 +no longer children, when they come you know 13 or older right. + +70 +00:03:17,130 --> 00:03:18,100 +>> Right. + +71 +00:03:18,100 --> 00:03:21,990 +>> And if we represent them with a separate class in a sense, then we + +72 +00:03:21,990 --> 00:03:26,620 +cannot really change the type of an instance of these classes. + +73 +00:03:26,620 --> 00:03:28,920 +So we're left to kind of destroy the patron, create + +74 +00:03:28,920 --> 00:03:31,190 +a new one, so that means we also have to transfer + +75 +00:03:31,190 --> 00:03:33,510 +any history we want to keep history and so on. + +76 +00:03:33,510 --> 00:03:35,680 +So I, I think I kind of like better the idea + +77 +00:03:35,680 --> 00:03:39,560 +that I represent the age exclusively in + +78 +00:03:39,560 --> 00:03:42,700 +the patron, and then I'll behave differently, based on whether the + +79 +00:03:42,700 --> 00:03:45,910 +patron is 12 years old, or younger, or 13 or, + +80 +00:03:45,910 --> 00:03:49,600 +13 or older. This, do you see any problem with that? + +81 +00:03:49,600 --> 00:03:51,210 +>> It makes things a little simpler. + +82 +00:03:51,210 --> 00:03:51,490 +>> Okay, + +83 +00:03:51,490 --> 00:03:53,550 +and we actually, it allows us also to eliminate + +84 +00:03:53,550 --> 00:03:56,450 +one class here. So I'm going to proceed this way. + +85 +00:03:56,450 --> 00:03:59,450 +I'm going to eliminate the children class, and I'm going to + +86 +00:03:59,450 --> 00:04:03,600 +put the age in the patron. Okay, and let me + +87 +00:04:03,600 --> 00:04:07,020 +see. But in this spirit, actually, something else that jumps + +88 +00:04:07,020 --> 00:04:09,740 +at me is this idea of the bestseller, because I + +89 +00:04:09,740 --> 00:04:11,850 +kind of feel like, we might have the same + +90 +00:04:11,850 --> 00:04:15,085 +problem. So, what is the story? What is a bestseller. + +91 +00:04:15,085 --> 00:04:16,850 +>> Well it's + +92 +00:04:16,850 --> 00:04:20,750 +an item that we want to restrict how + +93 +00:04:20,750 --> 00:04:23,896 +long people can keep, because there is such demand for it. + +94 +00:04:23,896 --> 00:04:26,880 +>> I see, and so basically a book that's a + +95 +00:04:26,880 --> 00:04:30,450 +bestseller, like the New York Times bestseller, is a bestseller forever? + +96 +00:04:30,450 --> 00:04:32,683 +>> No, no, no it's hot for + +97 +00:04:32,683 --> 00:04:35,940 +awhile, and then it becomes just a regular item. + +98 +00:04:35,940 --> 00:04:38,318 +>> I see. Hm. Then I guess it's a + +99 +00:04:38,318 --> 00:04:40,349 +similar situation to the one I was mentioning before, right? + +100 +00:04:40,349 --> 00:04:40,980 +>> Okay. + +101 +00:04:40,980 --> 00:04:41,800 +>> That if we have a book, + +102 +00:04:41,800 --> 00:04:44,530 +it will kind of have to change its type if it becomes a best seller. + +103 +00:04:44,530 --> 00:04:47,218 +Then we have to change its type again, if it's no longer a best seller. + +104 +00:04:47,218 --> 00:04:47,790 +>> Right. + +105 +00:04:47,790 --> 00:04:48,920 +>> So it seems to me that a better + +106 +00:04:48,920 --> 00:04:52,150 +way to represent this, is just to eliminate this BestSeller + +107 +00:04:52,150 --> 00:04:55,060 +class and instead, I'm going to put the best seller + +108 +00:04:55,060 --> 00:04:58,190 +attribute, which would just be a Boolean in the book. + +109 +00:04:58,190 --> 00:05:00,190 +>> Okay, what do you mean by Boolean? + +110 +00:05:00,190 --> 00:05:02,280 +>> Right. We don't know what Boolean is, right? The Boolean is + +111 +00:05:02,280 --> 00:05:04,940 +basically just a number. It can have two values, right? True or false. + +112 +00:05:04,940 --> 00:05:05,380 +>> Okay. + +113 +00:05:05,380 --> 00:05:06,830 +>> So we usually, normally use it + +114 +00:05:06,830 --> 00:05:09,510 +in this in this case. Imagine one, zero, + +115 +00:05:09,510 --> 00:05:10,970 +right? Then it's just kind of the basic. + +116 +00:05:10,970 --> 00:05:11,120 +>> Okay. + +117 +00:05:11,120 --> 00:05:12,250 +>> You know, the bits, right? + +118 +00:05:12,250 --> 00:05:12,590 +>> Okay. + +119 +00:05:12,590 --> 00:05:14,730 +>> So, this is just telling us, it's like a flag + +120 +00:05:14,730 --> 00:05:16,672 +that is telling this book is a best seller, or not. + +121 +00:05:16,672 --> 00:05:17,053 +>> Okay. + +122 +00:05:17,053 --> 00:05:20,920 +>> It's very easy to change this value and make a book a best + +123 +00:05:20,920 --> 00:05:22,880 +seller or not a best seller, than + +124 +00:05:22,880 --> 00:05:26,210 +just creating and destroying instances of these classes. + +125 +00:05:26,210 --> 00:05:27,135 +>> Okay, makes sense. + +126 +00:05:27,135 --> 00:05:32,630 +>> Okay, so at this point, this already looks better, right? Because we have, + +127 +00:05:32,630 --> 00:05:35,590 +less classes, and I think we did, yeah, we + +128 +00:05:35,590 --> 00:05:38,775 +did some serious cleanup. That's good. Okay, so now that + +129 +00:05:38,775 --> 00:05:40,975 +we eliminated some of this, what I would like to + +130 +00:05:40,975 --> 00:05:42,845 +do, as I said, we are going to both clean + +131 +00:05:42,845 --> 00:05:45,222 +up, but also refine. I would like to go + +132 +00:05:45,222 --> 00:05:48,826 +back to our, requirements and see whether we can identify + +133 +00:05:48,826 --> 00:05:52,566 +additional attributes for this, class that maybe are not as + +134 +00:05:52,566 --> 00:05:55,120 +obvious as the one that we saw so far, okay? + diff --git a/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/4 - Adding Attributes - lang_en.srt b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/4 - Adding Attributes - lang_en.srt new file mode 100644 index 0000000..0a48aae --- /dev/null +++ b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/4 - Adding Attributes - lang_en.srt @@ -0,0 +1,352 @@ +1 +00:00:00,240 --> 00:00:02,880 +Okay, so let me look at the requirements and + +2 +00:00:05,500 --> 00:00:09,150 +it's something that I can see here that we didn't point out before is that + +3 +00:00:09,150 --> 00:00:13,540 +there seems to be clearly some concept of a due date. And I'm telling you why + +4 +00:00:13,540 --> 00:00:17,610 +I'm saying that because here, for example, I notice that it says when items are + +5 +00:00:17,610 --> 00:00:22,580 +due. We mention overdue several times, so is + +6 +00:00:22,580 --> 00:00:24,410 +this something we need to keep track of? + +7 +00:00:24,410 --> 00:00:27,510 +>> Yeah remember when we used to stamp them on the books? In the stamp pad? + +8 +00:00:27,510 --> 00:00:28,240 +>> Oh yeah yeah yeah! Oh course! + +9 +00:00:28,240 --> 00:00:30,600 +>> Right? Yeah we definitely keep track of, + +10 +00:00:30,600 --> 00:00:32,390 +the system has to keep track of when books are due. + +11 +00:00:32,390 --> 00:00:35,300 +>> Okay. So it seems to me that one good way + +12 +00:00:35,300 --> 00:00:39,660 +of doing that is by basically adding an attribute to the, item. + +13 +00:00:39,660 --> 00:00:40,590 +>> Okay. + +14 +00:00:40,590 --> 00:00:41,910 +>> And I'll just call it due date. + +15 +00:00:41,910 --> 00:00:42,400 +>> Okay. + +16 +00:00:42,400 --> 00:00:45,360 +>> So basically for each item in case it's loaned + +17 +00:00:45,360 --> 00:00:48,315 +there will be this attribute that will contain the value of + +18 +00:00:48,315 --> 00:00:48,520 +>> Okay. + +19 +00:00:48,520 --> 00:00:55,710 +>> Of when, when the item is due. And then, something else that I noticed + +20 +00:00:55,710 --> 00:00:58,734 +here is that down here, it seems like + +21 +00:00:58,734 --> 00:01:00,900 +the requirements are saying that an item can + +22 +00:01:00,900 --> 00:01:04,190 +be renewed only once. So, I guess, that's + +23 +00:01:04,190 --> 00:01:05,933 +something we need to keep track of, right? + +24 +00:01:05,933 --> 00:01:06,056 +>> Yeah. + +25 +00:01:06,056 --> 00:01:06,700 +>> The system needs to know. + +26 +00:01:06,700 --> 00:01:08,360 +>> We have to know whether they've renewed it or not. + +27 +00:01:08,360 --> 00:01:14,132 +>> Okay so, I'll do a similar thing here. I think I want to go and add a an + +28 +00:01:14,132 --> 00:01:19,140 +attribute that we'd call number of times renewed, and add it to the item class. + +29 +00:01:19,140 --> 00:01:19,760 +>> Okay. + +30 +00:01:19,760 --> 00:01:21,140 +>> And this is kind of more generic + +31 +00:01:21,140 --> 00:01:23,180 +than what you need, because here it says only once, but + +32 +00:01:23,180 --> 00:01:25,800 +let's say that in the future you want to allow it to, + +33 +00:01:25,800 --> 00:01:28,690 +kind of renew twice, you'll be able to use these attributes again + +34 +00:01:28,690 --> 00:01:31,090 +because, we can just count how many times it was renewed. Okay? + +35 +00:01:31,090 --> 00:01:31,680 +>> Makes sense. + +36 +00:01:31,680 --> 00:01:35,980 +>> Alright. And one last thing I want to point out. + +37 +00:01:35,980 --> 00:01:38,310 +And this seems obvious but I'm going to check with + +38 +00:01:38,310 --> 00:01:43,150 +you anyways. And seems like there is a basically the + +39 +00:01:43,150 --> 00:01:46,090 +need to keep track of whether an item is checked + +40 +00:01:46,090 --> 00:01:48,210 +out or not. If you look at the text here, + +41 +00:01:48,210 --> 00:01:51,080 +the requirements here, I can see that check out and checked out are + +42 +00:01:51,080 --> 00:01:55,070 +mentioned five times. So, I'm assuming that that's something also + +43 +00:01:55,070 --> 00:01:58,080 +that we want to know about an item, whether it's checked out or not. + +44 +00:01:58,080 --> 00:01:59,970 +>> We have to keep track of whether they're checked out. + +45 +00:01:59,970 --> 00:02:01,930 +>> Okay, so I'll add an + +46 +00:02:01,930 --> 00:02:04,340 +additional attribute there. So I'm going to again go + +47 +00:02:04,340 --> 00:02:06,480 +back to the diagram and I'm + +48 +00:02:06,480 --> 00:02:10,139 +just going to write here also the checked out attribute. + +49 +00:02:12,260 --> 00:02:14,590 +And, I think that's it as far as I'm + +50 +00:02:14,590 --> 00:02:16,330 +concerned. Is there anything that you think is missing? + +51 +00:02:16,330 --> 00:02:21,077 +>> Well, I do have a question. Would checked out, + +52 +00:02:21,077 --> 00:02:27,140 +better not be the case that someone can check out a reference book. + +53 +00:02:27,140 --> 00:02:28,400 +>> Oh, I see, I see. + +54 +00:02:28,400 --> 00:02:30,120 +>> Okay. I mean, it's only the books and + +55 +00:02:30,120 --> 00:02:31,780 +the audio visual material that can be checked out. + +56 +00:02:31,780 --> 00:02:37,790 +>> Right, right, right. Okay, so I, I guess, well the way I will fix that is, + +57 +00:02:37,790 --> 00:02:42,300 +I'll probably put yet another attribute in the item class, and I'll + +58 +00:02:42,300 --> 00:02:45,860 +call it loanable. And basically, this attribute is just telling us whether + +59 +00:02:45,860 --> 00:02:49,580 +an item is loanable or not. So, when it's not true and + +60 +00:02:49,580 --> 00:02:53,480 +loanable is not on. Basically, that item can be checked out. + +61 +00:02:53,480 --> 00:02:55,174 +>> Okay. And, the system would know this. + +62 +00:02:55,174 --> 00:02:56,450 +>> The system will know that. + +63 +00:02:56,450 --> 00:02:57,160 +>> And prevent it from happening. + +64 +00:02:57,160 --> 00:02:58,240 +>> And prevent it from happening. Okay? + +65 +00:02:58,240 --> 00:02:58,750 +>> Alright. + +66 +00:02:58,750 --> 00:03:02,918 +>> Perfect. So, we're going to do that and, any other objections, + +67 +00:03:02,918 --> 00:03:04,035 +any other? + +68 +00:03:04,035 --> 00:03:05,730 +>> No, that was my question. + +69 +00:03:05,730 --> 00:03:08,040 +>> Okay, perfect, so what I'm going to do next, I + +70 +00:03:08,040 --> 00:03:11,130 +mean, I haven't mentioned that yet, but you know classes right + +71 +00:03:11,130 --> 00:03:12,890 +now we just looked at the attributes right that give + +72 +00:03:12,890 --> 00:03:16,140 +you sort of the state of the class. And there's something + +73 +00:03:16,140 --> 00:03:19,185 +else, there's a second part of the class that is kind of + +74 +00:03:19,185 --> 00:03:22,520 +an orthogonal aspect, which is what the class can do. And we + +75 +00:03:22,520 --> 00:03:25,640 +call those operations. So normally these kinds also have operations, I + +76 +00:03:25,640 --> 00:03:28,000 +guess you know it would make sense to you as well. + +77 +00:03:28,000 --> 00:03:30,070 +And one way, one very natural way to + +78 +00:03:30,070 --> 00:03:33,310 +identify operations is to look at the requirements and + +79 +00:03:33,310 --> 00:03:36,850 +look for verbs. Because verbs associated with an item + +80 +00:03:36,850 --> 00:03:38,480 +will tell you basically what the item can do. + +81 +00:03:38,480 --> 00:03:38,900 +>> Okay. + +82 +00:03:38,900 --> 00:03:41,250 +>> So I, I'd like to go back to the requirements and + +83 +00:03:41,250 --> 00:03:45,110 +start, the same way in which we underlined, nouns, we're going to underline + +84 +00:03:45,110 --> 00:03:49,340 +verbs and we're going to see which ones of those verbs actually represent + +85 +00:03:49,340 --> 00:03:53,120 +actions that we want to represent explicitly, we want to model explicitly in + +86 +00:03:53,120 --> 00:03:53,950 +our class diagram. + +87 +00:03:53,950 --> 00:03:54,490 +>> Okay. + +88 +00:03:54,490 --> 00:03:54,750 +>> Okay. + diff --git a/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/5 - Identifying Operations - lang_en.srt b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/5 - Identifying Operations - lang_en.srt new file mode 100644 index 0000000..74ca388 --- /dev/null +++ b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/5 - Identifying Operations - lang_en.srt @@ -0,0 +1,304 @@ +1 +00:00:00,460 --> 00:00:03,276 +>> And before we get started actually, I'd like to mention that there's + +2 +00:00:03,276 --> 00:00:05,124 +just, you know, FYI, there's different kinds + +3 +00:00:05,124 --> 00:00:06,708 +of verbs because what I'm looking for + +4 +00:00:06,708 --> 00:00:10,099 +is really action verbs. So verb, verbs that clearly express an action that + +5 +00:00:10,099 --> 00:00:13,580 +can tell me that, you know, what, for example, an item could do, 'kay? + +6 +00:00:13,580 --> 00:00:13,820 +>> Okay? + +7 +00:00:13,820 --> 00:00:16,620 +>> Not the verbs that represent, for example, relationships, 'kay? + +8 +00:00:16,620 --> 00:00:17,076 +>> Okay. + +9 +00:00:17,076 --> 00:00:19,080 +>> So, and the, there, and the ones + +10 +00:00:19,080 --> 00:00:22,020 +that I've identified und, underlined here actually, I, + +11 +00:00:22,020 --> 00:00:26,158 +I underlined complete sentences so that you kind of we can look at the verbs in + +12 +00:00:26,158 --> 00:00:29,150 +in context. And the first one is this + +13 +00:00:29,150 --> 00:00:30,850 +sentence that says that the library may need + +14 +00:00:30,850 --> 00:00:33,190 +to know or to calculate the items a + +15 +00:00:33,190 --> 00:00:35,790 +patron has checked out, when they are due, and + +16 +00:00:35,790 --> 00:00:38,860 +any outstanding overdue fines. So I, I will + +17 +00:00:38,860 --> 00:00:41,430 +imagine that this is representing a situation in + +18 +00:00:41,430 --> 00:00:44,224 +which you bring up a patron's record and + +19 +00:00:44,224 --> 00:00:46,131 +you start looking up this information. Is that [CROSSTALK] + +20 +00:00:46,131 --> 00:00:50,970 +>> The, the patron often wants to know what they have currently checked out. + +21 +00:00:50,970 --> 00:00:51,044 +>> Oh, + +22 +00:00:51,044 --> 00:00:51,282 +alright. + +23 +00:00:51,282 --> 00:00:53,260 +>> Or when are their due or how much they're owed or. + +24 +00:00:53,260 --> 00:00:55,100 +>> Oh, in fact, and then now that you mentioned it, + +25 +00:00:55,100 --> 00:00:57,500 +I think you sent me. One of the scenarios you sent + +26 +00:00:57,500 --> 00:00:59,400 +me had to do with that, right, with the patron coming + +27 +00:00:59,400 --> 00:01:01,930 +in and asking for this information. So yeah, and it makes + +28 +00:01:01,930 --> 00:01:05,025 +a lot of sense. So what I'm going to do, I'm going to + +29 +00:01:05,025 --> 00:01:10,520 +model this by adding this three operations to the patron method. + +30 +00:01:10,520 --> 00:01:13,410 +The first one, I'm going to call, itemsCheckedOut and, basically, it's an + +31 +00:01:13,410 --> 00:01:16,520 +operation, but you don't need to, you know, understand the implementation + +32 +00:01:16,520 --> 00:01:18,820 +details, but when you call this operation, it will + +33 +00:01:18,820 --> 00:01:21,770 +give you back exactly this information, so the items + +34 +00:01:21,770 --> 00:01:23,864 +that are checked out by that patron. The second + +35 +00:01:23,864 --> 00:01:25,965 +one, I'm going to call it whenDue. That will tell you + +36 +00:01:25,965 --> 00:01:29,080 +basically when a, when an item is due. And + +37 +00:01:29,080 --> 00:01:32,550 +the third one is going to be called the outstandingOverdueFines and, + +38 +00:01:32,550 --> 00:01:34,510 +you know, as the name says, it's going to tell + +39 +00:01:34,510 --> 00:01:36,860 +you what are the outstanding overdue fines for that patron. + +40 +00:01:36,860 --> 00:01:37,300 +>> Okay. + +41 +00:01:37,300 --> 00:01:39,306 +>> And as you might notice I mean, + +42 +00:01:39,306 --> 00:01:41,843 +I, I'm going to separate the, the, the attributes + +43 +00:01:41,843 --> 00:01:44,085 +from the operations by having a separate kind + +44 +00:01:44,085 --> 00:01:46,386 +of subrectangle so, in this way, it's clear + +45 +00:01:46,386 --> 00:01:48,274 +what is attribute and what is, what is + +46 +00:01:48,274 --> 00:01:51,000 +an attribute and what's an, what's an operation. + +47 +00:01:51,000 --> 00:01:51,420 +>> Gotcha. + +48 +00:01:51,420 --> 00:01:57,540 +>> And let me see then. Okay, for the + +49 +00:01:57,540 --> 00:02:00,040 +second one you can see that that patron can check + +50 +00:02:00,040 --> 00:02:02,990 +out books and audio visual materials. So I guess, + +51 +00:02:02,990 --> 00:02:06,880 +similarly you, you build kind of the record for a patron. + +52 +00:02:06,880 --> 00:02:09,150 +The patron will give you an item and you will record + +53 +00:02:09,150 --> 00:02:11,020 +the fact that the patron is kind of checking it out. + +54 +00:02:11,020 --> 00:02:15,730 +>> Right. And is that operation related to this, + +55 +00:02:15,730 --> 00:02:18,150 +the checked out attribute that we did a minute ago? + +56 +00:02:18,150 --> 00:02:21,495 +>> It is actually because what will happen then again, you know, if we jump + +57 +00:02:21,495 --> 00:02:24,975 +ahead a little bit would be that every time you invoke this operation. So I'm + +58 +00:02:24,975 --> 00:02:26,810 +going to represent this as a checkOut operation + +59 +00:02:26,810 --> 00:02:28,896 +for the patron. Every time you invoke this, + +60 +00:02:28,896 --> 00:02:31,920 +you will also have to say something about the item and so we will also + +61 +00:02:31,920 --> 00:02:35,700 +flip kind of that that, that build information in the, in the, in the item. + +62 +00:02:35,700 --> 00:02:36,904 +>> Okay. + +63 +00:02:36,904 --> 00:02:39,680 +>> Mm, 'kay? And, and finally, here, I can see that + +64 +00:02:39,680 --> 00:02:42,660 +a patron can request a book or an audio video item Is + +65 +00:02:42,660 --> 00:02:46,240 +not currently in. So I guess this is referring to items that + +66 +00:02:46,240 --> 00:02:48,980 +are already checked out but for which there is interest. Is that? + +67 +00:02:48,980 --> 00:02:54,770 +>> Right. So, particularly, the popular items the patrons want to get on + +68 +00:02:54,770 --> 00:02:57,140 +the list so that they get notified when it comes back in and. + +69 +00:02:57,140 --> 00:02:57,204 +>> Oh. + +70 +00:02:57,204 --> 00:02:57,730 +>> And check it out. + +71 +00:02:57,730 --> 00:03:00,570 +>> I see. I see. Okay. Then I'm going to do + +72 +00:03:00,570 --> 00:03:04,400 +the same thing here. I'm, I'm going to add this method, + +73 +00:03:04,400 --> 00:03:08,510 +which I'm going to call request and I'm going to put it + +74 +00:03:08,510 --> 00:03:11,340 +here in the list of the methods in the list. + +75 +00:03:11,340 --> 00:03:11,450 +>> Okay. + +76 +00:03:11,450 --> 00:03:12,810 +>> Of operations for the, for the patron, okay? + diff --git a/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/6 - Adding Relationships - lang_en.srt b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/6 - Adding Relationships - lang_en.srt new file mode 100644 index 0000000..d47ef80 --- /dev/null +++ b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/6 - Adding Relationships - lang_en.srt @@ -0,0 +1,488 @@ +1 +00:00:00,420 --> 00:00:02,740 +OK I like the way this class diagram is + +2 +00:00:02,740 --> 00:00:05,850 +coming along. So at this point I think we + +3 +00:00:05,850 --> 00:00:08,300 +have all the classes that we need. For each + +4 +00:00:08,300 --> 00:00:12,250 +class we specified the attributes or the characteristics of the + +5 +00:00:12,250 --> 00:00:15,150 +class. And we also specified the operations so we + +6 +00:00:15,150 --> 00:00:18,710 +know what the class can do And, I like to + +7 +00:00:18,710 --> 00:00:22,110 +kind of move forward on this, but I first + +8 +00:00:22,110 --> 00:00:25,690 +want to see that you're fine with the class structure. + +9 +00:00:25,690 --> 00:00:27,500 +So that's the way the class structure is going + +10 +00:00:27,500 --> 00:00:29,880 +to be in terms of attributes and operations. So anything + +11 +00:00:29,880 --> 00:00:34,910 +that bothers you? Well, one thing I didn't understand + +12 +00:00:34,910 --> 00:00:38,090 +is how come you put check out over where + +13 +00:00:38,090 --> 00:00:40,350 +the patron when it's really the item being checked + +14 +00:00:40,350 --> 00:00:46,280 +out? Right. Okay. So that actually is you know, is a perfect + +15 +00:00:46,280 --> 00:00:48,030 +segway for the next thing that really wanted + +16 +00:00:48,030 --> 00:00:50,780 +to model. Because what you're talking about is basically a + +17 +00:00:50,780 --> 00:00:54,100 +relationship between two classes which is something we haven't touched on + +18 +00:00:54,100 --> 00:00:57,582 +yet. So we haven't, haven't looked at individual classes. But now, it + +19 +00:00:57,582 --> 00:01:00,720 +is typical, now we are looking more at requirements, we're starting to + +20 +00:01:00,720 --> 00:01:04,800 +find more things about our system, and what you're pointed out right + +21 +00:01:04,800 --> 00:01:08,370 +now is the fact that patron and item are somehow related. So + +22 +00:01:08,370 --> 00:01:11,020 +this checkout operation is not really something that belongs only on in + +23 +00:01:11,020 --> 00:01:13,660 +the patron, because it needs to know about the item. And it + +24 +00:01:13,660 --> 00:01:15,790 +doesn't belong only on the item because it needs to know about + +25 +00:01:15,790 --> 00:01:19,640 +the patron. So, it's something that associates the patron and + +26 +00:01:19,640 --> 00:01:22,600 +the item. Okay. And that's exactly the way we call + +27 +00:01:22,600 --> 00:01:24,630 +in the UML which is the notation that we're using + +28 +00:01:24,630 --> 00:01:29,060 +here this kind of relationship. So, we're going to represent that + +29 +00:01:29,060 --> 00:01:32,820 +by drawing a line between these two classes that tells + +30 +00:01:32,820 --> 00:01:35,220 +us there is an association. And we're also going to + +31 +00:01:35,220 --> 00:01:37,890 +give a name to this. Since this refers to the + +32 +00:01:37,890 --> 00:01:40,280 +fact of checking out items. We're just going to call + +33 +00:01:40,280 --> 00:01:43,794 +it, checkout. Gotcha. And notice that this basically you + +34 +00:01:43,794 --> 00:01:48,500 +know,eventually will end up kind of replacing this attribute. Because + +35 +00:01:48,500 --> 00:01:51,780 +the existence of this association will tell us that + +36 +00:01:51,780 --> 00:01:53,932 +this is checked out. We're, we're not going to, you know, + +37 +00:01:53,932 --> 00:01:55,428 +do it right now, but in the final cleanup + +38 +00:01:55,428 --> 00:01:58,750 +or the diagram, this name will disappear. Okay. Okay. + +39 +00:01:58,750 --> 00:02:02,190 +And so since we started talking about relationships and + +40 +00:02:02,190 --> 00:02:05,280 +associations, is there any other kind of relationship that you + +41 +00:02:05,280 --> 00:02:08,805 +see here? Well, what you just did with checked + +42 +00:02:08,805 --> 00:02:12,009 +out is, it seems similar to the whole issue + +43 +00:02:12,009 --> 00:02:16,090 +of requests. It is, it is. So a request + +44 +00:02:16,090 --> 00:02:19,580 +is something else that happens in both, you know, in + +45 +00:02:19,580 --> 00:02:22,090 +the patron and in the item, it involves both. + +46 +00:02:22,090 --> 00:02:24,070 +And in fact in a request, I would definitely + +47 +00:02:24,070 --> 00:02:26,950 +represent this as an additional association. So I will + +48 +00:02:26,950 --> 00:02:30,730 +just draw an another line between these two that represent + +49 +00:02:30,730 --> 00:02:33,804 +that specific kind of relationship and I will call it + +50 +00:02:33,804 --> 00:02:37,330 +request. So that indicates that this association refers to a + +51 +00:02:37,330 --> 00:02:41,660 +request that also connects the patron with an item. Okay. + +52 +00:02:41,660 --> 00:02:45,710 +And, let's see. Any, anything else that jumps at you? + +53 +00:02:45,710 --> 00:02:47,590 +Yeah, well, how about all these ones down at the + +54 +00:02:47,590 --> 00:02:50,080 +bottom? I mean book and item's got to be + +55 +00:02:50,080 --> 00:02:52,920 +related, right? A book is a kind of item, And + +56 +00:02:52,920 --> 00:02:55,860 +audiovisual... are there associations between them? Can you repeat + +57 +00:02:55,860 --> 00:02:58,790 +that, you said that the book, yeah? Is + +58 +00:02:58,790 --> 00:03:02,550 +a kind of item. Perfect, that's exactly what we're + +59 +00:03:02,550 --> 00:03:04,700 +modeling next, which is, this, what we call the + +60 +00:03:04,700 --> 00:03:07,900 +is-a relationship. So you said, a book is an item? + +61 +00:03:07,900 --> 00:03:13,346 +A book is an item. And, we can model that in the diagram. So, we do that + +62 +00:03:13,346 --> 00:03:17,409 +using another kind of relationship between the classes. So + +63 +00:03:17,409 --> 00:03:21,210 +we're going to represent that as a specialization we call it. + +64 +00:03:21,210 --> 00:03:24,890 +And, a specialization is indicated in this way. Okay? + +65 +00:03:24,890 --> 00:03:27,410 +With this arrow at the end, so a solid + +66 +00:03:27,410 --> 00:03:30,800 +with this kind of arrow at the end. And + +67 +00:03:30,800 --> 00:03:34,160 +we can do the same for book, magazine, reference book + +68 +00:03:34,160 --> 00:03:36,200 +and audiovisual material. So we're all going to connect, + +69 +00:03:36,200 --> 00:03:37,950 +we're going to connect all of them, to the + +70 +00:03:37,950 --> 00:03:43,190 +item, using the same kind of connection. And now + +71 +00:03:43,190 --> 00:03:47,200 +that we have connected all these four, with item + +72 +00:03:47,200 --> 00:03:50,620 +and indicated them in subclasses. That's something else that we can + +73 +00:03:50,620 --> 00:03:54,370 +do. So we can make this kind of cleaner. And I'll + +74 +00:03:54,370 --> 00:03:56,360 +tell you what I mean by that. So now we have + +75 +00:03:56,360 --> 00:04:00,190 +this loanable attribute that refers to item, but it seems to + +76 +00:04:00,190 --> 00:04:03,100 +me from what you were saying before, that loanable is not + +77 +00:04:03,100 --> 00:04:05,490 +really an attribute of an item. Right? It's more of a + +78 +00:04:05,490 --> 00:04:09,240 +characteristic of the type of item. Right. Is that right? Right. + +79 +00:04:09,240 --> 00:04:13,120 +Books, and audio/visual are loanable but the others aren't. + +80 +00:04:13,120 --> 00:04:16,450 +Okay, and so representing it here, it's okay to, + +81 +00:04:16,450 --> 00:04:20,579 +it will work. But it's not really right so from + +82 +00:04:20,579 --> 00:04:23,590 +the style standpoint it doesn't really you know, + +83 +00:04:23,590 --> 00:04:26,100 +it's not the best way of modeling this. What we're going to + +84 +00:04:26,100 --> 00:04:30,130 +do instead, we're going to use this specialization relationship to make + +85 +00:04:30,130 --> 00:04:33,000 +that more explicit. To make it cleaner. Okay, so what + +86 +00:04:33,000 --> 00:04:35,300 +I'm doing here is I'm going to take this hierarchy + +87 +00:04:35,300 --> 00:04:38,130 +of classes, this is just on two levels now, and I'm + +88 +00:04:38,130 --> 00:04:40,380 +going to kind of make it a little richer. + +89 +00:04:40,380 --> 00:04:43,470 +So I'm going to add an intermediate set of + +90 +00:04:43,470 --> 00:04:45,756 +classes. And in particular I'm going to have these two + +91 +00:04:45,756 --> 00:04:48,306 +classes that I'm going to call non loanable item and loanable + +92 +00:04:48,306 --> 00:04:51,790 +item. So, they're both items but they tell me + +93 +00:04:51,790 --> 00:04:55,490 +clearly that some items are loanable and some items + +94 +00:04:55,490 --> 00:04:59,392 +are not. Okay. Okay. And then I'm simply going to + +95 +00:04:59,392 --> 00:05:03,192 +put book and audio video material as subclasses of loanable + +96 +00:05:03,192 --> 00:05:07,980 +item and reference book and magazine as subclasses of non-loanable + +97 +00:05:07,980 --> 00:05:10,510 +item. So, if we look at this diagram now it's + +98 +00:05:10,510 --> 00:05:13,650 +pretty clear what is loanable and what is not. And + +99 +00:05:13,650 --> 00:05:16,070 +it's actually is a very clean, much cleaner + +100 +00:05:16,070 --> 00:05:18,980 +design. And, and I see you've, gotten rid of + +101 +00:05:18,980 --> 00:05:21,560 +the loanable attribute, too. I did. Because at + +102 +00:05:21,560 --> 00:05:24,130 +this point this is already represented by the fact of + +103 +00:05:24,130 --> 00:05:28,570 +having these two classes. And actually, something else that I did + +104 +00:05:28,570 --> 00:05:31,820 +is that I moved all these attributes, value, + +105 +00:05:31,820 --> 00:05:34,220 +due date, renewed and checked out, that makes + +106 +00:05:34,220 --> 00:05:37,452 +sense only for loanable item. From item to + +107 +00:05:37,452 --> 00:05:40,450 +loanable item. So at this point, this really + +108 +00:05:40,450 --> 00:05:42,600 +is telling me that, you know, these + +109 +00:05:42,600 --> 00:05:46,410 +characteristics are just meaningful for the loanable item, + +110 +00:05:46,410 --> 00:05:53,800 +and not for the other ones. Well, speaking of that, the way that you got the + +111 +00:05:53,800 --> 00:05:57,270 +lines going in the diagram here is you still have + +112 +00:05:57,270 --> 00:05:59,920 +request and checked out going to item, even though you + +113 +00:05:59,920 --> 00:06:02,610 +can't request non loanable Items. You can't check out non + +114 +00:06:02,610 --> 00:06:05,630 +loanable Items. Oh, you were right actually. You got me on + +115 +00:06:05,630 --> 00:06:10,940 +that one. You're exactly right. So this associations are between + +116 +00:06:10,940 --> 00:06:13,440 +the two wrong classes. So, I guess, at this point, + +117 +00:06:13,440 --> 00:06:16,450 +you can probably go and fix the diagram yourself. Well, + +118 +00:06:16,450 --> 00:06:19,120 +can we just make the lines go from patron to loanable + +119 +00:06:19,120 --> 00:06:21,640 +item instead of to item? That's exactly the way in which we + +120 +00:06:21,640 --> 00:06:25,550 +are going to fix it. So, we're going to move these two associations down + +121 +00:06:25,550 --> 00:06:29,190 +here. And at this point, this will represent the right relationships in + +122 +00:06:29,190 --> 00:06:31,850 +the, in the diagram, and in the system. Makes sense to me. + diff --git a/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/7 - Refining Relationships - lang_en.srt b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/7 - Refining Relationships - lang_en.srt new file mode 100644 index 0000000..44f9165 --- /dev/null +++ b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/7 - Refining Relationships - lang_en.srt @@ -0,0 +1,188 @@ +1 +00:00:00,350 --> 00:00:03,460 +Spencer, I gotta tell you, I'm impressed. + +2 +00:00:03,460 --> 00:00:05,441 +You're getting very good at this. So, why + +3 +00:00:05,441 --> 00:00:07,190 +don't you go wild and continue, there + +4 +00:00:07,190 --> 00:00:09,240 +anything else you think we can improve here? + +5 +00:00:09,240 --> 00:00:11,800 +>> Well something was bothering + +6 +00:00:11,800 --> 00:00:14,600 +me, that what happens if there's more + +7 +00:00:14,600 --> 00:00:19,110 +than one book with the same title and somebody puts in a request? + +8 +00:00:19,110 --> 00:00:25,360 +>> Oh, I see. That's a good point. So basically what you are telling me is + +9 +00:00:25,360 --> 00:00:28,630 +there's kind of a difference between an item and + +10 +00:00:28,630 --> 00:00:30,660 +the title, so the title is kind of a more + +11 +00:00:30,660 --> 00:00:32,940 +general concept, in a sense. So if you can + +12 +00:00:32,940 --> 00:00:35,830 +have multiple copies of a given title, is that right? + +13 +00:00:35,830 --> 00:00:38,460 +>> Yeah, we have five copies of Tom Sawyer, and the + +14 +00:00:38,460 --> 00:00:42,810 +persons, the patrons, really putting in a request for any Tom Sawyer. + +15 +00:00:42,810 --> 00:00:45,332 +>> They don't want like copy number three of Tom Sawyer, right? They want, + +16 +00:00:45,332 --> 00:00:50,530 +they want to read Tom Sawyer. Okay and I can represent that. So, in which + +17 +00:00:50,530 --> 00:00:55,230 +I suggest we do that, and you can tell me whether it makes sense to you is by + +18 +00:00:55,230 --> 00:00:59,650 +introducing an additional class, which I call Title. And + +19 +00:00:59,650 --> 00:01:02,614 +that represents exactly the concept that you're mentioning. So + +20 +00:01:02,614 --> 00:01:04,666 +this is a title which represents some + +21 +00:01:04,666 --> 00:01:09,180 +specific content. That is not related to a specific + +22 +00:01:09,180 --> 00:01:12,110 +physical element. Like it can be rated to multiple, + +23 +00:01:12,110 --> 00:01:15,520 +physical elements. So basically I'm going to create this title. + +24 +00:01:15,520 --> 00:01:18,100 +And then I'm going to create a relationship between + +25 +00:01:18,100 --> 00:01:20,500 +the title and the item. And what + +26 +00:01:20,500 --> 00:01:22,530 +the relationship is telling me, the the association + +27 +00:01:22,530 --> 00:01:25,512 +between these two in this case. Is an association, + +28 +00:01:25,512 --> 00:01:30,320 +that we call aggregation. So it's a special kind of association, that basically + +29 +00:01:30,320 --> 00:01:35,450 +indicates that an item of this type, so a title can + +30 +00:01:35,450 --> 00:01:40,692 +consist of a multiple elements of this type of multiple items. + +31 +00:01:40,692 --> 00:01:42,710 +So it's telling me that one title can + +32 +00:01:42,710 --> 00:01:45,700 +consist of multiple items, and I'm going to indicate + +33 +00:01:45,700 --> 00:01:48,560 +it with this annotation, which is a this + +34 +00:01:49,700 --> 00:01:53,200 +diamond at the top of the association. + +35 +00:01:53,200 --> 00:01:55,570 +>> And so we can move our request + +36 +00:01:55,570 --> 00:01:57,510 +line, up from loanable item to + +37 +00:01:57,510 --> 00:01:59,010 +title, because that's what they're really requesting. + +38 +00:01:59,010 --> 00:02:00,710 +>> Definitely, definitely, and in fact, + +39 +00:02:00,710 --> 00:02:02,420 +you know, that represents exactly the situation + +40 +00:02:02,420 --> 00:02:06,350 +that you are mentioning, at this point when the patron makes a request. + +41 +00:02:06,350 --> 00:02:12,240 +It makes a request to a title and not to a loanable item. And then, and + +42 +00:02:12,240 --> 00:02:15,420 +when the actual loan will take place, + +43 +00:02:15,420 --> 00:02:18,420 +then that will be connected to a specific item. + +44 +00:02:18,420 --> 00:02:20,090 +>> Right. Okay that makes sense. + +45 +00:02:20,090 --> 00:02:20,388 +>> Makes sense? + +46 +00:02:20,388 --> 00:02:20,779 +>> Yeah. + +47 +00:02:20,779 --> 00:02:21,214 +>> Okay, good. + diff --git a/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/8 - Refining the Class Diagram - lang_en.srt b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/8 - Refining the Class Diagram - lang_en.srt new file mode 100644 index 0000000..1e47ea6 --- /dev/null +++ b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/8 - Refining the Class Diagram - lang_en.srt @@ -0,0 +1,328 @@ +1 +00:00:00,260 --> 00:00:01,720 +Okay, so let me see if + +2 +00:00:01,720 --> 00:00:07,930 +anything changed after we did this last modification. + +3 +00:00:07,930 --> 00:00:09,530 +Acutally, there is someting that I would like + +4 +00:00:09,530 --> 00:00:12,120 +to do here. Because looking at this a little + +5 +00:00:12,120 --> 00:00:15,560 +bit more, I noticed that there are two + +6 +00:00:15,560 --> 00:00:18,760 +attributes, renewed and due date. That we have in + +7 +00:00:18,760 --> 00:00:21,640 +loanable Item, right? But they don't seem to + +8 +00:00:21,640 --> 00:00:25,590 +be really, attributes or characteristics of loanable Item. + +9 +00:00:25,590 --> 00:00:29,150 +They're more of the characteristics of the association between the + +10 +00:00:29,150 --> 00:00:31,450 +Loanable Item and the patron. Wouldn't you agree? + +11 +00:00:32,470 --> 00:00:34,230 +>> Well, yeah, it's not like you could + +12 +00:00:34,230 --> 00:00:37,644 +only renew a book once in it's entire history. + +13 +00:00:37,644 --> 00:00:41,220 +>> Right. Exactly, exactly. So, that's why what l like + +14 +00:00:41,220 --> 00:00:43,970 +to do is I would like to move those out of loanable + +15 +00:00:43,970 --> 00:00:48,020 +item. And actually there is a construct that we can use + +16 +00:00:48,020 --> 00:00:50,710 +to express this. It's called, we haven't seen it yet, but it's + +17 +00:00:50,710 --> 00:00:52,780 +a special kind of class. It's called an association + +18 +00:00:52,780 --> 00:00:55,480 +class. So, it's a class that is connected to + +19 +00:00:55,480 --> 00:00:57,730 +a specific association. So what we can do + +20 +00:00:57,730 --> 00:01:00,730 +here, we can create this class, which I'm going to + +21 +00:01:00,730 --> 00:01:05,200 +call checked out. I'm going to, associate it with + +22 +00:01:05,200 --> 00:01:09,520 +this, association. I'm going to connect it with this association. And + +23 +00:01:09,520 --> 00:01:11,620 +then I'm going to move the due date and the + +24 +00:01:11,620 --> 00:01:16,300 +renewed attributes From the LoanableItem here in this checked + +25 +00:01:16,300 --> 00:01:18,520 +out class. So in this way, seems to me that + +26 +00:01:18,520 --> 00:01:20,910 +it makes it very explicit for somebody looking at this + +27 +00:01:20,910 --> 00:01:25,530 +class diagram, that these characteristics are characteristics of the loan, + +28 +00:01:25,530 --> 00:01:28,200 +and not of the elements involved in the loan. + +29 +00:01:28,200 --> 00:01:33,410 +>> Can you do the same thing with Fine, isn't Fine a property of the + +30 +00:01:33,410 --> 00:01:36,740 +loan? Yeah, actually is right because + +31 +00:01:36,740 --> 00:01:39,120 +a fine is a fine for a specific loan, right? + +32 +00:01:39,120 --> 00:01:39,910 +>> That's correct. + +33 +00:01:39,910 --> 00:01:41,950 +>> Okay, so yeah. Then we can do that. + +34 +00:01:41,950 --> 00:01:45,900 +We don't need to represent fine as a class, we can just transform + +35 +00:01:45,900 --> 00:01:49,460 +that into an attribute that we can put into the checked out association class. + +36 +00:01:49,460 --> 00:01:50,560 +>> Gotcha. + +37 +00:01:50,560 --> 00:01:52,760 +>> Anything else? + +38 +00:01:52,760 --> 00:01:57,990 +>> Yeah. It occurred to me that there's another thing that happens in one + +39 +00:01:57,990 --> 00:02:00,260 +of my scenarios, I put down + +40 +00:02:00,260 --> 00:02:02,770 +about the patron actually returning an item. + +41 +00:02:02,770 --> 00:02:07,620 +>> Right. Okay, so we would probably need an additional operation, + +42 +00:02:07,620 --> 00:02:08,550 +I guess, for the patron. + +43 +00:02:08,550 --> 00:02:08,990 +>> Right. + +44 +00:02:08,990 --> 00:02:11,310 +>> So, okay, so what I'm going to do, that's pretty easy + +45 +00:02:11,310 --> 00:02:15,350 +to do, I'm just going to add the return operation here in the + +46 +00:02:15,350 --> 00:02:19,310 +patron, and when that happens, that will mean that I'll get rid + +47 +00:02:19,310 --> 00:02:23,490 +of this association class because the item is returned. Is that right? + +48 +00:02:23,490 --> 00:02:27,060 +>> Well, what happens if somebody drops the + +49 +00:02:27,060 --> 00:02:29,400 +book in the book drop, but doesn't pay the, + +50 +00:02:29,400 --> 00:02:31,050 +if it's overdue and doesn't pay the fine? + +51 +00:02:31,050 --> 00:02:32,700 +Will that get rid of the information about what + +52 +00:02:32,700 --> 00:02:33,040 +they owe? + +53 +00:02:33,040 --> 00:02:37,960 +>> Oh, I see. So you can have the item being available, but you still + +54 +00:02:37,960 --> 00:02:42,510 +want to know whether there is any pending fines on the book. + +55 +00:02:42,510 --> 00:02:44,390 +>> Uh-huh, and how much those fines are. + +56 +00:02:44,390 --> 00:02:46,340 +>> And how do you compute how much it is? + +57 +00:02:47,420 --> 00:02:52,710 +>> It's how many days it was, from the time it was + +58 +00:02:52,710 --> 00:02:58,170 +due, to when they returned it. I see. OK. + +59 +00:02:58,170 --> 00:03:00,380 +So you know what we can do? I think + +60 +00:03:00,380 --> 00:03:03,690 +we can put an additional attribute in the checked out + +61 +00:03:03,690 --> 00:03:07,190 +class and I'm going to call it when returned and + +62 +00:03:07,190 --> 00:03:10,200 +that item will have either a special value or it + +63 +00:03:10,200 --> 00:03:12,040 +will contain the date in which the book was + +64 +00:03:12,040 --> 00:03:14,520 +returned. So in this way you should be able to + +65 +00:03:14,520 --> 00:03:18,040 +keep this in the system until it's paid, and also to compute + +66 +00:03:18,040 --> 00:03:19,970 +how much the fine is. Is that working? + +67 +00:03:19,970 --> 00:03:23,210 +>> So the special value is for a normal situation when they + +68 +00:03:23,210 --> 00:03:25,880 +haven't, they don't owe anything and haven't returned it yet. + +69 +00:03:25,880 --> 00:03:28,080 +>> Exactly so that will tell us that, + +70 +00:03:28,080 --> 00:03:29,970 +that the loan is still active basically. + +71 +00:03:29,970 --> 00:03:30,500 +>> Great. + +72 +00:03:30,500 --> 00:03:31,480 +>> Does that work for you? + +73 +00:03:31,480 --> 00:03:35,200 +>> Yes. And you know, I like this. I mean, I feel pretty good + +74 +00:03:35,200 --> 00:03:38,490 +about it. I think we have a nice class diagram. So what I'd like to + +75 +00:03:38,490 --> 00:03:43,280 +do is just go off and clean it up a little bit, and put it + +76 +00:03:43,280 --> 00:03:48,640 +in an IDE so I can pretty print it and rearrange things a little bit. + +77 +00:03:48,640 --> 00:03:50,080 +And then I'd like to sit down again and + +78 +00:03:50,080 --> 00:03:52,730 +just go through it for a last time. And + +79 +00:03:52,730 --> 00:03:54,900 +for some final considerations. So if you don't mind + +80 +00:03:54,900 --> 00:03:56,880 +we will take a ten minute break and reconvene here. + +81 +00:03:56,880 --> 00:03:57,500 +>> That's fine. + +82 +00:03:57,500 --> 00:03:57,990 +>> Alright. + diff --git a/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/9 - Final Considerations - lang_en.srt b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/9 - Final Considerations - lang_en.srt new file mode 100644 index 0000000..0dbfccd --- /dev/null +++ b/usth/ICT2.7/P3L2 A Tale of Analysis and Design Subtitles/9 - Final Considerations - lang_en.srt @@ -0,0 +1,196 @@ +1 +00:00:00,140 --> 00:00:03,202 +Okay. So this is what I've done as you see, + +2 +00:00:03,202 --> 00:00:06,130 +it looks a little nicer than it was before. And I didn't + +3 +00:00:06,130 --> 00:00:08,530 +really change that much. I just made a few changes, so + +4 +00:00:08,530 --> 00:00:11,560 +I just wanted to point them out to you, so that you + +5 +00:00:11,560 --> 00:00:13,690 +know what they are. And the main thing, one of the + +6 +00:00:13,690 --> 00:00:18,210 +main things I did is really to introduce these derived attributes. So + +7 +00:00:18,210 --> 00:00:19,860 +these are attributes that are basically + +8 +00:00:19,860 --> 00:00:22,520 +computed. Based on some other attributes. + +9 +00:00:22,520 --> 00:00:26,010 +Okay, they don't have a value themselves, but their value is computed. + +10 +00:00:26,010 --> 00:00:28,900 +And I used two. The first one is age. So + +11 +00:00:28,900 --> 00:00:31,930 +basically we know the age of the patron based on + +12 +00:00:31,930 --> 00:00:34,920 +the birthday, of the patron. So you guys, I don't + +13 +00:00:34,920 --> 00:00:37,150 +know if you have that information currently in the system. + +14 +00:00:37,150 --> 00:00:38,480 +>> No, we'll have to add that to the + +15 +00:00:38,480 --> 00:00:40,280 +form patrons fill out, when they get their card. + +16 +00:00:40,280 --> 00:00:42,255 +>> Is that, that an issue? Can you do it? + +17 +00:00:42,255 --> 00:00:44,130 +>> No yes, we, we can easily do that. + +18 +00:00:44,130 --> 00:00:46,670 +>> Okay, so then, perfect. So we'll do it that way. I think it's + +19 +00:00:46,670 --> 00:00:51,310 +a, in a little cleaner. And similarly, since you told me that the fine + +20 +00:00:51,310 --> 00:00:54,480 +was computed based on the amount of days that an + +21 +00:00:54,480 --> 00:00:58,310 +item was late. The patron was late returning the item, then I + +22 +00:00:58,310 --> 00:01:02,010 +also added this as a derived attribute that is computed based on + +23 +00:01:02,010 --> 00:01:05,140 +the due date and when the item is actually returned. + +24 +00:01:05,140 --> 00:01:05,780 +>> Makes sense. + +25 +00:01:05,780 --> 00:01:08,389 +>> Makes sense? Okay. And the rest + +26 +00:01:08,389 --> 00:01:10,590 +is kind of really minor things. So the, the only one I + +27 +00:01:10,590 --> 00:01:14,340 +want to point out is I didn't, you know, discuss that with + +28 +00:01:14,340 --> 00:01:17,260 +you before, but I added this, which is called cardinality + +29 +00:01:17,260 --> 00:01:20,700 +for some of these relationships. And what they say is basically + +30 +00:01:20,700 --> 00:01:25,360 +is how many elements are involved in the relationship. + +31 +00:01:25,360 --> 00:01:26,580 +>> So, you mean the stars? + +32 +00:01:26,580 --> 00:01:27,960 +>> Yeah, like the stars and the one... + +33 +00:01:27,960 --> 00:01:28,290 +>> Okay. + +34 +00:01:28,290 --> 00:01:31,380 +>> Here for example, this is telling you that for each item there + +35 +00:01:31,380 --> 00:01:35,490 +is only one title. And that for each title, there are multiple items. + +36 +00:01:35,490 --> 00:01:36,490 +>> So, star means many. + +37 +00:01:36,490 --> 00:01:37,716 +>> Stars mean many, yeah. + +38 +00:01:37,716 --> 00:01:39,045 +>> Okay, go you. + +39 +00:01:39,045 --> 00:01:42,321 +>> Sorry that's kind of computer science lingo - we use the star + +40 +00:01:42,321 --> 00:01:45,500 +for that kind of stuff. And, similarly, for the patron, it's + +41 +00:01:45,500 --> 00:01:48,510 +telling me that, you know, each patron can have multiple, can + +42 +00:01:48,510 --> 00:01:52,550 +request multiple titles, and that the same title can be requested + +43 +00:01:52,550 --> 00:01:55,650 +by multiple patrons, which I think is the way the system works. + +44 +00:01:55,650 --> 00:01:59,080 +>> Right. So except for these minor changes, + +45 +00:01:59,080 --> 00:02:01,850 +we already had a pretty good model in our hands, so + +46 +00:02:01,850 --> 00:02:04,620 +I think is a, we can finalize this and then just + +47 +00:02:04,620 --> 00:02:07,350 +move to the low level design and then implementation, and be + +48 +00:02:07,350 --> 00:02:07,970 +done with the system. + +49 +00:02:07,970 --> 00:02:08,979 +>> Sounds good. + diff --git a/usth/ICT2.7/P3L3 Design Patterns Subtitles/1 - Lesson Overview - lang_en_vs4.srt b/usth/ICT2.7/P3L3 Design Patterns Subtitles/1 - Lesson Overview - lang_en_vs4.srt new file mode 100644 index 0000000..152b961 --- /dev/null +++ b/usth/ICT2.7/P3L3 Design Patterns Subtitles/1 - Lesson Overview - lang_en_vs4.srt @@ -0,0 +1,31 @@ +1 +00:00:00,230 --> 00:00:04,560 +In the last lesson, we talked about design, and we saw how difficult it can + +2 +00:00:04,560 --> 00:00:10,010 +be to come up with a good and effective design for a given software system. To + +3 +00:00:10,010 --> 00:00:12,620 +help address these difficulties, we will discuss + +4 +00:00:12,620 --> 00:00:16,560 +design patterns, which can support design activities by + +5 +00:00:16,560 --> 00:00:20,710 +providing general, reusable solutions to commonly occurring design + +6 +00:00:20,710 --> 00:00:25,410 +problems. Similar to architectural styles, design patterns can + +7 +00:00:25,410 --> 00:00:30,400 +help developers build better designed systems by reusing design solutions that + +8 +00:00:30,400 --> 00:00:33,730 +worked well in the past and by building on those solutions. diff --git a/usth/ICT2.7/P3L3 Design Patterns Subtitles/10 - Choosing a Pattern - lang_en_vs5.srt b/usth/ICT2.7/P3L3 Design Patterns Subtitles/10 - Choosing a Pattern - lang_en_vs5.srt new file mode 100644 index 0000000..f273441 --- /dev/null +++ b/usth/ICT2.7/P3L3 Design Patterns Subtitles/10 - Choosing a Pattern - lang_en_vs5.srt @@ -0,0 +1,95 @@ +1 +00:00:00,150 --> 00:00:03,200 +But with so many patterns, how do we choose a pattern? So + +2 +00:00:03,200 --> 00:00:05,970 +this is a possible approach that you can follow. First of all, you + +3 +00:00:05,970 --> 00:00:09,140 +want to make sure that you understand your design context. You understand + +4 +00:00:09,140 --> 00:00:12,800 +what you're designing and what are the issues involved with this design. What + +5 +00:00:12,800 --> 00:00:15,200 +are the problems that you need to solve. At this point, you + +6 +00:00:15,200 --> 00:00:17,160 +can examine the patterns catalog, or,if + +7 +00:00:17,160 --> 00:00:18,750 +you're already familiar with the catalog, just + +8 +00:00:18,750 --> 00:00:22,430 +think about the possible patterns that you could use. Once you identify + +9 +00:00:22,430 --> 00:00:25,440 +the patterns that you can use, you also want to study them and + +10 +00:00:25,440 --> 00:00:29,090 +study the related patterns. So normally if you look at any pattern catalog, + +11 +00:00:29,090 --> 00:00:32,229 +for each pattern there will also be a list of related patterns. So + +12 +00:00:32,229 --> 00:00:35,010 +you can also look at those to see whether maybe some of those + +13 +00:00:35,010 --> 00:00:38,370 +might be more applicable. And finally, once you identify the pattern that you + +14 +00:00:38,370 --> 00:00:41,360 +think is appropriate, you will apply that pattern. When you do that, just + +15 +00:00:41,360 --> 00:00:44,850 +be mindful that there are pitfalls in the use of patterns. One obvious + +16 +00:00:44,850 --> 00:00:47,490 +one is the fact that you might select the wrong pattern and make + +17 +00:00:47,490 --> 00:00:50,460 +your design worse instead of better. The second one is that if you + +18 +00:00:50,460 --> 00:00:52,560 +get too excited about patterns, then you + +19 +00:00:52,560 --> 00:00:54,850 +might be abusing patterns, so just using too + +20 +00:00:54,850 --> 00:00:56,370 +many patterns, and end up with a design + +21 +00:00:56,370 --> 00:00:58,980 +that is more complicated rather than less complicated. + +22 +00:00:58,980 --> 00:01:01,890 +So always be careful, spend the time to figure out which one is the right + +23 +00:01:01,890 --> 00:01:03,577 +pattern to apply, and make sure that you + +24 +00:01:03,577 --> 00:01:05,190 +don't use patterns that you don't actually need. diff --git a/usth/ICT2.7/P3L3 Design Patterns Subtitles/11 - Choosing a Pattern Quiz - lang_en_vs4.srt b/usth/ICT2.7/P3L3 Design Patterns Subtitles/11 - Choosing a Pattern Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..76a78e0 --- /dev/null +++ b/usth/ICT2.7/P3L3 Design Patterns Subtitles/11 - Choosing a Pattern Quiz - lang_en_vs4.srt @@ -0,0 +1,31 @@ +1 +00:00:00,160 --> 00:00:02,780 +Now that we've discussed how to choose a pattern. Imagine that + +2 +00:00:02,780 --> 00:00:05,210 +you have to write a class that can have only one + +3 +00:00:05,210 --> 00:00:08,090 +instance. So to satisfy this requirement, I would like for you + +4 +00:00:08,090 --> 00:00:10,720 +to pick one of the design patterns that we discussed in + +5 +00:00:10,720 --> 00:00:14,580 +this lesson, and write the code here that satisfies that requirement. + +6 +00:00:14,580 --> 00:00:16,270 +And when you write the code, please make sure that your + +7 +00:00:16,270 --> 00:00:21,140 +class has only one method, without counting possible constructors, and that + +8 +00:00:21,140 --> 00:00:25,120 +the class is called Singleton. And write your class right here. diff --git a/usth/ICT2.7/P3L3 Design Patterns Subtitles/12 - Choosing a Pattern Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P3L3 Design Patterns Subtitles/12 - Choosing a Pattern Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..c348a2c --- /dev/null +++ b/usth/ICT2.7/P3L3 Design Patterns Subtitles/12 - Choosing a Pattern Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,79 @@ +1 +00:00:00,220 --> 00:00:01,750 +As we discussed in the class the right thing to + +2 +00:00:01,750 --> 00:00:05,050 +do here was to use the factory pattern. So here is + +3 +00:00:05,050 --> 00:00:07,910 +a possible code to solve the problem. Of course that there + +4 +00:00:07,910 --> 00:00:11,220 +are different possible solutions. So what we did for this code + +5 +00:00:11,220 --> 00:00:16,210 +was to first create a private, static, Singleton object called + +6 +00:00:16,210 --> 00:00:19,340 +instance, which is the one that will keep track of the + +7 +00:00:19,340 --> 00:00:22,250 +only instance that can be created on the class. Then we + +8 +00:00:22,250 --> 00:00:25,750 +define the default constructor, the constructor that doesn't take any parameter + +9 +00:00:25,750 --> 00:00:29,900 +as private. In this way other classes cannot create instances + +10 +00:00:29,900 --> 00:00:33,310 +of Singleton without calling our factory method, and finally we + +11 +00:00:33,310 --> 00:00:35,650 +create the factory method. And the factory method is very + +12 +00:00:35,650 --> 00:00:38,600 +simple. The method will first check whether an instance of + +13 +00:00:38,600 --> 00:00:40,970 +the class was already created. If it was created, it + +14 +00:00:40,970 --> 00:00:44,010 +would just return that instance. Otherwise, it will create a + +15 +00:00:44,010 --> 00:00:47,550 +new instance and assign it to that instance member variable + +16 +00:00:47,550 --> 00:00:50,960 +and then return the newly created instance. So with this code + +17 +00:00:50,960 --> 00:00:53,540 +you're guaranteed that other classes cannot bypass the factory + +18 +00:00:53,540 --> 00:00:56,530 +method, because the default constructor is private. And the that + +19 +00:00:56,530 --> 00:00:59,600 +the factory method will create one and only one instance + +20 +00:00:59,600 --> 00:01:02,020 +of the class, which is exactly what our requirements were. diff --git a/usth/ICT2.7/P3L3 Design Patterns Subtitles/13 - Negative Design Patterns - lang_en_vs4.srt b/usth/ICT2.7/P3L3 Design Patterns Subtitles/13 - Negative Design Patterns - lang_en_vs4.srt new file mode 100644 index 0000000..6433019 --- /dev/null +++ b/usth/ICT2.7/P3L3 Design Patterns Subtitles/13 - Negative Design Patterns - lang_en_vs4.srt @@ -0,0 +1,51 @@ +1 +00:00:00,100 --> 00:00:02,210 +To conclude this lesson, I want to discuss the + +2 +00:00:02,210 --> 00:00:06,170 +concept of negative design patterns, that is, patterns that should + +3 +00:00:06,170 --> 00:00:09,600 +be avoided. Interestingly, negative patterns were also mentioned in + +4 +00:00:09,600 --> 00:00:12,950 +Christopher Alexander's book, so in the first formulation of patterns. + +5 +00:00:12,950 --> 00:00:16,219 +So negative design pattern are basically guidelines on how + +6 +00:00:16,219 --> 00:00:19,689 +not to do things. In consoles with patterns, the guidelines + +7 +00:00:19,689 --> 00:00:21,920 +on how to do things. So basically, what the negative + +8 +00:00:21,920 --> 00:00:25,170 +design patterns do is, they enable recurring design defects to + +9 +00:00:25,170 --> 00:00:28,070 +be avoided. And as we will see in this class extensively, + +10 +00:00:28,070 --> 00:00:30,080 +in mini-course four, negative patterns are + +11 +00:00:30,080 --> 00:00:33,380 +also called anti-patterns or bad smells, + +12 +00:00:33,380 --> 00:00:36,540 +or bad code smells. So in mini-course four we will see several + +13 +00:00:36,540 --> 00:00:39,480 +examples of bad smells and what we can do to eliminate them. diff --git a/usth/ICT2.7/P3L3 Design Patterns Subtitles/2 - History of Design Patterns - lang_en_vs6.srt b/usth/ICT2.7/P3L3 Design Patterns Subtitles/2 - History of Design Patterns - lang_en_vs6.srt new file mode 100644 index 0000000..5fbb886 --- /dev/null +++ b/usth/ICT2.7/P3L3 Design Patterns Subtitles/2 - History of Design Patterns - lang_en_vs6.srt @@ -0,0 +1,179 @@ +1 +00:00:00,160 --> 00:00:02,780 +Let's start our decision of design patterns by looking + +2 +00:00:02,780 --> 00:00:05,280 +at the history of patterns. As you know, I like + +3 +00:00:05,280 --> 00:00:07,810 +to give this sort of historical perspective on how and + +4 +00:00:07,810 --> 00:00:10,600 +when concepts were defined. In this case, we have to + +5 +00:00:10,600 --> 00:00:14,830 +go back to 1977, when Christopher Alexander, an American professor + +6 +00:00:14,830 --> 00:00:18,300 +of architecture at UC Berkeley, introduces the idea of patterns, + +7 +00:00:18,300 --> 00:00:21,700 +successful solutions to problems, in his book called a Pattern + +8 +00:00:21,700 --> 00:00:25,640 +Language. The book contains about 250 patterns. And the idea + +9 +00:00:25,640 --> 00:00:27,700 +is that occupants of a building should be able + +10 +00:00:27,700 --> 00:00:30,110 +to design it. And the patterns in the book provide + +11 +00:00:30,110 --> 00:00:32,368 +a way to do that. And this idea of design + +12 +00:00:32,368 --> 00:00:35,964 +patterns, so, a formal way of documenting successful solutions to + +13 +00:00:35,964 --> 00:00:41,200 +problems, inspired several other disciplines. In particular, in 1987, + +14 +00:00:41,200 --> 00:00:44,810 +Ward Cunningham and Kent Beck leveraged this idea of Alexander's + +15 +00:00:44,810 --> 00:00:48,360 +patterns in the context of an object oriented language. + +16 +00:00:48,360 --> 00:00:50,840 +And in this specific the language was Smalltalk. + +17 +00:00:50,840 --> 00:00:52,666 +Some of you might know the language. So what Cunningham + +18 +00:00:54,492 --> 00:00:56,320 +and Beck did, was to create a 5 pattern + +19 +00:00:56,320 --> 00:00:59,880 +language for guiding novice Smalltalk programmers. So they did + +20 +00:00:59,880 --> 00:01:03,090 +an experiment and had several developers using their patterns, and + +21 +00:01:03,090 --> 00:01:06,330 +the experiment was extremely successful. The users were able to + +22 +00:01:06,330 --> 00:01:09,940 +create elegant designs using the provided patterns. And in case + +23 +00:01:09,940 --> 00:01:12,210 +you are interested in reading about it, Cunningham and Beck + +24 +00:01:12,210 --> 00:01:15,660 +reported the results in the article, Using Pattern Languages for + +25 +00:01:15,660 --> 00:01:17,940 +Object Oriented Programs, which was published at the + +26 +00:01:17,940 --> 00:01:21,854 +International Conference on Object Oriented Programming, Systems, Languages, and + +27 +00:01:21,854 --> 00:01:25,390 +Applications, also called OOPSLA, in 1987. At the + +28 +00:01:25,390 --> 00:01:28,480 +same time, Eric Gamma was working on his dissertation, + +29 +00:01:28,480 --> 00:01:31,030 +whose topic was the importance of patterns and + +30 +00:01:31,030 --> 00:01:34,430 +how to capture them. Between 1987 and 1992, there + +31 +00:01:34,430 --> 00:01:37,520 +were several workshops related to design patterns. And + +32 +00:01:37,520 --> 00:01:40,740 +in 1992, Jim Coplien compiled a catalog of C++ + +33 +00:01:40,740 --> 00:01:43,140 +items, which are some sort of patterns, and + +34 +00:01:43,140 --> 00:01:45,130 +he listed this catalog of patterns in his + +35 +00:01:45,130 --> 00:01:48,720 +book, which was titled Advanced C++ Programming Styles + +36 +00:01:48,720 --> 00:01:52,952 +and Idioms. Finally, in 1993 and 1994, there were + +37 +00:01:52,952 --> 00:01:56,160 +several additional workshops focused on patterns. And this + +38 +00:01:56,160 --> 00:01:59,625 +workshop brought together many patterns folks, including these + +39 +00:01:59,625 --> 00:02:03,040 +4 guys, Erich Gamma, Richard Helm, Ralph Johnson, + +40 +00:02:03,040 --> 00:02:06,040 +and John Vlissides. These guys are also known as + +41 +00:02:06,040 --> 00:02:08,970 +the gang of 4. And the result of this collaboration was the + +42 +00:02:08,970 --> 00:02:11,840 +famous book Design Patterns: Elements of + +43 +00:02:11,840 --> 00:02:14,320 +Reusable Object Oriented Software. So this + +44 +00:02:14,320 --> 00:02:17,640 +is basically The Book on design patterns. If you want to buy + +45 +00:02:17,640 --> 00:02:19,780 +a book on design pattern, this is the one you should get. diff --git a/usth/ICT2.7/P3L3 Design Patterns Subtitles/3 - Patterns Catalogue - lang_en_vs4.srt b/usth/ICT2.7/P3L3 Design Patterns Subtitles/3 - Patterns Catalogue - lang_en_vs4.srt new file mode 100644 index 0000000..764a309 --- /dev/null +++ b/usth/ICT2.7/P3L3 Design Patterns Subtitles/3 - Patterns Catalogue - lang_en_vs4.srt @@ -0,0 +1,79 @@ +1 +00:00:00,230 --> 00:00:03,380 +This book contains a patterns catalog which is + +2 +00:00:03,380 --> 00:00:06,725 +a number of design patterns classified by purpose. And + +3 +00:00:06,725 --> 00:00:09,122 +there are five main classes of patterns. There are + +4 +00:00:09,122 --> 00:00:11,890 +fundamental patterns which are the basic patterns. There are + +5 +00:00:11,890 --> 00:00:15,170 +creational patterns which are the patterns that support object + +6 +00:00:15,170 --> 00:00:18,290 +creation. Then there are structural patterns and these are + +7 +00:00:18,290 --> 00:00:22,090 +patterns that help compose objects, put objects together. The + +8 +00:00:22,090 --> 00:00:25,280 +next class of patterns are behavioral patterns and these + +9 +00:00:25,280 --> 00:00:28,840 +are patterns that are mostly focused on realizing interactions + +10 +00:00:28,840 --> 00:00:32,820 +among different objects. Finally, there are concurrency patterns and these + +11 +00:00:32,820 --> 00:00:36,400 +are patterns that support, as the name says, concurrency, so + +12 +00:00:36,400 --> 00:00:39,700 +they're more related to concurrency aspects. And for each of + +13 +00:00:39,700 --> 00:00:43,560 +these classes there are a number of specific patterns, and + +14 +00:00:43,560 --> 00:00:46,130 +here I'm just listing some of them. Clearly we cannot + +15 +00:00:46,130 --> 00:00:48,740 +cover in one lesson all of these patterns, but what + +16 +00:00:48,740 --> 00:00:50,440 +I want to do is to cover at least a few + +17 +00:00:50,440 --> 00:00:52,670 +of those to give an idea of what patterns are and + +18 +00:00:52,670 --> 00:00:55,430 +how they can be used. In particular, we will see in + +19 +00:00:55,430 --> 00:00:59,200 +detail the Factory Method Pattern and the Strategy Pattern. And we + +20 +00:00:59,200 --> 00:01:01,590 +will also discuss a few more patterns at a higher level. diff --git a/usth/ICT2.7/P3L3 Design Patterns Subtitles/4 - Pattern Format - lang_en_vs5.srt b/usth/ICT2.7/P3L3 Design Patterns Subtitles/4 - Pattern Format - lang_en_vs5.srt new file mode 100644 index 0000000..7df86c0 --- /dev/null +++ b/usth/ICT2.7/P3L3 Design Patterns Subtitles/4 - Pattern Format - lang_en_vs5.srt @@ -0,0 +1,71 @@ +1 +00:00:00,180 --> 00:00:02,711 +So let's start by seeing how patterns are defined. So + +2 +00:00:02,711 --> 00:00:05,620 +what is the format of the pattern definitions. If we look + +3 +00:00:05,620 --> 00:00:08,000 +at the Gang of Four's book we can see that these + +4 +00:00:08,000 --> 00:00:11,630 +definitions contain a lot of information. In fact, what I'm listing + +5 +00:00:11,630 --> 00:00:14,980 +here is just a subset of this information. In this lesson, + +6 +00:00:14,980 --> 00:00:17,510 +what I want to do is to focus on four essential + +7 +00:00:17,510 --> 00:00:21,480 +elements of a design pattern. It's name, the intent which is + +8 +00:00:21,480 --> 00:00:25,270 +the goal of the pattern. The pattern's applicability which is the + +9 +00:00:25,270 --> 00:00:28,040 +list of situations or context in which the + +10 +00:00:28,040 --> 00:00:31,560 +pattern is applicable. I also want to cover the structure + +11 +00:00:31,560 --> 00:00:34,700 +and participants. Which is the static model that describes + +12 +00:00:34,700 --> 00:00:37,870 +the elements, so normally the classes or the object + +13 +00:00:37,870 --> 00:00:39,900 +involved in the pattern. In addition to that + +14 +00:00:39,900 --> 00:00:41,400 +the structure also describes + +15 +00:00:41,400 --> 00:00:44,420 +the relationships, responsibilities and collaborations + +16 +00:00:44,420 --> 00:00:47,264 +among these classes or objects. Finally what I want + +17 +00:00:47,264 --> 00:00:50,560 +to cover is sample code. So examples that illustrate + +18 +00:00:50,560 --> 00:00:51,490 +the use of patterns. diff --git a/usth/ICT2.7/P3L3 Design Patterns Subtitles/5 - Factory Method Pattern - lang_en_vs5.srt b/usth/ICT2.7/P3L3 Design Patterns Subtitles/5 - Factory Method Pattern - lang_en_vs5.srt new file mode 100644 index 0000000..c7ebddd --- /dev/null +++ b/usth/ICT2.7/P3L3 Design Patterns Subtitles/5 - Factory Method Pattern - lang_en_vs5.srt @@ -0,0 +1,179 @@ +1 +00:00:00,012 --> 00:00:02,350 +Let's now look at the first design pattern that we + +2 +00:00:02,350 --> 00:00:05,700 +will discuss, the factory method pattern. And I'm going to start + +3 +00:00:05,700 --> 00:00:09,220 +by discussing the intent of the pattern and its applicability. + +4 +00:00:09,220 --> 00:00:12,210 +As far as the intent is concerned, the factory method pattern + +5 +00:00:12,210 --> 00:00:16,690 +allows for creating objects without specifying their class, by invoking + +6 +00:00:16,690 --> 00:00:19,370 +what we call a factory method. And what that is, is + +7 +00:00:19,370 --> 00:00:22,680 +a method whose main goal is to create class instances. + +8 +00:00:22,680 --> 00:00:25,510 +So when is this pattern useful? So when is it applicable? + +9 +00:00:25,510 --> 00:00:28,080 +For example, it is applicable in cases in which a class + +10 +00:00:28,080 --> 00:00:31,890 +cannot anticipate the type of object it must create. That is, + +11 +00:00:31,890 --> 00:00:34,800 +the type of an object is not known at compile time, + +12 +00:00:34,800 --> 00:00:37,800 +is not known until the code runs. A typical example of + +13 +00:00:37,800 --> 00:00:40,500 +this, are frameworks. So if you ever used a framework, you + +14 +00:00:40,500 --> 00:00:44,280 +will know that, normally, frameworks only know about interfaces and abstract + +15 +00:00:44,280 --> 00:00:47,450 +classes. So the exact type of the objects of these classes + +16 +00:00:47,450 --> 00:00:50,840 +is only known at runtime. The second case in which the factory + +17 +00:00:50,840 --> 00:00:53,835 +method pattern is applicable, is when a class wants its + +18 +00:00:53,835 --> 00:00:57,160 +subclasses to specify the type of objects it creates. And we'll + +19 +00:00:57,160 --> 00:00:59,920 +see an example of this in a minute. Finally, factory + +20 +00:00:59,920 --> 00:01:03,580 +method patterns are applicable when a class needs control over the + +21 +00:01:03,580 --> 00:01:06,760 +creation of its objects. And in this case, one possible + +22 +00:01:06,760 --> 00:01:09,380 +example is when there is a limit on the number of + +23 +00:01:09,380 --> 00:01:12,930 +objects that can be created. Special example, it's a singleton. If + +24 +00:01:12,930 --> 00:01:15,840 +you're familiar with a singleton, a singleton is a class for + +25 +00:01:15,840 --> 00:01:18,930 +which only one instance can be created. The factory method pattern + +26 +00:01:18,930 --> 00:01:21,760 +is perfect in these cases, because it allows to control how many + +27 +00:01:21,760 --> 00:01:24,640 +objects get created. So in this case, it would allow the creation + +28 +00:01:24,640 --> 00:01:27,290 +only of a single object. And from the second time that it + +29 +00:01:27,290 --> 00:01:30,040 +is invoked, it will just return the object that was previously + +30 +00:01:30,040 --> 00:01:33,700 +created. Now let's go ahead and see how this pattern actually works, + +31 +00:01:33,700 --> 00:01:37,100 +and let's do that by discussing the structure and the participants for + +32 +00:01:37,100 --> 00:01:41,330 +the pattern. The structure that is represented here, using the UML notation, + +33 +00:01:41,330 --> 00:01:45,530 +includes three classes, the Creator, the ConcreteCreator, + +34 +00:01:45,530 --> 00:01:48,000 +and the Product. The Creator provides the + +35 +00:01:48,000 --> 00:01:50,710 +interface for the factory method. So this + +36 +00:01:50,710 --> 00:01:53,200 +here, is the interface for the factory method + +37 +00:01:53,200 --> 00:01:55,950 +that, when invoked, returns an object of + +38 +00:01:55,950 --> 00:01:59,440 +type Product. The ConcreteCreator provides the actual + +39 +00:01:59,440 --> 00:02:02,350 +method for creating the Product. So this + +40 +00:02:02,350 --> 00:02:06,170 +method is a concrete implementation of this interface. + +41 +00:02:06,170 --> 00:02:10,630 +Finally, the Product is the object created by the factory method. So + +42 +00:02:10,630 --> 00:02:12,350 +summarizing, we have the interface for + +43 +00:02:12,350 --> 00:02:14,300 +the factory method, the actual implementation of + +44 +00:02:14,300 --> 00:02:17,540 +the summary method, and the object that is created by the factory method, + +45 +00:02:17,540 --> 00:02:21,020 +when it is invoked. So let's look at an example of this pattern. diff --git a/usth/ICT2.7/P3L3 Design Patterns Subtitles/6 - Factory Method Pattern Example - lang_en_vs5.srt b/usth/ICT2.7/P3L3 Design Patterns Subtitles/6 - Factory Method Pattern Example - lang_en_vs5.srt new file mode 100644 index 0000000..2812c39 --- /dev/null +++ b/usth/ICT2.7/P3L3 Design Patterns Subtitles/6 - Factory Method Pattern Example - lang_en_vs5.srt @@ -0,0 +1,127 @@ +1 +00:00:00,220 --> 00:00:03,260 +The example I'm going to use consists of a class called + +2 +00:00:03,260 --> 00:00:07,380 +ImageReaderFactory which provides the factory method which is this one; + +3 +00:00:07,380 --> 00:00:10,250 +createImageReader. As you can see the method takes an InputStream + +4 +00:00:10,250 --> 00:00:13,570 +as input and returns an object of type ImageReader, and it's + +5 +00:00:13,570 --> 00:00:15,645 +static so that we can invoke it even if we + +6 +00:00:15,645 --> 00:00:18,390 +don't have an instance of the ImageReaderFactory. So what does the + +7 +00:00:18,390 --> 00:00:22,275 +method do? Well the method first invokes, getImageType, passing the + +8 +00:00:22,275 --> 00:00:25,780 +InputStream as a parameter and this method figures out the type + +9 +00:00:25,780 --> 00:00:28,820 +of the image that is stored in this Inputstream and it's + +10 +00:00:28,820 --> 00:00:32,740 +an integer. Then, based on the value of this integer, the + +11 +00:00:32,740 --> 00:00:35,352 +method does one of several things. If the image type is + +12 +00:00:35,352 --> 00:00:38,970 +a GIF, it will invoke the constructor for GifReader passing the + +13 +00:00:38,970 --> 00:00:41,610 +stream as a parameter. And what will happen is that the + +14 +00:00:41,610 --> 00:00:44,450 +GIF reader will read a GIF from the stream, create a + +15 +00:00:44,450 --> 00:00:47,887 +corresponding object and return it. So in this case, the ImageReader + +16 +00:00:47,887 --> 00:00:51,460 +object return will be the object representing a GIF as appropriate. + +17 +00:00:51,460 --> 00:00:54,610 +Similarly, if the image type is JPEG, then the method will + +18 +00:00:54,610 --> 00:00:58,579 +invoke the constructor for JPEG Reader and in this case, this constructor + +19 +00:00:58,579 --> 00:01:01,981 +will read from the stream a JPEG, create a corresponding object + +20 +00:01:01,981 --> 00:01:05,640 +and return it. And so on for different types of images. So + +21 +00:01:05,640 --> 00:01:07,880 +why is this a situation in which it is appropriate to + +22 +00:01:07,880 --> 00:01:11,100 +use the factory method pattern? One, because it corresponds exactly to the + +23 +00:01:11,100 --> 00:01:14,250 +cases that we saw before, of applicability. This is a case + +24 +00:01:14,250 --> 00:01:16,560 +in which we don't know the type of the object that we + +25 +00:01:16,560 --> 00:01:20,080 +need to create until we run the code, because it depends + +26 +00:01:20,080 --> 00:01:22,530 +on the value of the InputStream. It depends on the content + +27 +00:01:22,530 --> 00:01:25,590 +of the InputStream. So, until we read the InputStream, we cannot + +28 +00:01:25,590 --> 00:01:28,380 +figure out whether we need to create a GIF, a JPEG or + +29 +00:01:28,380 --> 00:01:30,780 +some other type of image. So in this case, we want to + +30 +00:01:30,780 --> 00:01:33,630 +do, we want to simply delegate to this classes the creation of + +31 +00:01:33,630 --> 00:01:35,610 +the object, once we know what type of object needs to + +32 +00:01:35,610 --> 00:01:38,790 +be created. So perfect example of application of a factory method pattern. diff --git a/usth/ICT2.7/P3L3 Design Patterns Subtitles/7 - Strategy Pattern - lang_en_vs5.srt b/usth/ICT2.7/P3L3 Design Patterns Subtitles/7 - Strategy Pattern - lang_en_vs5.srt new file mode 100644 index 0000000..288b8d6 --- /dev/null +++ b/usth/ICT2.7/P3L3 Design Patterns Subtitles/7 - Strategy Pattern - lang_en_vs5.srt @@ -0,0 +1,143 @@ +1 +00:00:00,230 --> 00:00:02,110 +The second pattern I want to discuss is the + +2 +00:00:02,110 --> 00:00:05,050 +strategy pattern, which provides a way to configure a + +3 +00:00:05,050 --> 00:00:07,900 +class with one of many behaviors. What does that + +4 +00:00:07,900 --> 00:00:11,040 +mean? Well, more precisely, this pattern allows for defining + +5 +00:00:11,040 --> 00:00:15,330 +a family of algorithms, encapsulating them into separate classes, + +6 +00:00:15,330 --> 00:00:17,900 +so each algorithm in one class, and making these + +7 +00:00:17,900 --> 00:00:21,490 +classes interchangeable, but providing a common interface for all + +8 +00:00:21,490 --> 00:00:25,350 +the encapsulated algorithms. So in essence, the intent of + +9 +00:00:25,350 --> 00:00:29,250 +a strategy pattern is to allow for switching between + +10 +00:00:29,250 --> 00:00:33,490 +different algorithms for accomplishing a given task. For example, imagine + +11 +00:00:33,490 --> 00:00:36,610 +having different sorting algorithms with different space or time + +12 +00:00:36,610 --> 00:00:38,800 +tradeoffs. You might want to be able to have them + +13 +00:00:38,800 --> 00:00:42,670 +all available and use different ones in different situations. + +14 +00:00:42,670 --> 00:00:44,820 +And this pattern is applicable not only when we have + +15 +00:00:44,820 --> 00:00:47,260 +different variants of an algorithm, but also when we + +16 +00:00:47,260 --> 00:00:51,690 +have many related classes that differ only in their behavior. + +17 +00:00:51,690 --> 00:00:53,640 +So let's get more concrete and see how this is + +18 +00:00:53,640 --> 00:00:55,960 +done. And I'm going to do it as before, by + +19 +00:00:55,960 --> 00:00:59,700 +discussing the structure and the participants for this strategy pattern. + +20 +00:00:59,700 --> 00:01:02,540 +In this case, we have 3 types of participants for this + +21 +00:01:02,540 --> 00:01:07,210 +pattern, the context, the algorithm, and the concrete strategies. There + +22 +00:01:07,210 --> 00:01:09,580 +can be as many as the number of behaviors that + +23 +00:01:09,580 --> 00:01:12,300 +I need to implement. So, let's see what those are. + +24 +00:01:12,300 --> 00:01:16,690 +The context is the interface to the outside world. It maintains + +25 +00:01:16,690 --> 00:01:19,180 +a reference to the current algorithm and allows for + +26 +00:01:19,180 --> 00:01:22,860 +updating this reference at run time. So, basically the outside + +27 +00:01:22,860 --> 00:01:26,370 +world will invoke the functionality provided by the different algorithms, + +28 +00:01:26,370 --> 00:01:29,170 +by using this interface. And depending on which algorithm is + +29 +00:01:29,170 --> 00:01:31,640 +currently selected, that's the one that will be executed when + +30 +00:01:31,640 --> 00:01:35,920 +the functionality is involved. The algorithm, also called the strategy, + +31 +00:01:35,920 --> 00:01:37,970 +so that's where the pattern gets its name, Is the + +32 +00:01:37,970 --> 00:01:42,130 +common interface for the different algorithims. So all the algorithms + +33 +00:01:42,130 --> 00:01:46,690 +implement this interface. Finally, the concrete strategies are the + +34 +00:01:46,690 --> 00:01:49,920 +actual implementations of the algorithms. So if I have 10 + +35 +00:01:49,920 --> 00:01:53,030 +different variants of my algorithm, I will implement 10 different + +36 +00:01:53,030 --> 00:01:56,550 +concrete strategies. They will all be implementations of this interface. diff --git a/usth/ICT2.7/P3L3 Design Patterns Subtitles/8 - Strategy Pattern Example & Demo - lang_en_vs5.srt b/usth/ICT2.7/P3L3 Design Patterns Subtitles/8 - Strategy Pattern Example & Demo - lang_en_vs5.srt new file mode 100644 index 0000000..6d298d0 --- /dev/null +++ b/usth/ICT2.7/P3L3 Design Patterns Subtitles/8 - Strategy Pattern Example & Demo - lang_en_vs5.srt @@ -0,0 +1,511 @@ +1 +00:00:00,130 --> 00:00:03,320 +Now let's see how this whole thing works in practice by + +2 +00:00:03,320 --> 00:00:06,800 +using an example. We're going to consider a program that takes as + +3 +00:00:06,800 --> 00:00:10,450 +input a text file and produce it as output, a filtered + +4 +00:00:10,450 --> 00:00:14,170 +file. So basically it outputs a subset of the content of + +5 +00:00:14,170 --> 00:00:16,928 +this text file based on some filter. And we're going to have + +6 +00:00:16,928 --> 00:00:19,440 +four different types of filters. So the first one is + +7 +00:00:19,440 --> 00:00:21,680 +not filtering which means that the whole content of the text + +8 +00:00:21,680 --> 00:00:25,320 +file will be produced on the output. The second filter will output + +9 +00:00:25,320 --> 00:00:27,990 +only words that starts with t. So you'll take the text file + +10 +00:00:27,990 --> 00:00:30,540 +and simply ignore all of the words that do not start with + +11 +00:00:30,540 --> 00:00:33,130 +t. So in the output we'll have only those words that starts + +12 +00:00:33,130 --> 00:00:36,030 +with letter t. The third filter will produce in the output only + +13 +00:00:36,030 --> 00:00:39,180 +words that are longer than five characters. So all the other words + +14 +00:00:39,180 --> 00:00:43,740 +will be simply disregarded. And finally, the four filter will produce as + +15 +00:00:43,740 --> 00:00:47,630 +output only words in the text file that are palindromes, and in + +16 +00:00:47,630 --> 00:00:50,590 +case you don't know what a palindrome is, a palindrome is a word + +17 +00:00:50,590 --> 00:00:52,700 +that is the same whether you read it from left + +18 +00:00:52,700 --> 00:00:55,800 +to right or from right to left. For example, the + +19 +00:00:55,800 --> 00:00:58,480 +word kayak, you can read it in this direction, or + +20 +00:00:58,480 --> 00:01:00,740 +in this direction, and it's exactly the same word. So + +21 +00:01:00,740 --> 00:01:03,560 +let's see how this program could be implemented using a + +22 +00:01:03,560 --> 00:01:05,980 +strategy pattern. And let's do it for real as a + +23 +00:01:05,980 --> 00:01:10,100 +demo. What we're looking at here is the editor page + +24 +00:01:10,100 --> 00:01:15,520 +for Eclipse, open with the strategy pattern implementation for our example. + +25 +00:01:15,520 --> 00:01:17,130 +So what I'm going to do is that, I'm going to look at a + +26 +00:01:17,130 --> 00:01:20,310 +different part of implementation. And you will see that, you know, despite + +27 +00:01:20,310 --> 00:01:23,420 +the fact that it's slightly longer, it's really fairly simple, it's kind + +28 +00:01:23,420 --> 00:01:26,230 +of a straightforward implementation of what we just saw. As I just + +29 +00:01:26,230 --> 00:01:29,820 +said, what we are doing is basically building the strategy patterns that + +30 +00:01:29,820 --> 00:01:34,330 +allows for changing the strategies with which we're filtering an input file. + +31 +00:01:34,330 --> 00:01:37,380 +And we have different strategies, we'll look at those in detail, and + +32 +00:01:37,380 --> 00:01:41,050 +we said that the three participants for this pattern are the context, + +33 +00:01:41,050 --> 00:01:43,650 +the algorithm, which is the general interface and then the concrete + +34 +00:01:43,650 --> 00:01:47,270 +strategies, which are the concrete implementations of this algorithm. So let's + +35 +00:01:47,270 --> 00:01:49,790 +start by looking at the context. Which is this class here. + +36 +00:01:49,790 --> 00:01:52,960 +And as you can see it contains a reference at the current + +37 +00:01:52,960 --> 00:01:56,240 +strategy. We call this the check strategy, which is basically our + +38 +00:01:56,240 --> 00:01:59,910 +filter, and when the context is created by default it sets a + +39 +00:01:59,910 --> 00:02:02,890 +strategy to the old strategy. The old strategy is the one + +40 +00:02:02,890 --> 00:02:06,380 +that accepts all the input, so basically it doesn't filter out anything. + +41 +00:02:06,380 --> 00:02:08,320 +And we said that the context is the interface to the + +42 +00:02:08,320 --> 00:02:10,889 +outside world, right? So it has to provide the outside world + +43 +00:02:10,889 --> 00:02:14,140 +with a way of selecting the strategy, the specific algorithm to + +44 +00:02:14,140 --> 00:02:16,850 +be used, and it does that in this case by providing + +45 +00:02:16,850 --> 00:02:21,360 +this change strategy method. This method takes a strategy as input, + +46 +00:02:21,360 --> 00:02:24,930 +and simply replaces the current strategy with the one specified as + +47 +00:02:24,930 --> 00:02:28,035 +a parameter. And at this point, the context also will perform + +48 +00:02:28,035 --> 00:02:31,830 +the filtering. The filtering is pretty straightforward, so what it does is + +49 +00:02:31,830 --> 00:02:34,620 +that it opens a file that is passed as a parameter + +50 +00:02:34,620 --> 00:02:37,450 +so that this the file, the input file to be filtered. And + +51 +00:02:37,450 --> 00:02:40,560 +then it reads the file line by line and then splits + +52 +00:02:40,560 --> 00:02:43,620 +the lines into its composing words and then for each word in + +53 +00:02:43,620 --> 00:02:46,480 +each line, what it will do, it will basically invoke the + +54 +00:02:46,480 --> 00:02:50,270 +check method in the current strategy, which is basically the filtering method + +55 +00:02:50,270 --> 00:02:53,580 +and if the check method returns true, which basically means that + +56 +00:02:53,580 --> 00:02:57,150 +the word should be printed, it prints the word. Otherwise, it'll just + +57 +00:02:57,150 --> 00:03:00,480 +skip it. So basically the filter will return false for all the + +58 +00:03:00,480 --> 00:03:03,470 +words that have to be filtered out. Okay? This is the basic + +59 +00:03:03,470 --> 00:03:06,770 +way in which context works. Let's see how this is used in + +60 +00:03:06,770 --> 00:03:10,660 +our main method. The main method simply creates the context, reads the input file + +61 +00:03:10,660 --> 00:03:12,910 +from the arguments, and then what he does is simply as a + +62 +00:03:12,910 --> 00:03:16,720 +demonstration, it will perform the filtering using all the different filters. So + +63 +00:03:16,720 --> 00:03:19,310 +starting from the default one, which is the one that basically doesn't + +64 +00:03:19,310 --> 00:03:22,150 +do any filtering that reports all words, then it will switch to the + +65 +00:03:22,150 --> 00:03:25,400 +algorithm, that only considers the words that start with t, and + +66 +00:03:25,400 --> 00:03:28,880 +it will do that by invoking a change strategy and passing this + +67 +00:03:28,880 --> 00:03:30,890 +strategy as the argument, and then + +68 +00:03:30,890 --> 00:03:32,760 +performing the actual filtering through context. + +69 +00:03:32,760 --> 00:03:35,040 +And it will do exactly the same for the strategy that only + +70 +00:03:35,040 --> 00:03:37,540 +prints words that are longer than five and the one that + +71 +00:03:37,540 --> 00:03:40,460 +only prints words that are palindromes. So now let's look at the + +72 +00:03:40,460 --> 00:03:44,090 +actual algorithm. This is the interface, the algorithm interface. And you can + +73 +00:03:44,090 --> 00:03:47,080 +see that the only thing that the interface provides is this method, + +74 +00:03:47,080 --> 00:03:49,760 +which is the check method, that takes a string as input and will + +75 +00:03:49,760 --> 00:03:52,470 +return a boolean. So, basically, it's the boolean that we were seeing before. + +76 +00:03:52,470 --> 00:03:55,010 +The one that is true for the words that have to be printed + +77 +00:03:55,010 --> 00:03:57,490 +and false for the ones that have to be filtered out. Now, we have + +78 +00:03:57,490 --> 00:04:01,250 +all the different implementations of the algorithm, the simplest one is the all + +79 +00:04:01,250 --> 00:04:05,110 +algorithm, the simple return is always true, so all the words will be printed. + +80 +00:04:05,110 --> 00:04:08,740 +The second one starts with t, and again, without looking at the details + +81 +00:04:08,740 --> 00:04:10,660 +of implementations that don't really matter, what + +82 +00:04:10,660 --> 00:04:12,390 +it does is basically check that + +83 +00:04:12,390 --> 00:04:15,111 +the first character is t, and returns true in that case and + +84 +00:04:15,111 --> 00:04:17,720 +false otherwise. Similarly, for the LongerThan5 + +85 +00:04:17,720 --> 00:04:19,380 +algorithm, also in this case, this + +86 +00:04:19,380 --> 00:04:23,000 +will implement the check strategy interface, and the check will be performed + +87 +00:04:23,000 --> 00:04:25,980 +by checking that the word is longer than five characters and returning + +88 +00:04:25,980 --> 00:04:29,440 +true in that case and false otherwise. And finally the Palindrome check + +89 +00:04:29,440 --> 00:04:32,240 +is a little more complicated, but basically it just checks whether the + +90 +00:04:32,240 --> 00:04:35,190 +word is a Palindrome and returns true in that case. Okay, so + +91 +00:04:35,190 --> 00:04:37,950 +as I said, it doesn't really matter too much what is the specific + +92 +00:04:37,950 --> 00:04:40,630 +implementations of these matters. What matters is that we have + +93 +00:04:40,630 --> 00:04:44,150 +a general interface for the algorithm and then any different concrete + +94 +00:04:44,150 --> 00:04:48,130 +implementations of the algorithm that implement different strategies. So again, + +95 +00:04:48,130 --> 00:04:50,730 +this allows you to change the behavior of your class without + +96 +00:04:50,730 --> 00:04:53,420 +changing class. So we have this context class that does + +97 +00:04:53,420 --> 00:04:57,015 +different things when the filter method in invoked, depending on what + +98 +00:04:57,015 --> 00:04:59,930 +is the current strategy. So the behavior of the class can + +99 +00:04:59,930 --> 00:05:03,310 +change dynamically, and it changes dynamically every time that we change + +100 +00:05:03,310 --> 00:05:06,300 +the strategy. At this point, the way this whole thing works should + +101 +00:05:06,300 --> 00:05:08,430 +be clear, so what we're going to do is that we're going to go to + +102 +00:05:08,430 --> 00:05:12,010 +our console, and we're actually going to run the strategy pattern and see + +103 +00:05:12,010 --> 00:05:15,710 +what happens. So here I have a file, it's called foo.txt. And if + +104 +00:05:15,710 --> 00:05:18,290 +we look at the content of foo, you can see that it + +105 +00:05:18,290 --> 00:05:21,190 +says that this is just a test to assess how well this program + +106 +00:05:21,190 --> 00:05:24,430 +performs when used on files of text. And since it checks for + +107 +00:05:24,430 --> 00:05:28,560 +palindromes, we will also insert one such word, level. Level is a palindrome, + +108 +00:05:28,560 --> 00:05:31,042 +because you can read it from both sides. Okay, so let's + +109 +00:05:31,042 --> 00:05:33,657 +see what happens when we run our code. So we're going to + +110 +00:05:33,657 --> 00:05:36,900 +run java pattern.strategy.StrategyPattern which is + +111 +00:05:36,900 --> 00:05:38,550 +our class, and we going to fetch + +112 +00:05:38,550 --> 00:05:41,460 +foo.txt as an input, and let's go back to the beginning + +113 +00:05:41,460 --> 00:05:43,980 +of the output to see what happened exactly. You can see + +114 +00:05:43,980 --> 00:05:48,040 +here that for the default strategy, which was the old strategy, + +115 +00:05:48,040 --> 00:05:50,810 +the whole file is printed, so every word is printed. This + +116 +00:05:50,810 --> 00:05:53,485 +is just a test to assess and so on and so forth, + +117 +00:05:53,485 --> 00:05:57,290 +as expected. For the filter that only prints words that + +118 +00:05:57,290 --> 00:06:00,230 +start with t, only words that start with t are printed, + +119 +00:06:00,230 --> 00:06:04,180 +again, as expected. Similarly, for the filter that only prints words + +120 +00:06:04,180 --> 00:06:06,970 +that are longer than 5, and finally for the one that prints + +121 +00:06:06,970 --> 00:06:09,540 +palindromes. And here you can see that we actually have two + +122 +00:06:09,540 --> 00:06:12,410 +because the way in which this is implemented we'll also consider + +123 +00:06:12,410 --> 00:06:15,300 +single letter words as palindromes because you can read them from + +124 +00:06:15,300 --> 00:06:18,450 +both sides. But you definitely will also have level in the output. + +125 +00:06:18,450 --> 00:06:21,040 +And in case you want to play with this code yourself, I + +126 +00:06:21,040 --> 00:06:24,600 +have made this code and also the implementation for examples of other + +127 +00:06:24,600 --> 00:06:28,440 +design partners available as a compressed archive. And the archive is accessible + +128 +00:06:28,440 --> 00:06:31,120 +through a URL that is provided in the notes for the cost. diff --git a/usth/ICT2.7/P3L3 Design Patterns Subtitles/9 - Other Common Patterns - lang_en_vs5.srt b/usth/ICT2.7/P3L3 Design Patterns Subtitles/9 - Other Common Patterns - lang_en_vs5.srt new file mode 100644 index 0000000..756f38f --- /dev/null +++ b/usth/ICT2.7/P3L3 Design Patterns Subtitles/9 - Other Common Patterns - lang_en_vs5.srt @@ -0,0 +1,295 @@ +1 +00:00:00,060 --> 00:00:03,460 +Before concluding this lesson, let's look at a few more patterns. And + +2 +00:00:03,460 --> 00:00:05,880 +although it will take too long to cover them in detail, I + +3 +00:00:05,880 --> 00:00:08,986 +would like to at least mention and quickly discuss a few more + +4 +00:00:08,986 --> 00:00:12,080 +of these more commonly-used patterns. In fact, some of the patterns that + +5 +00:00:12,080 --> 00:00:15,400 +I will discuss, you might have used yourself. Maybe without knowing their + +6 +00:00:15,400 --> 00:00:18,300 +name or the fact that they were design patterns. So let's start + +7 +00:00:18,300 --> 00:00:21,660 +with a Visitor pattern, which is a way of separating an algorithm + +8 +00:00:21,660 --> 00:00:25,150 +from an object structure on which it operates. And a practical result + +9 +00:00:25,150 --> 00:00:28,010 +of this separation is the ability to add the new operation + +10 +00:00:28,010 --> 00:00:31,680 +to exist in object structures, without modifying the structures. So, basically + +11 +00:00:31,680 --> 00:00:34,540 +what this pattern does, is to allow for defining and easily + +12 +00:00:34,540 --> 00:00:37,870 +modifying set of operations to perform on the objects of the collection. + +13 +00:00:37,870 --> 00:00:40,570 +And the typical usage of this is, for example, when you're + +14 +00:00:40,570 --> 00:00:43,140 +visiting a graph, or a set of objects, and you want + +15 +00:00:43,140 --> 00:00:46,090 +to perform some operations on these objects. By using a visitor + +16 +00:00:46,090 --> 00:00:48,410 +pattern, you can decouple the operation + +17 +00:00:48,410 --> 00:00:50,830 +from the objects. Although not straightforward, + +18 +00:00:50,830 --> 00:00:53,360 +this pattern is very, very useful. So, I really encourage you + +19 +00:00:53,360 --> 00:00:56,060 +to look at it in more detail and get familiar with it. + +20 +00:00:56,060 --> 00:00:59,040 +The second pattern I want to mention is the decorator pattern. + +21 +00:00:59,040 --> 00:01:02,820 +The decorator pattern is basically a wrapper that adds functionality to a + +22 +00:01:02,820 --> 00:01:05,030 +class. So the way in which it works, is that you + +23 +00:01:05,030 --> 00:01:08,230 +will take a class, you will build a class that basically wraps + +24 +00:01:08,230 --> 00:01:12,250 +this class. So it reproduces the functionality of the original class, but + +25 +00:01:12,250 --> 00:01:15,900 +it also adds some functionality. And for all the functionality that was + +26 +00:01:15,900 --> 00:01:18,750 +already in the original class, it will simply invoke this + +27 +00:01:18,750 --> 00:01:21,080 +functionality and for the new one, you will implement it + +28 +00:01:21,080 --> 00:01:24,510 +using the services of the class. And a nice property + +29 +00:01:24,510 --> 00:01:26,760 +of the decorator pattern is that it's stackable. So you can + +30 +00:01:26,760 --> 00:01:30,210 +add decorators on decorators on decorators, and further increase the + +31 +00:01:30,210 --> 00:01:34,052 +functionality provided by your class. The iterator is another very + +32 +00:01:34,052 --> 00:01:37,810 +commonly-used pattern. And, you probably use this one yourself because, + +33 +00:01:37,810 --> 00:01:41,090 +it's also part of many standard libraries. What the iterator allows + +34 +00:01:41,090 --> 00:01:44,220 +you to do, is basically to access elements of a collection + +35 +00:01:44,220 --> 00:01:47,490 +without knowing the underlying representation. So the iterator will allow you + +36 +00:01:47,490 --> 00:01:50,630 +to just go through a set of objects without worrying about + +37 +00:01:50,630 --> 00:01:53,200 +how the objects are stored. So you basically just ask the + +38 +00:01:53,200 --> 00:01:55,810 +iterator to give you the first object, the next object and + +39 +00:01:55,810 --> 00:02:00,130 +so on. Another very commonly-used pattern is the observer pattern. And + +40 +00:02:00,130 --> 00:02:02,650 +this pattern is very useful when you have an object of + +41 +00:02:02,650 --> 00:02:06,190 +interest and a set of other objects that are interested in + +42 +00:02:06,190 --> 00:02:09,240 +the changes that might occur in this first object. So + +43 +00:02:09,240 --> 00:02:12,690 +what the observer pattern allows you to do is to register + +44 +00:02:12,690 --> 00:02:15,460 +these objects, so that they let the system know that + +45 +00:02:15,460 --> 00:02:18,690 +they're interested in changes in this first object. And then, every + +46 +00:02:18,690 --> 00:02:20,840 +time that there is a change, these other objects will + +47 +00:02:20,840 --> 00:02:23,030 +be automatically notified. So basically, + +48 +00:02:23,030 --> 00:02:25,290 +the observer pattern allows for notifying + +49 +00:02:25,290 --> 00:02:29,310 +dependents when an object of interest changes. If you want + +50 +00:02:29,310 --> 00:02:32,020 +an example of this, just think about the file system and + +51 +00:02:32,020 --> 00:02:35,870 +imagine having a folder. All the views of this folder will + +52 +00:02:35,870 --> 00:02:37,970 +want to be notified every time that there's a change in + +53 +00:02:37,970 --> 00:02:40,720 +the folder because they need to refresh. So instead of continuously + +54 +00:02:40,720 --> 00:02:44,390 +checking the state of the folder, they will just register and basically + +55 +00:02:44,390 --> 00:02:47,430 +say, hey, we're interested in knowing when something changes in this + +56 +00:02:47,430 --> 00:02:50,320 +folder. And when something changes in the folder, they will be automatically + +57 +00:02:50,320 --> 00:02:53,300 +notified. So it will be some sort of a push notification + +58 +00:02:53,300 --> 00:02:56,590 +instead of a pull notification, if you are familiar with that terminology. + +59 +00:02:56,590 --> 00:03:00,020 +Finally the proxy pattern is a pattern in which a surrogate + +60 +00:03:00,020 --> 00:03:04,370 +controls access to an object. In other words, we have our object, + +61 +00:03:04,370 --> 00:03:07,220 +and we have our proxy here. So all the requests to the + +62 +00:03:07,220 --> 00:03:09,950 +object will go through the proxy that will then forward them. And + +63 +00:03:09,950 --> 00:03:12,020 +all the responses from the object will also go through the + +64 +00:03:12,020 --> 00:03:15,580 +proxy. They will then forward them to the original requester. So what + +65 +00:03:15,580 --> 00:03:18,710 +the proxy allows you to do is to control how this object, + +66 +00:03:18,710 --> 00:03:22,180 +that is behind the proxy, is actually accessed, for example, by filtering + +67 +00:03:22,180 --> 00:03:24,500 +some calls. So in a sense, the proxy allows use + +68 +00:03:24,500 --> 00:03:27,470 +for masking some of the functionality of the object that + +69 +00:03:27,470 --> 00:03:31,070 +is behind the proxy. And there's many, many, many more + +70 +00:03:31,070 --> 00:03:34,424 +useful patterns. That can help you when designing and implementing + +71 +00:03:34,424 --> 00:03:37,220 +the system. So once more, I really encourage you to + +72 +00:03:37,220 --> 00:03:38,740 +have a look at the book, to look at the + +73 +00:03:38,740 --> 00:03:41,570 +resources online, and to really get more familiar with these + +74 +00:03:41,570 --> 00:03:43,890 +patterns, and to try to use them in your everyday work. diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/1 - Lesson Overview - lang_en_vs4.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/1 - Lesson Overview - lang_en_vs4.srt new file mode 100644 index 0000000..4abf070 --- /dev/null +++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/1 - Lesson Overview - lang_en_vs4.srt @@ -0,0 +1,31 @@ +1 +00:00:00,770 --> 00:00:02,830 +In the previous lessons of this mini-course, + +2 +00:00:02,830 --> 00:00:06,620 +we discussed high level design, or architecture, + +3 +00:00:06,620 --> 00:00:12,380 +low level design, and design patterns. Now, we're going to see how we can put + +4 +00:00:12,380 --> 00:00:15,380 +this and also others software engineering activities + +5 +00:00:15,380 --> 00:00:18,436 +together in the context of a UML-based + +6 +00:00:18,436 --> 00:00:21,820 +process model, the unified software process, or + +7 +00:00:21,820 --> 00:00:25,580 +USP. We will discuss how USP was defined, + +8 +00:00:25,580 --> 00:00:30,492 +its main characteristics, its phases, and how we can apply it in practice. diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/10 - Iterative and Incremental - lang_en_vs6.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/10 - Iterative and Incremental - lang_en_vs6.srt new file mode 100644 index 0000000..e542660 --- /dev/null +++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/10 - Iterative and Incremental - lang_en_vs6.srt @@ -0,0 +1,147 @@ +1 +00:00:00,190 --> 00:00:03,100 +We just saw two of the three distinguishing aspects of + +2 +00:00:03,100 --> 00:00:05,800 +the rational unified process. The fact that it is used + +3 +00:00:05,800 --> 00:00:08,810 +case driven and the fact that it is architecture centric. + +4 +00:00:08,810 --> 00:00:11,950 +The third and final distinguished aspect of R.U.P. is that + +5 +00:00:11,950 --> 00:00:15,210 +it is iterative and incremental. So let's see what that + +6 +00:00:15,210 --> 00:00:18,870 +means by considering the lifetime of a software project. Basically, + +7 +00:00:18,870 --> 00:00:22,120 +the lifetime of a rational unified process consists of a + +8 +00:00:22,120 --> 00:00:24,920 +series of cycles, such as the ones that are represented here. + +9 +00:00:24,920 --> 00:00:28,070 +Cycle one, cycle two, through cycle n. And as + +10 +00:00:28,070 --> 00:00:30,990 +you can see, these cycles can also be called increments. + +11 +00:00:30,990 --> 00:00:33,280 +And each one of the cycles involves all of + +12 +00:00:33,280 --> 00:00:36,700 +the main phases of software development. In addition, each cycle + +13 +00:00:36,700 --> 00:00:39,700 +results in a product release which can be internal + +14 +00:00:39,700 --> 00:00:43,210 +or external. More precisely, each cycle terminates with a product + +15 +00:00:43,210 --> 00:00:46,340 +release that includes a complete set of artifacts for + +16 +00:00:46,340 --> 00:00:50,150 +the project. That means code, manuals, use cases, non-functional + +17 +00:00:50,150 --> 00:00:52,840 +specification, test cases, and so on. So, I've just + +18 +00:00:52,840 --> 00:00:55,760 +said, that each cycle involves all of the main phases + +19 +00:00:55,760 --> 00:00:59,440 +of software development. Specifically, each cycle is further divided + +20 +00:00:59,440 --> 00:01:04,040 +in four phases. Inception, elaboration, construction and transition. In a + +21 +00:01:04,040 --> 00:01:06,290 +minute, we will look at each one of these + +22 +00:01:06,290 --> 00:01:08,840 +phases in detail and see how they relate to the + +23 +00:01:08,840 --> 00:01:12,150 +traditional activities of software development. Before that, I want + +24 +00:01:12,150 --> 00:01:15,760 +to mention the last level of these iterations, which happens + +25 +00:01:15,760 --> 00:01:20,330 +within these individual phases More precisely, inside each of these + +26 +00:01:20,330 --> 00:01:24,230 +phases, there might be multiple iterations. So what are these + +27 +00:01:24,230 --> 00:01:28,070 +iterations? Well, basically, each iteration corresponds to a group of + +28 +00:01:28,070 --> 00:01:30,550 +use cases that are selected so as to deal with + +29 +00:01:30,550 --> 00:01:33,200 +the most important risks first. So if you have a + +30 +00:01:33,200 --> 00:01:35,510 +set of use cases that you're considering, which means that + +31 +00:01:35,510 --> 00:01:37,450 +you have a set of features that you need to + +32 +00:01:37,450 --> 00:01:41,260 +implement, you will select for each iteration the most risky + +33 +00:01:41,260 --> 00:01:44,720 +ones that you still haven't realized, and realize them in that + +34 +00:01:44,720 --> 00:01:47,720 +iteration. And then continue in the following iterations with less and + +35 +00:01:47,720 --> 00:01:50,980 +less risky ones. So basically what happens in the end is + +36 +00:01:50,980 --> 00:01:52,960 +that essentially each iteration extends + +37 +00:01:52,960 --> 00:01:55,220 +the functionality beyond the previous iteration. diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/11 - Cycle Example - lang_en_vs6.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/11 - Cycle Example - lang_en_vs6.srt new file mode 100644 index 0000000..af70543 --- /dev/null +++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/11 - Cycle Example - lang_en_vs6.srt @@ -0,0 +1,147 @@ +1 +00:00:00,230 --> 00:00:02,590 +To make this a little more concrete, let's look at + +2 +00:00:02,590 --> 00:00:07,466 +an example involving cycles, phases, and iterations. Let's assume that we + +3 +00:00:07,466 --> 00:00:10,250 +have to develop a banking IT system. The first possible + +4 +00:00:10,250 --> 00:00:12,730 +cycle for such a system could be one in which we + +5 +00:00:12,730 --> 00:00:16,280 +implement the basic withdrawal facilities. What this means is that, + +6 +00:00:16,280 --> 00:00:18,400 +at the end of this cycle, there will be the release + +7 +00:00:18,400 --> 00:00:22,130 +of the product that implements this piece of functionality. But notice + +8 +00:00:22,130 --> 00:00:25,500 +that this will not be the only product release because within + +9 +00:00:25,500 --> 00:00:28,580 +the cycle, we will perform also the four phases that + +10 +00:00:28,580 --> 00:00:31,020 +we mentioned before, inception, elaboration, + +11 +00:00:31,020 --> 00:00:33,550 +construction, and transition. And within each + +12 +00:00:33,550 --> 00:00:36,980 +of these phases, we might have multiple iterations. And at the + +13 +00:00:36,980 --> 00:00:39,710 +end of each iteration, we will also have a product release. + +14 +00:00:39,710 --> 00:00:41,790 +Which in this case, will be an internal one. As + +15 +00:00:41,790 --> 00:00:44,690 +you can see, the iterative nature is really inherent in the + +16 +00:00:44,690 --> 00:00:48,030 +unified rational process. So, now let's clean up here, and let's + +17 +00:00:48,030 --> 00:00:50,814 +see what some other possible cycles could be for our banking + +18 +00:00:50,814 --> 00:00:54,070 +IT system. Here, I'm showing two possible additional ones. The first + +19 +00:00:54,070 --> 00:00:57,800 +one, cycle two, which will develop the account and system management. And + +20 +00:00:57,800 --> 00:01:00,230 +the third one, cycle three, which will develop the full account + +21 +00:01:00,230 --> 00:01:04,620 +management and cross selling. Similarly to cycle one, also these cycles will + +22 +00:01:04,620 --> 00:01:07,570 +produce a product, both at the end of the cycle, and + +23 +00:01:07,570 --> 00:01:10,740 +within the cycle in the different phases. And there's a few more + +24 +00:01:10,740 --> 00:01:13,150 +things to note. So the first one, is that each cycle + +25 +00:01:13,150 --> 00:01:15,900 +focuses on a different part of the system. So what you will + +26 +00:01:15,900 --> 00:01:19,350 +do, when you use the rational unified process, you will select a + +27 +00:01:19,350 --> 00:01:23,320 +subset of use cases that you want to realize within your cycle. + +28 +00:01:23,320 --> 00:01:26,640 +And the final product for that cycle, will be a product that + +29 +00:01:26,640 --> 00:01:30,190 +realizes those use cases. This is the first aspect. The second one, + +30 +00:01:30,190 --> 00:01:33,290 +is that these cycles, as you can see, are slightly overlapping. So + +31 +00:01:33,290 --> 00:01:35,880 +it is not the case that you finish a cycle, and then + +32 +00:01:35,880 --> 00:01:37,580 +you start the next one. So there is a little bit of + +33 +00:01:37,580 --> 00:01:41,250 +overlap among cycles, and we'll talk about that more. And finally, + +34 +00:01:41,250 --> 00:01:43,600 +I want to stress one more that each cycle + +35 +00:01:43,600 --> 00:01:46,960 +contains four phases, and each one of these phases might + +36 +00:01:46,960 --> 00:01:49,890 +be further splayed in iterations. So that's kind of a + +37 +00:01:49,890 --> 00:01:52,610 +high level view of how the whole process will work. diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/12 - Phases within a Cycle - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/12 - Phases within a Cycle - lang_en_vs5.srt new file mode 100644 index 0000000..c58be49 --- /dev/null +++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/12 - Phases within a Cycle - lang_en_vs5.srt @@ -0,0 +1,199 @@ +1 +00:00:00,240 --> 00:00:02,505 +Now let's go back to the phases within a cycle. + +2 +00:00:02,505 --> 00:00:04,930 +because I want to show you how they relate to traditional + +3 +00:00:04,930 --> 00:00:08,196 +activities of software development. Because this is the first time that + +4 +00:00:08,196 --> 00:00:12,066 +we talk about inception, elaboration, construction and transition. So we will + +5 +00:00:12,066 --> 00:00:14,859 +know what they mean, in terms of the traditional software + +6 +00:00:14,859 --> 00:00:18,380 +development. So I'm going to first discuss these relations and then + +7 +00:00:18,380 --> 00:00:22,198 +I'm going to talk about each individual phase in further detail. + +8 +00:00:22,198 --> 00:00:25,570 +So I'm going to start by representing the four RUP phases here + +9 +00:00:25,570 --> 00:00:29,810 +with possible internal iterations. I1, E1 and E2, C1, + +10 +00:00:29,810 --> 00:00:32,490 +C2, and so on. And just as a reference, this + +11 +00:00:32,490 --> 00:00:34,670 +is the way in which time will progress. So we + +12 +00:00:34,670 --> 00:00:37,890 +will start with inception and we will finish with transition. + +13 +00:00:37,890 --> 00:00:39,710 +So what I'm want to do now is to show the + +14 +00:00:39,710 --> 00:00:43,930 +actual, traditional, software development activities here on the left. And + +15 +00:00:43,930 --> 00:00:46,970 +I also want to show you, using this diagram, how these + +16 +00:00:46,970 --> 00:00:51,610 +activities are actually performed in each of the RUP phases. + +17 +00:00:51,610 --> 00:00:54,540 +So, let's see what this representation means. Basically, what + +18 +00:00:54,540 --> 00:00:58,410 +I'm showing here, is that requirements engineering actually starts in + +19 +00:00:58,410 --> 00:01:00,480 +the inception phase. So, you can see the height + +20 +00:01:00,480 --> 00:01:03,090 +of this bar as the amount of effort devoted to + +21 +00:01:03,090 --> 00:01:05,890 +this activity in this specific phase. So you can + +22 +00:01:05,890 --> 00:01:09,950 +see that requirements engineering starts in inception phase, is mostly + +23 +00:01:09,950 --> 00:01:13,210 +performed in the elaboration phase, and then it continues, + +24 +00:01:13,210 --> 00:01:16,820 +although to a lesser extent, throughout all phases up until + +25 +00:01:16,820 --> 00:01:18,570 +the end of the transition. But the bulk is really + +26 +00:01:18,570 --> 00:01:22,940 +performed here in the elaboration phase. Similarly, if we consider analysis + +27 +00:01:22,940 --> 00:01:25,450 +and design, we can see that analysis and design are + +28 +00:01:25,450 --> 00:01:29,510 +mainly performed in the elaboration phase. But a considerable amount of + +29 +00:01:29,510 --> 00:01:31,900 +it also continues in the construction phase, and then it + +30 +00:01:31,900 --> 00:01:34,514 +kind of phases out. So there's very little of that done + +31 +00:01:34,514 --> 00:01:37,300 +in the transition phase. Looking now at implementation, you can see + +32 +00:01:37,300 --> 00:01:41,190 +that the implementation happens mostly in the construction phase, which is, + +33 +00:01:41,190 --> 00:01:45,460 +unsurprisingly, the phase that is mostly concerned with actual code development, + +34 +00:01:45,460 --> 00:01:47,620 +as we will see in a minute. Testing, on the other + +35 +00:01:47,620 --> 00:01:50,990 +hand, is performed throughout most phases, with, peaks in some specific + +36 +00:01:50,990 --> 00:01:54,260 +point, for example, at the end of some iterations, like here + +37 +00:01:54,260 --> 00:01:57,880 +and here. To conclude, we have the business modeling activity that + +38 +00:01:57,880 --> 00:02:00,160 +happens mainly in the inception and a little bit in the + +39 +00:02:00,160 --> 00:02:04,100 +elaboration phase and the deployment activity which happens a little bit + +40 +00:02:04,100 --> 00:02:06,420 +throughout, but the bulk of it is really in the transition + +41 +00:02:06,420 --> 00:02:08,699 +phase, which is actually the phase that has to do + +42 +00:02:08,699 --> 00:02:12,070 +with deployment and then maintenance. So I hope this kind + +43 +00:02:12,070 --> 00:02:14,970 +of high level view gives you a better understanding of + +44 +00:02:14,970 --> 00:02:17,940 +what is the mapping between these new phases and, the + +45 +00:02:17,940 --> 00:02:21,760 +typical software development activities that we are more familiar with. + +46 +00:02:21,760 --> 00:02:24,360 +So to further this understanding, later in the lesson, I'm + +47 +00:02:24,360 --> 00:02:28,220 +also going to talk about these specific phases individually. First, however, + +48 +00:02:28,220 --> 00:02:31,610 +I want to spend a little more time discussing what happens + +49 +00:02:31,610 --> 00:02:35,200 +inside each one of these iterations, just to make sure + +50 +00:02:35,200 --> 00:02:38,410 +that we are all understand what an iteration is exactly. diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/13 - Iterations - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/13 - Iterations - lang_en_vs5.srt new file mode 100644 index 0000000..fbdc2b0 --- /dev/null +++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/13 - Iterations - lang_en_vs5.srt @@ -0,0 +1,95 @@ +1 +00:00:00,420 --> 00:00:03,520 +So what happens, exactly, within an iteration? In + +2 +00:00:03,520 --> 00:00:07,680 +almost every iteration, developers perform the following activities. + +3 +00:00:07,680 --> 00:00:10,830 +So they identify which pieces of functionality this + +4 +00:00:10,830 --> 00:00:14,450 +iteration will develop, will implement. After doing that, they + +5 +00:00:14,450 --> 00:00:17,240 +will create a design, for the considered use + +6 +00:00:17,240 --> 00:00:19,640 +cases, and they will do that guided by the + +7 +00:00:19,640 --> 00:00:22,334 +chosen architecture. So the set of use cases + +8 +00:00:22,334 --> 00:00:25,666 +plus the architectural guidelines will result in a design + +9 +00:00:25,666 --> 00:00:29,035 +for the selected use cases. Once the design is defined, + +10 +00:00:29,035 --> 00:00:32,060 +then the developers will implement the design, which will result + +11 +00:00:32,060 --> 00:00:35,430 +in a set of software components. They will then verify + +12 +00:00:35,430 --> 00:00:38,992 +the components against the use cases to make sure that the + +13 +00:00:38,992 --> 00:00:41,740 +components satisfy the use cases, they suitably realize the use + +14 +00:00:41,740 --> 00:00:43,995 +cases. And they will do that through testing or some + +15 +00:00:43,995 --> 00:00:47,730 +other verification and validation activity. Finally, after verifying that the + +16 +00:00:47,730 --> 00:00:51,320 +code actually implements the use cases, they will release a product, + +17 +00:00:51,320 --> 00:00:53,840 +which also represent the end of the iteration. And notice that + +18 +00:00:53,840 --> 00:00:56,370 +what I put here is an icon for the world, + +19 +00:00:56,370 --> 00:00:59,330 +in double quotes. Because in many cases the release will be + +20 +00:00:59,330 --> 00:01:02,050 +just an internal release or maybe a release that will just + +21 +00:01:02,050 --> 00:01:04,813 +go to some of the stakeholders so that they can provide + +22 +00:01:04,813 --> 00:01:07,040 +feedback on that. Okay. So it doesn't have to be an + +23 +00:01:07,040 --> 00:01:09,080 +external release. It doesn't have to be a release to the + +24 +00:01:09,080 --> 00:01:12,270 +world. But it is, nevertheless, a release of a software product. . diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/14 - Iterative Approach Quiz - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/14 - Iterative Approach Quiz - lang_en_vs5.srt new file mode 100644 index 0000000..d4b7808 --- /dev/null +++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/14 - Iterative Approach Quiz - lang_en_vs5.srt @@ -0,0 +1,43 @@ +1 +00:00:00,182 --> 00:00:02,850 +So now, since we're talking about the incremental and iterative + +2 +00:00:02,850 --> 00:00:05,950 +nature of the Rational Unified Process, let's have a quiz on + +3 +00:00:05,950 --> 00:00:09,460 +the benefits of iterative approaches. So I'd like for you to tell + +4 +00:00:09,460 --> 00:00:12,710 +me what are these benefits. Is one benefit the fact that + +5 +00:00:12,710 --> 00:00:16,129 +iterative approaches keep developers busy or maybe that they give developers + +6 +00:00:16,129 --> 00:00:19,480 +early feedback, that they allow for doing the same thing over + +7 +00:00:19,480 --> 00:00:22,930 +and over in an iterative way. Maybe they also minimize the + +8 +00:00:22,930 --> 00:00:25,210 +risk of developing the wrong system. Can they be used to + +9 +00:00:25,210 --> 00:00:27,170 +improve planning, or is it the benefit + +10 +00:00:27,170 --> 00:00:30,160 +that they accommodate evolving requirements. Also, in this + +11 +00:00:30,160 --> 00:00:34,360 +case, I would like for you to check all the answers that you think are correct. diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/15 - Iterative Approach Quiz Solution - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/15 - Iterative Approach Quiz Solution - lang_en_vs5.srt new file mode 100644 index 0000000..6e69cec --- /dev/null +++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/15 - Iterative Approach Quiz Solution - lang_en_vs5.srt @@ -0,0 +1,179 @@ +1 +00:00:00,180 --> 00:00:01,740 +Okay so let's look at the first one. Well I + +2 +00:00:01,740 --> 00:00:04,760 +don't think that the fact of keeping developers busy is really + +3 +00:00:04,760 --> 00:00:08,020 +one of the highlights or the main benefits of iterative + +4 +00:00:08,020 --> 00:00:12,310 +approaches. Developers are really busy without any need for additional help. + +5 +00:00:12,310 --> 00:00:14,950 +So I will just not mark this one. The second + +6 +00:00:14,950 --> 00:00:19,280 +one conversely is definitely one of the advantages of iterative approaches. + +7 +00:00:19,280 --> 00:00:21,710 +So the fact that iterative approaches give the developers a early + +8 +00:00:21,710 --> 00:00:25,890 +feedback, is a great advantage which has in turn additional advantages. + +9 +00:00:25,890 --> 00:00:29,340 +For example, it increases the project tempo, so it gives the developers + +10 +00:00:29,340 --> 00:00:32,350 +not busy but more focused. It's easier to be focused when you + +11 +00:00:32,350 --> 00:00:35,790 +have a short term deadline, or a short term goal + +12 +00:00:35,790 --> 00:00:38,670 +rather than a release that is planned in six months or even + +13 +00:00:38,670 --> 00:00:42,420 +later. Another advantage of this early feedback is the fact that developers + +14 +00:00:42,420 --> 00:00:45,390 +are rewarded for their efforts so, there is sort of an immediate + +15 +00:00:45,390 --> 00:00:48,360 +rewards because you can see the results of your effort instead of + +16 +00:00:48,360 --> 00:00:51,310 +having to wait a long time to see such results. And last, + +17 +00:00:51,310 --> 00:00:55,126 +but not least the fact of getting early feedback also minimizes + +18 +00:00:55,126 --> 00:00:58,570 +the risks of developing the wrong system. So why is that? + +19 +00:00:58,570 --> 00:01:01,820 +Well because getting early feedback will also allow us to find + +20 +00:01:01,820 --> 00:01:05,140 +out whether we're going in the wrong direction early in the development process + +21 +00:01:05,140 --> 00:01:08,460 +rather than at the end. And therefore, will minimize this risk. + +22 +00:01:08,460 --> 00:01:10,760 +Going back to the previous question, yeah, I don't think that, you + +23 +00:01:10,760 --> 00:01:12,960 +know, doing the same thing over and over is a great + +24 +00:01:12,960 --> 00:01:16,170 +advantage. And in fact, iterative approaches do not do the same thing + +25 +00:01:16,170 --> 00:01:18,940 +over and over. So they keep iterating, but they keep + +26 +00:01:18,940 --> 00:01:21,930 +augmenting the amount of functionality in the system. They don't + +27 +00:01:21,930 --> 00:01:24,960 +just repeat the same thing. As for improving planning, actually + +28 +00:01:24,960 --> 00:01:27,980 +improving planning is not really a strength of these approaches, + +29 +00:01:27,980 --> 00:01:30,880 +because sometimes the number of iterations is hard to predict, + +30 +00:01:30,880 --> 00:01:33,050 +so it's hard to do a natural planning when you + +31 +00:01:33,050 --> 00:01:36,440 +are using an iterative approach. So finally, are iterative approaches + +32 +00:01:36,440 --> 00:01:38,700 +good for accomodating evolving requirements? + +33 +00:01:38,700 --> 00:01:41,630 +Most definitely. First, iterative approaches, and + +34 +00:01:41,630 --> 00:01:44,590 +in particular, the one that we're discussing consider requirements + +35 +00:01:44,590 --> 00:01:47,900 +incrementally, so they can better incorporate your requirements. So if + +36 +00:01:47,900 --> 00:01:51,030 +there are new requirements, it's easier to accommodate them using + +37 +00:01:51,030 --> 00:01:55,210 +an iterative approach. Second, these approaches realize a few requirements + +38 +00:01:55,210 --> 00:01:57,740 +at a time. Something from the most risky ones, as + +39 +00:01:57,740 --> 00:02:00,600 +we said. So any problem with those risky requirements will + +40 +00:02:00,600 --> 00:02:04,220 +be discovered early, and suitable course corrections could be taken. + +41 +00:02:04,220 --> 00:02:06,850 +So in case you still have doubts about iterative approaches, + +42 +00:02:06,850 --> 00:02:08,460 +it might be worth it to go back to + +43 +00:02:08,460 --> 00:02:11,390 +mini course number one, lesson number two to discuss the + +44 +00:02:11,390 --> 00:02:14,620 +life cycle models. Because we talk about iterative approaches + +45 +00:02:14,620 --> 00:02:17,770 +and their advantages and their characteristics there in some detail. diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/16 - Inception Phase - lang_en_vs4.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/16 - Inception Phase - lang_en_vs4.srt new file mode 100644 index 0000000..60ab80a --- /dev/null +++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/16 - Inception Phase - lang_en_vs4.srt @@ -0,0 +1,323 @@ +1 +00:00:00,175 --> 00:00:03,510 +Let's talk a little bit more about phases. The rational unified + +2 +00:00:03,510 --> 00:00:07,050 +process phases are fundamental aspects of this process and which just touched + +3 +00:00:07,050 --> 00:00:09,200 +on them so we just give a quick overview. And I want to + +4 +00:00:09,200 --> 00:00:12,010 +look at these phases in a little more detail. So, what I'm + +5 +00:00:12,010 --> 00:00:14,960 +going to do is, for each phase, I'm going to discuss what it is, + +6 +00:00:14,960 --> 00:00:18,310 +what it produces and how is the result of the phase suppose + +7 +00:00:18,310 --> 00:00:21,910 +to be,. Assessed, and what are the consequences of this assessment. So + +8 +00:00:21,910 --> 00:00:25,350 +let's start with the first phase, the inception phase. The first phase + +9 +00:00:25,350 --> 00:00:27,920 +goes from the idea of the product to the + +10 +00:00:27,920 --> 00:00:30,990 +vision of the end product. What this involves is basically + +11 +00:00:30,990 --> 00:00:34,230 +to delimiting the project scope. And making the business case + +12 +00:00:34,230 --> 00:00:37,040 +for the product presented. Why is it worth doing? What + +13 +00:00:37,040 --> 00:00:39,870 +are the success criteria? What are the main risks? What + +14 +00:00:39,870 --> 00:00:43,690 +resources will be needed? And so on, specifically these phases + +15 +00:00:43,690 --> 00:00:47,310 +answer three main questions. The first one is, what are + +16 +00:00:47,310 --> 00:00:51,330 +the major users or actors, to use the UML terminology. + +17 +00:00:51,330 --> 00:00:53,450 +And what will the system do for them? To + +18 +00:00:53,450 --> 00:00:56,780 +answer this, these phases produce a simplified use-case model where + +19 +00:00:56,780 --> 00:01:00,480 +only a few use-cases are represented and described. So this + +20 +00:01:00,480 --> 00:01:03,390 +is a sort of initial use-case model. The second question + +21 +00:01:03,390 --> 00:01:05,610 +is about the architecture, what could be an architecture + +22 +00:01:05,610 --> 00:01:08,370 +for the system? So in this phase we will normally + +23 +00:01:08,370 --> 00:01:12,420 +also develop a tentative architecture. So an initial architecture that + +24 +00:01:12,420 --> 00:01:16,540 +describes the most crucial subsystems. Finally this phase also answers + +25 +00:01:16,540 --> 00:01:18,890 +the question, what is the plan and how much + +26 +00:01:18,890 --> 00:01:21,620 +will it cost? To answer this question. This phase will + +27 +00:01:21,620 --> 00:01:24,930 +identify the main risks for the project and also produce + +28 +00:01:24,930 --> 00:01:28,600 +a rough plan with estimates for resources, initial planning for + +29 +00:01:28,600 --> 00:01:32,820 +the phases and dates and milestones. Specifically, the inception phase + +30 +00:01:32,820 --> 00:01:36,370 +generates several deliverables. It is very important that you pay + +31 +00:01:36,370 --> 00:01:39,600 +attention so that you understand what this deliberate approach are. + +32 +00:01:39,600 --> 00:01:42,320 +Starting from the first one, which is the vision document. + +33 +00:01:42,320 --> 00:01:44,800 +And this is a document that provides a general + +34 +00:01:44,800 --> 00:01:48,420 +vision of the core projects requirements, key features and main + +35 +00:01:48,420 --> 00:01:51,890 +constraints. Together with this, the inception phase also produces an + +36 +00:01:51,890 --> 00:01:54,900 +initial use case model, as I just mentioned. So this + +37 +00:01:54,900 --> 00:01:57,720 +is a use case model that includes an initial set + +38 +00:01:57,720 --> 00:02:00,670 +of use cases, and then will be later refined. Two + +39 +00:02:00,670 --> 00:02:04,300 +additional variables are the initial project glossary, which describes the + +40 +00:02:04,300 --> 00:02:07,330 +main terms, using the project and their meaning, and the + +41 +00:02:07,330 --> 00:02:10,229 +initial business case which includes business context. And + +42 +00:02:10,229 --> 00:02:13,470 +success criteria. Yet another deliverable for the inception phase + +43 +00:02:13,470 --> 00:02:15,770 +is the initial project plan, which shows the + +44 +00:02:15,770 --> 00:02:20,650 +phases, iterations, roles of the participants, schedule and initial + +45 +00:02:20,650 --> 00:02:23,610 +estimates. In addition, the inception phase also produces + +46 +00:02:23,610 --> 00:02:26,810 +a risk assessment document, which describes the main risks + +47 +00:02:26,810 --> 00:02:29,970 +and counters measures for this risk. Finally, and this + +48 +00:02:29,970 --> 00:02:32,430 +is an optional deliverable, in the sense that it, + +49 +00:02:32,430 --> 00:02:34,990 +it might or might not be produced, depending on the specific + +50 +00:02:34,990 --> 00:02:37,870 +project. As part of the inception phase we might also generate + +51 +00:02:37,870 --> 00:02:41,780 +1 or more prototypes. For example, we might develop prototypes to + +52 +00:02:41,780 --> 00:02:45,590 +address some specific risks that we have identified or to show some + +53 +00:02:45,590 --> 00:02:48,380 +specific aspect of the system of which we are unsure to + +54 +00:02:48,380 --> 00:02:51,910 +the stakeholders. So basically all the typical users of prototypes that + +55 +00:02:51,910 --> 00:02:54,600 +we discussed before. So when we're done with the inception phase + +56 +00:02:54,600 --> 00:02:58,300 +we hit the first milestone for the cycle we are currently performing. + +57 +00:02:58,300 --> 00:03:00,600 +And so there are some evaluation criteria that will tell + +58 +00:03:00,600 --> 00:03:03,640 +us whether we can consider the inception phase concluded or not. + +59 +00:03:03,640 --> 00:03:06,840 +And the first of this criteria is stakeholder concurrence, which + +60 +00:03:06,840 --> 00:03:10,510 +means that all the stakeholders must agree on the scope, definition, + +61 +00:03:10,510 --> 00:03:13,510 +and cost schedule estimates for the projects. The second criteria + +62 +00:03:13,510 --> 00:03:17,040 +needs requirements understanding, out of the initial primary use cases that + +63 +00:03:17,040 --> 00:03:20,380 +we have identified so far, the right one for our system. + +64 +00:03:20,380 --> 00:03:23,760 +And other criteria is the credibility of the cost schedule estimates, + +65 +00:03:23,760 --> 00:03:28,280 +the priorities, defined the risks identifies and the countermeasures for + +66 +00:03:28,280 --> 00:03:31,590 +those risks, and the development process that we're following. Finally, in + +67 +00:03:31,590 --> 00:03:34,000 +the case we produce prototypes as part of the inceptional + +68 +00:03:34,000 --> 00:03:37,520 +phase, this will also be evaluated and assessed to judge the + +69 +00:03:37,520 --> 00:03:39,960 +overall outcome of the phase. So what happens if the + +70 +00:03:39,960 --> 00:03:43,170 +project fails to pass this milestone? So if the outcome of + +71 +00:03:43,170 --> 00:03:46,020 +the inception phase is considered to be inadequate with respect + +72 +00:03:46,020 --> 00:03:48,642 +to one or more of these criteria. Well at this point, + +73 +00:03:48,642 --> 00:03:51,240 +since we're kind of an initial phase of the cycle + +74 +00:03:51,240 --> 00:03:54,370 +the project may be cancelled or considerably re-thought. So to + +75 +00:03:54,370 --> 00:03:57,610 +summarize all of these in one sentence the Inception Phase + +76 +00:03:57,610 --> 00:04:00,320 +is the phase in which we produce. Then you shall vision, + +77 +00:04:00,320 --> 00:04:04,750 +used case model, project plan, risk assessment and possibly, prototypes + +78 +00:04:04,750 --> 00:04:07,290 +for the project. And we have to make sure, that + +79 +00:04:07,290 --> 00:04:10,680 +all of this deliverables satisfy a set of criteria, so + +80 +00:04:10,680 --> 00:04:13,770 +that we can continue on the project. And otherwise, we'll either + +81 +00:04:13,770 --> 00:04:17,160 +cancel the project or rethink its scope, or other aspects of it. diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/17 - Elaboration Phase - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/17 - Elaboration Phase - lang_en_vs5.srt new file mode 100644 index 0000000..1025b2c --- /dev/null +++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/17 - Elaboration Phase - lang_en_vs5.srt @@ -0,0 +1,215 @@ +1 +00:00:00,350 --> 00:00:02,400 +Now that we've discussed the inception phase, let's move + +2 +00:00:02,400 --> 00:00:04,180 +on to the second phase of RUP, which is + +3 +00:00:04,180 --> 00:00:07,280 +the elaboration phase. And there are four main goals + +4 +00:00:07,280 --> 00:00:10,900 +and activities for the elaboration phase. Analyzing the problem domain + +5 +00:00:10,900 --> 00:00:13,690 +to get a better understanding of the domain. Establishing + +6 +00:00:13,690 --> 00:00:17,840 +a solid architectural foundation for the project. Eliminating the highest + +7 +00:00:17,840 --> 00:00:21,454 +risk elements which basically means addressing the most critical + +8 +00:00:21,454 --> 00:00:25,590 +use cases. And finally, refine the plan of activities and estimates + +9 +00:00:25,590 --> 00:00:28,250 +of resources to complete the project. The outcome + +10 +00:00:28,250 --> 00:00:31,310 +of the elaboration phase reflects these activities and also + +11 +00:00:31,310 --> 00:00:34,440 +in this case produces several artifacts. The first one + +12 +00:00:34,440 --> 00:00:38,700 +is an almost complete use case model with all use cases + +13 +00:00:38,700 --> 00:00:42,560 +and actors identified and most use case descriptions developed. + +14 +00:00:42,560 --> 00:00:44,070 +As part of this phase we also identify a + +15 +00:00:44,070 --> 00:00:47,550 +set of what we called supplementary requirements. So these + +16 +00:00:47,550 --> 00:00:50,685 +are basically all the requirements that are not associated + +17 +00:00:50,685 --> 00:00:53,483 +with a use case. And these sets includes in particular all + +18 +00:00:53,483 --> 00:00:56,110 +non-functional requirements such as security, + +19 +00:00:56,110 --> 00:00:58,630 +reliability, maintainability and so on. So + +20 +00:00:58,630 --> 00:01:00,770 +all the ones that are relevant for the system that + +21 +00:01:00,770 --> 00:01:02,280 +you're developing. We mentioned before + +22 +00:01:02,280 --> 00:01:04,410 +that the software architecture is developed + +23 +00:01:04,410 --> 00:01:07,220 +in an incremental way, so it's not created at once. + +24 +00:01:07,220 --> 00:01:09,650 +And this is exactly what happens in the elaboration phase, that + +25 +00:01:09,650 --> 00:01:12,990 +we take the initial architecture that was defined in the inception + +26 +00:01:12,990 --> 00:01:16,280 +phase and we refine it until we get to a software + +27 +00:01:16,280 --> 00:01:19,400 +architecture which is complete. And that is part of the + +28 +00:01:19,400 --> 00:01:22,410 +deliverables for this phase. And the list continues, so let + +29 +00:01:22,410 --> 00:01:25,020 +me make some room. In addition to producing a complete + +30 +00:01:25,020 --> 00:01:28,270 +architecture for our system, in the elaboration phase we also + +31 +00:01:28,270 --> 00:01:32,130 +define the lower-level design for the system. And, therefore, as + +32 +00:01:32,130 --> 00:01:35,560 +part of this phase, we produce as deliverables a design + +33 +00:01:35,560 --> 00:01:38,000 +model, and together with that, a complete set of test + +34 +00:01:38,000 --> 00:01:41,770 +cases, and an executable prototype. We also produce a revised + +35 +00:01:41,770 --> 00:01:44,390 +project plan. Now that we have more information about the + +36 +00:01:44,390 --> 00:01:47,120 +project we can refine the various estimates and the various + +37 +00:01:47,120 --> 00:01:50,020 +pieces of information in the project plan. And also an + +38 +00:01:50,020 --> 00:01:54,160 +updated risk assessment document. Finally, in this phase we also generate + +39 +00:01:54,160 --> 00:01:57,680 +a preliminary user manual that describes to the users how + +40 +00:01:57,680 --> 00:02:00,350 +the system can be used and should be used. So now + +41 +00:02:00,350 --> 00:02:03,630 +let's see what are the evaluation criteria for the elaboration + +42 +00:02:03,630 --> 00:02:06,880 +phase which is our second milestone. So I'm just going to list + +43 +00:02:06,880 --> 00:02:09,400 +them here. The first one is whether the vision + +44 +00:02:09,400 --> 00:02:12,620 +and the architecture are stable or they're still changing so + +45 +00:02:12,620 --> 00:02:15,680 +did we converge into a final complete vision for the + +46 +00:02:15,680 --> 00:02:18,620 +system? Does the prototype show that the major risks that + +47 +00:02:18,620 --> 00:02:22,090 +we have identified have been resolved or at least addressed + +48 +00:02:22,090 --> 00:02:25,390 +in this phase? Is the project plan sufficiently detailed and + +49 +00:02:25,390 --> 00:02:29,030 +accurate? Do all stakeholders agree that the vision can be + +50 +00:02:29,030 --> 00:02:32,320 +achieved with the current plan? Is the actual resource expenditure + +51 +00:02:32,320 --> 00:02:35,840 +versus the planned expenditure acceptable? So now we study consumer + +52 +00:02:35,840 --> 00:02:39,120 +resources and therefore we can check whether our estimates were + +53 +00:02:39,120 --> 00:02:41,964 +correct. And also in this case the project might be + +54 +00:02:41,964 --> 00:02:45,730 +cancelled or considerably reshaped if it fails to pass this milestone. diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/18 - Construction Phase - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/18 - Construction Phase - lang_en_vs5.srt new file mode 100644 index 0000000..70051fd --- /dev/null +++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/18 - Construction Phase - lang_en_vs5.srt @@ -0,0 +1,247 @@ +1 +00:00:00,230 --> 00:00:03,170 +So if the elaboration phase is successful, we then move + +2 +00:00:03,170 --> 00:00:06,560 +to the construction phase, which is our third phase. And + +3 +00:00:06,560 --> 00:00:09,550 +the construction phase is basically the phase in which most + +4 +00:00:09,550 --> 00:00:13,860 +of the actual development occurs. In short, all the features considered + +5 +00:00:13,860 --> 00:00:17,360 +are developed. So we'll continue with our car metaphor that + +6 +00:00:17,360 --> 00:00:19,310 +we used for the prototype. And in this case we + +7 +00:00:19,310 --> 00:00:22,390 +will have our complete car ready. Not only the features + +8 +00:00:22,390 --> 00:00:25,940 +are developed but they're also thoroughly tested. So we have performed + +9 +00:00:25,940 --> 00:00:29,490 +quality assurance. We have verified and validated the software, + +10 +00:00:29,490 --> 00:00:32,580 +the system and we know that it works correctly. Or + +11 +00:00:32,580 --> 00:00:34,620 +at least that it works correctly as far as + +12 +00:00:34,620 --> 00:00:37,850 +we can tell. So, in general, the construction phase is + +13 +00:00:37,850 --> 00:00:39,760 +the phase in which there is a shift in + +14 +00:00:39,760 --> 00:00:42,640 +emphasis from intellectual property development + +15 +00:00:42,640 --> 00:00:45,460 +to product development. From ideas + +16 +00:00:45,460 --> 00:00:47,650 +to products. So, what is the outcome of the + +17 +00:00:47,650 --> 00:00:51,250 +construction phase? Well, basically the construction phrase produces a product + +18 +00:00:51,250 --> 00:00:54,520 +that is ready to be deployed to the users. Specifically, + +19 +00:00:54,520 --> 00:00:57,570 +the phase generates the following outcomes. First of all, at the + +20 +00:00:57,570 --> 00:01:00,150 +end of this phase, all the use cases have been + +21 +00:01:00,150 --> 00:01:03,220 +realized with traceability information. What does that mean? It means that + +22 +00:01:03,220 --> 00:01:06,640 +not only all the functionality expressed by the use cases + +23 +00:01:06,640 --> 00:01:10,240 +have been implemented, but also that we have traceability information from + +24 +00:01:10,240 --> 00:01:13,530 +the use cases, to the different artifacts. So for example, + +25 +00:01:13,530 --> 00:01:16,780 +we know which part of the design realizes which use case. + +26 +00:01:16,780 --> 00:01:19,230 +We know which part of the implementation is related to a + +27 +00:01:19,230 --> 00:01:22,150 +given use case. Which use cases were derived from a use + +28 +00:01:22,150 --> 00:01:24,390 +case, and so on and so forth. And in this way + +29 +00:01:24,390 --> 00:01:28,310 +we can trace our requirements throughout the system. Throughout the different + +30 +00:01:28,310 --> 00:01:32,162 +artifacts that were developed during the software process. As we were + +31 +00:01:32,162 --> 00:01:35,790 +saying, we also have complete software product here, which is integrated + +32 +00:01:35,790 --> 00:01:39,240 +on all the needed platforms. Since the system, the software product, + +33 +00:01:39,240 --> 00:01:42,200 +has to be thoroughly tested, we will also have a complete + +34 +00:01:42,200 --> 00:01:44,900 +set of results for our tests. As part of this + +35 +00:01:44,900 --> 00:01:47,980 +phase, we will also finalize the user manual, so you'll have + +36 +00:01:47,980 --> 00:01:51,050 +a user manual ready to be provided to the users, and + +37 +00:01:51,050 --> 00:01:53,700 +ready to be used. And finally, we will have a complete + +38 +00:01:53,700 --> 00:01:58,370 +set of artifacts that include design documents, code, test cases, and + +39 +00:01:58,370 --> 00:02:00,440 +so on and so forth, so basically all of the artifacts + +40 +00:02:00,440 --> 00:02:04,240 +that have been produced during the development process. So roughly speaking, + +41 +00:02:04,240 --> 00:02:07,280 +we can consider the product that is produced at the end + +42 +00:02:07,280 --> 00:02:10,570 +of this phase as a typical beta release. So in case + +43 +00:02:10,570 --> 00:02:12,920 +you're not familiar with that, a beta release is an initial + +44 +00:02:12,920 --> 00:02:16,050 +release normally meant for a selected subset of users. So it + +45 +00:02:16,050 --> 00:02:19,250 +is something that is not quite yet ready for primetime, but + +46 +00:02:19,250 --> 00:02:22,540 +almost. So let's see also in this case, what are the evaluation + +47 +00:02:22,540 --> 00:02:25,740 +criteria for the construction phase. So how do we assess, that + +48 +00:02:25,740 --> 00:02:29,620 +this third milestone has been accomplished, successfully? We pretty much have + +49 +00:02:29,620 --> 00:02:32,510 +a complete product ready to be shipped right? So the first question + +50 +00:02:32,510 --> 00:02:35,260 +we want to ask is, whether the product is stable and mature + +51 +00:02:35,260 --> 00:02:37,910 +enough to be deployed to users. At the end of this + +52 +00:02:37,910 --> 00:02:40,510 +phase it has to be. Are the stakeholders ready for the + +53 +00:02:40,510 --> 00:02:44,160 +transition into the user community? Are we ready to go from development + +54 +00:02:44,160 --> 00:02:45,450 +to production? Are the actual + +55 +00:02:45,450 --> 00:02:48,060 +resource expenditures versus the planned expenditures + +56 +00:02:48,060 --> 00:02:50,890 +still acceptable? So what this means is that at this point we + +57 +00:02:50,890 --> 00:02:54,660 +can really assess whether our estimates were accurate enough with respect + +58 +00:02:54,660 --> 00:02:57,740 +to what we actually spent for the project up to this point. + +59 +00:02:57,740 --> 00:03:00,390 +So unless we can answer in a positive way to + +60 +00:03:00,390 --> 00:03:03,790 +all these questions, the transition might be postponed by one release. + +61 +00:03:03,790 --> 00:03:05,930 +Because that means that we're still not ready to go + +62 +00:03:05,930 --> 00:03:08,660 +to the market. We're still not ready to deploy our product. diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/19 - Transition Phase - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/19 - Transition Phase - lang_en_vs5.srt new file mode 100644 index 0000000..e09b6fc --- /dev/null +++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/19 - Transition Phase - lang_en_vs5.srt @@ -0,0 +1,231 @@ +1 +00:00:00,300 --> 00:00:02,080 +But if we are ready to go to the market, + +2 +00:00:02,080 --> 00:00:04,800 +if we are ready to deploy our product, then we can + +3 +00:00:04,800 --> 00:00:07,160 +move to the transition phase, which has mainly to do + +4 +00:00:07,160 --> 00:00:10,360 +with deployment and maintainence of a system. So what are the + +5 +00:00:10,360 --> 00:00:12,950 +main activities in the transition phase? As we discussed in + +6 +00:00:12,950 --> 00:00:16,280 +our initial lessons, in most real world cases, there are issues + +7 +00:00:16,280 --> 00:00:20,820 +that manifest themselves after deployment, when we release our software and + +8 +00:00:20,820 --> 00:00:22,870 +actual users interact with the + +9 +00:00:22,870 --> 00:00:26,230 +software. Specifically, users might report failures + +10 +00:00:26,230 --> 00:00:28,965 +that they experienced while using the system. So, what we call + +11 +00:00:28,965 --> 00:00:33,120 +bug reports. Or they might report improvements they might want to see + +12 +00:00:33,120 --> 00:00:36,798 +in the software. So typically these will be new feature requests. And + +13 +00:00:36,798 --> 00:00:40,270 +in addition, there might be issues that don't come necessarily from the + +14 +00:00:40,270 --> 00:00:42,734 +users but that are related to the fact that our system + +15 +00:00:42,734 --> 00:00:45,920 +has to operate, has to work in a new execution environment. For + +16 +00:00:45,920 --> 00:00:48,930 +example, the new version of an operating system, or the new version + +17 +00:00:48,930 --> 00:00:51,474 +of a set of libraries. When this happens, we have to address + +18 +00:00:51,474 --> 00:00:55,020 +these issues by performing maintenance. Specifically, corrective maintenance + +19 +00:00:55,020 --> 00:00:58,900 +for bug reports, perfective maintenance, for feature requests, and + +20 +00:00:58,900 --> 00:01:02,270 +adaptive maintenance, for environment changes. And the result of + +21 +00:01:02,270 --> 00:01:04,319 +this is that we will have a new release + +22 +00:01:04,319 --> 00:01:06,550 +of the software. Other activities that are performed in + +23 +00:01:06,550 --> 00:01:10,480 +this phase include training, customer service, and providing help-line + +24 +00:01:10,480 --> 00:01:13,350 +assistance. Finally, if you remember what we saw when + +25 +00:01:13,350 --> 00:01:16,810 +we were looking at the banking IT system example, + +26 +00:01:16,810 --> 00:01:21,300 +the cycles within a development are not necessarily completely dis-joined, but + +27 +00:01:21,300 --> 00:01:23,940 +they might overlap a little bit. So something else that might + +28 +00:01:23,940 --> 00:01:26,650 +happen in the transition phase is that a new cycle may + +29 +00:01:26,650 --> 00:01:29,020 +start. So there might be some activities that are related to + +30 +00:01:29,020 --> 00:01:32,190 +the fact that we're starting to think about the new cycle. + +31 +00:01:32,190 --> 00:01:35,150 +So now let's see what kind of outcome these activities will + +32 +00:01:35,150 --> 00:01:38,410 +produce. The first one is a complete project with all the + +33 +00:01:38,410 --> 00:01:41,820 +artifacts that we mentioned before. Another outcome is that the product will + +34 +00:01:41,820 --> 00:01:44,090 +be actually in use. So the product will be in the + +35 +00:01:44,090 --> 00:01:46,870 +hands of the users and the users will start using it, will + +36 +00:01:46,870 --> 00:01:49,760 +start interacting with it, for real, not just in a beta testing + +37 +00:01:49,760 --> 00:01:53,260 +setting. Another outcome will be a lesson learnt. What worked. What didn't + +38 +00:01:53,260 --> 00:01:56,240 +work. What should we do different in the next cycle or in + +39 +00:01:56,240 --> 00:01:59,446 +the next development? And this is a very important part of the + +40 +00:01:59,446 --> 00:02:01,651 +whole process, because it;s what provides + +41 +00:02:01,651 --> 00:02:04,378 +feedback between cycles, and between projects. + +42 +00:02:04,378 --> 00:02:07,018 +And as we said before, in case we have a next released + +43 +00:02:07,018 --> 00:02:09,478 +planned or a next cycle coming up, we might want to + +44 +00:02:09,478 --> 00:02:12,922 +start planning for the next release. So another outcome will be + +45 +00:02:12,922 --> 00:02:15,783 +the plan for the next release. So similar to the other + +46 +00:02:15,783 --> 00:02:19,147 +phases, also for the transition phase, we have a milestone, which + +47 +00:02:19,147 --> 00:02:21,733 +is the fourth milestone in this case. And therefore we + +48 +00:02:21,733 --> 00:02:25,061 +have evaluation criteria for the transition phase that will define whether + +49 +00:02:25,061 --> 00:02:28,530 +we've reached the milestone or not. And in this case, one + +50 +00:02:28,530 --> 00:02:32,040 +important assessment is whether the user is satisfied. So users are + +51 +00:02:32,040 --> 00:02:34,370 +actually using our product now, so we can get feedback + +52 +00:02:34,370 --> 00:02:36,260 +from them, we can see whether the product makes them + +53 +00:02:36,260 --> 00:02:40,390 +happy or not. And we continue assessing whether our expenditures + +54 +00:02:40,390 --> 00:02:43,460 +are fine with respect to our estimates. And in this case, + +55 +00:02:43,460 --> 00:02:46,882 +problems with this milestone might lead to further maintenance of + +56 +00:02:46,882 --> 00:02:48,840 +the system. So for example, we might need to produce + +57 +00:02:48,840 --> 00:02:51,460 +a new release to address some of the issues that + +58 +00:02:51,460 --> 00:02:54,410 +the users identified, as we discussed a couple of minutes ago. diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/2 - History of RUP - lang_en_vs6.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/2 - History of RUP - lang_en_vs6.srt new file mode 100644 index 0000000..83a656b --- /dev/null +++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/2 - History of RUP - lang_en_vs6.srt @@ -0,0 +1,115 @@ +1 +00:00:00,320 --> 00:00:02,252 +As I just said, today we're going to talk about the + +2 +00:00:02,252 --> 00:00:04,876 +Rational Unified Process. And you know that I like to provide + +3 +00:00:04,876 --> 00:00:07,632 +the historical perspective of the topics that we cover in class + +4 +00:00:07,632 --> 00:00:10,070 +and this lesson is no exception. So let's see a little bit + +5 +00:00:10,070 --> 00:00:12,500 +of history of RUP. To do that we have to go + +6 +00:00:12,500 --> 00:00:17,620 +back to 1997 when Rational defined six best practices for modern software + +7 +00:00:17,620 --> 00:00:20,930 +engineering. So let's look at what these practices were. The first + +8 +00:00:20,930 --> 00:00:25,330 +practice involved developing in an iterative way with risk as the primary + +9 +00:00:25,330 --> 00:00:27,700 +iteration driver. The second practice had to do + +10 +00:00:27,700 --> 00:00:31,375 +with managing requirements, including updating them and keeping + +11 +00:00:31,375 --> 00:00:34,570 +traceability information between requirements and other software + +12 +00:00:34,570 --> 00:00:37,675 +artifacts. Practice number three was to employ a + +13 +00:00:37,675 --> 00:00:40,830 +component-based architecture. What that means is to have + +14 +00:00:40,830 --> 00:00:43,540 +a high level design that focuses on cooperating + +15 +00:00:43,540 --> 00:00:46,780 +components that are nevertheless very cohesive and highly + +16 +00:00:46,780 --> 00:00:50,710 +decoupled. Modeling software visually is another key aspect + +17 +00:00:50,710 --> 00:00:53,250 +of the rational unified process. And the key concept + +18 +00:00:53,250 --> 00:00:56,070 +here is to use visual diagrams, and in particular UML + +19 +00:00:56,070 --> 00:00:58,520 +visual diagrams, in a very extensive way so as + +20 +00:00:58,520 --> 00:01:01,950 +to make artifacts easier to understand and agree upon among + +21 +00:01:01,950 --> 00:01:04,849 +stakeholders. And the fact that the process is defined + +22 +00:01:04,849 --> 00:01:08,510 +in an iterative way, allows for performing quality assurance activities + +23 +00:01:08,510 --> 00:01:11,430 +in a continuous way. So it allows for continuously + +24 +00:01:11,430 --> 00:01:13,860 +verifying quality throughout the development + +25 +00:01:13,860 --> 00:01:16,220 +process. Finally, change management and + +26 +00:01:16,220 --> 00:01:18,750 +control were also at the center of the rational + +27 +00:01:18,750 --> 00:01:22,100 +approach These six practices, that I just mentioned were + +28 +00:01:22,100 --> 00:01:24,740 +the starting point for the development of the Rational + +29 +00:01:24,740 --> 00:01:27,300 +Unified Process, which is what we're going to discuss next. diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/20 - Phases and Iterations - lang_en_vs4.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/20 - Phases and Iterations - lang_en_vs4.srt new file mode 100644 index 0000000..01689f9 --- /dev/null +++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/20 - Phases and Iterations - lang_en_vs4.srt @@ -0,0 +1,107 @@ +1 +00:00:00,170 --> 00:00:02,210 +So now I would like to wrap up this lesson + +2 +00:00:02,210 --> 00:00:05,720 +by going back to our discussion of rational unified process + +3 +00:00:05,720 --> 00:00:08,630 +phases and iterations. So to do that I'm going to bring + +4 +00:00:08,630 --> 00:00:12,480 +back the presentation that I used before, the summary representation + +5 +00:00:12,480 --> 00:00:16,840 +about phases and traditional software engineering activities. And I want to + +6 +00:00:16,840 --> 00:00:19,720 +use this representation to stress and discuss a couple of + +7 +00:00:19,720 --> 00:00:22,140 +things. Mainly I want to recap it because I think + +8 +00:00:22,140 --> 00:00:25,480 +it is very important. What is the relation between the rational + +9 +00:00:25,480 --> 00:00:29,270 +unified process, and the traditional software engineering phases, and software + +10 +00:00:29,270 --> 00:00:31,540 +engineering activities? And I like to do it now that + +11 +00:00:31,540 --> 00:00:33,648 +we have discussed the phases in a little more detail. + +12 +00:00:33,648 --> 00:00:35,920 +So I want to make sure that it is clear by now + +13 +00:00:35,920 --> 00:00:39,660 +how and when the traditional software engineering activities, the ones + +14 +00:00:39,660 --> 00:00:42,620 +listed here, take place in the context of the RUP + +15 +00:00:42,620 --> 00:00:45,850 +phases, the four listed up here. For instance, it should + +16 +00:00:45,850 --> 00:00:50,410 +be clear why implementation takes place mainly in the construction phase. + +17 +00:00:50,410 --> 00:00:54,140 +Why requirements engineering is prominent in the elaboration phase + +18 +00:00:54,140 --> 00:00:58,290 +and why deployment activities occur mostly in the transition phase, + +19 +00:00:58,290 --> 00:01:00,120 +and so on. So it should be clear now + +20 +00:01:00,120 --> 00:01:03,930 +why the activities are so distributed in the four phases. + +21 +00:01:03,930 --> 00:01:06,130 +It should also be clear that although there is + +22 +00:01:06,130 --> 00:01:09,350 +normally one main phase for each activity, the activities really + +23 +00:01:09,350 --> 00:01:12,550 +span multiple phases. Which is actually one of the interesting + +24 +00:01:12,550 --> 00:01:15,580 +aspect of RUP. So the fact that you're not really + +25 +00:01:15,580 --> 00:01:19,700 +done with an activity even in later phases. Why? Well, because that allows + +26 +00:01:19,700 --> 00:01:22,070 +you, in subsequent iterations, to address + +27 +00:01:22,070 --> 00:01:24,370 +problems that came up in previous iterations. diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/3 - Key Features of RUP - lang_en_vs6.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/3 - Key Features of RUP - lang_en_vs6.srt new file mode 100644 index 0000000..74dc52a --- /dev/null +++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/3 - Key Features of RUP - lang_en_vs6.srt @@ -0,0 +1,103 @@ +1 +00:00:00,300 --> 00:00:03,450 +So let's start by seeing how these activities and principles + +2 +00:00:03,450 --> 00:00:06,640 +are reflected in the key features of the Rational Unified + +3 +00:00:06,640 --> 00:00:10,010 +Process. First of all, the Rational Unified Process is a + +4 +00:00:10,010 --> 00:00:13,700 +software process model. So if you recall our introductory lessons, + +5 +00:00:13,700 --> 00:00:16,670 +that means two main things. The first one is that + +6 +00:00:16,670 --> 00:00:19,200 +it defines an order of phases that have to be + +7 +00:00:19,200 --> 00:00:21,970 +followed in the software process. And the second thing is + +8 +00:00:21,970 --> 00:00:25,420 +that it also prescribes transition criteria, so when to go + +9 +00:00:25,420 --> 00:00:28,030 +from one phase to the next. The second key + +10 +00:00:28,030 --> 00:00:31,290 +feature of RUP is that it is component based. And + +11 +00:00:31,290 --> 00:00:33,810 +also in this case, this implies two main things. + +12 +00:00:33,810 --> 00:00:36,410 +The first one is that a software system is defined + +13 +00:00:36,410 --> 00:00:39,420 +and built as a set of software components. So + +14 +00:00:39,420 --> 00:00:43,110 +software components are the building blocks of our software system. + +15 +00:00:43,110 --> 00:00:45,550 +And the second one is that there must be well-defined + +16 +00:00:45,550 --> 00:00:48,440 +interfaces between these components, interfaces + +17 +00:00:48,440 --> 00:00:50,750 +through which these components communicate. + +18 +00:00:50,750 --> 00:00:53,020 +In addition, the Rational Unified Process is + +19 +00:00:53,020 --> 00:00:56,080 +tightly related to UML. And in particular, it + +20 +00:00:56,080 --> 00:00:58,820 +relies extensively on UML for its notation, and + +21 +00:00:58,820 --> 00:01:02,120 +with respect to its basic principles. Finally, the + +22 +00:01:02,120 --> 00:01:05,140 +three main distinguishing aspects of the Rational Unified + +23 +00:01:05,140 --> 00:01:09,830 +Process are that it is use-case driven, architecture-centric + +24 +00:01:09,830 --> 00:01:12,680 +and iterative and incremental. So let's now look + +25 +00:01:12,680 --> 00:01:15,565 +in more detail at these three distinguishing aspects, + +26 +00:01:15,565 --> 00:01:17,540 +and we're going to look at each one of them individually. diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/4 - UML Quiz - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/4 - UML Quiz - lang_en_vs5.srt new file mode 100644 index 0000000..4f4af17 --- /dev/null +++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/4 - UML Quiz - lang_en_vs5.srt @@ -0,0 +1,47 @@ +1 +00:00:00,160 --> 00:00:03,440 +Before doing that though, let's have a quiz to check whether you remember + +2 +00:00:03,440 --> 00:00:07,160 +the basics of UML. Since we're going to talk about use cases, I want + +3 +00:00:07,160 --> 00:00:10,040 +to ask you, what is the difference between a use case and a + +4 +00:00:10,040 --> 00:00:13,330 +use case model. So here are the possible answers, and you can mark + +5 +00:00:13,330 --> 00:00:16,710 +more than one. First one is that only use case models include actors. + +6 +00:00:16,710 --> 00:00:19,150 +The second is that they are the same thing. The third one is + +7 +00:00:19,150 --> 00:00:22,000 +that a use case model is a set of use cases. The fourth + +8 +00:00:22,000 --> 00:00:24,950 +one says that a use case is a set of use case models. + +9 +00:00:24,950 --> 00:00:26,520 +Finally, the last one says that use cases + +10 +00:00:26,520 --> 00:00:29,650 +are a dynamic representation, whereas use case models + +11 +00:00:29,650 --> 00:00:31,880 +are a static representation of a system. So + +12 +00:00:31,880 --> 00:00:33,810 +mark all the answers that you think are correct. diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/5 - UML Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/5 - UML Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..c107545 --- /dev/null +++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/5 - UML Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,15 @@ +1 +00:00:00,150 --> 00:00:02,350 +And the correct answer, in this case it's only one, + +2 +00:00:02,350 --> 00:00:04,720 +is that a use case model is a set of use + +3 +00:00:04,720 --> 00:00:07,390 +cases. So a use case model is simply a collection of + +4 +00:00:07,390 --> 00:00:10,790 +use cases that represent different pieces of functionality for the system. diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/6 - UML Quiz - lang_en_vs6.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/6 - UML Quiz - lang_en_vs6.srt new file mode 100644 index 0000000..c2627aa --- /dev/null +++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/6 - UML Quiz - lang_en_vs6.srt @@ -0,0 +1,39 @@ +1 +00:00:00,330 --> 00:00:02,650 +So, since we are talking about use case diagrams, I also want + +2 +00:00:02,650 --> 00:00:05,593 +to ask you, what are use case diagrams used for? So, what + +3 +00:00:05,593 --> 00:00:08,600 +are they good for? Why are they useful within a software process? + +4 +00:00:08,600 --> 00:00:12,130 +Also in this case, I'm providing several possible answers. They are not really + +5 +00:00:12,130 --> 00:00:15,420 +used for anything. Or, they can be used to prioritize requirements. Or, + +6 +00:00:15,420 --> 00:00:18,220 +maybe they can be used for user interface design. They can be + +7 +00:00:18,220 --> 00:00:20,280 +used during requirements elicitation. They can + +8 +00:00:20,280 --> 00:00:21,890 +be used for code optimization. And + +9 +00:00:21,890 --> 00:00:25,570 +finally, they can be used for test case design. Also, in this case, + +10 +00:00:25,570 --> 00:00:28,650 +I would like you to mark all the answers that you think are correct. diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/7 - UML Quiz Solution - lang_en_vs6.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/7 - UML Quiz Solution - lang_en_vs6.srt new file mode 100644 index 0000000..c201e96 --- /dev/null +++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/7 - UML Quiz Solution - lang_en_vs6.srt @@ -0,0 +1,143 @@ +1 +00:00:00,140 --> 00:00:02,910 +In this case there are multiple, correct answers. So you should have + +2 +00:00:02,910 --> 00:00:05,800 +marked several of those. So let's go through the list. Well this + +3 +00:00:05,800 --> 00:00:08,970 +is definitely not true. They are used for something. The second answer, + +4 +00:00:08,970 --> 00:00:11,880 +is a correct one, because you can order, the use cases that + +5 +00:00:11,880 --> 00:00:13,320 +you planned to realize, according to + +6 +00:00:13,320 --> 00:00:15,580 +your prioritization criteria. So basically what + +7 +00:00:15,580 --> 00:00:19,100 +you're doing you're prioritizing either in terms of functionality. So you, you + +8 +00:00:19,100 --> 00:00:21,680 +can decide which piece of functionality you want to realize first in + +9 +00:00:21,680 --> 00:00:25,430 +your system. Or you can also prioritize based on the actors involved. + +10 +00:00:25,430 --> 00:00:27,530 +Maybe there are some actors, maybe there are some user + +11 +00:00:27,530 --> 00:00:30,580 +roles that you want to support before others, and we'll + +12 +00:00:30,580 --> 00:00:33,580 +see some examples of that. The next correct question is + +13 +00:00:33,580 --> 00:00:37,190 +that they can be used for requirements elicitation. Why? Well + +14 +00:00:37,190 --> 00:00:40,130 +because used cases express what the system is supposed to + +15 +00:00:40,130 --> 00:00:43,490 +do for each user. They're an ideal way to collect, + +16 +00:00:43,490 --> 00:00:47,110 +represent, and check functional requirements. And we'll also get back + +17 +00:00:47,110 --> 00:00:50,700 +to this. And finally, use cases can definitely be used + +18 +00:00:50,700 --> 00:00:54,160 +for test case design. So why is that? Because each + +19 +00:00:54,160 --> 00:00:58,500 +use case represents a scenario of interaction between users and the + +20 +00:00:58,500 --> 00:01:03,470 +system. So testers can very naturally construct test cases based + +21 +00:01:03,470 --> 00:01:06,570 +on use cases. And in addition, and most importantly, they can + +22 +00:01:06,570 --> 00:01:09,320 +do that even in the absence of code that realizes + +23 +00:01:09,320 --> 00:01:11,490 +a use case. So they can do it as soon as + +24 +00:01:11,490 --> 00:01:13,740 +they have the requirements. They don't have to wait until the + +25 +00:01:13,740 --> 00:01:16,150 +code is ready. So this is not very a important point. + +26 +00:01:16,150 --> 00:01:18,400 +So you can have your test cases ready even before + +27 +00:01:18,400 --> 00:01:21,150 +writing the code. And now for completeness. Even though this is + +28 +00:01:21,150 --> 00:01:23,787 +not listed in the quiz. I also want to mention two + +29 +00:01:23,787 --> 00:01:27,040 +additional uses for use cases. The first one is that use + +30 +00:01:27,040 --> 00:01:30,080 +cases can be used to estimate effort as we will discuss + +31 +00:01:30,080 --> 00:01:32,710 +in more detail in mini course four, when we talk about + +32 +00:01:32,710 --> 00:01:35,770 +agile software development. And they can also be used by + +33 +00:01:35,770 --> 00:01:38,290 +customers to assess requirements. Which + +34 +00:01:38,290 --> 00:01:41,170 +is another fundamentally important role of + +35 +00:01:41,170 --> 00:01:44,640 +the use cases. They provide a common language between the customers + +36 +00:01:44,640 --> 00:01:47,850 +and the developers which makes it easier to collect the right requirements. diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/8 - Use Case Driven - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/8 - Use Case Driven - lang_en_vs5.srt new file mode 100644 index 0000000..14ddaab --- /dev/null +++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/8 - Use Case Driven - lang_en_vs5.srt @@ -0,0 +1,71 @@ +1 +00:00:00,150 --> 00:00:02,370 +Now let's go back to the distinguishing aspects of + +2 +00:00:02,370 --> 00:00:04,710 +RUP, starting from the first one. That is, that the + +3 +00:00:04,710 --> 00:00:08,170 +rational unified process is use-case driven. So let's see what + +4 +00:00:08,170 --> 00:00:11,310 +that means. Generally speaking, we can see a system as + +5 +00:00:11,310 --> 00:00:14,500 +something that performs a sequence of actions in response to + +6 +00:00:14,500 --> 00:00:18,100 +user inputs. So the user submits some requests, or requests + +7 +00:00:18,100 --> 00:00:22,140 +some functionality, and the system responds to those requests. Use + +8 +00:00:22,140 --> 00:00:25,750 +cases, as we just said, capture exactly this interaction and + +9 +00:00:25,750 --> 00:00:28,620 +answer the question, what is the system supposed to do + +10 +00:00:28,620 --> 00:00:32,150 +for each user? So, this is a very important point. + +11 +00:00:32,150 --> 00:00:34,160 +So they can represent what a system can do for + +12 +00:00:34,160 --> 00:00:37,240 +each of the different types of users of the system. + +13 +00:00:37,240 --> 00:00:39,430 +For this reason, and as we will see in more + +14 +00:00:39,430 --> 00:00:42,430 +detail, in the rational unified process, use cases are a + +15 +00:00:42,430 --> 00:00:46,680 +central element of the whole development life cycle. From requirements + +16 +00:00:46,680 --> 00:00:51,360 +engineering, all the way through the process until testing and maintenance. + +17 +00:00:51,360 --> 00:00:54,620 +So, once more, use cases are used to support and + +18 +00:00:54,620 --> 00:00:58,162 +help each one of these phases in the rational unified process. diff --git a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/9 - Architecture Centric - lang_en_vs5.srt b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/9 - Architecture Centric - lang_en_vs5.srt new file mode 100644 index 0000000..b0f5487 --- /dev/null +++ b/usth/ICT2.7/P3L4 Unified Software Process Subtitles/9 - Architecture Centric - lang_en_vs5.srt @@ -0,0 +1,131 @@ +1 +00:00:00,180 --> 00:00:02,760 +The second distinguishing aspect of RUP is that it + +2 +00:00:02,760 --> 00:00:06,290 +is architecture-centric. As we saw in the first lesson + +3 +00:00:06,290 --> 00:00:09,340 +of this mini-course, a software architecture is a view + +4 +00:00:09,340 --> 00:00:12,740 +of the entire system that represents all high level + +5 +00:00:12,740 --> 00:00:15,710 +principal design decisions. Another way to see this is + +6 +00:00:15,710 --> 00:00:18,640 +by saying that use cases define the function of + +7 +00:00:18,640 --> 00:00:22,220 +the system, where as architecture defines the form of + +8 +00:00:22,220 --> 00:00:25,260 +the system. Use cases give the functionality, architecture tells + +9 +00:00:25,260 --> 00:00:28,670 +you how the system should be structured to provide the functionality. + +10 +00:00:28,670 --> 00:00:31,000 +So how do we define a software architecture in the rational + +11 +00:00:31,000 --> 00:00:33,730 +unified process. Also in this case this happens through + +12 +00:00:33,730 --> 00:00:37,340 +a sort of a iterative process. We start by creating a rough + +13 +00:00:37,340 --> 00:00:40,070 +outline of the system. And in this case we do it + +14 +00:00:40,070 --> 00:00:44,260 +independently from the functionality. So this is just the general structure + +15 +00:00:44,260 --> 00:00:46,770 +of the system. For example, we model aspects such as the + +16 +00:00:46,770 --> 00:00:50,840 +platform on which the system will run, the overall style. For example, + +17 +00:00:50,840 --> 00:00:52,780 +whether it's a client server or a peer to peer + +18 +00:00:52,780 --> 00:00:56,450 +system and so on. We then use the key use cases + +19 +00:00:56,450 --> 00:01:00,550 +in our use case diagram to define the main subsystems of + +20 +00:01:00,550 --> 00:01:03,470 +my architecture. For example, in the case of a banking IT + +21 +00:01:03,470 --> 00:01:07,150 +system, one of these subsystems might be the withdrawal system. So + +22 +00:01:07,150 --> 00:01:09,410 +what will happen in that case is that we will have + +23 +00:01:09,410 --> 00:01:13,240 +some use case that refers to the withdrawal activity, and by + +24 +00:01:13,240 --> 00:01:16,470 +analyzing that use case, we'll realize that we need a subsystem + +25 +00:01:16,470 --> 00:01:19,810 +that implements that piece of functionality. So again, we use + +26 +00:01:19,810 --> 00:01:22,680 +the key use cases to identify and define the key + +27 +00:01:22,680 --> 00:01:26,290 +subsystems for my architecture. So once we have that we + +28 +00:01:26,290 --> 00:01:30,510 +keep refining the architecture by using additional use cases. So + +29 +00:01:30,510 --> 00:01:33,030 +considering more and more pieces of functionality that will help + +30 +00:01:33,030 --> 00:01:35,430 +us to refine the architecture of the system and also + +31 +00:01:35,430 --> 00:01:39,260 +leveraging our increasing understanding of the system that we're modeling. + +32 +00:01:39,260 --> 00:01:41,470 +And this will continue until we are happy with the + +33 +00:01:41,470 --> 00:01:42,550 +architecture that we define. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/1 - Lesson Overview - lang_en_vs5.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/1 - Lesson Overview - lang_en_vs5.srt new file mode 100644 index 0000000..df7cdbe --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/1 - Lesson Overview - lang_en_vs5.srt @@ -0,0 +1,91 @@ +1 +00:00:00,700 --> 00:00:03,682 +Hello, and welcome back. In the previous + +2 +00:00:03,682 --> 00:00:07,160 +mini course we covered software design, discussed the + +3 +00:00:07,160 --> 00:00:10,020 +UML and the unified software process, and worked + +4 +00:00:10,020 --> 00:00:12,160 +on a complex project in which we developed + +5 +00:00:12,160 --> 00:00:16,020 +a distributed software system. In this mini course, + +6 +00:00:16,020 --> 00:00:17,900 +which is the last one for this class, + +7 +00:00:17,900 --> 00:00:21,080 +we will cover my very favorite topic, software + +8 +00:00:21,080 --> 00:00:24,850 +testing or more generally, software verification and validation. + +9 +00:00:25,860 --> 00:00:28,850 +So why do I love software testing? Well, + +10 +00:00:28,850 --> 00:00:32,430 +I love it because it is extremely important. It + +11 +00:00:32,430 --> 00:00:38,330 +is very challenging and it is fun but only if you do it in the right way. + +12 +00:00:38,330 --> 00:00:40,900 +In the upcoming lessons we will discuss why + +13 +00:00:40,900 --> 00:00:44,710 +software verification is important, why software testing, which is + +14 +00:00:44,710 --> 00:00:47,730 +a specific type of verification, is important, and + +15 +00:00:47,730 --> 00:00:50,730 +what are the main techniques for performing software testing. + +16 +00:00:51,910 --> 00:00:54,866 +We will also discuss test-driven development and agile methods, + +17 +00:00:54,866 --> 00:00:57,780 +in which we'll lose some of the rigidity of + +18 +00:00:57,780 --> 00:01:01,340 +the earlier processes and turn things around by writing + +19 +00:01:01,340 --> 00:01:04,260 +tests before we write the code and then writing + +20 +00:01:04,260 --> 00:01:08,280 +code that makes the test pass. Finally, we will + +21 +00:01:08,280 --> 00:01:10,750 +perform a project, in which you get to apply + +22 +00:01:10,750 --> 00:01:14,010 +most of the principles and practices of agile development + +23 +00:01:14,010 --> 00:01:17,430 +in a realistic scenario. So let's jump right in. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/10 - Verification Approaches - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/10 - Verification Approaches - lang_en_vs4.srt new file mode 100644 index 0000000..a671818 --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/10 - Verification Approaches - lang_en_vs4.srt @@ -0,0 +1,239 @@ +1 +00:00:00,320 --> 00:00:01,630 +Now that we got out of the way this + +2 +00:00:01,630 --> 00:00:04,460 +initial set of basic definitions. Let's go back to our + +3 +00:00:04,460 --> 00:00:08,770 +main concept, which is software verification. We said that software + +4 +00:00:08,770 --> 00:00:11,730 +is buggy, and because software is buggy, we need to + +5 +00:00:11,730 --> 00:00:14,690 +verify the software as much as we can. But how + +6 +00:00:14,690 --> 00:00:17,960 +can we verify software? There are several ways to verify + +7 +00:00:17,960 --> 00:00:21,150 +a software system. Among those, we will discuss four mainstream + +8 +00:00:21,150 --> 00:00:25,410 +approaches. The first one is testing, also called dynamic verification. + +9 +00:00:25,410 --> 00:00:29,400 +The second approach is static verification. The third approach is + +10 +00:00:29,400 --> 00:00:33,000 +inspections. And finally, we're going to consider a fourth approach which is + +11 +00:00:33,000 --> 00:00:36,090 +formal proofs of correctness. So what I'm going to do + +12 +00:00:36,090 --> 00:00:39,570 +next, I'm going to first provide an overview of these approaches and + +13 +00:00:39,570 --> 00:00:41,930 +then discuss some of them in more depth and please + +14 +00:00:41,930 --> 00:00:44,430 +note that although we will discuss all four approaches we will + +15 +00:00:44,430 --> 00:00:47,350 +spend most of our time on software testing. As software + +16 +00:00:47,350 --> 00:00:50,850 +testing is the most popular and most used approach in industry. + +17 +00:00:50,850 --> 00:00:53,050 +So let's start with our overview and in particular + +18 +00:00:53,050 --> 00:00:58,050 +with testing. Testing a software system means exercising the system + +19 +00:00:58,050 --> 00:01:01,680 +to try to make it fail. More precisely, let's consider + +20 +00:01:01,680 --> 00:01:04,440 +a program. Its input domain, which is the set of + +21 +00:01:04,440 --> 00:01:06,990 +all the possible inputs for the program and, its output + +22 +00:01:06,990 --> 00:01:09,470 +domain, which is a set of all the possible corresponding + +23 +00:01:09,470 --> 00:01:13,010 +outputs. Given this context, we can define what a test + +24 +00:01:13,010 --> 00:01:16,360 +case is. A test case is a pair that consists + +25 +00:01:16,360 --> 00:01:19,090 +of a, an input from the input domain D, + +26 +00:01:19,090 --> 00:01:22,620 +and then, expected output O from the output domain. + +27 +00:01:22,620 --> 00:01:25,950 +And O is the element in the output domain + +28 +00:01:25,950 --> 00:01:29,670 +that a correct software would produce when ran against I. + +29 +00:01:29,670 --> 00:01:32,170 +We can also define the concept of test suite, + +30 +00:01:32,170 --> 00:01:34,840 +which is a set of test cases, and we're going to + +31 +00:01:34,840 --> 00:01:37,730 +use these two concepts of test case and test + +32 +00:01:37,730 --> 00:01:41,400 +suite quite a bit in the rest of the lessons. + +33 +00:01:41,400 --> 00:01:44,980 +Subject verification, tries to identify specific classes of problems + +34 +00:01:44,980 --> 00:01:47,620 +in the program. Such as null pointer dereferences. And + +35 +00:01:47,620 --> 00:01:49,750 +unlike testing, what it does is that it does + +36 +00:01:49,750 --> 00:01:53,610 +not just consider individual inputs, it instead considers all + +37 +00:01:53,610 --> 00:01:56,594 +possible inputs for the program. So it consider in + +38 +00:01:56,594 --> 00:01:59,366 +a sense all possible executions of the program and + +39 +00:01:59,366 --> 00:02:02,402 +all possible behaviors of the program, that's why we + +40 +00:02:02,402 --> 00:02:06,560 +save the verification unlike testing it's complete. The 3rd technique + +41 +00:02:06,560 --> 00:02:08,755 +we are going to consider is inspections, + +42 +00:02:08,755 --> 00:02:12,804 +and inspections are also called reviews or walkthroughs. + +43 +00:02:12,804 --> 00:02:15,010 +And unlike the previous techniques, inspections are a + +44 +00:02:15,010 --> 00:02:18,660 +human intensive activity, more precisely, they are a + +45 +00:02:18,660 --> 00:02:22,520 +manual and group activity in which several + +46 +00:02:22,520 --> 00:02:25,700 +people from the organization that developed the software, + +47 +00:02:25,700 --> 00:02:29,190 +look at the code or other artifacts developed + +48 +00:02:29,190 --> 00:02:31,888 +during the software production and try to identify + +49 +00:02:31,888 --> 00:02:35,950 +defects in these artifacts. And interestingly inspections + +50 +00:02:35,950 --> 00:02:37,580 +have been shown to be quite effective in + +51 +00:02:37,580 --> 00:02:39,820 +practice and that's the reason why they're used + +52 +00:02:39,820 --> 00:02:42,550 +quite widely in the industry. Finally, the last + +53 +00:02:42,550 --> 00:02:45,100 +technique I want to mention is Formal + +54 +00:02:45,100 --> 00:02:49,650 +Proof (of correctness). Given a software specification, and + +55 +00:02:49,650 --> 00:02:53,370 +actually a formal specification, so a document that + +56 +00:02:53,370 --> 00:02:57,410 +formally defines and specifies the behavior, the expected + +57 +00:02:57,410 --> 00:03:00,320 +behavior of the program. A form of proof of + +58 +00:03:00,320 --> 00:03:05,400 +correctness proves that the program being verified, actually implements + +59 +00:03:05,400 --> 00:03:07,922 +the program specification and it does that through a + +60 +00:03:07,922 --> 00:03:12,880 +sophisticated mathematical analysis of the specifications and of the code. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/11 - Pros and Cons of Approaches - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/11 - Pros and Cons of Approaches - lang_en_vs4.srt new file mode 100644 index 0000000..36a58ee --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/11 - Pros and Cons of Approaches - lang_en_vs4.srt @@ -0,0 +1,195 @@ +1 +00:00:00,230 --> 00:00:02,870 +The four different techniques that we just discussed have + +2 +00:00:02,870 --> 00:00:06,120 +a number of pros and cons. So next we + +3 +00:00:06,120 --> 00:00:08,780 +are going to discuss the main pros and cons + +4 +00:00:08,780 --> 00:00:11,140 +for these techniques, so as to be able to compare + +5 +00:00:11,140 --> 00:00:14,330 +them. When testing is concerned the main positive about + +6 +00:00:14,330 --> 00:00:17,600 +this technique is that it does not generate false + +7 +00:00:17,600 --> 00:00:21,740 +alarms. In other words, it doesn't generate false positives. + +8 +00:00:21,740 --> 00:00:25,180 +What that means, is that when testing generates a failure, + +9 +00:00:25,180 --> 00:00:27,230 +that means that there is an actual problem in the + +10 +00:00:27,230 --> 00:00:30,060 +code. The main limitation of testing, however, is that it + +11 +00:00:30,060 --> 00:00:33,680 +is highly incomplete. Consider again the picture that we drew + +12 +00:00:33,680 --> 00:00:36,430 +a little earlier. The one representing the input domain of + +13 +00:00:36,430 --> 00:00:39,430 +the program being tested. Even in the best scenario, testing + +14 +00:00:39,430 --> 00:00:44,050 +can consider only a tiny fraction of the problem domain, + +15 +00:00:44,050 --> 00:00:47,430 +and therefor a tiny fraction of the program's behavior, and + +16 +00:00:47,430 --> 00:00:50,308 +we'll say a lot more about that in the following lessons. + +17 +00:00:50,308 --> 00:00:53,780 +Static verification, unlike testing, has the main advantage + +18 +00:00:53,780 --> 00:00:57,320 +that it considers all program behaviors. If we + +19 +00:00:57,320 --> 00:01:00,370 +look back at our diagram, whereas testing will + +20 +00:01:00,370 --> 00:01:04,010 +select only a few of those inputs, static verification + +21 +00:01:04,010 --> 00:01:07,120 +will consider them all. Unfortunately, however, this comes + +22 +00:01:07,120 --> 00:01:08,990 +with a price. Due to limitation of this + +23 +00:01:08,990 --> 00:01:11,490 +kind of analysis and due to infeasibility issues, + +24 +00:01:11,490 --> 00:01:15,260 +static verifiation considers not only all the possible behaviours, + +25 +00:01:15,260 --> 00:01:18,870 +but also some impossible behaviors. And what that means is + +26 +00:01:18,870 --> 00:01:22,472 +that static gratificaition can generate false positives. And this is, + +27 +00:01:22,472 --> 00:01:24,590 +in fact, the main issue with static verification techniques. As + +28 +00:01:24,590 --> 00:01:28,550 +we will further discuss later in the class, static verification can + +29 +00:01:28,550 --> 00:01:31,280 +generate results that are not true. For example, it might + +30 +00:01:31,280 --> 00:01:33,970 +report a possible no point of the refernce that cannot + +31 +00:01:33,970 --> 00:01:37,590 +actually occur in practice. The strongest point about inspections is + +32 +00:01:37,590 --> 00:01:40,950 +that, when they're done in a rigorous way, they're systematic and + +33 +00:01:40,950 --> 00:01:43,420 +they result in a thorough analysis of the code. + +34 +00:01:43,420 --> 00:01:46,840 +They are nevertheless a manual process, a human process. + +35 +00:01:46,840 --> 00:01:49,890 +So they're not formal and their effectiveness may depend + +36 +00:01:49,890 --> 00:01:53,560 +on the specific people performing the inspection. So its results + +37 +00:01:53,560 --> 00:01:57,150 +can be subjective. Finally, the main pro about formal + +38 +00:01:57,150 --> 00:02:01,090 +proofs of correctness is that they provide strong guarantees. + +39 +00:02:01,090 --> 00:02:03,740 +They can guarantee that the program is correct, which + +40 +00:02:03,740 --> 00:02:06,280 +is not something that any of the other approaches can + +41 +00:02:06,280 --> 00:02:09,505 +do, including study verification. But the main limitation of + +42 +00:02:09,505 --> 00:02:12,680 +formal proofs is that they need a form of specification, + +43 +00:02:12,680 --> 00:02:15,750 +a complete mathematical description of the expected behavior of + +44 +00:02:15,750 --> 00:02:19,060 +the whole program, and unfortunately such a specification is rarely + +45 +00:02:19,060 --> 00:02:21,920 +available, and it is very complex to build one. + +46 +00:02:21,920 --> 00:02:25,170 +In addition, it is also very complex, and possibly expensive, + +47 +00:02:25,170 --> 00:02:27,720 +to prove that the program corresponds to a specification. + +48 +00:02:27,720 --> 00:02:30,990 +That is a process that requires strong mathematical skills and, + +49 +00:02:30,990 --> 00:02:32,551 +therefore, a very specialized personnel. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/12 - Verification Approaches Quiz - lang_en_vs5.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/12 - Verification Approaches Quiz - lang_en_vs5.srt new file mode 100644 index 0000000..a5aa4f7 --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/12 - Verification Approaches Quiz - lang_en_vs5.srt @@ -0,0 +1,47 @@ +1 +00:00:00,240 --> 00:00:02,570 +So let's have another simple quiz, and we're going to + +2 +00:00:02,570 --> 00:00:05,490 +have our developer Brett introducing the quiz. And the + +3 +00:00:05,490 --> 00:00:07,900 +starting point for this quiz is the fact that + +4 +00:00:07,900 --> 00:00:11,970 +today, quality assurance, or verification, if you wish, is mostly + +5 +00:00:11,970 --> 00:00:15,730 +testing. That is, testing is the most commonly used + +6 +00:00:15,730 --> 00:00:19,550 +activity to perform software verification. So now, I'm going to show + +7 +00:00:19,550 --> 00:00:22,310 +you a quote, 50% of my company employees are + +8 +00:00:22,310 --> 00:00:25,691 +testers and the rest spends 50% of their time testing, + +9 +00:00:25,691 --> 00:00:27,347 +so I want to ask you, who said + +10 +00:00:27,347 --> 00:00:29,664 +that? I'm going to give you some possibilities. Was + +11 +00:00:29,664 --> 00:00:34,215 +that Yogi Berra, Steve Jobs, Henry Ford, Bill + +12 +00:00:34,215 --> 00:00:37,360 +Gates or Frank Gehry? Take your best guess. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/13 - Verification Approaches Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/13 - Verification Approaches Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..b8a0076 --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/13 - Verification Approaches Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,11 @@ +1 +00:00:00,260 --> 00:00:04,090 +And the correct answer is Bill Gates. So this gives you an idea of how + +2 +00:00:04,090 --> 00:00:07,070 +important testing is in Microsoft in particular, + +3 +00:00:07,070 --> 00:00:09,350 +but in many other software companies in general. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/14 - Testing Introduction - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/14 - Testing Introduction - lang_en_vs4.srt new file mode 100644 index 0000000..70df565 --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/14 - Testing Introduction - lang_en_vs4.srt @@ -0,0 +1,119 @@ +1 +00:00:00,340 --> 00:00:02,290 +So let's talk more about testing, as we said a + +2 +00:00:02,290 --> 00:00:06,500 +little earlier in the lesson, testing means executing the program on + +3 +00:00:06,500 --> 00:00:09,400 +a sample of the input domain, that is of all + +4 +00:00:09,400 --> 00:00:12,210 +the possible input data and I really want to stress that + +5 +00:00:12,210 --> 00:00:16,190 +this sample is tiny sample of the input domain. There + +6 +00:00:16,190 --> 00:00:19,154 +are two important aspects of testing that I'm want to mention here, + +7 +00:00:19,154 --> 00:00:22,360 +there first one is that testing is a dynamic technique. And + +8 +00:00:22,360 --> 00:00:25,370 +what that means is that the program must be executed in + +9 +00:00:25,370 --> 00:00:28,130 +order to perform testing. The second important point is that + +10 +00:00:28,130 --> 00:00:32,040 +testing is an optimistic approximation. And what does it mean + +11 +00:00:32,040 --> 00:00:35,590 +to be optimistic? Well, it means that the program under + +12 +00:00:35,590 --> 00:00:38,820 +test is exercised with a very small subset of all the + +13 +00:00:38,820 --> 00:00:41,260 +possible inputs as we just said. And this is done + +14 +00:00:41,260 --> 00:00:45,150 +under the assumption that the behavior with any other input + +15 +00:00:45,150 --> 00:00:47,770 +is consistent with the behavior shown for the selected subset + +16 +00:00:47,770 --> 00:00:51,140 +of input data, that is why it is an optimistic approach. + +17 +00:00:51,140 --> 00:00:54,620 +Another concept that I want to mention explicitly, is the + +18 +00:00:54,620 --> 00:00:57,930 +concept of successful test. And I'm going to do that, + +19 +00:00:57,930 --> 00:01:01,260 +using another quote. This one from Goodenough and Gerhart + +20 +00:01:01,260 --> 00:01:03,850 +in their paper Towards a Theory of Test Data Selection, + +21 +00:01:03,850 --> 00:01:06,420 +and what the quote says is that a test + +22 +00:01:06,420 --> 00:01:10,000 +is successful if the program fails. And this might sound + +23 +00:01:10,000 --> 00:01:13,650 +counterintuitive, but the point here is that testing cannot + +24 +00:01:13,650 --> 00:01:16,490 +prove the absence of errors, but only reveal their presence. + +25 +00:01:16,490 --> 00:01:21,550 +If a set of tests does not produce any failure, we are either in the extremely + +26 +00:01:21,550 --> 00:01:24,050 +unlikely case of a correct program, or in + +27 +00:01:24,050 --> 00:01:26,650 +the very likely situation of a bad set of + +28 +00:01:26,650 --> 00:01:30,932 +tests that are not able to reveal failures of the program. And that is why we + +29 +00:01:30,932 --> 00:01:32,730 +say that the test is successful if you + +30 +00:01:32,730 --> 00:01:35,110 +can show that there are problems in the program. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/15 - Testing Granularity Levels - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/15 - Testing Granularity Levels - lang_en_vs4.srt new file mode 100644 index 0000000..83df7ea --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/15 - Testing Granularity Levels - lang_en_vs4.srt @@ -0,0 +1,275 @@ +1 +00:00:00,160 --> 00:00:03,050 +And before I start talking about specific testing techniques, there's + +2 +00:00:03,050 --> 00:00:05,490 +something else that I want to discuss, which is Testing + +3 +00:00:05,490 --> 00:00:09,090 +Granularity Levels. So let's consider a software system, a system + +4 +00:00:09,090 --> 00:00:12,310 +made out of components that interact with one another. So the + +5 +00:00:12,310 --> 00:00:15,000 +first level that we consider in testing is called Unit + +6 +00:00:15,000 --> 00:00:18,490 +Testing, which is the testing of the individual units or modules + +7 +00:00:18,490 --> 00:00:20,690 +in isolation. The next step, is to see there are + +8 +00:00:20,690 --> 00:00:25,340 +multiple modules and their interactions. And this is called Integration Testing. + +9 +00:00:25,340 --> 00:00:28,650 +So, integration testing is the testing of the interactions among + +10 +00:00:28,650 --> 00:00:31,460 +different modules. And it can be performed according to different + +11 +00:00:31,460 --> 00:00:34,260 +strategies. Depending on the order in which the modules are + +12 +00:00:34,260 --> 00:00:37,570 +integrated and on whether we integrate one module at a time + +13 +00:00:37,570 --> 00:00:40,510 +or multiple modules together, all at once. And in this + +14 +00:00:40,510 --> 00:00:43,240 +latter case, we call this kind of integration testing, the one that + +15 +00:00:43,240 --> 00:00:47,640 +integrates all the modules at once, Big Bang integration testing. + +16 +00:00:47,640 --> 00:00:50,520 +And after performing integration testing, the next step is to test + +17 +00:00:50,520 --> 00:00:52,750 +the complete system as a whole. And this level of + +18 +00:00:52,750 --> 00:00:56,190 +testing is normally called, System Testing. So system testing in the + +19 +00:00:56,190 --> 00:00:59,560 +testing of the complete system and it includes both functional and + +20 +00:00:59,560 --> 00:01:03,250 +non functional testing. We will discuss functional and non functional testing + +21 +00:01:03,250 --> 00:01:05,575 +in details in the next two lessons. But I just + +22 +00:01:05,575 --> 00:01:08,330 +want to give you an idea of what they are intuitively. Functional + +23 +00:01:08,330 --> 00:01:12,250 +tests are the test that aim to verify the functionality provided + +24 +00:01:12,250 --> 00:01:15,680 +by the system. For example if you consider the function double + +25 +00:01:15,680 --> 00:01:17,840 +value that we saw earlier in the lesson, a + +26 +00:01:17,840 --> 00:01:20,660 +functional test will try to assess that that function + +27 +00:01:20,660 --> 00:01:23,970 +is producing the right value given a specific input. + +28 +00:01:23,970 --> 00:01:26,826 +Conversely, no functional test are the one that target, as + +29 +00:01:26,826 --> 00:01:30,540 +surprisingly, no functional properties of the system. For example, + +30 +00:01:30,540 --> 00:01:34,060 +no functional test will include performance tests, load tests, + +31 +00:01:34,060 --> 00:01:37,310 +robustness tests. In general, no functional tests will try + +32 +00:01:37,310 --> 00:01:41,410 +to assess different qualities of the system, such as reliability, + +33 +00:01:41,410 --> 00:01:45,970 +maintainability, usability, so basically, all the ilities that you can + +34 +00:01:45,970 --> 00:01:49,760 +think about. In addition to these three basic testing levels, there + +35 +00:01:49,760 --> 00:01:51,830 +are two more levels that I want to consider and that + +36 +00:01:51,830 --> 00:01:55,150 +I want to discuss. And they both involve the whole system. + +37 +00:01:55,150 --> 00:01:57,610 +And the first one is Acceptance Testing which is the + +38 +00:01:57,610 --> 00:02:01,320 +validation of the software against the Customer requirements. So this is + +39 +00:02:01,320 --> 00:02:04,090 +the testing that makes sure that the system does what the + +40 +00:02:04,090 --> 00:02:06,720 +customer wants it to do. And the last type of testing + +41 +00:02:06,720 --> 00:02:09,729 +that I want to mention is Regression Testing. And regression testing + +42 +00:02:09,729 --> 00:02:13,260 +is the type of testing or retesting, that we perform every time + +43 +00:02:13,260 --> 00:02:15,540 +that we change our system. And we need to make sure + +44 +00:02:15,540 --> 00:02:19,060 +that the changes behave as intended and that the unchanged code is + +45 +00:02:19,060 --> 00:02:22,680 +not negatively affected by the modification, by these changes. In fact, + +46 +00:02:22,680 --> 00:02:25,070 +what can happen when you modify the code is that parts of + +47 +00:02:25,070 --> 00:02:28,120 +the code that are related to the changes, are actually affected + +48 +00:02:28,120 --> 00:02:32,110 +by the changes, and start misbehaving. And we call those regression errors. + +49 +00:02:32,110 --> 00:02:35,080 +And regression errors, are very common. For example, you're probably + +50 +00:02:35,080 --> 00:02:38,070 +familiar with the situation in which, one software update is + +51 +00:02:38,070 --> 00:02:41,350 +released, and just a few days later, another software update + +52 +00:02:41,350 --> 00:02:44,640 +is released. In many cases that happens because the first update + +53 +00:02:44,640 --> 00:02:47,760 +was containing regression errors. So the changes in the code + +54 +00:02:47,760 --> 00:02:51,100 +that broke some functionality, that resulted in failures on the user's + +55 +00:02:51,100 --> 00:02:53,940 +machine and in bug reports and therefore that caused further + +56 +00:02:53,940 --> 00:02:57,090 +maintenance, further bug fixes, and a release on a new version. + +57 +00:02:57,090 --> 00:02:59,790 +Something else I'd like to mention about regression testing, is that + +58 +00:02:59,790 --> 00:03:02,535 +regression testing is one of the main causes why software maintenance is + +59 +00:03:02,535 --> 00:03:05,679 +so expensive. And that's also why researchers have invested a great + +60 +00:03:05,679 --> 00:03:07,481 +deal of effort into refining regression + +61 +00:03:07,481 --> 00:03:09,495 +testing techniques that can make regression + +62 +00:03:09,495 --> 00:03:12,599 +testing more effective and more efficient. So let me leave you, + +63 +00:03:12,599 --> 00:03:15,129 +with a little piece of advice which is try to automate as + +64 +00:03:15,129 --> 00:03:19,470 +much as possible regression testing. For example use scripts, use tools, make + +65 +00:03:19,470 --> 00:03:22,660 +sure to save your harness, make sure to save your input, and + +66 +00:03:22,660 --> 00:03:24,820 +outputs for the test, because you want to be able + +67 +00:03:24,820 --> 00:03:27,680 +to rerun your test, at a push of a button as + +68 +00:03:27,680 --> 00:03:29,750 +much as possible every time you change your code, to + +69 +00:03:29,750 --> 00:03:32,560 +avoid the presence of regression errors in the code you release. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/16 - Alpha and Beta Testing - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/16 - Alpha and Beta Testing - lang_en_vs4.srt new file mode 100644 index 0000000..f81f551 --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/16 - Alpha and Beta Testing - lang_en_vs4.srt @@ -0,0 +1,95 @@ +1 +00:00:00,510 --> 00:00:02,754 +All the testing levels that we've seen so far is what + +2 +00:00:02,754 --> 00:00:06,058 +we can call developer's testing. So that's testing that is performed + +3 +00:00:06,058 --> 00:00:09,649 +either within the testing organization, or by somebody who's doing like + +4 +00:00:09,649 --> 00:00:13,520 +third-party testers on behalf of the testing organization. But there are two + +5 +00:00:13,520 --> 00:00:16,280 +other kinds of testing that are worth mentioning that are also + +6 +00:00:16,280 --> 00:00:19,600 +related to testing phases and these are alpha and beta testing. + +7 +00:00:19,600 --> 00:00:23,050 +Alpha testing is the testing performed by distributing a software system + +8 +00:00:23,050 --> 00:00:26,000 +ready to be released to a set of users that are internal + +9 +00:00:26,000 --> 00:00:29,480 +to the organization that developed the software. So you can consider these + +10 +00:00:29,480 --> 00:00:32,460 +users as, if you pass me the term, guinea pigs that will + +11 +00:00:32,460 --> 00:00:35,170 +use an early version of the code and will likely discover errors + +12 +00:00:35,170 --> 00:00:37,850 +that escaped testing and will have made it to the field if + +13 +00:00:37,850 --> 00:00:41,390 +not caught. Beta testing is the next step after alpha testing, in + +14 +00:00:41,390 --> 00:00:44,530 +which the software is released to a selected subset of users, in + +15 +00:00:44,530 --> 00:00:47,770 +this case, outside your organization. And also in this case, the users + +16 +00:00:47,770 --> 00:00:51,110 +are likely to discover latent errors in the code before it is officially + +17 +00:00:51,110 --> 00:00:54,240 +released to the broader user population, so before we have an + +18 +00:00:54,240 --> 00:00:56,850 +actual product release. So you may wonder why do we need + +19 +00:00:56,850 --> 00:00:59,360 +to do both alpha and beta testing. Why not just one + +20 +00:00:59,360 --> 00:01:02,980 +of the two? The reason is that alpha testing is performed + +21 +00:01:02,980 --> 00:01:06,730 +to iron out the very obvious issues that still escape testing, + +22 +00:01:06,730 --> 00:01:09,610 +but we want to do that before involving people outside your + +23 +00:01:09,610 --> 00:01:12,730 +organization. And the rationale is that alpha testers have a higher + +24 +00:01:12,730 --> 00:01:16,710 +tolerance for problems than beta testers, who expect a mostly working system. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/17 - Black and White Box Testing Introduction - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/17 - Black and White Box Testing Introduction - lang_en_vs4.srt new file mode 100644 index 0000000..c61e331 --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/17 - Black and White Box Testing Introduction - lang_en_vs4.srt @@ -0,0 +1,115 @@ +1 +00:00:00,370 --> 00:00:02,520 +We're almost at the end of this lesson. In the + +2 +00:00:02,520 --> 00:00:05,520 +next two lessons we're going to talk about two main families + +3 +00:00:05,520 --> 00:00:07,800 +of testing techniques, black-box testing + +4 +00:00:07,800 --> 00:00:10,340 +techniques, and white-box testing techniques. So, + +5 +00:00:10,340 --> 00:00:12,730 +what I want to do before getting into the discussion of the + +6 +00:00:12,730 --> 00:00:15,385 +specific techniques in this families. I want to give you an + +7 +00:00:15,385 --> 00:00:19,440 +overview of what black-box testing and white-box testing are. Black box + +8 +00:00:19,440 --> 00:00:21,950 +testing is the kind of testing in which we consider the + +9 +00:00:21,950 --> 00:00:25,570 +software as a closed box. That's why it's called black box. + +10 +00:00:25,570 --> 00:00:27,770 +So we don't look inside the software, we don't want to + +11 +00:00:27,770 --> 00:00:30,131 +look at the code. We just going to look at the description + +12 +00:00:30,131 --> 00:00:33,210 +of the software. So this is the testing that is based + +13 +00:00:33,210 --> 00:00:36,100 +on a description of the software, which is what we normally + +14 +00:00:36,100 --> 00:00:39,690 +call the specification for the software. And what black box testing + +15 +00:00:39,690 --> 00:00:44,040 +tries to do is to cover as much specified behavior as + +16 +00:00:44,040 --> 00:00:47,290 +possible, and the main limitation black box testing and the reason + +17 +00:00:47,290 --> 00:00:51,540 +why this is complimentary to white-box testing is that it cannot reveal + +18 +00:00:51,540 --> 00:00:56,590 +errors due to implementation details. Conversely, white-box testing + +19 +00:00:56,590 --> 00:00:58,430 +is the kind of testing that looks inside the + +20 +00:00:58,430 --> 00:01:00,360 +box. So looks at the code and how + +21 +00:01:00,360 --> 00:01:02,760 +the code is written and uses this information to + +22 +00:01:02,760 --> 00:01:06,300 +perform the testing. So white-box testing is based + +23 +00:01:06,300 --> 00:01:09,120 +on the code, its goal is to cover as + +24 +00:01:09,120 --> 00:01:13,210 +much coded behavior in this case, as possible, and + +25 +00:01:13,210 --> 00:01:17,100 +its limitation is that unlike black-box testing, it can't + +26 +00:01:17,100 --> 00:01:21,880 +reveal errors due to missing paths. Where missing paths are + +27 +00:01:21,880 --> 00:01:25,250 +a part of a software specification that are not implemented and + +28 +00:01:25,250 --> 00:01:27,320 +the reason why you can not reveal them is because + +29 +00:01:27,320 --> 00:01:29,790 +it is focused on the code and not on the specification. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/18 - Black Box Testing Example - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/18 - Black Box Testing Example - lang_en_vs4.srt new file mode 100644 index 0000000..dab72eb --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/18 - Black Box Testing Example - lang_en_vs4.srt @@ -0,0 +1,135 @@ +1 +00:00:00,500 --> 00:00:03,185 +To give you a slightly better understanding of the differences + +2 +00:00:03,185 --> 00:00:06,300 +between black-box testing and white-box testing, I am going to provide you + +3 +00:00:06,300 --> 00:00:10,040 +a couple of simple examples that illustrate the, the strengths and + +4 +00:00:10,040 --> 00:00:12,920 +limitations of these two techniques. So, in this case, let's start + +5 +00:00:12,920 --> 00:00:15,750 +with black-box testing, so we're only working with this specification. + +6 +00:00:15,750 --> 00:00:18,540 +So, let's say that our specification says that this is a + +7 +00:00:18,540 --> 00:00:23,550 +program that inputs an integer value and prints it. And implementation, + +8 +00:00:23,550 --> 00:00:25,900 +we don't know because we're working at the black box level. + +9 +00:00:25,900 --> 00:00:28,710 +If we wanted to test this function according to its + +10 +00:00:28,710 --> 00:00:32,060 +specification, what we will probably do is to select a positive + +11 +00:00:32,060 --> 00:00:35,370 +integer, a negative integer, and the zero as test inputs + +12 +00:00:35,370 --> 00:00:37,840 +and see how the program behaves for these inputs. So let + +13 +00:00:37,840 --> 00:00:41,500 +me now show you a possible implementation for this specification. + +14 +00:00:41,500 --> 00:00:44,590 +What I'm showing here is this function that we called print + +15 +00:00:44,590 --> 00:00:48,010 +NumBytes, which takes the parameter and prints it. And one thing + +16 +00:00:48,010 --> 00:00:50,905 +that we notice right away is that, although in the specification, + +17 +00:00:50,905 --> 00:00:53,960 +numbers that are less than 1024 and numbers that + +18 +00:00:53,960 --> 00:00:57,320 +are greater or equal to 1024 are exactly equivalent from + +19 +00:00:57,320 --> 00:01:01,020 +the specification standpoint. They're however treated differently in the + +20 +00:01:01,020 --> 00:01:04,140 +code, so the developer decided that the program was just + +21 +00:01:04,140 --> 00:01:06,200 +going to print the value of the parameter if it's + +22 +00:01:06,200 --> 00:01:09,300 +less than 1024. But it was actually divided by 1024 + +23 +00:01:09,300 --> 00:01:13,560 +and printing it with a kilobyte mark after it + +24 +00:01:13,560 --> 00:01:16,170 +if you are greater than 1024. And notice that here, + +25 +00:01:16,170 --> 00:01:19,370 +there is a problem. The developer, just a number 124, instead + +26 +00:01:19,370 --> 00:01:22,840 +of 1024. So there's probably a typo in this point in the + +27 +00:01:22,840 --> 00:01:26,260 +code. So this is a case in which by simply doing black-box + +28 +00:01:26,260 --> 00:01:28,750 +testing, so by simply looking at the specific issue, we might miss + +29 +00:01:28,750 --> 00:01:31,510 +this problem. Because we have no reason to consider numbers that are + +30 +00:01:31,510 --> 00:01:34,780 +less than 1024 or greater than 1024. However if we were to + +31 +00:01:34,780 --> 00:01:38,010 +look at the code, so operating at white-box manner, we will right + +32 +00:01:38,010 --> 00:01:41,340 +away see that we need to have a test case that checks + +33 +00:01:41,340 --> 00:01:44,880 +the program when the parameter is greater than 1024. And we will find + +34 +00:01:44,880 --> 00:01:47,300 +the problem right away. So now let me show you a dual example. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/19 - White Box Testing Example - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/19 - White Box Testing Example - lang_en_vs4.srt new file mode 100644 index 0000000..896f9b1 --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/19 - White Box Testing Example - lang_en_vs4.srt @@ -0,0 +1,143 @@ +1 +00:00:00,080 --> 00:00:03,086 +In this case we focus on white box testing. So consider now this + +2 +00:00:03,086 --> 00:00:06,556 +other function, called fun. And let's assume that we want to test this function + +3 +00:00:06,556 --> 00:00:09,777 +without having a specification. So without knowing exactly what it needs to do. + +4 +00:00:09,777 --> 00:00:12,996 +But just by looking at the code. So we will try to do the + +5 +00:00:12,996 --> 00:00:16,030 +problem in this case is to try to just execute all the statements. + +6 +00:00:16,030 --> 00:00:18,995 +In the function. And notice I will talk extensively of what does it + +7 +00:00:18,995 --> 00:00:22,560 +means to do white box testing later on in the next, two classes. + +8 +00:00:22,560 --> 00:00:25,560 +So if that's our goal, if our goal is to cover all the statements, + +9 +00:00:25,560 --> 00:00:27,670 +any input will really do. So any test case + +10 +00:00:27,670 --> 00:00:30,250 +will excecute all statements in the code. And we'll a + +11 +00:00:30,250 --> 00:00:33,801 +complete, you know, white-box testing coverage for the program. + +12 +00:00:33,801 --> 00:00:35,865 +Imagine that I now give you a specification for this + +13 +00:00:35,865 --> 00:00:39,071 +function. And what the specification says is that this + +14 +00:00:39,071 --> 00:00:43,232 +function inputs an integer parameter, param, and returns half of + +15 +00:00:43,232 --> 00:00:45,860 +its value, if param is even, and its value + +16 +00:00:45,860 --> 00:00:50,740 +unchanged otherwise. That means if param is odd. So looking + +17 +00:00:50,740 --> 00:00:54,320 +at this specification, we can clearly see that the function fun + +18 +00:00:54,320 --> 00:00:57,740 +works correctly only for even integers, and it doesn't work for + +19 +00:00:57,740 --> 00:01:00,570 +odd integers. Because it computes. Half of the value of the + +20 +00:01:00,570 --> 00:01:04,410 +parameter and returns it every time, no matter what param is. So + +21 +00:01:04,410 --> 00:01:07,320 +this is a case in which white box testing could easily + +22 +00:01:07,320 --> 00:01:10,620 +miss the problem, because as we said any input will exercise + +23 +00:01:10,620 --> 00:01:12,900 +the code. It's just by chance that we could reveal one + +24 +00:01:12,900 --> 00:01:15,750 +that revealed the problem in the code. Conversely if we were to + +25 +00:01:15,750 --> 00:01:19,520 +work, in a black box manner. Typically looking at the specification, we + +26 +00:01:19,520 --> 00:01:22,390 +will select at least one odd, and one even input number to + +27 +00:01:22,390 --> 00:01:25,010 +exercise all of the specified behavior. And we will find the problem + +28 +00:01:25,010 --> 00:01:28,110 +right away. So these two examples are just very small examples, and + +29 +00:01:28,110 --> 00:01:30,910 +they're kind of, you know, stretched. But these kind of issues occur + +30 +00:01:30,910 --> 00:01:33,680 +on a much bigger scale and in much more subtle ways in + +31 +00:01:33,680 --> 00:01:36,970 +real world software. And so what this examples do is to show + +32 +00:01:36,970 --> 00:01:41,270 +you, how black box and white box tests are really complimentary techniques. + +33 +00:01:41,270 --> 00:01:43,130 +So in the next two lessions we will explore + +34 +00:01:43,130 --> 00:01:45,130 +these two types of techniques in detail. We will + +35 +00:01:45,130 --> 00:01:48,020 +see different kinds of white box and black box + +36 +00:01:48,020 --> 00:01:50,670 +testing. And we'll talk about their strengths and the mutations diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/2 - Introduction - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/2 - Introduction - lang_en_vs4.srt new file mode 100644 index 0000000..1a25089 --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/2 - Introduction - lang_en_vs4.srt @@ -0,0 +1,103 @@ +1 +00:00:00,280 --> 00:00:02,750 +So let me start with some examples that motivate the + +2 +00:00:02,750 --> 00:00:06,330 +need for very fine software. The first example I want to + +3 +00:00:06,330 --> 00:00:09,580 +use is the famous Arian five. And if you remember + +4 +00:00:09,580 --> 00:00:13,060 +that's a rocket that exploded not too long after departure. + +5 +00:00:13,060 --> 00:00:15,800 +Because of a software error. And even without going to + +6 +00:00:15,800 --> 00:00:19,400 +such dramatic examples. I'm sure you're all familiar with this + +7 +00:00:19,400 --> 00:00:22,470 +kind of situation. Or this one, or again in this + +8 +00:00:22,470 --> 00:00:26,070 +one. And here I'm not really picking on any specific organization, + +9 +00:00:26,070 --> 00:00:32,280 +operating system or software. The point I want to make is that software is + +10 +00:00:32,280 --> 00:00:34,730 +buggy. In fact, a federal report from + +11 +00:00:34,730 --> 00:00:37,810 +a few years ago assessed that software bugs + +12 +00:00:37,810 --> 00:00:41,300 +are costing the US economy, $60 billion + +13 +00:00:41,300 --> 00:00:44,120 +every year. In addition, studies have shown that + +14 +00:00:44,120 --> 00:00:47,810 +software contains on average one to five + +15 +00:00:47,810 --> 00:00:51,472 +bugs every 1000 lines of code. Building 100% + +16 +00:00:51,472 --> 00:00:55,940 +correct mass-market software is just impossible. And if + +17 +00:00:55,940 --> 00:00:58,270 +this is the case, what can we do? + +18 +00:00:58,270 --> 00:01:03,520 +What we need to do is to verify software as much as possible. In this part of + +19 +00:01:03,520 --> 00:01:05,750 +the course, we will discuss how we can + +20 +00:01:05,750 --> 00:01:09,480 +do this. We will discuss different alternative ways + +21 +00:01:09,480 --> 00:01:13,980 +of very fine software systems. With particular attention + +22 +00:01:13,980 --> 00:01:16,570 +to the most common type of verification. Which is + +23 +00:01:16,570 --> 00:01:19,470 +software testing. Before doing that however, let + +24 +00:01:19,470 --> 00:01:21,090 +me go over some basic terms that are + +25 +00:01:21,090 --> 00:01:23,190 +commonly used. And I have to say, + +26 +00:01:23,190 --> 00:01:26,330 +often misused in the context of software verification. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/3 - Failure, Fault, and Error - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/3 - Failure, Fault, and Error - lang_en_vs4.srt new file mode 100644 index 0000000..e6459c0 --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/3 - Failure, Fault, and Error - lang_en_vs4.srt @@ -0,0 +1,79 @@ +1 +00:00:00,390 --> 00:00:03,460 +The first term I want to define, is failure. + +2 +00:00:03,460 --> 00:00:09,080 +A failure is an observable incorrect behavior of the software. + +3 +00:00:09,080 --> 00:00:10,910 +It is conceptually related to the behavior of the + +4 +00:00:10,910 --> 00:00:13,910 +program, rather than its code. The second term I want + +5 +00:00:13,910 --> 00:00:17,600 +to introduce is fault, which is also called bug. + +6 +00:00:17,600 --> 00:00:20,540 +And the fault or bug, is an incorrect piece of + +7 +00:00:20,540 --> 00:00:22,780 +code. In other words, a fault is related to + +8 +00:00:22,780 --> 00:00:25,900 +the code. And is a necessary, but not sufficient condition + +9 +00:00:25,900 --> 00:00:28,160 +for the occurrence of a failure. The final + +10 +00:00:28,160 --> 00:00:30,880 +term I want to introduce is, error. Where an + +11 +00:00:30,880 --> 00:00:33,630 +error is the cause of a fault. It is + +12 +00:00:33,630 --> 00:00:36,990 +usually a human error, which can be conceptual. A + +13 +00:00:36,990 --> 00:00:39,620 +typo or something along those lines. And know that + +14 +00:00:39,620 --> 00:00:43,422 +this terminology, failure, fault and error, is the official + +15 +00:00:43,422 --> 00:00:46,945 +[UNKNOWN] terminology. So you cannot go wrong if you + +16 +00:00:46,945 --> 00:00:51,282 +use it. Now, let me illustrate the difference between + +17 +00:00:51,282 --> 00:00:57,153 +failure, fault and error. Using a small example. What I'm showing here is + +18 +00:00:57,153 --> 00:01:00,876 +a small function that, as you can see from its name, takes an + +19 +00:01:00,876 --> 00:01:04,920 +integer parameter i. And is supposed to double the value of i, and + +20 +00:01:04,920 --> 00:01:08,420 +return it. As we can clearly see, this is not what the function does. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/4 - Failure, Fault, and Error Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/4 - Failure, Fault, and Error Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..03f6a6a --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/4 - Failure, Fault, and Error Quiz - lang_en_vs4.srt @@ -0,0 +1,15 @@ +1 +00:00:00,120 --> 00:00:02,900 +So now I have a few questions for you. And so we use, as + +2 +00:00:02,900 --> 00:00:07,350 +usual, our developer Janet to introduce a quiz. And the first question I want to + +3 +00:00:07,350 --> 00:00:11,710 +ask you is the following. A call to double passing three as a parameter returns + +4 +00:00:11,710 --> 00:00:16,149 +the value nine. What is this? Is that a failure, a fault, or an error? diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/5 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/5 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..1bcde7f --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/5 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,15 @@ +1 +00:00:00,440 --> 00:00:06,614 +The fact that the call to double three returns nine instead of six is clearly + +2 +00:00:06,614 --> 00:00:13,000 +a failure because it is an observable incorrect behavior of the program. + +3 +00:00:13,000 --> 00:00:16,110 +So let me remind you that the failure is conceptually related to the + +4 +00:00:16,110 --> 00:00:20,076 +behavior of the program, to the way the program acts and not its code. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/6 - Failure, Fault, and Error Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/6 - Failure, Fault, and Error Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..f51ac9f --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/6 - Failure, Fault, and Error Quiz - lang_en_vs4.srt @@ -0,0 +1,19 @@ +1 +00:00:00,310 --> 00:00:02,690 +So now, let me ask you a second question. We just saw that we + +2 +00:00:02,690 --> 00:00:04,640 +can, reveal a failure in the program + +3 +00:00:04,640 --> 00:00:06,640 +by calling double with parameter three. Where + +4 +00:00:06,640 --> 00:00:09,750 +is the fault that causes such failure in the program? So I want you + +5 +00:00:09,750 --> 00:00:12,900 +to write the number of the line of code that, that contains the fault. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/7 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/7 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..bc55603 --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/7 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,31 @@ +1 +00:00:00,190 --> 00:00:02,404 +Before telling you what the right answer is, let + +2 +00:00:02,404 --> 00:00:04,240 +me remind you that the fault is related to + +3 +00:00:04,240 --> 00:00:06,508 +the code, and is a necessary, but not sufficient + +4 +00:00:06,508 --> 00:00:09,560 +condition for the occurrence of a failure. So in this + +5 +00:00:09,560 --> 00:00:12,450 +case, a single faulty line is responsible for the + +6 +00:00:12,450 --> 00:00:17,435 +failure, which is line three. So the correct answer, is + +7 +00:00:17,435 --> 00:00:20,700 +three. At line three, the program computes i times + +8 +00:00:20,700 --> 00:00:23,080 +i, instead of i times 2, as it should do. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/8 - Failure, Fault, and Error Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/8 - Failure, Fault, and Error Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..18515a6 --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/8 - Failure, Fault, and Error Quiz - lang_en_vs4.srt @@ -0,0 +1,15 @@ +1 +00:00:00,370 --> 00:00:02,090 +So, I want to ask you one last question about + +2 +00:00:02,090 --> 00:00:05,480 +this problem. What is the error that cause the fault + +3 +00:00:05,480 --> 00:00:08,180 +at line three? Remember that an error is the + +4 +00:00:08,180 --> 00:00:11,010 +cause of a fault and it's usually a human error. diff --git a/usth/ICT2.7/P4L1 General Concepts Subtitles/9 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L1 General Concepts Subtitles/9 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..56db4c1 --- /dev/null +++ b/usth/ICT2.7/P4L1 General Concepts Subtitles/9 - Failure, Fault, and Error Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,39 @@ +1 +00:00:00,350 --> 00:00:02,740 +And I apologize, but this was a tricky question that + +2 +00:00:02,740 --> 00:00:06,770 +we cannot really answer. We really have no way to + +3 +00:00:06,770 --> 00:00:08,860 +know what the error was. It could have been a + +4 +00:00:08,860 --> 00:00:13,240 +typo, an erroneous copy and paste operation, or even worse + +5 +00:00:13,240 --> 00:00:16,079 +a conceptual error. In case a developer did not know + +6 +00:00:16,079 --> 00:00:19,910 +what it means to double a number. Unfortunately though, the + +7 +00:00:19,910 --> 00:00:22,200 +developer is the only one who could actually answer this + +8 +00:00:22,200 --> 00:00:25,610 +question. So even though we cannot really answer this question, + +9 +00:00:25,610 --> 00:00:28,000 +having it help us think about how the + +10 +00:00:28,000 --> 00:00:31,000 +error is in fact related to human behavior. diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/1 - Lesson Overview - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/1 - Lesson Overview - lang_en_vs4.srt new file mode 100644 index 0000000..09a8f10 --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/1 - Lesson Overview - lang_en_vs4.srt @@ -0,0 +1,47 @@ +1 +00:00:00,320 --> 00:00:02,620 +In the previous lesson, we discussed the fundamental + +2 +00:00:02,620 --> 00:00:06,380 +concepts behind software verification in general, and software testing + +3 +00:00:06,380 --> 00:00:09,470 +in particular. In this lesson, we will discuss + +4 +00:00:09,470 --> 00:00:12,310 +one of the two main testing approaches. Black box + +5 +00:00:12,310 --> 00:00:16,180 +testing, also called functional testing. We will cover + +6 +00:00:16,180 --> 00:00:19,180 +the main characteristic of black box testing, its pros + +7 +00:00:19,180 --> 00:00:22,260 +and cons, and discuss some commonly used black + +8 +00:00:22,260 --> 00:00:25,350 +box testing techniques. We will conclude the lesson with + +9 +00:00:25,350 --> 00:00:28,520 +a practical exercise in which we will apply a specific black + +10 +00:00:28,520 --> 00:00:32,520 +box testing technique to a real program. We will derive test + +11 +00:00:32,520 --> 00:00:34,980 +cases for the program and assess how the use of a + +12 +00:00:34,980 --> 00:00:38,690 +systematic approach, in contrast to a brute force approach, can help. diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/10 - Test Data Selection Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/10 - Test Data Selection Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..418ed91 --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/10 - Test Data Selection Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,79 @@ +1 +00:00:00,025 --> 00:00:02,900 +Okay, so now we're going to answer the question. So if we want + +2 +00:00:02,900 --> 00:00:06,520 +to consider all these inputs, and run them all on the software, + +3 +00:00:06,520 --> 00:00:09,490 +let's see how it will work. Let's assume that these are, 32 + +4 +00:00:09,490 --> 00:00:12,280 +bit integers. So at this point what we will have is, a + +5 +00:00:12,280 --> 00:00:15,130 +number of combination, which is 2 to the 32, times 2 to + +6 +00:00:15,130 --> 00:00:18,390 +the 32. They're two integers. This is equal to 2 to the + +7 +00:00:18,390 --> 00:00:21,910 +64, which in turn, is more or less equal, to 10 to + +8 +00:00:21,910 --> 00:00:25,110 +the 19. So 10 to the 19 is the number of tests that + +9 +00:00:25,110 --> 00:00:27,960 +we need to run to cover the whole domain. Now let's assume + +10 +00:00:27,960 --> 00:00:31,400 +that we can run one test per nanosecond. So what that means + +11 +00:00:31,400 --> 00:00:34,290 +is that we can run 10 to the 9 tests per second, + +12 +00:00:34,290 --> 00:00:37,240 +and that's a lot. If we do the math, that results in 10 + +13 +00:00:37,240 --> 00:00:40,750 +to the 10 seconds over all, because we have 10 to the + +14 +00:00:40,750 --> 00:00:43,760 +19 tests, we could run 10 to the 9 tests per second + +15 +00:00:43,760 --> 00:00:46,630 +so, we do the math, and we can run all these tests + +16 +00:00:46,630 --> 00:00:50,340 +in 10 to the 10 seconds. And what that corresponds to, it's about + +17 +00:00:50,340 --> 00:00:54,470 +600 years, so a lot of time. So even for such + +18 +00:00:54,470 --> 00:00:57,710 +a simple problem, a problem that takes two integers and adds them, + +19 +00:00:57,710 --> 00:01:00,990 +it will take more than 500 years to test it exhaustively. So + +20 +00:01:00,990 --> 00:01:04,690 +the bottom line here is that we just can't do exhaustive testing. diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/11 - Why Not Random Testing? - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/11 - Why Not Random Testing? - lang_en_vs4.srt new file mode 100644 index 0000000..a91af45 --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/11 - Why Not Random Testing? - lang_en_vs4.srt @@ -0,0 +1,143 @@ +1 +00:00:00,310 --> 00:00:02,250 +So then maybe what we can do is just to + +2 +00:00:02,250 --> 00:00:05,720 +pick our test inputs randomly so to do what is called + +3 +00:00:05,720 --> 00:00:08,850 +random testing. And what that means is that we pick the + +4 +00:00:08,850 --> 00:00:11,720 +inputs to test just as we pick a number by rolling + +5 +00:00:11,720 --> 00:00:15,410 +a set of dice randomly. And this will have several advantages. + +6 +00:00:15,410 --> 00:00:18,780 +First, we will pick inputs uniformly. So if we use a + +7 +00:00:18,780 --> 00:00:21,790 +uniform distribution as the basis for our random testing, we will + +8 +00:00:21,790 --> 00:00:25,540 +make no preferences. In other words, all inputs will be considered + +9 +00:00:25,540 --> 00:00:28,324 +equal, of equal value. And what that means in turn, is + +10 +00:00:28,324 --> 00:00:32,640 +that random testing eliminates designer bias. So what does designer bias + +11 +00:00:32,640 --> 00:00:36,030 +mean? Designer bias is the problem of making the same assumption, + +12 +00:00:36,030 --> 00:00:38,570 +when we read the specification and we interpret it and when we + +13 +00:00:38,570 --> 00:00:42,100 +develop test cases. Which means that the developer might develop code, + +14 +00:00:42,100 --> 00:00:44,930 +assuming a given behavior of the user. And we may write + +15 +00:00:44,930 --> 00:00:47,520 +tests, making the same assumptions. And the problem, of course, is + +16 +00:00:47,520 --> 00:00:50,690 +even worse if it's the same person that develops the code and + +17 +00:00:50,690 --> 00:00:53,730 +writes the test cases. With random testing, the problem is gone, + +18 +00:00:53,730 --> 00:00:57,440 +because we just pick randomly what our inputs will be. So + +19 +00:00:57,440 --> 00:01:00,180 +why not do in random? The problem is that when testing, + +20 +00:01:00,180 --> 00:01:03,610 +we are looking for a needle in a haystack. Actually, multiple + +21 +00:01:03,610 --> 00:01:06,620 +needles in multiple haystacks, if we want to be precise. So, + +22 +00:01:06,620 --> 00:01:09,500 +random approaches are not necessarily the best way to go about + +23 +00:01:09,500 --> 00:01:12,430 +it, because we might just be looking in all the wrong + +24 +00:01:12,430 --> 00:01:15,760 +places. So let me show you this, using a different representation + +25 +00:01:15,760 --> 00:01:18,000 +for the haystack. What I'm showing here is a grid, and + +26 +00:01:18,000 --> 00:01:22,130 +imagine this grid just expanding indefinitely outside the screen, and this grid + +27 +00:01:22,130 --> 00:01:26,120 +represents the domain for the program, so each box in the grid, + +28 +00:01:26,120 --> 00:01:29,050 +each square in the grid, it's a possible input. So what happens + +29 +00:01:29,050 --> 00:01:32,670 +with bugs is that bugs are very scarce in this grid. Maybe + +30 +00:01:32,670 --> 00:01:35,070 +there is a bug here, so that means that there is a + +31 +00:01:35,070 --> 00:01:38,090 +bug, than an input, in this point we'll reveal. And maybe there + +32 +00:01:38,090 --> 00:01:40,820 +is another bug that will be triggered by an input over here. + +33 +00:01:40,820 --> 00:01:44,570 +So imagine this spread out over this infinite grid. Its very unlikely + +34 +00:01:44,570 --> 00:01:47,440 +that just by picking randomly that we will be able to get to + +35 +00:01:47,440 --> 00:01:50,910 +these two points. Fortunately not all is lost, there is a silver lining. + +36 +00:01:50,910 --> 00:01:53,410 +So we need to look a little more in depth into this grid. diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/12 - Partition Testing - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/12 - Partition Testing - lang_en_vs4.srt new file mode 100644 index 0000000..b91462c --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/12 - Partition Testing - lang_en_vs4.srt @@ -0,0 +1,67 @@ +1 +00:00:00,110 --> 00:00:02,570 +So let me use a slightly expanded version of this + +2 +00:00:02,570 --> 00:00:05,560 +grid. Although we're indeed looking at a needle in a haystack. + +3 +00:00:05,560 --> 00:00:09,560 +And failing inputs are generally sparse, very sparse, in the input + +4 +00:00:09,560 --> 00:00:12,890 +domain. However, they tend to be dense in some parts of + +5 +00:00:12,890 --> 00:00:15,860 +the domain. Like here or here. So how can we leverage + +6 +00:00:15,860 --> 00:00:18,920 +this? The fact that the failures are dense in some subdomains? + +7 +00:00:18,920 --> 00:00:22,290 +As it turns out, the domain is naturally split into partitions. + +8 +00:00:22,290 --> 00:00:25,340 +Where partitions are areas of the domain that are treated homogeneously + +9 +00:00:25,340 --> 00:00:28,070 +by the software. And this is what happens, that normally, + +10 +00:00:28,070 --> 00:00:31,020 +failures tend to be dense in this partitions. So the way + +11 +00:00:31,020 --> 00:00:34,000 +to leverage this characteristic of failures, is that we don't know + +12 +00:00:34,000 --> 00:00:36,950 +want to pick inputs randomly, in the input domain. Just here + +13 +00:00:36,950 --> 00:00:39,460 +and there. Rather we want to do two things. First we + +14 +00:00:39,460 --> 00:00:43,300 +want to identify partitions of our domain. And second we want + +15 +00:00:43,300 --> 00:00:46,950 +to select inputs from each partition. And by doing so, we + +16 +00:00:46,950 --> 00:00:50,300 +can dramatically increase our chances to reveal faults in the code. + +17 +00:00:50,300 --> 00:00:54,170 +So the name that is normally used for this process, is partition testing. diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/13 - Partition Testing Example - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/13 - Partition Testing Example - lang_en_vs4.srt new file mode 100644 index 0000000..6738346 --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/13 - Partition Testing Example - lang_en_vs4.srt @@ -0,0 +1,167 @@ +1 +00:00:00,120 --> 00:00:02,969 +So let's look at how this will work with an example. + +2 +00:00:02,969 --> 00:00:06,210 +I'm going to use this simple program that takes two inputs. The + +3 +00:00:06,210 --> 00:00:08,790 +first input is a string, str, and the second one is + +4 +00:00:08,790 --> 00:00:11,575 +an integer, size. And the problem is called split. And as + +5 +00:00:11,575 --> 00:00:14,363 +the name says what it does is to take this string, + +6 +00:00:14,363 --> 00:00:17,491 +str, and split it into sub string, into chunks of size + +7 +00:00:17,491 --> 00:00:21,550 +characters each. So how do we identify some possible partitions for + +8 +00:00:21,550 --> 00:00:25,620 +this program? If we consider the input size, we can identify + +9 +00:00:25,620 --> 00:00:29,630 +three neutral partitions which are size less than 0. For example, + +10 +00:00:29,630 --> 00:00:32,259 +we want to test how the program behaves. But if we pass an + +11 +00:00:32,259 --> 00:00:36,100 +incorrect size, size equal to 0, which is also a partition. In + +12 +00:00:36,100 --> 00:00:39,390 +this case, a partition with a single element. And the third case + +13 +00:00:39,390 --> 00:00:42,540 +is size greater than 0, which I will consider to be + +14 +00:00:42,540 --> 00:00:44,960 +kind of the standard case. And actually let me do a, you + +15 +00:00:44,960 --> 00:00:48,220 +know, slight aggression so when I was talking about designer bias. So + +16 +00:00:48,220 --> 00:00:50,630 +this is a case in which designer bias might not make you + +17 +00:00:50,630 --> 00:00:53,050 +think of using size less than 0 because you read the + +18 +00:00:53,050 --> 00:00:56,210 +spec. And you sort of assume that the size will be positive. + +19 +00:00:56,210 --> 00:00:58,556 +Whereas the right thing to do when we test is to consider + +20 +00:00:58,556 --> 00:01:01,700 +the complete domain rather than just parts of it. So now let's + +21 +00:01:01,700 --> 00:01:04,760 +look at string, str, and let's see what kind of sub + +22 +00:01:04,760 --> 00:01:06,538 +domains we could identify for this + +23 +00:01:06,538 --> 00:01:08,670 +parameter. And notice another important aspect + +24 +00:01:08,670 --> 00:01:12,290 +here is that we treat each different part of the input independently, + +25 +00:01:12,290 --> 00:01:15,760 +which also helps breaking down the problem. One interesting sub domain is + +26 +00:01:15,760 --> 00:01:18,980 +the domain that includes all the strings whose length is less than + +27 +00:01:18,980 --> 00:01:22,310 +size. So all the strings that will not be displayed. Another subdomain + +28 +00:01:22,310 --> 00:01:25,000 +is all the strings with length which is between the value of + +29 +00:01:25,000 --> 00:01:28,350 +size and twice the value of size. A third subdomain is the one + +30 +00:01:28,350 --> 00:01:31,820 +including all the strings whose length is greater than twice the value + +31 +00:01:31,820 --> 00:01:35,140 +of size. And we can continue and identify more and more subdomain. + +32 +00:01:35,140 --> 00:01:38,350 +The key thing here is that we have to do that based + +33 +00:01:38,350 --> 00:01:41,180 +on the domain. So we need to adapt what we just did here + +34 +00:01:41,180 --> 00:01:44,620 +based on, on the specific domain involved and on the type + +35 +00:01:44,620 --> 00:01:47,190 +of data in this domain. So at this point we said that + +36 +00:01:47,190 --> 00:01:49,630 +there were two steps. One was to identify the subdomains and + +37 +00:01:49,630 --> 00:01:52,990 +the second one was to pick values in this subdomain. The values + +38 +00:01:52,990 --> 00:01:55,320 +that we'll actually use for the testing. In this case, we + +39 +00:01:55,320 --> 00:01:58,218 +do not want to just pick any value. Rather we want to + +40 +00:01:58,218 --> 00:01:59,871 +pick values that are particularly + +41 +00:01:59,871 --> 00:02:02,710 +interesting, particularly representative. So what does + +42 +00:02:02,710 --> 00:02:05,800 +that mean? Well, we're going to do that based on an intuitive idea. diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/14 - Boundary Values - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/14 - Boundary Values - lang_en_vs4.srt new file mode 100644 index 0000000..3d54ad4 --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/14 - Boundary Values - lang_en_vs4.srt @@ -0,0 +1,55 @@ +1 +00:00:00,150 --> 00:00:02,590 +So let's go back again to our domain, with + +2 +00:00:02,590 --> 00:00:06,580 +all the sub-domains identified. And the basic idea, or the + +3 +00:00:06,580 --> 00:00:09,750 +intuitive idea I was talking about, is that errors tend + +4 +00:00:09,750 --> 00:00:12,425 +to occur at the boundary of a domain, or a + +5 +00:00:12,425 --> 00:00:15,510 +sub-domain. Like in this case. And why? Because these + +6 +00:00:15,510 --> 00:00:19,360 +are the cases that are less understood by the developers. + +7 +00:00:19,360 --> 00:00:22,155 +Like for example, the last iteration of a loop, or + +8 +00:00:22,155 --> 00:00:25,150 +a special value like zero for integers. So if this + +9 +00:00:25,150 --> 00:00:29,590 +is true, what we want to do is to select inputs at these + +10 +00:00:29,590 --> 00:00:32,189 +boundaries. And this is complementary to partition + +11 +00:00:32,189 --> 00:00:34,270 +testing, in the sense that partition testing + +12 +00:00:34,270 --> 00:00:38,160 +will identify the partitions in which we want to select inputs, and boundary + +13 +00:00:38,160 --> 00:00:40,570 +testing. So the selection of boundary values + +14 +00:00:40,570 --> 00:00:43,060 +will help select inputs in these partitions. diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/15 - Boundary Values Example - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/15 - Boundary Values Example - lang_en_vs4.srt new file mode 100644 index 0000000..b344802 --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/15 - Boundary Values Example - lang_en_vs4.srt @@ -0,0 +1,99 @@ +1 +00:00:00,200 --> 00:00:03,320 +So now let's go back to our split example. Let me + +2 +00:00:03,320 --> 00:00:05,790 +rearrange things a little bit to make more room. So now I'm + +3 +00:00:05,790 --> 00:00:09,160 +going to put the domains for size and for strength one next to + +4 +00:00:09,160 --> 00:00:12,210 +the other. So let's look at what some possible inputs will be + +5 +00:00:12,210 --> 00:00:15,140 +for the sub domains that we identified when we use the idea + +6 +00:00:15,140 --> 00:00:17,790 +of selecting input of the boundary. If we look at the first + +7 +00:00:17,790 --> 00:00:21,860 +subdomain, size less than zero, one reasonable input is, size equals to + +8 +00:00:21,860 --> 00:00:25,360 +minus 1, because minus 1 is the boundary value for the domain + +9 +00:00:25,360 --> 00:00:28,530 +of the integers less than zero. If we look at the third + +10 +00:00:28,530 --> 00:00:32,119 +subdomain, possibly interesting case is the one of size of equal to + +11 +00:00:32,119 --> 00:00:34,900 +1, for the same reasoning that we used for the previous subdomain, + +12 +00:00:34,900 --> 00:00:37,670 +for size less than zero. And, let's try to select another one + +13 +00:00:37,670 --> 00:00:40,870 +for this subdomain, for the integers greater than zero. If there is + +14 +00:00:40,870 --> 00:00:44,200 +a concept of maximal integer, we can select that one as our + +15 +00:00:44,200 --> 00:00:47,140 +boundary value. And of course we could select much more, but this + +16 +00:00:47,140 --> 00:00:50,630 +is just to give you an idea. Other possible inputs. One interesting + +17 +00:00:50,630 --> 00:00:53,310 +example for the first one, string with length less than + +18 +00:00:53,310 --> 00:00:57,690 +size will be a string with length size minus one. Again + +19 +00:00:57,690 --> 00:01:00,240 +this is the boundary value for this domain. And we could + +20 +00:01:00,240 --> 00:01:03,500 +continue in this way like for example selecting a string who's + +21 +00:01:03,500 --> 00:01:07,310 +length is exactly size as a boundary value for this + +22 +00:01:07,310 --> 00:01:10,490 +other domain. Instant one, and we look back actually to this + +23 +00:01:10,490 --> 00:01:12,940 +example and look at it in a more extensive way when + +24 +00:01:12,940 --> 00:01:15,690 +we actually talk about a specific method for doing this kind + +25 +00:01:15,690 --> 00:01:16,340 +of process. diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/16 - Deriving Test Case Specifications - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/16 - Deriving Test Case Specifications - lang_en_vs4.srt new file mode 100644 index 0000000..5164f1a --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/16 - Deriving Test Case Specifications - lang_en_vs4.srt @@ -0,0 +1,199 @@ +1 +00:00:00,140 --> 00:00:02,790 +Now, let's go back to our systematic functional testing + +2 +00:00:02,790 --> 00:00:05,540 +approach and all the steps in this process. So + +3 +00:00:05,540 --> 00:00:07,680 +far we've seen the first step and the second + +4 +00:00:07,680 --> 00:00:10,340 +step. Now we're going to look at this step in which, + +5 +00:00:10,340 --> 00:00:13,290 +once we have identified the values of interest, we + +6 +00:00:13,290 --> 00:00:18,110 +derive test case specifications for these values, or using these + +7 +00:00:18,110 --> 00:00:21,300 +values. And the test case specification defines how the + +8 +00:00:21,300 --> 00:00:25,230 +values should be put together when actually testing the system. + +9 +00:00:25,230 --> 00:00:29,110 +And test case specification describe how these values should be put + +10 +00:00:29,110 --> 00:00:32,360 +together when testing the system. So let me go back one more + +11 +00:00:32,360 --> 00:00:34,780 +time to our split program, so that we can use the + +12 +00:00:34,780 --> 00:00:37,450 +information that we already computed. At this point what we have is + +13 +00:00:37,450 --> 00:00:41,670 +some possible inputs for "string," our first parameter, and for "size," + +14 +00:00:41,670 --> 00:00:44,410 +our second parameter. And we want to put them together, to generate + +15 +00:00:44,410 --> 00:00:47,080 +the description of what the test case should be. So let + +16 +00:00:47,080 --> 00:00:50,420 +me once more rearrange this a little bit. I first remove the + +17 +00:00:50,420 --> 00:00:53,360 +description of the subdomains, because we won't use them in this step. + +18 +00:00:53,360 --> 00:00:55,800 +And I moved out the set of all our possible inputs, that we're + +19 +00:00:55,800 --> 00:00:59,470 +going to combine to create the test case specification. And one possible way + +20 +00:00:59,470 --> 00:01:03,320 +of doing that is simply to combine the values for the first parameter, + +21 +00:01:03,320 --> 00:01:06,370 +and the values for the second parameter. So the Cartesian product. So + +22 +00:01:06,370 --> 00:01:09,060 +if we do that, what we will obtain is, for example, if we + +23 +00:01:09,060 --> 00:01:12,470 +consider the first possible input, size is equal to minus 1, we can + +24 +00:01:12,470 --> 00:01:15,510 +combine it with these two possible inputs for string, and we will get + +25 +00:01:15,510 --> 00:01:18,680 +size is equal to minus 1 string with length minus 2, or + +26 +00:01:18,680 --> 00:01:21,680 +size is equal to minus 1 string with length minus 1. And we'll + +27 +00:01:21,680 --> 00:01:24,200 +go back in a second to see what this means. Now if we + +28 +00:01:24,200 --> 00:01:27,510 +consider the second possible value for size, size is equal to one, we + +29 +00:01:27,510 --> 00:01:30,260 +also have two cases so the first one in this case that will + +30 +00:01:30,260 --> 00:01:34,030 +be considered a string with length zero. So the antistring. And we can + +31 +00:01:34,030 --> 00:01:37,410 +continue combining this value, but one thing I want to point out is + +32 +00:01:37,410 --> 00:01:40,570 +that if we just go in this straight forward and brute force sort + +33 +00:01:40,570 --> 00:01:43,390 +of way, we will obtain many combinations that don't make any sense, + +34 +00:01:43,390 --> 00:01:46,500 +like for example, this combination which doesn't make any sense because we can + +35 +00:01:46,500 --> 00:01:50,410 +not create the string with length minus 2. Similar for this combination, because + +36 +00:01:50,410 --> 00:01:53,190 +then by the same token, we cannot raise things with length minus 1. + +37 +00:01:53,190 --> 00:01:55,730 +And so there's a lot of cases that we will have to eliminate + +38 +00:01:55,730 --> 00:01:59,380 +afterwards. So what we're going to see in a few minutes is a possible + +39 +00:01:59,380 --> 00:02:02,970 +way in which we can avoid producing these meaningless cases. And at the + +40 +00:02:02,970 --> 00:02:06,380 +same time, keep under control, the number of test cases that we generate. + +41 +00:02:06,380 --> 00:02:09,070 +So lets go back for the last time to our steps + +42 +00:02:09,070 --> 00:02:11,980 +for systematic functional testing. What we just did was to derive + +43 +00:02:11,980 --> 00:02:15,040 +test case specification from a set of relevant inputs. The following + +44 +00:02:15,040 --> 00:02:18,420 +step is to use these test case specifications to generate actual test + +45 +00:02:18,420 --> 00:02:21,170 +cases. And this is normally a fairly mechanical step in the + +46 +00:02:21,170 --> 00:02:23,900 +sense that we just have to instantiate what is in the test + +47 +00:02:23,900 --> 00:02:27,970 +case specification as actual test cases. And it's really dependent on + +48 +00:02:27,970 --> 00:02:32,300 +the specific type of partitions and values identified on the specific context. + +49 +00:02:32,300 --> 00:02:35,100 +So instead of looking at that here in the, in the abstract, + +50 +00:02:35,100 --> 00:02:37,480 +I'm going to show you with an example later on, in the lesson. diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/17 - Category Partition Method - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/17 - Category Partition Method - lang_en_vs4.srt new file mode 100644 index 0000000..938e80c --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/17 - Category Partition Method - lang_en_vs4.srt @@ -0,0 +1,99 @@ +1 +00:00:00,200 --> 00:00:03,690 +What we will discuss next is a specific black-box testing + +2 +00:00:03,690 --> 00:00:07,240 +approach. So a specific instance of the general approach that + +3 +00:00:07,240 --> 00:00:10,814 +we just saw. And this approach is the category-partition method, + +4 +00:00:10,814 --> 00:00:13,418 +and was defined by Ostrand & Balcer in 1988 in + +5 +00:00:13,418 --> 00:00:16,760 +an article to the peer [UNKNOWN] communication of the ACM. + +6 +00:00:16,760 --> 00:00:19,490 +So this is a method for going from a specification, + +7 +00:00:19,490 --> 00:00:21,370 +a description of the system, to a set of test + +8 +00:00:21,370 --> 00:00:26,170 +cases like any other black-box testing approach by following six steps. + +9 +00:00:26,170 --> 00:00:28,370 +So let's look at what these steps are. The first + +10 +00:00:28,370 --> 00:00:31,850 +step is to identify independently testable features and this is + +11 +00:00:31,850 --> 00:00:33,870 +a step that we are familiar with because its exactly + +12 +00:00:33,870 --> 00:00:36,950 +the same step that we performed in the generic black box + +13 +00:00:36,950 --> 00:00:39,480 +testing approach that we just discussed. The second step is + +14 +00:00:39,480 --> 00:00:42,250 +to identify categories. Then the next step is to partition + +15 +00:00:42,250 --> 00:00:45,070 +categories into choices. Identify constraints + +16 +00:00:45,070 --> 00:00:47,530 +among choices. Produce and evaluate + +17 +00:00:47,530 --> 00:00:51,330 +test case specifications. And finally, the sixth step is to generate + +18 +00:00:51,330 --> 00:00:54,100 +test cases from test case specifications. So two of + +19 +00:00:54,100 --> 00:00:56,970 +the key elements in these six steps are the two + +20 +00:00:56,970 --> 00:00:59,430 +that give the name to the technique so the identification + +21 +00:00:59,430 --> 00:01:02,240 +of the categories and the partition of these categories into + +22 +00:01:02,240 --> 00:01:04,810 +choices. What we're going to do next is to go + +23 +00:01:04,810 --> 00:01:07,670 +and look at each one of the steps independently, except + +24 +00:01:07,670 --> 00:01:10,285 +for the first one. Because we're already familiar with that + +25 +00:01:10,285 --> 00:01:12,650 +step, and this method doesn't really add much to it. diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/18 - Identify Categories - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/18 - Identify Categories - lang_en_vs4.srt new file mode 100644 index 0000000..a1eb4dd --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/18 - Identify Categories - lang_en_vs4.srt @@ -0,0 +1,127 @@ +1 +00:00:00,140 --> 00:00:02,980 +In the second step of the category partition technique, the goal is + +2 +00:00:02,980 --> 00:00:05,630 +to Identify Categories. Where categories are + +3 +00:00:05,630 --> 00:00:08,650 +characteristics of each input element. So + +4 +00:00:08,650 --> 00:00:11,490 +let me illustrate what that means using an example. And to do + +5 +00:00:11,490 --> 00:00:14,440 +that I'm going to use again the example of the split program, as + +6 +00:00:14,440 --> 00:00:16,830 +we are already familiar with it and we kind of already played + +7 +00:00:16,830 --> 00:00:20,110 +with it. When we were talking about the generic black box approach. + +8 +00:00:20,110 --> 00:00:22,293 +So let me bring back the program, and let me remind you + +9 +00:00:22,293 --> 00:00:25,440 +that what the program does is to take two inputs, a string and + +10 +00:00:25,440 --> 00:00:28,560 +the size, and it breaks down the string into chunks, + +11 +00:00:28,560 --> 00:00:31,300 +whose length is size. If we look at the split program + +12 +00:00:31,300 --> 00:00:34,330 +there are two input elements, str and size so we going to + +13 +00:00:34,330 --> 00:00:37,930 +identify categories for these two. So starting from str, what are + +14 +00:00:37,930 --> 00:00:41,228 +the interesting characteristics of the string? In, in this step + +15 +00:00:41,228 --> 00:00:44,948 +you're going to use your domain knowledge, your understanding of what a + +16 +00:00:44,948 --> 00:00:47,986 +string is, and for example we might identify the length of + +17 +00:00:47,986 --> 00:00:50,528 +the string and the content of the string as the two + +18 +00:00:50,528 --> 00:00:53,840 +main characteristics that we want to focus on. If we now + +19 +00:00:53,840 --> 00:00:57,540 +move our focus to size, the only characteristic I can really + +20 +00:00:57,540 --> 00:01:00,340 +think of for an integer is its value. So that's what + +21 +00:01:00,340 --> 00:01:02,470 +I'm going to mark here. So at the end of the step + +22 +00:01:02,470 --> 00:01:05,030 +what we have is that we have two categories. So two + +23 +00:01:05,030 --> 00:01:08,930 +interesting characteristics for the string input str, which are the length + +24 +00:01:08,930 --> 00:01:12,940 +and the content. And one category for the integer input size + +25 +00:01:12,940 --> 00:01:16,480 +which is its value. And notice that there's not only one solution. + +26 +00:01:16,480 --> 00:01:18,200 +So there's not only one possibility. + +27 +00:01:18,200 --> 00:01:20,384 +So that the specific characteristics that you + +28 +00:01:20,384 --> 00:01:22,800 +will identify are somehow subjective. But the + +29 +00:01:22,800 --> 00:01:25,630 +important point is that you identify characteristics + +30 +00:01:25,630 --> 00:01:29,259 +that are meaningful and they sort of cover the main aspects of the + +31 +00:01:29,259 --> 00:01:31,200 +inputs, which is the case for the + +32 +00:01:31,200 --> 00:01:33,440 +categories that we've identified in this example. diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/19 - Partition Categories into Choices - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/19 - Partition Categories into Choices - lang_en_vs4.srt new file mode 100644 index 0000000..a411c30 --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/19 - Partition Categories into Choices - lang_en_vs4.srt @@ -0,0 +1,151 @@ +1 +00:00:00,230 --> 00:00:03,250 +Now we move to the next step, which involves partitioning the + +2 +00:00:03,250 --> 00:00:07,680 +categories that we just identified into choices. And these choices are the + +3 +00:00:07,680 --> 00:00:11,930 +interesting cases for each category. So the interesting subdomains for each one + +4 +00:00:11,930 --> 00:00:14,810 +of these categories. So once more, lets look at that using our + +5 +00:00:14,810 --> 00:00:18,110 +example, the split program. So lets start by considering length. What are + +6 +00:00:18,110 --> 00:00:20,710 +the interesting cases when we think about the length of a string? + +7 +00:00:20,710 --> 00:00:23,220 +Some of those we already saw, one interesting case is the case + +8 +00:00:23,220 --> 00:00:26,190 +of the length of size zero, so a string with no characters. + +9 +00:00:26,190 --> 00:00:29,030 +Another interesting case is the one in which the length of the + +10 +00:00:29,030 --> 00:00:31,780 +string is size minus one, so the string is just one character + +11 +00:00:31,780 --> 00:00:34,610 +short of the size at which it will be cut by the + +12 +00:00:34,610 --> 00:00:38,160 +split program. And we can continue along these lines, so we will select + +13 +00:00:38,160 --> 00:00:42,950 +size, size plus one, size twice the value of size minus one, + +14 +00:00:42,950 --> 00:00:45,560 +and so on and so forth. But even without listing all of + +15 +00:00:45,560 --> 00:00:47,500 +those, I'm sure you get the idea of what it means to + +16 +00:00:47,500 --> 00:00:49,780 +identify this interesting cases. Let's see + +17 +00:00:49,780 --> 00:00:51,702 +the movements that are considering the content. + +18 +00:00:51,702 --> 00:00:53,990 +So without the interesting cases when we think about the content + +19 +00:00:53,990 --> 00:00:56,520 +of the string. So possible interesting case is the string that + +20 +00:00:56,520 --> 00:01:00,660 +contains only spaces. Why? Well maybe because a split is written + +21 +00:01:00,660 --> 00:01:04,290 +spaces in a special way. Similarly a string that contains special + +22 +00:01:04,290 --> 00:01:06,780 +characters, like non printable characters, + +23 +00:01:06,780 --> 00:01:09,020 +like tabulation characters, new line might + +24 +00:01:09,020 --> 00:01:12,240 +also be an interesting case, something that we want to test. Also + +25 +00:01:12,240 --> 00:01:14,280 +in this case we could continue and go on and on. + +26 +00:01:14,280 --> 00:01:17,250 +So basically here you just want to put all the interesting cases + +27 +00:01:17,250 --> 00:01:20,010 +that you can think of when you consider the content + +28 +00:01:20,010 --> 00:01:22,440 +of a string. Now let's move to the value as the + +29 +00:01:22,440 --> 00:01:25,740 +next category. So the value of the input size. And + +30 +00:01:25,740 --> 00:01:29,280 +here we might want to consider a size zero, special case, a + +31 +00:01:29,280 --> 00:01:33,640 +normal situation, like size greater than zero, another special case, + +32 +00:01:33,640 --> 00:01:36,420 +size less than zero or maxint. And these are, if you + +33 +00:01:36,420 --> 00:01:39,420 +remember, I accepted the cases that we consider when we look + +34 +00:01:39,420 --> 00:01:42,350 +at this example, before. And also here we can continue and + +35 +00:01:42,350 --> 00:01:43,970 +go on and on. So, at the end of the + +36 +00:01:43,970 --> 00:01:46,860 +step, what we have is a set of interesting cases + +37 +00:01:46,860 --> 00:01:49,220 +for each one of the categories, and now we can + +38 +00:01:49,220 --> 00:01:51,150 +start to think about how we want to combine them. diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/2 - Overview - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/2 - Overview - lang_en_vs4.srt new file mode 100644 index 0000000..2af56c5 --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/2 - Overview - lang_en_vs4.srt @@ -0,0 +1,103 @@ +1 +00:00:00,450 --> 00:00:03,400 +As we said at the end of the previous lesson, black-box testing is + +2 +00:00:03,400 --> 00:00:06,230 +the testing of the software when we look at it as a black box, + +3 +00:00:06,230 --> 00:00:09,110 +as a closed box, without looking at it inside, without looking at the + +4 +00:00:09,110 --> 00:00:10,750 +code. And there are several advantages in + +5 +00:00:10,750 --> 00:00:12,680 +using black-box testing. So let me recap + +6 +00:00:12,680 --> 00:00:15,590 +those advantages, some of which we already mentioned, and let me also expand + +7 +00:00:15,590 --> 00:00:18,220 +on that a little bit. The first advantage of when I mentioned is that + +8 +00:00:18,220 --> 00:00:22,760 +black box focuses on the domain, on the input domain of the software. And + +9 +00:00:22,760 --> 00:00:25,750 +as such, we can use it to make sure that we are actually covering + +10 +00:00:25,750 --> 00:00:28,400 +this domain, that we are actually covering the important behaviors of + +11 +00:00:28,400 --> 00:00:32,200 +the software. A second advantage is that black box testing does not + +12 +00:00:32,200 --> 00:00:35,402 +need the code. What that means is that you can perform early + +13 +00:00:35,402 --> 00:00:38,801 +test design. So you can start designing and writing your test cases, + +14 +00:00:38,801 --> 00:00:41,423 +even before writing your code, so that when the code is + +15 +00:00:41,423 --> 00:00:44,520 +ready, we can test it right away. And that helps prevent a + +16 +00:00:44,520 --> 00:00:48,054 +problem that is very typical in real life software development, which is + +17 +00:00:48,054 --> 00:00:50,790 +getting an idea of the project and having no time to create + +18 +00:00:50,790 --> 00:00:53,040 +the tests. In this way, we already have the tests, so + +19 +00:00:53,040 --> 00:00:56,170 +we just have to run them. Another advantage is that black-box testing + +20 +00:00:56,170 --> 00:00:59,530 +can catch logic defects, because it focuses on the description of what + +21 +00:00:59,530 --> 00:01:02,440 +the software should do, and therefore on its logic. If we derive + +22 +00:01:02,440 --> 00:01:05,250 +test cases from such description, then we can catch these kind of + +23 +00:01:05,250 --> 00:01:07,510 +problems. And finally, black-box testing is + +24 +00:01:07,510 --> 00:01:09,900 +applicable at all granularity levels, which + +25 +00:01:09,900 --> 00:01:13,490 +means that we can use black-box testing in unit testing, integration testing, + +26 +00:01:13,490 --> 00:01:16,290 +system testing, and so on. We can use it at all levels. diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/20 - Identify Constraints Among Choices - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/20 - Identify Constraints Among Choices - lang_en_vs4.srt new file mode 100644 index 0000000..0278cc8 --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/20 - Identify Constraints Among Choices - lang_en_vs4.srt @@ -0,0 +1,239 @@ +1 +00:00:00,160 --> 00:00:02,080 +Something that we saw when we were looking at the split + +2 +00:00:02,080 --> 00:00:05,760 +program before is that if we just combine the interesting values that + +3 +00:00:05,760 --> 00:00:08,490 +we identify, we might end up with a lot of cases. + +4 +00:00:08,490 --> 00:00:11,030 +And I mentioned that we, we're going to look at some way of + +5 +00:00:11,030 --> 00:00:13,720 +addressing that problem. And this is exactly what happens in the + +6 +00:00:13,720 --> 00:00:17,420 +next step of the category partition method, in which we identify constraints + +7 +00:00:17,420 --> 00:00:20,510 +among choices. And why do we identify these constraints? We do + +8 +00:00:20,510 --> 00:00:23,440 +that to eliminate meaningless combinations of + +9 +00:00:23,440 --> 00:00:25,460 +inputs. If you remember, for example, + +10 +00:00:25,460 --> 00:00:27,260 +we had the case in which we were trying to + +11 +00:00:27,260 --> 00:00:30,110 +create a string with a size less than 0, which + +12 +00:00:30,110 --> 00:00:32,930 +doesn't make any sense. And very importantly, we also do + +13 +00:00:32,930 --> 00:00:37,070 +that to reduce the number of test cases. Because every time + +14 +00:00:37,070 --> 00:00:40,930 +we constrain one of the possible choices, we eliminate possible + +15 +00:00:40,930 --> 00:00:43,250 +test cases, so we can use it to keep under + +16 +00:00:43,250 --> 00:00:45,960 +control the number of tests that we generate. There are + +17 +00:00:45,960 --> 00:00:47,571 +three types of properties. The + +18 +00:00:47,571 --> 00:00:50,610 +pair property...if, error properties, and properties + +19 +00:00:50,610 --> 00:00:52,610 +of type single. So we're going to look at what these + +20 +00:00:52,610 --> 00:00:56,230 +properties mean, using, once more, our example of the split program. + +21 +00:00:56,230 --> 00:00:58,750 +In particular, we're going to use some of the choices that we + +22 +00:00:58,750 --> 00:01:02,080 +identified earlier. So let's look, for example, at choice 0, for + +23 +00:01:02,080 --> 00:01:04,599 +category length of the string. All we can say is that, + +24 +00:01:04,599 --> 00:01:07,860 +if the length is 0, this define a special property of + +25 +00:01:07,860 --> 00:01:11,160 +the string. And that was specified in this way by saying + +26 +00:01:11,160 --> 00:01:15,610 +that this identifies property zerovalue. So every time that we use + +27 +00:01:15,610 --> 00:01:19,080 +this choice, zerovalue is defined. At this point, we can use + +28 +00:01:19,080 --> 00:01:20,550 +this to exclude some meaningless + +29 +00:01:20,550 --> 00:01:23,170 +combinations. For instance, consider special characters. + +30 +00:01:23,170 --> 00:01:25,130 +If we have a string of length 0, which means a + +31 +00:01:25,130 --> 00:01:26,850 +string with no characters. Obviously, there + +32 +00:01:26,850 --> 00:01:28,760 +cannot be special characters. So, considering + +33 +00:01:28,760 --> 00:01:31,020 +this combination will just be a waste of time. So what + +34 +00:01:31,020 --> 00:01:33,770 +we do is that we specify next to this choice, that we + +35 +00:01:33,770 --> 00:01:36,360 +will only consider this if length is not 0. And we + +36 +00:01:36,360 --> 00:01:41,110 +do this by saying that we consider this only if not zerovalue. + +37 +00:01:41,110 --> 00:01:43,970 +So, if zerovalue is not defined. So this pair is an + +38 +00:01:43,970 --> 00:01:47,640 +example of a property...if case. Define a property and use that + +39 +00:01:47,640 --> 00:01:49,770 +property. Now let's look at a case in which we might + +40 +00:01:49,770 --> 00:01:52,580 +want to use an error property. For instance, when we look at + +41 +00:01:52,580 --> 00:01:56,480 +the category value for the input size, the choice value less + +42 +00:01:56,480 --> 00:01:59,510 +than 0 is an erroneous choice. So it's a choice that + +43 +00:01:59,510 --> 00:02:02,630 +we selected to test a possibly erroneous situation, so we can + +44 +00:02:02,630 --> 00:02:06,160 +mark this as an error property. And what that means is that + +45 +00:02:06,160 --> 00:02:09,949 +when generating a combination of choices, we will consider this only + +46 +00:02:09,949 --> 00:02:12,990 +once because we assume that we just want to test this error condition + +47 +00:02:12,990 --> 00:02:16,260 +once. Finally, the single property is a property that we use + +48 +00:02:16,260 --> 00:02:19,050 +when we want to limit the number of test cases. And it's + +49 +00:02:19,050 --> 00:02:21,900 +similar as an effect to error. It just has a different + +50 +00:02:21,900 --> 00:02:24,410 +meaning. So what we do when we use the single property is + +51 +00:02:24,410 --> 00:02:27,420 +that we're saying that this choice, we want to use in only + +52 +00:02:27,420 --> 00:02:31,120 +one combination. So don't combine it multiple times. And that, of course, + +53 +00:02:31,120 --> 00:02:34,260 +given the combinatorial nature of the problem, cuts down dramatically + +54 +00:02:34,260 --> 00:02:36,370 +the number of test cases. And we might use, for + +55 +00:02:36,370 --> 00:02:39,500 +instance, the single property for maxint, which means that we + +56 +00:02:39,500 --> 00:02:41,890 +will only have one test case in which the size is + +57 +00:02:41,890 --> 00:02:44,300 +equal to maxint. We're actually going to see a demo + +58 +00:02:44,300 --> 00:02:46,880 +on this topic so we'll have more chances of seeing how + +59 +00:02:46,880 --> 00:02:49,370 +properties work in practice and how good they are at + +60 +00:02:49,370 --> 00:02:53,022 +eliminating meaningless combinations and at reducing the number of test cases. diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/21 - Produce and Evaluate Test Case Specifications - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/21 - Produce and Evaluate Test Case Specifications - lang_en_vs4.srt new file mode 100644 index 0000000..ebf8098 --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/21 - Produce and Evaluate Test Case Specifications - lang_en_vs4.srt @@ -0,0 +1,111 @@ +1 +00:00:00,130 --> 00:00:03,200 +Before getting to our demo, we still have two steps to consider. + +2 +00:00:03,200 --> 00:00:06,570 +The first step corresponds to the identification of the test case specifications + +3 +00:00:06,570 --> 00:00:09,890 +in our general systematic approach. And in fact, it's called produce and + +4 +00:00:09,890 --> 00:00:13,410 +evaluate test case specifications. This is a step than can be completely + +5 +00:00:13,410 --> 00:00:16,590 +automated given the results of the previous steps. And the final result + +6 +00:00:16,590 --> 00:00:19,860 +of this step is the production of a set of test frames. + +7 +00:00:19,860 --> 00:00:22,820 +Where a test frame is the specification of a test. Let me + +8 +00:00:22,820 --> 00:00:25,330 +show you an example of this. What we are looking at here + +9 +00:00:25,330 --> 00:00:28,380 +is a test frame for the program split. Test frames are normally + +10 +00:00:28,380 --> 00:00:31,460 +identified by a sequence number. But in this case we are looking at + +11 +00:00:31,460 --> 00:00:34,290 +the 30th six test frame. And what they do is simply to + +12 +00:00:34,290 --> 00:00:38,280 +specify the characteristic of the inputs for that test. In this case, since + +13 +00:00:38,280 --> 00:00:40,920 +we have two inputs, we have two entries, the first one for + +14 +00:00:40,920 --> 00:00:44,010 +string str tells us that the length of the string has to be + +15 +00:00:44,010 --> 00:00:47,840 +size minus 1, and that the string has to contain special characters. And + +16 +00:00:47,840 --> 00:00:50,380 +for size, it tells us that the value of size has to be + +17 +00:00:50,380 --> 00:00:53,340 +greater than zero. As the title says, this step is meant + +18 +00:00:53,340 --> 00:00:56,790 +to produce but also evaluate the case specification. What does it mean + +19 +00:00:56,790 --> 00:01:00,070 +to evaluate? One of the advantages of this approach is that we + +20 +00:01:00,070 --> 00:01:03,420 +can easily use it to assess how many test frames and therefore + +21 +00:01:03,420 --> 00:01:06,120 +how many test cases we will generate with the current least + +22 +00:01:06,120 --> 00:01:09,340 +of categories, choices and constraints. And the beauty of this is that + +23 +00:01:09,340 --> 00:01:12,320 +if the number is too large we can just add additional constraints + +24 +00:01:12,320 --> 00:01:15,840 +and reduce it. And given then the step is automated we just + +25 +00:01:15,840 --> 00:01:19,030 +add constraints push a button and we get our new set of + +26 +00:01:19,030 --> 00:01:21,580 +test frames. And again we can have a wait it either go + +27 +00:01:21,580 --> 00:01:24,560 +hat or add more constraints if we need to further reduce it + +28 +00:01:24,560 --> 00:01:26,320 +and this is something else that we will see in our demo. diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/22 - Generate Test Cases from Test Case Specifications - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/22 - Generate Test Cases from Test Case Specifications - lang_en_vs4.srt new file mode 100644 index 0000000..7d74ae3 --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/22 - Generate Test Cases from Test Case Specifications - lang_en_vs4.srt @@ -0,0 +1,91 @@ +1 +00:00:00,135 --> 00:00:01,935 +So we get to the last step of the technique in + +2 +00:00:01,935 --> 00:00:05,142 +which once we have generated test case specifications. We create test + +3 +00:00:05,142 --> 00:00:09,180 +cases starting from this specifications. This step mainly consists in a + +4 +00:00:09,180 --> 00:00:12,840 +simple instantiation of frames and it's final result is a set of + +5 +00:00:12,840 --> 00:00:16,840 +concrete tests. For our example, test frame number 36 that we + +6 +00:00:16,840 --> 00:00:19,270 +just saw, this will be the resulting test case, which has + +7 +00:00:19,270 --> 00:00:21,490 +the same ID, so that we can track it and will + +8 +00:00:21,490 --> 00:00:25,520 +specify to concrete values, not just the specification for the input elements. + +9 +00:00:25,520 --> 00:00:29,130 +So string STR will have this value. And the integer size + +10 +00:00:29,130 --> 00:00:31,720 +will have this value. And these two values satisfy what this + +11 +00:00:31,720 --> 00:00:35,260 +test case specification was. Which was, having a string contain special + +12 +00:00:35,260 --> 00:00:38,760 +characters. Here, we have two special characters, like the new line + +13 +00:00:38,760 --> 00:00:41,900 +and the tab. And, we have a size which is greater + +14 +00:00:41,900 --> 00:00:44,430 +than zero, in particular, okay? And this is a test case + +15 +00:00:44,430 --> 00:00:46,880 +that we can actually run on our code. That we can + +16 +00:00:46,880 --> 00:00:50,730 +run on the split program. So, to summarize, we perform six steps + +17 +00:00:50,730 --> 00:00:54,400 +in which we went from a high level description of what the program does, to a + +18 +00:00:54,400 --> 00:00:56,070 +set of concrete test cases. And this is + +19 +00:00:56,070 --> 00:00:57,880 +one of those test cases. So what, what we're + +20 +00:00:57,880 --> 00:01:00,210 +going to do next, we're going to do a mini-demo, + +21 +00:01:00,210 --> 00:01:02,260 +in which we do this for real. We take + +22 +00:01:02,260 --> 00:01:05,440 +the program, we identify categories, choices, constraints, and + +23 +00:01:05,440 --> 00:01:07,800 +we actually generate test frames and then test cases. diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/23 - Category Partition Demo - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/23 - Category Partition Demo - lang_en_vs4.srt new file mode 100644 index 0000000..51c2e52 --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/23 - Category Partition Demo - lang_en_vs4.srt @@ -0,0 +1,867 @@ +1 +00:00:01,290 --> 00:00:03,210 +In this demo, we're going to do exactly what we + +2 +00:00:03,210 --> 00:00:06,370 +did just now in the lesson. We're going to use + +3 +00:00:06,370 --> 00:00:09,250 +the category partition method to go from a high-level + +4 +00:00:09,250 --> 00:00:12,930 +description of a piece of software of a program to + +5 +00:00:12,930 --> 00:00:15,512 +a set of test cases for that program. To + +6 +00:00:15,512 --> 00:00:17,640 +do that, we're going to use a simple tool. So + +7 +00:00:17,640 --> 00:00:21,040 +I'm going to show you here the tool that is + +8 +00:00:21,040 --> 00:00:26,380 +called a tsl generator right here. This tool is available + +9 +00:00:26,380 --> 00:00:28,520 +to you, so you can look in the class notes to + +10 +00:00:28,520 --> 00:00:31,900 +see information on how to download it. And together with the tool, + +11 +00:00:31,900 --> 00:00:34,890 +we are also going to provide a manual for the tool, and + +12 +00:00:34,890 --> 00:00:37,680 +a set of files that I'm going to use in this demo. So + +13 +00:00:37,680 --> 00:00:40,420 +you should be able to do exactly what I'm doing. So + +14 +00:00:40,420 --> 00:00:45,110 +again, all of those are available from the class notes. So specifically, + +15 +00:00:45,110 --> 00:00:48,390 +today we're going to write test cases for the grep program. So in + +16 +00:00:48,390 --> 00:00:51,970 +case you're familiar with the grep utility, this is a simplified version + +17 +00:00:51,970 --> 00:00:55,060 +of that utility. So basically the grep utility allows you + +18 +00:00:55,060 --> 00:00:58,410 +to search a file for the occurrences of a given + +19 +00:00:58,410 --> 00:01:01,552 +pattern. So you can invoke it, as it's shown here + +20 +00:01:01,552 --> 00:01:05,570 +in the synopsis, by executing grep, the pattern that you're + +21 +00:01:05,570 --> 00:01:08,310 +looking for, and the filename in which you want to + +22 +00:01:08,310 --> 00:01:10,300 +look for the pattern. And let me read the description + +23 +00:01:10,300 --> 00:01:13,650 +of the grep utility. The grep utility searches files for + +24 +00:01:13,650 --> 00:01:17,110 +a pattern and brings all lines that contain that pattern + +25 +00:01:17,110 --> 00:01:20,900 +on the standard output. A line that contains multiple occurrences of + +26 +00:01:20,900 --> 00:01:24,350 +the pattern is printed only once. The pattern is any sequence + +27 +00:01:24,350 --> 00:01:27,700 +of characters. To include a blank in the pattern, the entire + +28 +00:01:27,700 --> 00:01:31,060 +pattern must be enclosed in single quotes. To include a quote + +29 +00:01:31,060 --> 00:01:34,420 +sign in the pattern, the quote sign must be escaped, which + +30 +00:01:34,420 --> 00:01:36,260 +means that we have to put a slash in front of + +31 +00:01:36,260 --> 00:01:39,290 +the quotes sign. And in general, it is safest to enclose + +32 +00:01:39,290 --> 00:01:42,210 +the entire pattern in single quotes. So this is our high + +33 +00:01:42,210 --> 00:01:45,420 +level description for the program, for the softer system, that + +34 +00:01:45,420 --> 00:01:47,270 +we need to test. So now let me show you + +35 +00:01:47,270 --> 00:01:50,600 +what a possible set of categories and partitions could be + +36 +00:01:50,600 --> 00:01:53,770 +for this program. So what I have here is a + +37 +00:01:53,770 --> 00:01:58,080 +file, a textual file, which contains all the categories and + +38 +00:01:58,080 --> 00:02:02,760 +partitions for the elements that are relevant for my program. + +39 +00:02:02,760 --> 00:02:05,240 +In particular, when we look at the file, we can + +40 +00:02:05,240 --> 00:02:07,809 +see that the file can be characterized by its size. + +41 +00:02:08,889 --> 00:02:12,160 +And in this case, I've got two choices. The file can + +42 +00:02:12,160 --> 00:02:16,050 +be empty or not empty. The second characteristic of the file + +43 +00:02:16,050 --> 00:02:19,490 +that I'm considering is the number of occurrences of the pattern + +44 +00:02:19,490 --> 00:02:22,320 +in the file. And I'm considering that the pattern might not occur + +45 +00:02:22,320 --> 00:02:25,780 +in the file or it might occur once, or multiple times. + +46 +00:02:25,780 --> 00:02:28,264 +I'm not going to go through the rest of the file because we + +47 +00:02:28,264 --> 00:02:31,234 +already covered how to apply the category partition method in the + +48 +00:02:31,234 --> 00:02:34,226 +lesson. So if you had doubts about that, about the method and + +49 +00:02:34,226 --> 00:02:36,952 +how to apply, you might want to go back and watch again the + +50 +00:02:36,952 --> 00:02:40,040 +lesson. What I want to show you here is how you can go + +51 +00:02:40,040 --> 00:02:43,670 +from this information that you have here, that we have derived by + +52 +00:02:43,670 --> 00:02:47,020 +applying the, the first steps of the method, to a set of + +53 +00:02:47,020 --> 00:02:50,650 +test frames, and then, a set of test packs. So to do + +54 +00:02:50,650 --> 00:02:53,240 +that we're going to use the tool that I just mentioned. So let + +55 +00:02:53,240 --> 00:02:56,670 +me bring back my terminal. So first of all, let's see how + +56 +00:02:56,670 --> 00:02:59,570 +we can run the tool. So you have a manual that will explain + +57 +00:02:59,570 --> 00:03:02,180 +all the details on how to build the file that we're + +58 +00:03:02,180 --> 00:03:04,350 +going to feed the tool. So what is the format and so + +59 +00:03:04,350 --> 00:03:07,780 +on. Here I'm just going to see how I can run the + +60 +00:03:07,780 --> 00:03:10,828 +tool. So first of all, let me point out that this was + +61 +00:03:10,828 --> 00:03:15,028 +developed together by professors from the University of California Irvine and + +62 +00:03:15,028 --> 00:03:18,020 +Oregon State University. And as you can see, we can run + +63 +00:03:18,020 --> 00:03:20,968 +TSL generator and specify that we want to see the main + +64 +00:03:20,968 --> 00:03:24,361 +page. So in this case if we run it this, this way, + +65 +00:03:24,361 --> 00:03:27,723 +you'll have some basic information on how to run + +66 +00:03:27,723 --> 00:03:30,720 +the tool. And from the main page you can see + +67 +00:03:30,720 --> 00:03:33,520 +that you can specify the minus c flag and in + +68 +00:03:33,520 --> 00:03:37,360 +this case the TSL generator will report the number of + +69 +00:03:37,360 --> 00:03:41,410 +test frames generated without writing them to output. For + +70 +00:03:41,410 --> 00:03:43,828 +example, you might want to use this as we will do + +71 +00:03:43,828 --> 00:03:46,308 +to see how many tests that you will generate with + +72 +00:03:46,308 --> 00:03:49,630 +a current set of category partitions and choices. The minus + +73 +00:03:49,630 --> 00:03:52,620 +s option will bring the result of the TSL + +74 +00:03:52,620 --> 00:03:55,620 +generator on the standard output. And finally, you can + +75 +00:03:55,620 --> 00:03:58,330 +use minus o to specify an output file, where + +76 +00:03:58,330 --> 00:04:01,010 +to put the output of the program. So let's + +77 +00:04:01,010 --> 00:04:05,070 +at first run our TSL generator by specifying the + +78 +00:04:05,070 --> 00:04:08,620 +minus c option and by bypassing our current set + +79 +00:04:08,620 --> 00:04:11,860 +of category partitions and choices. Okay, so let me + +80 +00:04:11,860 --> 00:04:15,140 +remind you that what the, the tool will do + +81 +00:04:15,140 --> 00:04:17,790 +is what we will do manually. Otherwise, which is + +82 +00:04:17,790 --> 00:04:20,380 +to combine all these choices so as to have one + +83 +00:04:20,380 --> 00:04:23,305 +test case for each combination. So if we do + +84 +00:04:23,305 --> 00:04:27,412 +that, you can see that the tool tells us that + +85 +00:04:27,412 --> 00:04:32,383 +we will generate 7776 test frames in this case. + +86 +00:04:32,383 --> 00:04:34,660 +And this seems to be a little too much for + +87 +00:04:34,660 --> 00:04:36,868 +a program as small as the one that we are + +88 +00:04:36,868 --> 00:04:40,341 +testing. And assume for instance that we don't have the + +89 +00:04:40,341 --> 00:04:43,149 +resources to run this many test cases for, for + +90 +00:04:43,149 --> 00:04:46,518 +the grep program. In addition, consider that in this case, + +91 +00:04:46,518 --> 00:04:50,356 +we're computing all possible combinations of choices. And there's going to + +92 +00:04:50,356 --> 00:04:52,384 +be some combination that do not make sense as we + +93 +00:04:52,384 --> 00:04:54,945 +discussed in the lesson. So what we might want to + +94 +00:04:54,945 --> 00:04:57,051 +do in this case is to go back to our + +95 +00:04:57,051 --> 00:05:03,120 +spec and start adding constraints to eliminate this meaningless combination. + +96 +00:05:03,120 --> 00:05:05,980 +So I'm going to show you the result of doing that. + +97 +00:05:05,980 --> 00:05:08,690 +And I'm going to show you a few examples. + +98 +00:05:08,690 --> 00:05:11,670 +For example here, when the file is empty, I'm going to + +99 +00:05:11,670 --> 00:05:15,010 +define this property empty file. And how am I + +100 +00:05:15,010 --> 00:05:18,490 +going to use this property? Well for example here, it + +101 +00:05:18,490 --> 00:05:20,760 +doesn't make sense to consider the case in which + +102 +00:05:20,760 --> 00:05:24,660 +we have one or many occurrences of the pattern in + +103 +00:05:24,660 --> 00:05:27,020 +the file if the file is empty. Therefore I'm + +104 +00:05:27,020 --> 00:05:31,650 +going to tell the tool that it should consider this specific + +105 +00:05:31,650 --> 00:05:35,780 +choice only if the file is not empty, only if + +106 +00:05:35,780 --> 00:05:38,660 +empty file is not defined. And that will skip, for + +107 +00:05:38,660 --> 00:05:41,330 +example, all of the combinations in which the file is + +108 +00:05:41,330 --> 00:05:44,171 +empty. And I'm trying to generate the test case that has + +109 +00:05:44,171 --> 00:05:46,364 +one occurrence of the pattern in the file, which is + +110 +00:05:46,364 --> 00:05:49,355 +simply not possible. For another example, in case I have + +111 +00:05:49,355 --> 00:05:52,824 +an empty pattern, I define the property empty pattern. And + +112 +00:05:52,824 --> 00:05:56,725 +then I avoid the choices that involve the pattern in case + +113 +00:05:56,725 --> 00:05:59,820 +the pattern is empty. because, for example, I cannot + +114 +00:05:59,820 --> 00:06:03,900 +have quotes in a pattern that is empty. For example, + +115 +00:06:03,900 --> 00:06:06,760 +it doesn't make sense to have blanks. So, one or + +116 +00:06:06,760 --> 00:06:10,250 +more blanks if the pattern is empty. So I'm going to + +117 +00:06:10,250 --> 00:06:14,180 +specify again that this choice should be considered only if + +118 +00:06:14,180 --> 00:06:16,140 +we don't have an empty pattern. And so on and + +119 +00:06:16,140 --> 00:06:20,080 +so forth. So now after I edit these constraints, I + +120 +00:06:20,080 --> 00:06:21,890 +can go back and compute again the number of test + +121 +00:06:21,890 --> 00:06:23,970 +frames and therefore the test cases that will be + +122 +00:06:23,970 --> 00:06:27,530 +generated with these constraints. So let me go again + +123 +00:06:27,530 --> 00:06:30,381 +to my terminal. Okay, so now I'm going to run + +124 +00:06:30,381 --> 00:06:34,061 +my TSL generator again, and I'm going to run it on + +125 +00:06:34,061 --> 00:06:37,389 +the second version of this file. And you can + +126 +00:06:37,389 --> 00:06:40,546 +see that I reduced the, the number of test frames + +127 +00:06:40,546 --> 00:06:43,889 +from about 7800 to about 1700. So it's quite + +128 +00:06:43,889 --> 00:06:46,967 +a, quite a big reduction by eliminating all these combinations + +129 +00:06:46,967 --> 00:06:49,540 +that do not make sense. But let's assume again that + +130 +00:06:49,540 --> 00:06:52,040 +we want to reduce this further so that we don't want to + +131 +00:06:52,040 --> 00:06:55,610 +generate those many test frames and therefore test cases. So + +132 +00:06:55,610 --> 00:06:58,660 +what can we do? We go back to our spec. And + +133 +00:06:58,660 --> 00:07:02,280 +in this case, we start adding error constraints. So if + +134 +00:07:02,280 --> 00:07:05,200 +you remember what we said in the lesson, error constraints are + +135 +00:07:05,200 --> 00:07:08,310 +constraints that indicate a choice that has to do with an + +136 +00:07:08,310 --> 00:07:11,980 +erroneous behaviour. For example, an erroneous input provided to the problem. + +137 +00:07:11,980 --> 00:07:15,210 +So here for instance, we're indicating the presence + +138 +00:07:15,210 --> 00:07:20,060 +of incorrectly enclosing quotes as an error choice. Same + +139 +00:07:20,060 --> 00:07:22,270 +thing if there's no file corresponding to the + +140 +00:07:22,270 --> 00:07:23,970 +name that we provide to the tool, we say + +141 +00:07:23,970 --> 00:07:26,760 +that this corresponds to an error. So how + +142 +00:07:26,760 --> 00:07:29,130 +is the tool going to use this information? It uses + +143 +00:07:29,130 --> 00:07:33,980 +this information by producing only one combination that involves + +144 +00:07:33,980 --> 00:07:37,270 +error choices, instead of combining them with other choices. + +145 +00:07:37,270 --> 00:07:39,780 +So let's see what happens after we added this + +146 +00:07:39,780 --> 00:07:43,370 +error constraints. So we go back to our console + +147 +00:07:43,370 --> 00:07:46,920 +once more. And in this case, we want to run + +148 +00:07:46,920 --> 00:07:50,910 +the TSL generator with the version of the, of my + +149 +00:07:50,910 --> 00:07:53,900 +file that contains the area of constraints. And again, + +150 +00:07:53,900 --> 00:07:56,390 +I reduce quite a bit the number of test frames. + +151 +00:07:56,390 --> 00:07:59,110 +So now I have only 562 test frames that + +152 +00:07:59,110 --> 00:08:02,660 +will be generated by using the file that I provided. + +153 +00:08:02,660 --> 00:08:05,460 +So for the last time, let's assume that we really want + +154 +00:08:05,460 --> 00:08:07,780 +to cut down the number of test frames or the number of + +155 +00:08:07,780 --> 00:08:10,380 +test cases. So once more, we go back to our file, and + +156 +00:08:10,380 --> 00:08:12,980 +at this point what we can add is the final type of + +157 +00:08:12,980 --> 00:08:14,170 +constraints that we have, which are + +158 +00:08:14,170 --> 00:08:17,245 +single constraints. And single constraints are + +159 +00:08:17,245 --> 00:08:21,360 +basically indicated choices that we don't want to combine with other choices. + +160 +00:08:21,360 --> 00:08:24,210 +So they have the same effect of the error constraints, but they + +161 +00:08:24,210 --> 00:08:28,120 +have a different meaning, so they do not indicate choices that corresponds + +162 +00:08:28,120 --> 00:08:29,860 +to an error. In other words, I can use a + +163 +00:08:29,860 --> 00:08:35,280 +single constraints to identify choices that I want to test only once. + +164 +00:08:35,280 --> 00:08:38,510 +So for example in this case, I might decide that I + +165 +00:08:38,510 --> 00:08:42,520 +want to have only one test frame that tests my program + +166 +00:08:42,520 --> 00:08:44,420 +with a file being empty and I can do the + +167 +00:08:44,420 --> 00:08:47,370 +same for other choices. So basically I can continue adding this + +168 +00:08:47,370 --> 00:08:50,400 +single constraint until I get down to the number of test + +169 +00:08:50,400 --> 00:08:53,410 +frames and therefore the number of test cases that I want. + +170 +00:08:53,410 --> 00:08:57,770 +So now let's go back once more to our console. And so now if we run + +171 +00:08:59,060 --> 00:09:04,450 +using this file as input, you can see that we have 35 test frames generated. So + +172 +00:09:04,450 --> 00:09:07,750 +this is a fairly low number of test cases, so we might decide that we want to + +173 +00:09:07,750 --> 00:09:13,380 +go ahead and write these test frames to a file. So now let's open this file + +174 +00:09:15,990 --> 00:09:25,500 +that we just generated. And as you can see here, I have exactly 35 test frames, + +175 +00:09:26,670 --> 00:09:30,900 +as expected. Some of those correspond to the single and error cases. So in this + +176 +00:09:30,900 --> 00:09:33,330 +case, the only choice that I have indicated + +177 +00:09:33,330 --> 00:09:35,690 +is the one that corresponds to the single + +178 +00:09:35,690 --> 00:09:38,310 +or error constraint. What is for the other + +179 +00:09:38,310 --> 00:09:42,170 +ones? I actually have the whole test spec. + +180 +00:09:42,170 --> 00:09:45,530 +So let's pick one just to give you an example. + +181 +00:09:45,530 --> 00:09:48,440 +In this case, that's frame number 15 that will correspond to + +182 +00:09:48,440 --> 00:09:51,910 +test case number 15. And here you can see that + +183 +00:09:51,910 --> 00:09:55,280 +we have all the information. So this is a test specification. + +184 +00:09:55,280 --> 00:09:57,560 +All the information that we need to generate the corresponding + +185 +00:09:57,560 --> 00:09:59,760 +test. We know that we need a file that is not + +186 +00:09:59,760 --> 00:10:03,810 +empty. That we need to have one occurrence of the pattern + +187 +00:10:03,810 --> 00:10:07,580 +in the file. One occurrence of the pattern in one line. + +188 +00:10:08,680 --> 00:10:10,360 +The position of the pattern in the file can + +189 +00:10:10,360 --> 00:10:13,740 +be any position. The length of the pattern must + +190 +00:10:13,740 --> 00:10:16,640 +be more than one character. The pattern should not + +191 +00:10:16,640 --> 00:10:20,140 +be enclosed in quotes. There should be one white + +192 +00:10:20,140 --> 00:10:24,460 +space, one quote within the pattern, and finally the + +193 +00:10:24,460 --> 00:10:27,230 +file that would pass through the program should exist. + +194 +00:10:27,230 --> 00:10:29,680 +So the file should be present. So I can + +195 +00:10:29,680 --> 00:10:33,950 +easily transform all of this into an actual test case. + +196 +00:10:33,950 --> 00:10:35,540 +And notice that even though we're not, we're not + +197 +00:10:35,540 --> 00:10:38,420 +going to do it here. In cases like this, it might + +198 +00:10:38,420 --> 00:10:42,190 +even be possible to automatically generate the test cases + +199 +00:10:42,190 --> 00:10:45,020 +from the test specifications because, here for example, here it + +200 +00:10:45,020 --> 00:10:48,150 +should be relatively straight forward to parse these test + +201 +00:10:48,150 --> 00:10:52,450 +specifications and generate test cases accordingly. So, just to summarize, + +202 +00:10:52,450 --> 00:10:55,910 +what we have done is to go from one high-level + +203 +00:10:55,910 --> 00:10:58,880 +description of a program to a set of categories, partitions, + +204 +00:10:58,880 --> 00:11:01,820 +and choices for that program. Then we have combined them + +205 +00:11:01,820 --> 00:11:04,930 +in different ways, adding more and more constraints to reduce the + +206 +00:11:04,930 --> 00:11:07,600 +number of combinations until we ended up with the right number + +207 +00:11:07,600 --> 00:11:09,650 +of test cases, so the number of test cases that we + +208 +00:11:09,650 --> 00:11:14,630 +were fine generating. We generated the corresponding test specifications. And at + +209 +00:11:14,630 --> 00:11:17,340 +that point, we could just go ahead, generate the test case, + +210 +00:11:17,340 --> 00:11:20,660 +and test our application. So, and you can see how this + +211 +00:11:20,660 --> 00:11:23,720 +can result in a much more thorough testing of your application. + +212 +00:11:23,720 --> 00:11:27,890 +Because instead of reading this description and just trying to come up with test + +213 +00:11:27,890 --> 00:11:33,900 +cases for it, we can break down the process in steps that are easy to perform + +214 +00:11:33,900 --> 00:11:36,960 +individually. They can be automated as much + +215 +00:11:36,960 --> 00:11:38,600 +as possible. And they will end up with + +216 +00:11:38,600 --> 00:11:40,380 +a set of test cases that will test + +217 +00:11:40,380 --> 00:11:42,790 +all the interests and aspects of your application. diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/24 - Model Based Testing - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/24 - Model Based Testing - lang_en_vs4.srt new file mode 100644 index 0000000..3d41cd9 --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/24 - Model Based Testing - lang_en_vs4.srt @@ -0,0 +1,83 @@ +1 +00:00:00,370 --> 00:00:02,950 +What we just saw with the category-partition method, is a + +2 +00:00:02,950 --> 00:00:05,530 +specific instance of this systematic + +3 +00:00:05,530 --> 00:00:08,230 +functional testing approach. So specific instance + +4 +00:00:08,230 --> 00:00:10,900 +of the steps that we represented here. And, as I + +5 +00:00:10,900 --> 00:00:13,100 +mentioned earlier on, this is not the only way in which + +6 +00:00:13,100 --> 00:00:16,700 +you can generate test cases, starting from a functional specification. + +7 +00:00:16,700 --> 00:00:20,190 +In particular, this step, in which we identified relevant inputs and + +8 +00:00:20,190 --> 00:00:23,390 +then we combine them to generate test case specifications, can also + +9 +00:00:23,390 --> 00:00:25,490 +be done in different ways. And, we're going to look at one + +10 +00:00:25,490 --> 00:00:28,170 +of these ways. Which is through the construction of a + +11 +00:00:28,170 --> 00:00:31,040 +model. And, the reason why I want to talk about models. + +12 +00:00:31,040 --> 00:00:34,090 +Is because, model based testing is also, fairly popular in + +13 +00:00:34,090 --> 00:00:37,680 +industry. And fairly used in practice. In model based testing, the + +14 +00:00:37,680 --> 00:00:41,150 +way in which we go from specifications, to test cases, + +15 +00:00:41,150 --> 00:00:44,220 +is through the construction of a model. Where a model is + +16 +00:00:44,220 --> 00:00:47,670 +an abstract representation of the software under test. Also in + +17 +00:00:47,670 --> 00:00:50,860 +this case there are many possible models, that we can use. + +18 +00:00:50,860 --> 00:00:52,180 +And what we're going to do, we're going to focus + +19 +00:00:52,180 --> 00:00:54,370 +on a specific kind of model. And I'll + +20 +00:00:54,370 --> 00:00:57,010 +just point you to additional sources of information, + +21 +00:00:57,010 --> 00:00:59,070 +in case you're interested in seeing other examples. diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/25 - Finite State Machines - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/25 - Finite State Machines - lang_en_vs4.srt new file mode 100644 index 0000000..26f2fd7 --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/25 - Finite State Machines - lang_en_vs4.srt @@ -0,0 +1,103 @@ +1 +00:00:00,160 --> 00:00:02,320 +The model that we will consider, is a very well + +2 +00:00:02,320 --> 00:00:05,330 +known one. Which is finite state machines. And you might have + +3 +00:00:05,330 --> 00:00:08,320 +seen them before. At a high level, a state machine is + +4 +00:00:08,320 --> 00:00:11,990 +a graph in which nodes represent states of the system. For + +5 +00:00:11,990 --> 00:00:15,650 +example, in this case, state 1, state 2, and state 3. + +6 +00:00:15,650 --> 00:00:19,950 +Edges represent transitions between states. For instance, in this case we + +7 +00:00:19,950 --> 00:00:22,850 +have one edge from state 1, to state 2. That means + +8 +00:00:22,850 --> 00:00:25,640 +that the system can go from state 1, to state 2. + +9 +00:00:25,640 --> 00:00:29,530 +And finally, the labels on the edges represent events + +10 +00:00:29,530 --> 00:00:32,800 +and actions. For example, what this label means is that + +11 +00:00:32,800 --> 00:00:35,400 +the system goes from state three to state two + +12 +00:00:35,400 --> 00:00:39,140 +when event five occurs. And when going from state three + +13 +00:00:39,140 --> 00:00:42,190 +to state two, it generates action four. And does + +14 +00:00:42,190 --> 00:00:45,430 +reacher model, sir reacher's kind of state machines, but we're + +15 +00:00:45,430 --> 00:00:48,160 +just going to stick to this ones which are enough. For + +16 +00:00:48,160 --> 00:00:50,760 +our purpose. So how do we build such a final + +17 +00:00:50,760 --> 00:00:53,530 +state machine starting from a specification? The first thing + +18 +00:00:53,530 --> 00:00:56,660 +we need to do is to identify the system's boundaries + +19 +00:00:56,660 --> 00:00:59,250 +and the input and output to the system. Once we + +20 +00:00:59,250 --> 00:01:01,960 +have done that, we can identify, within the boundaries of + +21 +00:01:01,960 --> 00:01:06,070 +the system, the relevant states and transitions. So we split + +22 +00:01:06,070 --> 00:01:09,670 +this single state We'll refine it into several states. And + +23 +00:01:09,670 --> 00:01:12,640 +we also identify how the system can go from one + +24 +00:01:12,640 --> 00:01:16,830 +state to another. Including which inputs cause which transition, and + +25 +00:01:16,830 --> 00:01:19,350 +which result in outputs we can obtain. To + +26 +00:01:19,350 --> 00:01:21,810 +better illustrate that, let's look at a concrete example. diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/26 - Finite State Machines Example - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/26 - Finite State Machines Example - lang_en_vs4.srt new file mode 100644 index 0000000..f889057 --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/26 - Finite State Machines Example - lang_en_vs4.srt @@ -0,0 +1,251 @@ +1 +00:00:00,140 --> 00:00:03,010 +In this example, we're going to start from an informal specification, and the + +2 +00:00:03,010 --> 00:00:06,670 +specification is the one shown here in file spec.txt. This is the + +3 +00:00:06,670 --> 00:00:10,210 +specification for the maintenance function in a specific system. So what we're + +4 +00:00:10,210 --> 00:00:13,630 +doing is that we're taking the description of the functionality of a system, + +5 +00:00:13,630 --> 00:00:16,219 +and we're building a model, in this case a final state machine + +6 +00:00:16,219 --> 00:00:18,710 +for it. And there is no need to look at all the details + +7 +00:00:18,710 --> 00:00:21,350 +for this specification, but I want to point out that if you + +8 +00:00:21,350 --> 00:00:25,640 +look at the way the specification is written, we can identify specific cases + +9 +00:00:25,640 --> 00:00:28,210 +that we need to take into account. Like here if something + +10 +00:00:28,210 --> 00:00:31,920 +happens, something else will follow. Again, if something happens something else + +11 +00:00:31,920 --> 00:00:35,690 +will follow. So we have multiple choices here. Here will determine + +12 +00:00:35,690 --> 00:00:38,140 +the next steps and so on. So all we have to + +13 +00:00:38,140 --> 00:00:42,420 +do is to go through this process, identify these cases and + +14 +00:00:42,420 --> 00:00:45,300 +then build a machine that represents these cases. For the spec + +15 +00:00:45,300 --> 00:00:47,830 +that we just consider this is the state machine that will + +16 +00:00:47,830 --> 00:00:50,960 +result. Again there is no need to go through all the details, + +17 +00:00:50,960 --> 00:00:53,090 +but what I want to point out is that we have + +18 +00:00:53,090 --> 00:00:55,710 +a set of states. So for instance, we have state zero, + +19 +00:00:55,710 --> 00:00:58,380 +which is no maintenance, and if a request comes in, the + +20 +00:00:58,380 --> 00:01:01,350 +system will move, and the system wait for pickup. Then if + +21 +00:01:01,350 --> 00:01:04,400 +the pickup actually occurs, the system will move to the repair + +22 +00:01:04,400 --> 00:01:07,540 +state, and so on and so forth. So this is just + +23 +00:01:07,540 --> 00:01:13,070 +a more systematic representation of what was in the former specification. + +24 +00:01:13,070 --> 00:01:16,160 +And I will argue that this is much easier to understand at + +25 +00:01:16,160 --> 00:01:19,170 +least for somebody who has to develop tests for this system. In + +26 +00:01:19,170 --> 00:01:21,770 +fact what we're going to see next is how we can go from that + +27 +00:01:21,770 --> 00:01:24,790 +representation to a set of test cases. And the way which we do + +28 +00:01:24,790 --> 00:01:28,950 +it is by covering the behaviors represented by defining state machine. And we + +29 +00:01:28,950 --> 00:01:31,500 +can decide how we want to cover them. For example we might want + +30 +00:01:31,500 --> 00:01:35,080 +to cover all the states. So we might want to identify paths in + +31 +00:01:35,080 --> 00:01:38,310 +the state machine that go through all the states in the machine. Like + +32 +00:01:38,310 --> 00:01:41,840 +the one I just draw or this one, this one and this one. + +33 +00:01:41,840 --> 00:01:44,900 +So if we consider these four test cases, we can see that all the + +34 +00:01:44,900 --> 00:01:48,470 +states in my system or at least all the states that I have identified + +35 +00:01:48,470 --> 00:01:51,450 +are covered. I might want to go a little further, and decide that I + +36 +00:01:51,450 --> 00:01:54,210 +don't only want to cover all of the states, but I want to cover, all + +37 +00:01:54,210 --> 00:01:57,930 +of the transitions, because, it makes sense to visit a state, when coming from + +38 +00:01:57,930 --> 00:02:00,380 +different states. And, if I want to do that, and I look at the + +39 +00:02:00,380 --> 00:02:03,440 +test cases that I generated so far, I can see that there is one + +40 +00:02:03,440 --> 00:02:06,910 +transition, the one here, that is not covered. And, the same can be said for + +41 +00:02:06,910 --> 00:02:09,210 +the two transitions here. So what I can decide to do is + +42 +00:02:09,210 --> 00:02:13,370 +to generate another test case, that covers those or extend an existing one. + +43 +00:02:13,370 --> 00:02:16,500 +For instance, I could extend this test case by adding a visit to + +44 +00:02:16,500 --> 00:02:20,760 +the state, before going back to these two. Alternatively, I could also generate + +45 +00:02:20,760 --> 00:02:24,390 +new test cases, such as this one. To cover the missing transitions. + +46 +00:02:24,390 --> 00:02:26,350 +And once I have these test cases, I can express them in a + +47 +00:02:26,350 --> 00:02:29,860 +clearer way by simply specifying what are the states that they cover. I'm + +48 +00:02:29,860 --> 00:02:31,990 +just going to give you a couple of examples. Say, if we look + +49 +00:02:31,990 --> 00:02:34,280 +at the last one that I added, which will be test case + +50 +00:02:34,280 --> 00:02:37,190 +number five, I just need to specify that it will go through state + +51 +00:02:37,190 --> 00:02:41,090 +zero, which is this one, five, which is this one, six, and + +52 +00:02:41,090 --> 00:02:43,130 +then back to zero. And I can do the same for the other + +53 +00:02:43,130 --> 00:02:46,500 +test cases. So this will be my complete set of test cases. + +54 +00:02:46,500 --> 00:02:50,060 +So the bottom line here is that it is much harder to build + +55 +00:02:50,060 --> 00:02:53,080 +a set of test cases that will cover the behavior of an informal + +56 +00:02:53,080 --> 00:02:56,970 +description. But by going through a model, so by building in this case, + +57 +00:02:56,970 --> 00:03:01,700 +a finite state machine for that description, we can, in a much easier way, see + +58 +00:03:01,700 --> 00:03:04,100 +what the behaviors of interest of the system + +59 +00:03:04,100 --> 00:03:05,960 +are, and try to cover them. And there + +60 +00:03:05,960 --> 00:03:07,400 +is again in the spirit of breaking + +61 +00:03:07,400 --> 00:03:09,950 +down a complex problem into smaller steps that + +62 +00:03:09,950 --> 00:03:11,620 +we can better manage, which in the end, + +63 +00:03:11,620 --> 00:03:14,450 +results in a more efficient and effective testing. diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/27 - Finite State Machines Considerations - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/27 - Finite State Machines Considerations - lang_en_vs4.srt new file mode 100644 index 0000000..64c2c00 --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/27 - Finite State Machines Considerations - lang_en_vs4.srt @@ -0,0 +1,99 @@ +1 +00:00:00,100 --> 00:00:03,060 +There are some important considerations I want to make on final state + +2 +00:00:03,060 --> 00:00:06,410 +machines. And more in general, on model based testing. The first one + +3 +00:00:06,410 --> 00:00:10,600 +is about applicability. Testing based on final state machines is a very + +4 +00:00:10,600 --> 00:00:13,890 +general approach, that we can apply in a number of contexts. And in + +5 +00:00:13,890 --> 00:00:16,510 +particular, if you are working with UML, you have state machines for + +6 +00:00:16,510 --> 00:00:19,720 +free. Because state charts are nothing else but a special kind of + +7 +00:00:19,720 --> 00:00:22,210 +state machine. So you can apply the technique that we just saw + +8 +00:00:22,210 --> 00:00:26,010 +directly on state charts, and try to cover their states and their transitions. + +9 +00:00:26,010 --> 00:00:29,980 +Another important point is that abstraction is key. You have to find the + +10 +00:00:29,980 --> 00:00:33,280 +right level of abstraction. The bigger the system, the more you have to + +11 +00:00:33,280 --> 00:00:36,130 +abstract if you want to represent it with a model, and in particular, with + +12 +00:00:36,130 --> 00:00:38,710 +the final state machine. So it's like having a slider, and you have + +13 +00:00:38,710 --> 00:00:41,840 +to decide where you want to move on that slider. The more you represent, + +14 +00:00:41,840 --> 00:00:44,700 +the more complex your system is going to be and the more thorough your + +15 +00:00:44,700 --> 00:00:48,110 +testing is going to be but also more expensive. The less you represent the + +16 +00:00:48,110 --> 00:00:51,330 +less expensive testing is going to be, but also testing might not be as + +17 +00:00:51,330 --> 00:00:53,500 +thorough as it would be otherwise. So you have to find + +18 +00:00:53,500 --> 00:00:56,150 +the right balance between abstracting the weight too much and abstracting + +19 +00:00:56,150 --> 00:00:59,840 +the weight too little. And finally there are many other approaches. + +20 +00:00:59,840 --> 00:01:02,840 +So we just scratched the surface, and we just saw one possible + +21 +00:01:02,840 --> 00:01:05,760 +approach. But for instance, other models that you can use are + +22 +00:01:05,760 --> 00:01:09,780 +decision tables, flow graphs and even historical models. Models that can + +23 +00:01:09,780 --> 00:01:13,560 +guide your testing based on problems that occurred in your system + +24 +00:01:13,560 --> 00:01:16,500 +in the past. And also, in this case, I'm going to put pointers + +25 +00:01:16,500 --> 00:01:18,460 +to additional materials in the class notes. diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/28 - Summary - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/28 - Summary - lang_en_vs4.srt new file mode 100644 index 0000000..1b68b9f --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/28 - Summary - lang_en_vs4.srt @@ -0,0 +1,67 @@ +1 +00:00:00,110 --> 00:00:01,600 +Now we are at the end of this lesson, and I + +2 +00:00:01,600 --> 00:00:04,450 +just want to wrap it up by summarizing what we've seen. We talked + +3 +00:00:04,450 --> 00:00:06,340 +about black-box testing, the testing of + +4 +00:00:06,340 --> 00:00:08,760 +software based on a functional specification, + +5 +00:00:08,760 --> 00:00:11,510 +a description of the software rather than its code. We saw a + +6 +00:00:11,510 --> 00:00:15,500 +systematic way of doing that, that allows for breaking down the problem + +7 +00:00:15,500 --> 00:00:19,140 +of testing software, so the problem of going from this functional specification + +8 +00:00:19,140 --> 00:00:22,540 +to a set of test cases into smaller steps, more manageable steps. + +9 +00:00:22,540 --> 00:00:25,466 +And we saw two main ways of doing this. One by identifying + +10 +00:00:25,466 --> 00:00:28,304 +relevant inputs for the main features in the system + +11 +00:00:28,304 --> 00:00:31,802 +and then deriving test case specifications and test cases from + +12 +00:00:31,802 --> 00:00:34,180 +this set of inputs. And the second way by + +13 +00:00:34,180 --> 00:00:36,780 +building a model for the main features of the system + +14 +00:00:36,780 --> 00:00:39,210 +and then using this model to decide how to + +15 +00:00:39,210 --> 00:00:41,680 +test the system. In the next lesson, we are going + +16 +00:00:41,680 --> 00:00:44,440 +to discuss, how to do testing by looking inside the + +17 +00:00:44,440 --> 00:00:47,716 +box? So, how to do testing in a white-box fashion. diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/3 - Systematic Functional Testing Approach - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/3 - Systematic Functional Testing Approach - lang_en_vs4.srt new file mode 100644 index 0000000..75da7e8 --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/3 - Systematic Functional Testing Approach - lang_en_vs4.srt @@ -0,0 +1,179 @@ +1 +00:00:00,140 --> 00:00:02,690 +So what is the starting point of black box testing? Black + +2 +00:00:02,690 --> 00:00:06,010 +box testing start from a description of the software or as we + +3 +00:00:06,010 --> 00:00:09,590 +call it, a functional specification. And the final result of black + +4 +00:00:09,590 --> 00:00:12,760 +box testing is a set of test cases, a set of actual + +5 +00:00:12,760 --> 00:00:16,410 +inputs and corresponding outputs that we can use to exercise our + +6 +00:00:16,410 --> 00:00:19,030 +code and to try to find defects in our code. So the + +7 +00:00:19,030 --> 00:00:22,060 +question is, how do we get from functional specification to test + +8 +00:00:22,060 --> 00:00:25,510 +cases? Doing these derivations, so going from this description to a concrete + +9 +00:00:25,510 --> 00:00:28,550 +set of tests, is a very complex analytical process. + +10 +00:00:28,550 --> 00:00:31,220 +And normally brute force generation is not a good + +11 +00:00:31,220 --> 00:00:34,430 +idea because it's inefficient and ineffective. What we want + +12 +00:00:34,430 --> 00:00:37,540 +to do instead is to have a systematic approach to + +13 +00:00:37,540 --> 00:00:40,250 +derive test cases from a functional specification. What a + +14 +00:00:40,250 --> 00:00:43,970 +systematic approach does is to simplify the overall problem by + +15 +00:00:43,970 --> 00:00:48,320 +dividing the process into elementary steps. In particular, in + +16 +00:00:48,320 --> 00:00:50,520 +this case, we will perform three main steps. The first + +17 +00:00:50,520 --> 00:00:55,790 +step is to identify independently testable features. Individual features in + +18 +00:00:55,790 --> 00:00:57,600 +the soft hood that we can test. And we're going to + +19 +00:00:57,600 --> 00:00:59,990 +expand on each one of these steps in the next + +20 +00:00:59,990 --> 00:01:02,490 +part of the lesson. The following step is once we have + +21 +00:01:02,490 --> 00:01:06,000 +these independently testable features to identify what are the relevant + +22 +00:01:06,000 --> 00:01:08,590 +inputs. So what are the inputs or the behavior that is + +23 +00:01:08,590 --> 00:01:11,610 +worth testing for these features. Next once we have these + +24 +00:01:11,610 --> 00:01:13,020 +inputs, we're going to derive test + +25 +00:01:13,020 --> 00:01:15,770 +specifications. And test case specifications are + +26 +00:01:15,770 --> 00:01:19,490 +description of the test cases that we can then use + +27 +00:01:19,490 --> 00:01:23,270 +to generate actual test cases. And proceeding in this way, + +28 +00:01:23,270 --> 00:01:26,050 +by this steps, has many advantages. It allows for the + +29 +00:01:26,050 --> 00:01:29,920 +coupling different activities. It allows for dividing brain intensive steps from + +30 +00:01:29,920 --> 00:01:32,240 +steps that can be automated, which is a great advantage. + +31 +00:01:32,240 --> 00:01:34,980 +And also we will see, it allows you for monitoring + +32 +00:01:34,980 --> 00:01:38,040 +the testing process. So to figure out whether your testing + +33 +00:01:38,040 --> 00:01:41,000 +process is going as expected, for example, if you're generating too + +34 +00:01:41,000 --> 00:01:44,160 +many test cases. Or you're generating the number of test cases that your + +35 +00:01:44,160 --> 00:01:47,880 +amount of resources available allows you to run. So let's start by looking + +36 +00:01:47,880 --> 00:01:51,230 +at the first step of this process in which our goal is to + +37 +00:01:51,230 --> 00:01:54,820 +go from a Functional Specification to a set of features that we can + +38 +00:01:54,820 --> 00:01:57,700 +test in the software. So what we want to do is to identify all + +39 +00:01:57,700 --> 00:02:00,290 +of the feature of the software. And why do we want to do this? + +40 +00:02:00,290 --> 00:02:02,650 +Well you know, in the spirit of breaking down the complexity of the + +41 +00:02:02,650 --> 00:02:06,170 +problem, it does not make sense to just try to devise test cases for + +42 +00:02:06,170 --> 00:02:08,750 +all the features of the software at once. For any non-trivial + +43 +00:02:08,750 --> 00:02:11,980 +software, that's a humongous problem, and something that we cannot really + +44 +00:02:11,980 --> 00:02:16,300 +handle effectively. A much better way is to identify independently testable + +45 +00:02:16,300 --> 00:02:19,100 +features and consider one of them at a time when generating tests. diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/4 - Overview Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/4 - Overview Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..dda3144 --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/4 - Overview Quiz - lang_en_vs4.srt @@ -0,0 +1,35 @@ +1 +00:00:00,740 --> 00:00:02,780 +So, now I want to do a little quiz about + +2 +00:00:02,780 --> 00:00:05,530 +identifying testable features. Let's consider + +3 +00:00:05,530 --> 00:00:07,700 +this simple problem called printSum. + +4 +00:00:07,700 --> 00:00:09,680 +We won't see the implementation because we are doing black-box + +5 +00:00:09,680 --> 00:00:12,780 +testing. And all we need to know is that printSum takes + +6 +00:00:12,780 --> 00:00:15,550 +two integers, a and b, and prints the sum of + +7 +00:00:15,550 --> 00:00:17,540 +these two numbers. So what I want to ask, is + +8 +00:00:17,540 --> 00:00:20,700 +how many independently testable features do we have here? Do + +9 +00:00:20,700 --> 00:00:24,860 +we have one, two, three features? Or more than three features? diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/5 - Overview Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/5 - Overview Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..5503f98 --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/5 - Overview Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,15 @@ +1 +00:00:00,360 --> 00:00:03,760 +Sum is a very simple program, that only does one thing, + +2 +00:00:03,760 --> 00:00:07,540 +summing two number, adding two numbers. So the answer in this + +3 +00:00:07,540 --> 00:00:10,640 +case, it's one. There's only one feature that we can test + +4 +00:00:10,640 --> 00:00:14,060 +in PrintSum. So let's look at the slightly more interesting example. diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/6 - Overview Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/6 - Overview Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..96c643e --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/6 - Overview Quiz - lang_en_vs4.srt @@ -0,0 +1,19 @@ +1 +00:00:00,150 --> 00:00:02,469 +Let's look at this spreadsheet. I'm pretty sure most of you + +2 +00:00:02,469 --> 00:00:05,990 +are familiar with what a spreadsheet is and have used them before. + +3 +00:00:05,990 --> 00:00:08,119 +So now I'm going to ask the same question, which is I'd + +4 +00:00:08,119 --> 00:00:10,480 +like you to identify three possible + +5 +00:00:10,480 --> 00:00:13,190 +independently testable features for a spreadsheet. diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/7 - Overview Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/7 - Overview Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..88e7cd5 --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/7 - Overview Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,71 @@ +1 +00:00:00,190 --> 00:00:03,030 +In this case there's not really a right answer because there's + +2 +00:00:03,030 --> 00:00:05,750 +many, many features that you could identify in a piece of + +3 +00:00:05,750 --> 00:00:08,655 +software as complex as a, a spreadsheet. So I'm just going + +4 +00:00:08,655 --> 00:00:11,900 +to give you three examples. So one could be the cell merging + +5 +00:00:11,900 --> 00:00:14,950 +operation. So the operation in which we merge two cells in + +6 +00:00:14,950 --> 00:00:18,550 +the spreadsheet. Another example could be chart creation, so I might want + +7 +00:00:18,550 --> 00:00:21,370 +to test the feature that allows you to create charts in + +8 +00:00:21,370 --> 00:00:23,310 +your spreadsheets. Yet another example could + +9 +00:00:23,310 --> 00:00:25,540 +be the test of statistical functions, + +10 +00:00:25,540 --> 00:00:29,350 +so the function that allows you to do various statistical calculations on + +11 +00:00:29,350 --> 00:00:32,650 +the numbers in your cells. And as I said there's many, many + +12 +00:00:32,650 --> 00:00:35,900 +more example that we could use. But the key thing I want + +13 +00:00:35,900 --> 00:00:38,770 +to convey here is the fact that there is no way you + +14 +00:00:38,770 --> 00:00:42,020 +can look at a spreadsheet with all the functionality that it provides + +15 +00:00:42,020 --> 00:00:44,160 +and just go and test it. The first step, what you need + +16 +00:00:44,160 --> 00:00:47,430 +to do first, is to identify which ones are the pieces of + +17 +00:00:47,430 --> 00:00:50,620 +functionality that I can test individually. So that's why this is the + +18 +00:00:50,620 --> 00:00:52,310 +first step in black-box testing. diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/8 - Test Data Selection - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/8 - Test Data Selection - lang_en_vs4.srt new file mode 100644 index 0000000..51aaffe --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/8 - Test Data Selection - lang_en_vs4.srt @@ -0,0 +1,103 @@ +1 +00:00:00,230 --> 00:00:03,550 +Once we have identified Independently Testable Features, the next step is to + +2 +00:00:03,550 --> 00:00:07,720 +identify the Relevant Inputs for each one of these features. And there are + +3 +00:00:07,720 --> 00:00:10,420 +many ways to do that. So, what we're going to do, instead of + +4 +00:00:10,420 --> 00:00:13,770 +looking at them all, is that we're just going to focus on two different + +5 +00:00:13,770 --> 00:00:16,239 +ways of doing it. And they are fairly general ways. So, they + +6 +00:00:16,239 --> 00:00:19,910 +are applicable to a number of situations. And in addition, what I will + +7 +00:00:19,910 --> 00:00:22,190 +do, I will point you to other sources in which you can + +8 +00:00:22,190 --> 00:00:25,530 +look at different ways of doing this in the class notes. The problem + +9 +00:00:25,530 --> 00:00:28,390 +of identifying relevant inputs for some Software or some feature + +10 +00:00:28,390 --> 00:00:31,930 +of it is called Test Data Selection and can be expressed + +11 +00:00:31,930 --> 00:00:35,040 +as followed. Let's consider our software as usual we have + +12 +00:00:35,040 --> 00:00:38,190 +our Input Domain, which is the set of inputs for all + +13 +00:00:38,190 --> 00:00:40,980 +the software. And again as usual, we have our Output + +14 +00:00:40,980 --> 00:00:44,050 +Domain, which is the set of corresponding outlets for these inputs. + +15 +00:00:44,050 --> 00:00:47,450 +So the question here is, how can we select a meaningful + +16 +00:00:47,450 --> 00:00:50,920 +set of inputs in my domain? And of course corresponding outputs + +17 +00:00:50,920 --> 00:00:53,240 +because we know that test cases are an input, plus an + +18 +00:00:53,240 --> 00:00:56,900 +expected output. So how can we select interesting inputs for our + +19 +00:00:56,900 --> 00:01:00,040 +software? So a set of inputs that, after we run them + +20 +00:01:00,040 --> 00:01:02,950 +on the software, if the software behaves correctly, we'll have enough + +21 +00:01:02,950 --> 00:01:07,060 +confidence that the software is correctly implemented. So one possible idea + +22 +00:01:07,060 --> 00:01:09,830 +is, hey, why don't we just test them all? We just + +23 +00:01:09,830 --> 00:01:12,800 +do exhaustive testing. We do all the inputs, nowadays we have + +24 +00:01:12,800 --> 00:01:16,290 +powerful machines, we have a lot of computational power in the cloud. + +25 +00:01:16,290 --> 00:01:17,890 +Why not just doing it? So to answer that + +26 +00:01:17,890 --> 00:01:20,480 +question, what I'm going to do? I'm going to use another quiz. diff --git a/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/9 - Test Data Selection Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/9 - Test Data Selection Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..9ffead6 --- /dev/null +++ b/usth/ICT2.7/P4L2 Black-Box Testing Subtitles/9 - Test Data Selection Quiz - lang_en_vs4.srt @@ -0,0 +1,31 @@ +1 +00:00:00,200 --> 00:00:02,180 +So I'm going to ask you something. Which is if + +2 +00:00:02,180 --> 00:00:04,750 +we consider again our function print sum, the one + +3 +00:00:04,750 --> 00:00:06,760 +that takes two integers and prints the sum. How + +4 +00:00:06,760 --> 00:00:09,300 +long would it take to exhaustively test this function? And + +5 +00:00:09,300 --> 00:00:10,950 +this is a very simple one. There's just two + +6 +00:00:10,950 --> 00:00:13,240 +inputs, right? So we can just enumerate them all. + +7 +00:00:13,240 --> 00:00:15,950 +And put them throw them at the computer form, + +8 +00:00:15,950 --> 00:00:18,440 +and wait for the results. How long would that take? diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/1 - Lesson Overview - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/1 - Lesson Overview - lang_en_vs4.srt new file mode 100644 index 0000000..64f1576 --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/1 - Lesson Overview - lang_en_vs4.srt @@ -0,0 +1,47 @@ +1 +00:00:00,110 --> 00:00:02,570 +In the previous lesson we discussed black box + +2 +00:00:02,570 --> 00:00:05,120 +testing, which is the testing performed based on a + +3 +00:00:05,120 --> 00:00:08,760 +description of the software, but without considering any of + +4 +00:00:08,760 --> 00:00:12,440 +software's internal details. In this lesson, we will discuss + +5 +00:00:12,440 --> 00:00:15,490 +the counterpart of black box testing, which is called + +6 +00:00:15,490 --> 00:00:20,590 +unsurprisingly white box testing or structural testing. And just + +7 +00:00:20,590 --> 00:00:22,780 +like we did for black box testing, we will + +8 +00:00:22,780 --> 00:00:25,740 +cover the main characteristics of white box testing and + +9 +00:00:25,740 --> 00:00:30,620 +this casts the most commonly used white box testing techniques. We + +10 +00:00:30,620 --> 00:00:33,650 +will conclude the lesson with the discussion of the main strengths and + +11 +00:00:33,650 --> 00:00:37,540 +limitations of white box testing. So that you will know, when to + +12 +00:00:37,540 --> 00:00:40,950 +use it? How to use it? And what to expect from it? diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/10 - Statement Coverage Quiz Solution - lang_en_vs7.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/10 - Statement Coverage Quiz Solution - lang_en_vs7.srt new file mode 100644 index 0000000..c18d579 --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/10 - Statement Coverage Quiz Solution - lang_en_vs7.srt @@ -0,0 +1,31 @@ +1 +00:00:00,210 --> 00:00:01,900 +To get the answer to this question, I'm + +2 +00:00:01,900 --> 00:00:03,540 +going to ask you to be a little patient, and + +3 +00:00:03,540 --> 00:00:05,120 +to wait until the end of the lesson. + +4 +00:00:05,120 --> 00:00:06,792 +Because there are a couple of more topics that + +5 +00:00:06,792 --> 00:00:08,244 +I want to cover, before I actually get in + +6 +00:00:08,244 --> 00:00:10,210 +to this. Nevertheless, I wanted to ask you right + +7 +00:00:10,210 --> 00:00:11,880 +away, because I wanted you to think about + +8 +00:00:11,880 --> 00:00:13,560 +this, before you see the rest of the lesson. diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/11 - Control Flow Graphs - lang_en_vs5.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/11 - Control Flow Graphs - lang_en_vs5.srt new file mode 100644 index 0000000..83d5860 --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/11 - Control Flow Graphs - lang_en_vs5.srt @@ -0,0 +1,167 @@ +1 +00:00:00,320 --> 00:00:03,450 +Let's look at the code for PrintSum in a slightly different way + +2 +00:00:03,450 --> 00:00:06,140 +by making something explicit. If we go through the code, we can + +3 +00:00:06,140 --> 00:00:08,578 +see that the, the code does something in that case, if the + +4 +00:00:08,578 --> 00:00:11,720 +result greater then zero, does something else if the result is not + +5 +00:00:11,720 --> 00:00:14,890 +greater than zero but is less than zero, and otherwise in the + +6 +00:00:14,890 --> 00:00:17,800 +case in which neither of these two conditions is true. Nothing really + +7 +00:00:17,800 --> 00:00:19,090 +happens. So we're going to make that + +8 +00:00:19,090 --> 00:00:21,290 +explicit, we're going to say here, otherwise + +9 +00:00:21,290 --> 00:00:25,430 +do nothing, which is exactly our problem, the code does nothing, in this + +10 +00:00:25,430 --> 00:00:28,380 +case where it should do something. So now, let's look again in + +11 +00:00:28,380 --> 00:00:31,470 +our test cases, let's consider the first one, and I'm going to go a + +12 +00:00:31,470 --> 00:00:34,410 +little faster in this case, because we already saw what happens If + +13 +00:00:34,410 --> 00:00:37,890 +we execute the first test case, we get to this point, we execute + +14 +00:00:37,890 --> 00:00:40,710 +this statement, and then we just jump to the end, as we + +15 +00:00:40,710 --> 00:00:44,020 +saw. Now we, if we execute the second test case, we do the + +16 +00:00:44,020 --> 00:00:46,740 +same, we get to the else statement, the condition for the if is + +17 +00:00:46,740 --> 00:00:50,770 +true, and therefore we execute this statement. And we never reached this point + +18 +00:00:50,770 --> 00:00:53,320 +for either of the test cases. So how can we express + +19 +00:00:53,320 --> 00:00:56,470 +this? In order to do that, I'm going to introduce a very useful + +20 +00:00:56,470 --> 00:01:00,450 +concept. The concept of control flow graphs. The control flow graphs + +21 +00:01:00,450 --> 00:01:03,310 +is just a representation for the code that is very convenient when + +22 +00:01:03,310 --> 00:01:06,030 +we run our reason about the code and its structure. And + +23 +00:01:06,030 --> 00:01:09,910 +it's a fairly simple one that represents statement with notes and the + +24 +00:01:09,910 --> 00:01:12,900 +flow of control within the code with edges. So here's an + +25 +00:01:12,900 --> 00:01:16,180 +example of control flow graph for this code. There is the entry + +26 +00:01:16,180 --> 00:01:19,790 +point of the code right here, then our statement in which we + +27 +00:01:19,790 --> 00:01:23,320 +assign the result of A plus B to variable result. Our if + +28 +00:01:23,320 --> 00:01:25,720 +statement and as you can see the if statement it's got two + +29 +00:01:25,720 --> 00:01:28,930 +branches coming out of it, because based on the outcome of this + +30 +00:01:28,930 --> 00:01:32,376 +predicate we will go one way or the other. In fact normally + +31 +00:01:32,376 --> 00:01:36,000 +what we do, we will label this edges accordingly. So for example, + +32 +00:01:36,000 --> 00:01:38,580 +here we will say that this is the label to be executed + +33 +00:01:38,580 --> 00:01:41,470 +when the predicate is true. And this is the label that is executed + +34 +00:01:41,470 --> 00:01:44,120 +when the predicate is false. Now, at this point, similar + +35 +00:01:44,120 --> 00:01:47,080 +thing, statement five which corresponds with this one, we have another + +36 +00:01:47,080 --> 00:01:49,650 +if statement and if that statement is true, then we get + +37 +00:01:49,650 --> 00:01:51,830 +to this point and if it's false, we get to this + +38 +00:01:51,830 --> 00:01:54,370 +point. So as you can see, this graph represents my + +39 +00:01:54,370 --> 00:01:57,040 +code, in a much more intuitive way, because I can see + +40 +00:01:57,040 --> 00:02:00,650 +right away where the control flows, while I execute the code. + +41 +00:02:00,650 --> 00:02:01,730 +So we're going to use this + +42 +00:02:01,730 --> 00:02:04,430 +representation to introduce further coverage criteria. diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/12 - Branch Coverage - lang_en_vs3.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/12 - Branch Coverage - lang_en_vs3.srt new file mode 100644 index 0000000..a1dedad --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/12 - Branch Coverage - lang_en_vs3.srt @@ -0,0 +1,267 @@ +1 +00:00:00,400 --> 00:00:03,780 +So now that we know what the CFG is, let's see how we can get into a count, + +2 +00:00:03,780 --> 00:00:07,860 +that else part, that is missing in our example code by introducing a new + +3 +00:00:07,860 --> 00:00:10,480 +kind of coverage. Branch coverage. As usual, + +4 +00:00:10,480 --> 00:00:13,550 +I'm going to describe branch coverage in terms of test requirements and + +5 +00:00:13,550 --> 00:00:17,100 +coverage measure. So starting from test requirements. The test requirement for + +6 +00:00:17,100 --> 00:00:21,080 +branch coverage are the branches in the program. In other words, + +7 +00:00:21,080 --> 00:00:25,240 +the goal of branch coverage is to execute all of the branches in the program. + +8 +00:00:25,240 --> 00:00:28,370 +The coverage measure is defined accordingly as the number of branches + +9 +00:00:28,370 --> 00:00:33,150 +executed by my test cases over the total number of branches in the program. And + +10 +00:00:33,150 --> 00:00:37,020 +let me remind you that branches are the outgoing edges from a decision point. + +11 +00:00:37,020 --> 00:00:40,410 +Therefore, an if statement, a switch statement, a while statement. + +12 +00:00:40,410 --> 00:00:44,400 +Any note in the c of g that has got more than one outgoing edge. + +13 +00:00:44,400 --> 00:00:48,170 +Those edges are called branches. So let's look at that using our example. So + +14 +00:00:48,170 --> 00:00:51,690 +now we're looking back at our printSum example. And in addition to the code, + +15 +00:00:51,690 --> 00:00:54,440 +I also want to represent the CFG for the program. So + +16 +00:00:54,440 --> 00:00:58,590 +let's start by looking at how many branches we have in our code. Which means how + +17 +00:00:58,590 --> 00:01:02,070 +many test requirements we have. And in this case there are two decision points. + +18 +00:01:02,070 --> 00:01:04,940 +The first one that corresponds to the first if, and the second one that + +19 +00:01:04,940 --> 00:01:10,100 +corresponds to the second if. So we have one, two, three, and four branches. So + +20 +00:01:10,100 --> 00:01:13,880 +now, let's bring back our current set of test cases. We had two test cases. + +21 +00:01:13,880 --> 00:01:17,440 +The one's that, with which we achieved a 100% statement coverage. And + +22 +00:01:17,440 --> 00:01:21,140 +let's see what happens in terms of branch coverage when we run these test cases. + +23 +00:01:21,140 --> 00:01:24,110 +I start from the first one, when we execute it, we follow the code, + +24 +00:01:24,110 --> 00:01:27,890 +we get to this decision point because the predicate in the if statement is true. + +25 +00:01:27,890 --> 00:01:30,770 +We follow the true branch, therefore we get here and then, + +26 +00:01:30,770 --> 00:01:34,970 +we exit from the program. So, in this case, we covered one of the branches, + +27 +00:01:34,970 --> 00:01:40,710 +which means that we got to 25% coverage. Now when we run the second test case, + +28 +00:01:40,710 --> 00:01:44,160 +again we follow this path. We get to this, the first if and + +29 +00:01:44,160 --> 00:01:47,730 +in this case the predicate of the if is false. Therefore, we go this way. + +30 +00:01:47,730 --> 00:01:51,160 +We reach the second predicate, the second if. The result is true, so + +31 +00:01:51,160 --> 00:01:55,490 +we follow the true branch and therefore, we cover these additional two branches. + +32 +00:01:55,490 --> 00:01:59,900 +So at this point, we are at 75% branch coverage. So what + +33 +00:01:59,900 --> 00:02:04,070 +happens is that we're missing this branch. For now, the inputs that we consider, + +34 +00:02:04,070 --> 00:02:07,740 +this branch is executed. Therefore, we need to add an additional test case. And + +35 +00:02:07,740 --> 00:02:11,600 +that this case that we need, is one for which this predicate is false and this + +36 +00:02:11,600 --> 00:02:15,680 +predicate is false. The simplest possibility in this case is the test case for + +37 +00:02:15,680 --> 00:02:20,170 +which A is equal to 0 and B is equal to 0. If we execute this test case, + +38 +00:02:20,170 --> 00:02:24,250 +our execution again followed this path, follows the fourth branch here. + +39 +00:02:24,250 --> 00:02:28,090 +And in this case, because result is not less than zero either, will follow + +40 +00:02:28,090 --> 00:02:33,090 +this branch as well. And therefore, we will reach our 100% branch coverage. And + +41 +00:02:33,090 --> 00:02:35,820 +this covered the problem. Something that I would like to clarify before we + +42 +00:02:35,820 --> 00:02:40,920 +move to the next topic, is that 100% coverage does not provide any guarantee of + +43 +00:02:40,920 --> 00:02:44,530 +finding the problems in the code. All we saw so far is the fact that by + +44 +00:02:44,530 --> 00:02:48,580 +testing more thoroughly we have more chances of finding a problem in the code. + +45 +00:02:48,580 --> 00:02:51,680 +But it doesn't matter which kind of coverage we utilize, and how much + +46 +00:02:51,680 --> 00:02:55,440 +coverage we achieve. There's always a chance that we might miss something. And + +47 +00:02:55,440 --> 00:02:59,760 +I will get back to this later on in the lesson. I just mentioned the fact that + +48 +00:02:59,760 --> 00:03:03,910 +we tested more fully when we went from statement coverage to branch coverage. + +49 +00:03:03,910 --> 00:03:06,900 +What does that mean exactly? To explain that, I'm going to introduce the concept + +50 +00:03:06,900 --> 00:03:11,420 +of test criteria subsumption. One test criteria subsumes another criteria when + +51 +00:03:11,420 --> 00:03:16,760 +all the tests widths that satisfy that criteria will also satisfy the other one. + +52 +00:03:16,760 --> 00:03:18,740 +So let me show you that with statement and + +53 +00:03:18,740 --> 00:03:23,220 +branch coverage. If we identify a test width that achieves 100% branch coverage, + +54 +00:03:23,220 --> 00:03:27,780 +the same test width will also achieve, necessarily, 100% statement coverage. + +55 +00:03:27,780 --> 00:03:31,290 +That's what happened for our example, and also what happens in general, + +56 +00:03:31,290 --> 00:03:35,660 +because branch coverage is a stronger criteria than statement coverage. + +57 +00:03:35,660 --> 00:03:39,670 +There is no way to cover all the branches without covering all the statements. + +58 +00:03:39,670 --> 00:03:43,480 +It is not true that any test results satisfies statement coverage will also + +59 +00:03:43,480 --> 00:03:47,040 +satisfy branch coverage. And, in fact, we just saw a counter example. + +60 +00:03:47,040 --> 00:03:50,569 +When we look at the printSum code. We had a test where there was achieving 100% + +61 +00:03:50,569 --> 00:03:53,910 +statement coverage and was not achieving 100% branch coverage. Therefore, + +62 +00:03:53,910 --> 00:03:58,301 +in this case we have a substantial relation in this direction. Branch coverage, + +63 +00:03:58,301 --> 00:04:02,860 +subsumes statement coverage. What it also means is that normally, or in general, + +64 +00:04:02,860 --> 00:04:06,910 +it is more expensive to achieve branch coverage than achieve statement coverage, + +65 +00:04:06,910 --> 00:04:09,490 +because achieving branch coverage requires the generation of + +66 +00:04:09,490 --> 00:04:13,770 +a larger number of test cases. So what this relation means is that + +67 +00:04:13,770 --> 00:04:17,779 +branch coverage is stronger than statement coverage but also more expensive. diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/13 - Condition Coverage - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/13 - Condition Coverage - lang_en_vs4.srt new file mode 100644 index 0000000..bba72fc --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/13 - Condition Coverage - lang_en_vs4.srt @@ -0,0 +1,191 @@ +1 +00:00:00,470 --> 00:00:03,046 +What I'm going to do next is to introduce a few additional + +2 +00:00:03,046 --> 00:00:06,350 +coverage criteria using a slightly more complex example, but still a + +3 +00:00:06,350 --> 00:00:09,370 +pretty simple one. What I'm showing here is a program that + +4 +00:00:09,370 --> 00:00:12,145 +reads two real numbers, x and y. And then, if x + +5 +00:00:12,145 --> 00:00:15,148 +is equal to 0 or y is greater than 0, it + +6 +00:00:15,148 --> 00:00:19,360 +computes y as y divided by x. Otherwise, it computes x + +7 +00:00:19,360 --> 00:00:22,110 +as y plus 2, then it writes the value of x, + +8 +00:00:22,110 --> 00:00:25,730 +the value of y, and it terminates. Let's also introduce a CFG + +9 +00:00:25,730 --> 00:00:29,160 +for the program. As you can see, the CFG represents the statements + +10 +00:00:29,160 --> 00:00:31,900 +in the code and their control flow. And in this case, I made + +11 +00:00:31,900 --> 00:00:35,800 +explicit over the branches what are the conditions under which those branches + +12 +00:00:35,800 --> 00:00:38,530 +are taken to make it simpler to look at the example. Let's assume + +13 +00:00:38,530 --> 00:00:41,280 +that we have two tests for this code that are shown here. + +14 +00:00:41,280 --> 00:00:44,286 +For the first one, the inputs are 5 and 5. For the second + +15 +00:00:44,286 --> 00:00:47,610 +one, 5 and minus 5. If we consider branch coverage for this code + +16 +00:00:47,610 --> 00:00:50,990 +and we consider the two test cases, for the first one this condition + +17 +00:00:50,990 --> 00:00:53,440 +is true. Because x is not equal to 0 but y + +18 +00:00:53,440 --> 00:00:56,660 +is greater than 0. And therefore, we will follow this tree branch. + +19 +00:00:56,660 --> 00:00:59,640 +For the second one, the condition is false. Because x is not + +20 +00:00:59,640 --> 00:01:03,200 +equal to 0 and y is not greater than 0. Therefore, the + +21 +00:01:03,200 --> 00:01:05,990 +negation of it is true and we will follow this branch. In + +22 +00:01:05,990 --> 00:01:09,530 +other words, these two test cases achieve 100% branch coverage on this + +23 +00:01:09,530 --> 00:01:12,120 +code. If we look at the code though, we can see that + +24 +00:01:12,120 --> 00:01:15,879 +there is the possibility of making this code fail. Consider this statement, + +25 +00:01:15,879 --> 00:01:18,147 +if x is equal to 0, we could have a division + +26 +00:01:18,147 --> 00:01:21,710 +by 0. However, these two test cases, despite the fact that + +27 +00:01:21,710 --> 00:01:25,008 +they achieved 100% branch coverage, will not rebuild this problem. So + +28 +00:01:25,008 --> 00:01:27,564 +how can we be more thorough? I'll let you think about it + +29 +00:01:27,564 --> 00:01:29,964 +for a second, so think about how can we test more + +30 +00:01:29,964 --> 00:01:33,260 +thoroughly, in a more complete way, this code. So, in a way + +31 +00:01:33,260 --> 00:01:37,220 +that goes beyond branch coverage. And the answer is that we + +32 +00:01:37,220 --> 00:01:41,250 +can make each condition true and false. Instead of just considering the + +33 +00:01:41,250 --> 00:01:44,570 +whole predicate here. And that's exactly what is required by + +34 +00:01:44,570 --> 00:01:47,480 +the next criteria that we're going to consider which is condition + +35 +00:01:47,480 --> 00:01:49,880 +coverage. We're going to define it as usual in terms of + +36 +00:01:49,880 --> 00:01:53,070 +test requirements and coverage measure. In this case, the test + +37 +00:01:53,070 --> 00:01:57,540 +requirements for condition coverage are the individual conditions in the + +38 +00:01:57,540 --> 00:02:00,510 +program. So we want each condition in the program to + +39 +00:02:00,510 --> 00:02:03,900 +be both true and false first time execution. So the + +40 +00:02:03,900 --> 00:02:06,420 +way in which we can measure that is by measuring the + +41 +00:02:06,420 --> 00:02:09,150 +number of conditions that were both true and false + +42 +00:02:09,150 --> 00:02:11,580 +when we executed our tests over the total number + +43 +00:02:11,580 --> 00:02:14,180 +of conditions. And that gives us the percentage of + +44 +00:02:14,180 --> 00:02:17,270 +coverage that we achieved for condition coverage. Again, if you + +45 +00:02:17,270 --> 00:02:18,638 +want to look at this criteria in the form + +46 +00:02:18,638 --> 00:02:21,245 +of a question. The question would be, has each boolean + +47 +00:02:21,245 --> 00:02:25,480 +sub-expression, which means every condition in every predicate, evaluated + +48 +00:02:25,480 --> 00:02:28,010 +both to true and false when we run our tests. diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/14 - Subsumption Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/14 - Subsumption Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..de78093 --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/14 - Subsumption Quiz - lang_en_vs4.srt @@ -0,0 +1,31 @@ +1 +00:00:00,080 --> 00:00:02,220 +So now that we introduced an additional criterion, + +2 +00:00:02,220 --> 00:00:04,290 +let's have a quiz to see whether everybody + +3 +00:00:04,290 --> 00:00:06,410 +understood the concept of subsumption. We know that + +4 +00:00:06,410 --> 00:00:09,490 +branch coverage subsumes statement coverage, but what about condition + +5 +00:00:09,490 --> 00:00:12,230 +coverage? Does it subsume branch coverage? Is it + +6 +00:00:12,230 --> 00:00:13,720 +the case that all of the test which + +7 +00:00:13,720 --> 00:00:16,980 +satisfy condition coverage will also satisfy branch coverage? + +8 +00:00:16,980 --> 00:00:19,160 +Think about it, and answer either yes or no. diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/15 - Subsumption Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/15 - Subsumption Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..87140c9 --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/15 - Subsumption Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,7 @@ +1 +00:00:00,170 --> 00:00:02,475 +In this case, the answer is no, and I'm + +2 +00:00:02,475 --> 00:00:04,650 +going to show you an example of this in a minute. diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/16 - Branch and Condition Coverage - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/16 - Branch and Condition Coverage - lang_en_vs4.srt new file mode 100644 index 0000000..143a534 --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/16 - Branch and Condition Coverage - lang_en_vs4.srt @@ -0,0 +1,143 @@ +1 +00:00:00,052 --> 00:00:03,407 +Let's go back to our test criteria subsumption representation, where + +2 +00:00:03,407 --> 00:00:06,770 +we already had branch coverage and statement coverage. In this case, + +3 +00:00:06,770 --> 00:00:09,350 +if we want to add condition coverage to this page, we + +4 +00:00:09,350 --> 00:00:12,050 +have to put it here on this side, with no relationship + +5 +00:00:12,050 --> 00:00:15,830 +of subsumption with either branch coverage or statement coverage, which + +6 +00:00:15,830 --> 00:00:19,270 +means that the criteria are not comparable. So now let's consider + +7 +00:00:19,270 --> 00:00:22,108 +again our last example, and let's use a different test + +8 +00:00:22,108 --> 00:00:25,060 +with this time. We still have two tests, but the first + +9 +00:00:25,060 --> 00:00:27,575 +one has x is equal to 0 and y is equal to minus + +10 +00:00:27,575 --> 00:00:30,370 +5. And the second one, x is equal to 5 and y is + +11 +00:00:30,370 --> 00:00:33,350 +equal to 5 as well. Let's see what happens in terms of condition + +12 +00:00:33,350 --> 00:00:36,740 +coverage, when we run these tests. If we look at the first condition, x + +13 +00:00:36,740 --> 00:00:39,820 +is equal to 0. It is both true, for the first test case, + +14 +00:00:39,820 --> 00:00:43,240 +and false for the second one. As for the second condition, y greater + +15 +00:00:43,240 --> 00:00:45,800 +than 0, it is false for the first test case and true for + +16 +00:00:45,800 --> 00:00:47,770 +the second one. Therefore we've achieved a + +17 +00:00:47,770 --> 00:00:50,400 +100% condition coverage with these two tests. + +18 +00:00:50,400 --> 00:00:54,020 +But what about branch coverage? If we consider the whole predicate, + +19 +00:00:54,020 --> 00:00:56,620 +instead of just the individual conditions, let's see what happens for the + +20 +00:00:56,620 --> 00:00:59,090 +two test cases. If we look at the first one, because + +21 +00:00:59,090 --> 00:01:02,200 +x is equal to 0, the overall predicate is true. As for + +22 +00:01:02,200 --> 00:01:05,750 +the second one, because the second condition is true, the overall + +23 +00:01:05,750 --> 00:01:09,110 +predicate is true. In other words, despite the fact that we're exercising + +24 +00:01:09,110 --> 00:01:12,520 +all the possible values for the two conditions, the overall predicate is + +25 +00:01:12,520 --> 00:01:16,540 +always true. And therefore, we're covering only one of the two branches. + +26 +00:01:16,540 --> 00:01:19,591 +So our coverage will be 50%. This is the reason + +27 +00:01:19,591 --> 00:01:22,231 +why normally the two criteria that we just saw, decision + +28 +00:01:22,231 --> 00:01:26,205 +coverage, and condition coverage are considered together. And the resulting + +29 +00:01:26,205 --> 00:01:30,320 +criterion is called branch and condition coverage, or also decision + +30 +00:01:30,320 --> 00:01:33,030 +and condition coverage. At this point the test requirements and + +31 +00:01:33,030 --> 00:01:35,590 +the coverage measure should be pretty straight forward, because they're + +32 +00:01:35,590 --> 00:01:38,120 +just considering the two criteria together. As far as the + +33 +00:01:38,120 --> 00:01:39,960 +requirements are concerned, they include + +34 +00:01:39,960 --> 00:01:41,880 +all the branches and individual conditions + +35 +00:01:41,880 --> 00:01:44,580 +in the program. Where as the coverage measure is computed + +36 +00:01:44,580 --> 00:01:49,180 +considering both coverage measures, both branch coverage and condition coverage. diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/17 - Subsumption Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/17 - Subsumption Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..9d99495 --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/17 - Subsumption Quiz - lang_en_vs4.srt @@ -0,0 +1,15 @@ +1 +00:00:00,100 --> 00:00:02,810 +Let's have another quick quiz about Subsumption. If we + +2 +00:00:02,810 --> 00:00:06,720 +consider Branch and Condition Coverage, does it subsume Branch Coverage, + +3 +00:00:06,720 --> 00:00:09,512 +and therefore Statement Coverage? Or in other words, does branch + +4 +00:00:09,512 --> 00:00:12,750 +and condition coverage imply branch coverage? Answer yes, or no. diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/18 - Subsumption Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/18 - Subsumption Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..c836f04 --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/18 - Subsumption Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,19 @@ +1 +00:00:00,150 --> 00:00:01,880 +In this case it should be clear that the + +2 +00:00:01,880 --> 00:00:05,640 +answer is yes, because branch and condition coverage actually includes + +3 +00:00:05,640 --> 00:00:08,580 +branch coverage. Therefore, by definition, any test rate that + +4 +00:00:08,580 --> 00:00:10,505 +satisfies branch and condition coverage + +5 +00:00:10,505 --> 00:00:12,664 +will necessarily satisfy branch coverage. diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/19 - Test Criteria Subsumption - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/19 - Test Criteria Subsumption - lang_en_vs4.srt new file mode 100644 index 0000000..f40ccdf --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/19 - Test Criteria Subsumption - lang_en_vs4.srt @@ -0,0 +1,47 @@ +1 +00:00:00,280 --> 00:00:03,400 +So we can now update our test criteria subsumption. We start + +2 +00:00:03,400 --> 00:00:06,700 +from this situation in which there are no relationship between condition + +3 +00:00:06,700 --> 00:00:09,650 +coverage, branch coverage and statement coverage. And when we add branch + +4 +00:00:09,650 --> 00:00:12,160 +and condition coverage, we can mark the fact that branch and + +5 +00:00:12,160 --> 00:00:14,470 +condition coverage subsumes branch coverage + +6 +00:00:14,470 --> 00:00:16,370 +and also subsumes condition coverage, for + +7 +00:00:16,370 --> 00:00:19,660 +the same reason. Therefore, this is a stronger criterion than both + +8 +00:00:19,660 --> 00:00:23,100 +branch coverage and condition coverage, and of course indirectly also soft + +9 +00:00:23,100 --> 00:00:25,330 +statement coverage. So once more, to make sure we are all + +10 +00:00:25,330 --> 00:00:29,255 +on the same page, if I develop a test rate that satisfies branch and condition + +11 +00:00:29,255 --> 00:00:31,380 +coverage, the same test will satisfy also + +12 +00:00:31,380 --> 00:00:35,210 +branch coverage, statement coverage and condition coverage, necessarily. diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/2 - Overview - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/2 - Overview - lang_en_vs4.srt new file mode 100644 index 0000000..c032d40 --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/2 - Overview - lang_en_vs4.srt @@ -0,0 +1,167 @@ +1 +00:00:00,420 --> 00:00:03,860 +In the last lesson, we talked about black-box testing or functional testing, + +2 +00:00:03,860 --> 00:00:06,110 +which is the kind of testing that you perform when you just + +3 +00:00:06,110 --> 00:00:09,860 +look at the description of the software. Today we're going to cover white-box + +4 +00:00:09,860 --> 00:00:12,490 +testing, which is the kind of testing that we perform when we + +5 +00:00:12,490 --> 00:00:15,800 +open up the box. We look inside the program, and we actually + +6 +00:00:15,800 --> 00:00:19,490 +test it based on its code. And there is one basic assumption + +7 +00:00:19,490 --> 00:00:22,320 +behind the idea of white-box testing, which is a very intuitive one, + +8 +00:00:22,320 --> 00:00:26,080 +and the assumption is that executing the faulty statement is a necessary + +9 +00:00:26,080 --> 00:00:29,380 +condition for revealing a fault. In other words, if there is + +10 +00:00:29,380 --> 00:00:31,690 +a bug in the program there is no way were going to be + +11 +00:00:31,690 --> 00:00:34,490 +able to find this bug or this fault, if we don't execute + +12 +00:00:34,490 --> 00:00:37,110 +the statement that contains it. Which makes a lot of sense. As + +13 +00:00:37,110 --> 00:00:40,240 +we did for black-box testing, we're going to start by summarizing what + +14 +00:00:40,240 --> 00:00:43,650 +are the main advantages of white-box testing. The main advantage is that + +15 +00:00:43,650 --> 00:00:48,050 +it's based on the code, and as such, the quality of white-box + +16 +00:00:48,050 --> 00:00:51,760 +testing can be measured objectively. And what I mean here by objectively + +17 +00:00:51,760 --> 00:00:54,390 +is that if you think about black-box testing In many + +18 +00:00:54,390 --> 00:00:57,630 +cases, there were subjective decisions, there were had to be made + +19 +00:00:57,630 --> 00:01:00,830 +in order to define tests in a black-box fashion. In the + +20 +00:01:00,830 --> 00:01:03,990 +case of white-box testing, because everything is based on the quota, + +21 +00:01:03,990 --> 00:01:07,965 +we don't have to make such subjective decisions. And similarly, because + +22 +00:01:07,965 --> 00:01:10,680 +white-box testing is based on the code, it can be measured + +23 +00:01:10,680 --> 00:01:14,250 +automatically. So we can build tools and actually there are tools, + +24 +00:01:14,250 --> 00:01:16,860 +and there's plenty of tools, that can be measured, the level + +25 +00:01:16,860 --> 00:01:19,670 +of white-box testing can be achieved in a fully automated way. + +26 +00:01:19,670 --> 00:01:21,620 +And we're going to see some of them in the course of the + +27 +00:01:21,620 --> 00:01:24,600 +class. Another advantage of white-box testing is that it can be + +28 +00:01:24,600 --> 00:01:27,700 +used to compare test suites. So if you have two alternative sets + +29 +00:01:27,700 --> 00:01:30,270 +of tests that you can use to assess the quality of + +30 +00:01:30,270 --> 00:01:34,360 +your software, white-box testing techniques can tell you which one of these + +31 +00:01:34,360 --> 00:01:37,580 +two test suites is likely to be more effective in testing + +32 +00:01:37,580 --> 00:01:42,350 +your code. And finally, white-box testing allows for covering the coded behavior + +33 +00:01:42,350 --> 00:01:44,470 +of the software. What that means is that if there is + +34 +00:01:44,470 --> 00:01:47,680 +some mistake in the code and is not obvious by looking at + +35 +00:01:47,680 --> 00:01:50,300 +the specification of the code, white box testing might be able + +36 +00:01:50,300 --> 00:01:53,330 +to catch it, because it tries to exercise the code. There's many + +37 +00:01:53,330 --> 00:01:56,430 +different kinds of white box testing, there are control flow based + +38 +00:01:56,430 --> 00:02:00,550 +techniques, data flow based techniques, and fault based techniques. And for each + +39 +00:02:00,550 --> 00:02:04,030 +one of these family of techniques there are many variations. So + +40 +00:02:04,030 --> 00:02:07,450 +this field is very, very broad. In this lesson we will talk + +41 +00:02:07,450 --> 00:02:09,110 +about white-box testing by focusing + +42 +00:02:09,110 --> 00:02:11,910 +mainly on control-flow based testing techniques. diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/20 - B&C Coverage Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/20 - B&C Coverage Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..6f5c9a1 --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/20 - B&C Coverage Quiz - lang_en_vs4.srt @@ -0,0 +1,35 @@ +1 +00:00:00,130 --> 00:00:02,969 +So let's have another quiz using the example that we just + +2 +00:00:02,969 --> 00:00:06,660 +used. This one is about achieving 100% branch and condition coverage. So + +3 +00:00:06,660 --> 00:00:08,850 +let me bring back the two tests cases that we just saw, + +4 +00:00:08,850 --> 00:00:11,420 +and as we saw a few minutes ago, these tests cases do + +5 +00:00:11,420 --> 00:00:15,540 +not achieve 100% branch and condition coverage despite the fact that they + +6 +00:00:15,540 --> 00:00:19,430 +achieve 100% condition coverage. So both conditions are both true and false, + +7 +00:00:19,430 --> 00:00:21,820 +for these test cases. So what I want you to do is + +8 +00:00:21,820 --> 00:00:25,630 +to add a test case, to achieve 100% branch and condition coverages. + +9 +00:00:25,630 --> 00:00:29,740 +So specify the test case by writing here the value for x, and the value for y. diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/21 - B&C Coverage Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/21 - B&C Coverage Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..2b6fe4b --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/21 - B&C Coverage Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,67 @@ +1 +00:00:00,190 --> 00:00:03,010 +Obviously there are many possible tests that we can use to + +2 +00:00:03,010 --> 00:00:05,910 +reach 100% branch and condition coverage. So I'm just going to show a + +3 +00:00:05,910 --> 00:00:08,740 +possible one, which is x equal to 3 and y is + +4 +00:00:08,740 --> 00:00:11,410 +equal to negative 2. If we specify this as case, you can + +5 +00:00:11,410 --> 00:00:14,900 +see that the overall condition is false, because neither x is + +6 +00:00:14,900 --> 00:00:17,990 +equal to 0 nor y is greater than 0. Therefore we will + +7 +00:00:17,990 --> 00:00:22,420 +follow the false, false branch, and achieve 100% branch and condition coverage + +8 +00:00:22,420 --> 00:00:25,400 +for this code. And we might require to be even more thorough, + +9 +00:00:25,400 --> 00:00:28,690 +that all the combinations of our conditions inside each + +10 +00:00:28,690 --> 00:00:31,790 +decision, inside each predicate, are tested. Which is what is + +11 +00:00:31,790 --> 00:00:36,010 +called, multiple condition coverage. But because of the way + +12 +00:00:36,010 --> 00:00:39,050 +this criterion is defined, it is combinatorial, becuse you have + +13 +00:00:39,050 --> 00:00:42,220 +to consider all the possible combinations of conditions. And + +14 +00:00:42,220 --> 00:00:45,210 +therefore it's extremely expensive, to the point of being impractical. + +15 +00:00:45,210 --> 00:00:47,610 +So instead of defining that criterion, we're going to find + +16 +00:00:47,610 --> 00:00:51,000 +another one which finds a good trade off between thoroughness + +17 +00:00:51,000 --> 00:00:52,815 +of the tests and their cost. diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/22 - MC DC Coverage - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/22 - MC DC Coverage - lang_en_vs4.srt new file mode 100644 index 0000000..1a971f9 --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/22 - MC DC Coverage - lang_en_vs4.srt @@ -0,0 +1,307 @@ +1 +00:00:00,120 --> 00:00:03,880 +And this criterion is called Modified Condition/Decision Coverage, + +2 +00:00:03,880 --> 00:00:07,750 +also called MC/DC. This criterion is very important because + +3 +00:00:07,750 --> 00:00:10,330 +it is often required for safety critical applications. + +4 +00:00:10,330 --> 00:00:13,920 +For example, the FAA, the Federal Aviation Administration, requires + +5 +00:00:13,920 --> 00:00:15,980 +for all the software that runs on commercial + +6 +00:00:15,980 --> 00:00:19,420 +airplanes to be tested according to the Modified Condition/Decision + +7 +00:00:19,420 --> 00:00:22,015 +Coverage. So what is the key idea behind the + +8 +00:00:22,015 --> 00:00:25,270 +MC/DC criterion? It is to test only the important + +9 +00:00:25,270 --> 00:00:28,710 +combinations of conditions instead of all of them, and limit + +10 +00:00:28,710 --> 00:00:32,189 +the testing cost by excluding the other combinations. And the way + +11 +00:00:32,189 --> 00:00:34,950 +in which it works is by extending branch and decision + +12 +00:00:34,950 --> 00:00:38,860 +coverage with the requirement that each condition should affect the decision + +13 +00:00:38,860 --> 00:00:41,940 +outcome independently. So let's see what this means with an + +14 +00:00:41,940 --> 00:00:45,030 +example that will also show you how you can reduce the + +15 +00:00:45,030 --> 00:00:46,940 +number of combinations in this way. I am going to + +16 +00:00:46,940 --> 00:00:50,460 +show you an example of how MC/DC works using this predicate + +17 +00:00:50,460 --> 00:00:53,870 +which consists of three conditions. a, b, and c, which are all + +18 +00:00:53,870 --> 00:00:57,070 +in and, so the overall predicate is a and b and c. + +19 +00:00:57,070 --> 00:00:58,980 +The first thing I'm going to do is to show you how + +20 +00:00:58,980 --> 00:01:03,370 +many test cases we will need to satisfy the multiple condition coverage + +21 +00:01:03,370 --> 00:01:06,440 +for this simple predicate. Which means, how many test cases we will + +22 +00:01:06,440 --> 00:01:09,780 +need to test all the possible combinations of true and false values + +23 +00:01:09,780 --> 00:01:12,740 +for these conditions. So I'm going to populate this table. And as you + +24 +00:01:12,740 --> 00:01:15,870 +can see, at the end we have eight test cases. Each test case + +25 +00:01:15,870 --> 00:01:18,650 +tests a different combination of values for a, b, and c. + +26 +00:01:18,650 --> 00:01:21,200 +I'm also showing, for each test case, the outcome of the overall + +27 +00:01:21,200 --> 00:01:23,930 +predicate. So, for example, if we look at the first one, the + +28 +00:01:23,930 --> 00:01:27,200 +first test case, will be such that a is true, b is + +29 +00:01:27,200 --> 00:01:30,210 +true, and c is true. And therefore, the overall outcome of + +30 +00:01:30,210 --> 00:01:34,360 +the predicate is true. Now lets consider the first condition, a. As + +31 +00:01:34,360 --> 00:01:36,300 +I said a minute ago, what we want to test are the + +32 +00:01:36,300 --> 00:01:39,160 +important combination. Which are the comibatinos + +33 +00:01:39,160 --> 00:01:41,930 +in which a single condition independently + +34 +00:01:41,930 --> 00:01:45,610 +effects the outcome of the overall predicate. So if we consider a + +35 +00:01:45,610 --> 00:01:48,490 +and we look at this possible set of this cases. Let's try to + +36 +00:01:48,490 --> 00:01:51,850 +find two test cases such that the only difference between the two + +37 +00:01:51,850 --> 00:01:54,960 +test cases is the value of a, and the overall outcome of the + +38 +00:01:54,960 --> 00:01:57,790 +predicate is different. If we look at the table, we can see + +39 +00:01:57,790 --> 00:02:00,920 +that this is true for test cases one and five. If we look + +40 +00:02:00,920 --> 00:02:04,030 +at these two cases, we can see that the overall of the predicate + +41 +00:02:04,030 --> 00:02:07,420 +in the two cases is true and false, and that the only difference + +42 +00:02:07,420 --> 00:02:10,720 +between the value of the conditions in the value of a. So + +43 +00:02:10,720 --> 00:02:13,990 +these test cases satisfy exactly what we wanted. There are two test + +44 +00:02:13,990 --> 00:02:18,270 +cases in which the value of a independently decides the overall value + +45 +00:02:18,270 --> 00:02:21,380 +of the predicate. What we do, therefore, is to add these first + +46 +00:02:21,380 --> 00:02:24,740 +two test cases to our set of tests down here. Now let's + +47 +00:02:24,740 --> 00:02:27,520 +focus on b and let's try to find two test cases such + +48 +00:02:27,520 --> 00:02:30,280 +that the value of b is the only value that changes between + +49 +00:02:30,280 --> 00:02:32,450 +the two test cases, but the overall value of the predicate is + +50 +00:02:32,450 --> 00:02:34,980 +different, the same thing we did for a. And in this case, + +51 +00:02:34,980 --> 00:02:37,610 +we can see that if we select test case number one, and test + +52 +00:02:37,610 --> 00:02:40,420 +case number three, we have exactly that situation. b is true in the + +53 +00:02:40,420 --> 00:02:44,250 +first case, false in the second one, a and c don't change, but + +54 +00:02:44,250 --> 00:02:46,830 +the overall value of the predicate changes. And now you can notice + +55 +00:02:46,830 --> 00:02:50,720 +something else. That even though we selected two test cases, tested two values, + +56 +00:02:50,720 --> 00:02:53,950 +one we already had. So, we only need three test cases overall to + +57 +00:02:53,950 --> 00:02:57,730 +test a and b according to MC/DC. Now, let's look at our last + +58 +00:02:57,730 --> 00:03:00,510 +condition, c. At this point, we know the game, so we + +59 +00:03:00,510 --> 00:03:02,780 +just have to look for two test cases that satisfy our + +60 +00:03:02,780 --> 00:03:06,380 +requirements. And in this case, one and two are suitable candidates. + +61 +00:03:06,380 --> 00:03:08,820 +And once more, because we already have one, we just have to + +62 +00:03:08,820 --> 00:03:11,070 +add two to our list. So as you can see from + +63 +00:03:11,070 --> 00:03:14,730 +this example, we went from having eight test cases needed to cover + +64 +00:03:14,730 --> 00:03:18,600 +all the possible combinations of conditions to only four test cases + +65 +00:03:18,600 --> 00:03:22,880 +to satisfy the MC/DC criteria. So let's see where MC/DC stands in + +66 +00:03:22,880 --> 00:03:25,510 +our substantion hierarchy. This is what we had so far + +67 +00:03:25,510 --> 00:03:28,430 +in the hierarchy and this is where the MC/DC criterion will + +68 +00:03:28,430 --> 00:03:31,930 +stand. MC/DC criterion is stronger than branch and condition coverage. + +69 +00:03:31,930 --> 00:03:35,210 +Why? Because it requires every single condition to be true and + +70 +00:03:35,210 --> 00:03:38,400 +false. And therefore, this section was a condition coverage criteria. + +71 +00:03:38,400 --> 00:03:41,610 +And it also requires every predicate to be true and false + +72 +00:03:41,610 --> 00:03:44,425 +and therefore, this section is branch coverage. And in addition, + +73 +00:03:44,425 --> 00:03:47,790 +it's got the additional requirements that the true and false values, + +74 +00:03:47,790 --> 00:03:50,330 +all the conditions have to also decide the overall + +75 +00:03:50,330 --> 00:03:53,190 +value of the predicate. So it's stronger. Which is more + +76 +00:03:53,190 --> 00:03:56,130 +thorough than branch and condition coverage and, as usual, + +77 +00:03:56,130 --> 00:03:59,380 +also stronger than branch coverage, statement coverage, and condition coverage. diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/23 - Other Criteria - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/23 - Other Criteria - lang_en_vs4.srt new file mode 100644 index 0000000..27bf0fe --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/23 - Other Criteria - lang_en_vs4.srt @@ -0,0 +1,275 @@ +1 +00:00:00,120 --> 00:00:02,900 +As I mentioned at the beginning of the class, there are many, many, + +2 +00:00:02,900 --> 00:00:06,150 +many, white box criteria. And we're not going to have time to cover them + +3 +00:00:06,150 --> 00:00:08,000 +all. So what I like to do now is just to give you + +4 +00:00:08,000 --> 00:00:11,290 +the flavor, of some other criteria by just mentioning them, and saying a + +5 +00:00:11,290 --> 00:00:13,740 +couple of things, about the way they work. And the first one I + +6 +00:00:13,740 --> 00:00:15,370 +want to mention is path coverage. And + +7 +00:00:15,370 --> 00:00:17,800 +in path coverage, the test requirements are + +8 +00:00:17,800 --> 00:00:21,220 +all the paths in the program. So what that means is that to + +9 +00:00:21,220 --> 00:00:25,250 +satisfy this criteria, we need to generate enough test cases such that all + +10 +00:00:25,250 --> 00:00:27,230 +the paths in my program are covered. As you can + +11 +00:00:27,230 --> 00:00:31,970 +imagine this is incredibly expensive because any nontrivial program has got + +12 +00:00:31,970 --> 00:00:34,280 +a virtual infinite number of paths and therefore we will + +13 +00:00:34,280 --> 00:00:36,910 +need a virtual infinite number of test cases to satisfy the + +14 +00:00:36,910 --> 00:00:39,950 +path coverage criteria. Another family of criteria I want to mention + +15 +00:00:39,950 --> 00:00:43,970 +are data-flow coverage criteria and in data-flow coverage criteria, the focus + +16 +00:00:43,970 --> 00:00:47,480 +shifts from the coverage of individual elements in the code to + +17 +00:00:47,480 --> 00:00:50,320 +the coverage of pairs of elements. And in particular the coverage + +18 +00:00:50,320 --> 00:00:53,770 +of Statements, in which the content of some memory locations + +19 +00:00:53,770 --> 00:00:56,920 +modified, and statements in which the content of the same + +20 +00:00:56,920 --> 00:00:59,860 +memory location is used. So in this way, our test + +21 +00:00:59,860 --> 00:01:03,030 +will exercise the assignments of values to memory, and the + +22 +00:01:03,030 --> 00:01:06,020 +usage of those assignments,. Finally, I want to mention mutation + +23 +00:01:06,020 --> 00:01:09,150 +coverage. And this is a fairly different and new idea, + +24 +00:01:09,150 --> 00:01:11,910 +so the key concept in mutation coverage is that we + +25 +00:01:11,910 --> 00:01:16,156 +want to evaluate the goodness of our test by modifying the code. + +26 +00:01:16,156 --> 00:01:18,704 +For example here in this small I'm, I'm showing that I might + +27 +00:01:18,704 --> 00:01:21,820 +change it. An if statement from K greater than 9, to K + +28 +00:01:21,820 --> 00:01:24,310 +greater than or equal to 9. And the reason why I want to + +29 +00:01:24,310 --> 00:01:27,750 +do that, is that if I generate enough mutants, enough variation of + +30 +00:01:27,750 --> 00:01:30,340 +my program, then I can use them to assess how good are + +31 +00:01:30,340 --> 00:01:34,330 +my tests at distinguishing the original program and the mutants. And because + +32 +00:01:34,330 --> 00:01:37,430 +I'm changing the code based on the way I expect to introduce + +33 +00:01:37,430 --> 00:01:41,370 +errors in the code, the more my test can identify mutants, the better + +34 +00:01:41,370 --> 00:01:44,140 +they are at identifying real faults. This is a very high + +35 +00:01:44,140 --> 00:01:46,470 +level [UNKNOWN], but just to give you the intuition and the idea + +36 +00:01:46,470 --> 00:01:50,210 +behind these criteria, and I'm going to provide as usual, additional pointers + +37 +00:01:50,210 --> 00:01:52,930 +to go in more depth on these topics in the notes of + +38 +00:01:52,930 --> 00:01:55,170 +the class. So now, let's go back to our test criteria + +39 +00:01:55,170 --> 00:01:59,310 +subsumption hierarchy, and see how all of these criteria fit together in + +40 +00:01:59,310 --> 00:02:02,663 +this context. Let me start with multiple condition coverage. As we saw, + +41 +00:02:02,663 --> 00:02:06,740 +MC/DC is sort of as [UNKNOWN] way of doing multiple condition coverage + +42 +00:02:06,740 --> 00:02:09,229 +in the sense that it doesn't consider all the combinations, + +43 +00:02:09,229 --> 00:02:11,460 +but only the ones that are more likely to matter. + +44 +00:02:11,460 --> 00:02:14,930 +And as such, MC/DC exercises a subset of the elements + +45 +00:02:14,930 --> 00:02:16,220 +of the multiple condition coverage + +46 +00:02:16,220 --> 00:02:18,760 +exercises. And therefore, multiple condition coverage + +47 +00:02:18,760 --> 00:02:22,060 +is more thorough than MC/DC and subsumption, and it's also + +48 +00:02:22,060 --> 00:02:26,300 +as we saw incredibly more expensive. Path coverage subsumes branch coverage, + +49 +00:02:26,300 --> 00:02:28,090 +because if I cover all of the paths in the + +50 +00:02:28,090 --> 00:02:32,140 +code, I necessarily cover all the branches. However, it doesn't subsume + +51 +00:02:32,140 --> 00:02:34,130 +multiple condition coverage, MC/CD, or + +52 +00:02:34,130 --> 00:02:35,910 +branch and condition coverage. Because this + +53 +00:02:35,910 --> 00:02:38,590 +criteria, have additional requirements involving + +54 +00:02:38,590 --> 00:02:39,940 +the conditions of the predicate that + +55 +00:02:39,940 --> 00:02:42,730 +path coverage does not have. As for data-flow coverage criteria and + +56 +00:02:42,730 --> 00:02:45,010 +mutation coverage criteria, there really no + +57 +00:02:45,010 --> 00:02:46,860 +relation with the other criteria, because + +58 +00:02:46,860 --> 00:02:49,710 +they look at different aspects, of the code. So they're not + +59 +00:02:49,710 --> 00:02:52,220 +really comparable, and therefore we're just going to put them on the + +60 +00:02:52,220 --> 00:02:55,000 +side, without any relationship with the other ones. The reason why + +61 +00:02:55,000 --> 00:02:57,300 +I want to represent them all anyways is because I want to make + +62 +00:02:57,300 --> 00:02:59,950 +an important distinction between these different criteria. And + +63 +00:02:59,950 --> 00:03:02,690 +that's the distinction between practical criteria, which are + +64 +00:03:02,690 --> 00:03:05,490 +criteria that are actually not too expansive to + +65 +00:03:05,490 --> 00:03:08,790 +be used in real scenarios. And theoretical criteria, which + +66 +00:03:08,790 --> 00:03:11,590 +are criteria that are useful in theory from + +67 +00:03:11,590 --> 00:03:14,140 +the conceptual standpoint, but they're not really applicable + +68 +00:03:14,140 --> 00:03:16,540 +in practice because they're too expansive, because they + +69 +00:03:16,540 --> 00:03:19,460 +require basically too many test cases to be satisfied. diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/24 - Review Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/24 - Review Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..3f1d6ee --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/24 - Review Quiz - lang_en_vs4.srt @@ -0,0 +1,63 @@ +1 +00:00:00,160 --> 00:00:04,260 +White box testing, in general, and coverage criteria in particular, involve some + +2 +00:00:04,260 --> 00:00:07,550 +subtle concepts, so before I conclude this lesson, I want to have a + +3 +00:00:07,550 --> 00:00:10,960 +few more quizzes to make sure that we all understand these concepts. + +4 +00:00:10,960 --> 00:00:13,610 +The first one involves a very simple piece of code, a straight line + +5 +00:00:13,610 --> 00:00:16,540 +of code, three statements, in which we simply read an integer and + +6 +00:00:16,540 --> 00:00:20,180 +then prints 10 divided by the value of that integer minus 3. Now, + +7 +00:00:20,180 --> 00:00:22,250 +let's imagine that we have a test where there consists of three + +8 +00:00:22,250 --> 00:00:25,250 +test cases for this code, and what I'm showing in the test cases + +9 +00:00:25,250 --> 00:00:28,580 +is the input and the expected output. So for the first one, + +10 +00:00:28,580 --> 00:00:31,280 +the input is 1, and I expect the output to be minus 5. + +11 +00:00:31,280 --> 00:00:34,480 +For the second one, the input is minus 1, I'm expecting to + +12 +00:00:34,480 --> 00:00:37,120 +have 2.5. And for the third one, the input is 0, and I'm + +13 +00:00:37,120 --> 00:00:42,440 +expecting to have minus 3.3333 as the result. Now the first question + +14 +00:00:42,440 --> 00:00:45,180 +I want to ask, is if we considered this test suite, and we + +15 +00:00:45,180 --> 00:00:48,050 +run it on the code, does it achieve path coverage? And remember + +16 +00:00:48,050 --> 00:00:50,960 +that path coverage is one of the strongest coverage criteria that we saw. diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/25 - Review Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/25 - Review Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..19d1177 --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/25 - Review Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,7 @@ +1 +00:00:00,180 --> 00:00:04,040 +And the answer in this case is clearly yes. In fact, any input will really + +2 +00:00:04,040 --> 00:00:07,430 +achieve path coverage for this code because there is only one path in the code. diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/26 - Review Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/26 - Review Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..a07e712 --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/26 - Review Quiz - lang_en_vs4.srt @@ -0,0 +1,15 @@ +1 +00:00:00,108 --> 00:00:03,890 +But now want to ask a different question which is, does this test reveal + +2 +00:00:03,890 --> 00:00:07,760 +the fault at line three? Clearly, here there is a possible problem, because + +3 +00:00:07,760 --> 00:00:10,440 +if we pass the right input, we can have a division by zero. + +4 +00:00:10,440 --> 00:00:13,760 +Is that revealed if we run this test within the code? Yes or no? diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/27 - Review Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/27 - Review Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..9945694 --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/27 - Review Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,55 @@ +1 +00:00:00,340 --> 00:00:03,581 +And the answer is no. So even path coverage's stronger criteria + +2 +00:00:03,581 --> 00:00:06,376 +that we saw is not enough to reveal this problem. And why + +3 +00:00:06,376 --> 00:00:08,526 +is that? So let me go back to a concept that + +4 +00:00:08,526 --> 00:00:12,491 +I mentioned in a previous lesson, the cost of exhaustive testing. Exhaustive + +5 +00:00:12,491 --> 00:00:15,236 +testing is really the only way in which we can exercise + +6 +00:00:15,236 --> 00:00:18,230 +all of the possible behaviors of a program. So we can say + +7 +00:00:18,230 --> 00:00:21,884 +even though it might sound like topology, that only exhaustive testing is + +8 +00:00:21,884 --> 00:00:25,710 +exhausted. All the coverage criteria that we saw are just process and + +9 +00:00:25,710 --> 00:00:30,900 +just approximation of a complete test. So test is a best effort kind + +10 +00:00:30,900 --> 00:00:33,180 +of activity. Coverage criteria help you assess + +11 +00:00:33,180 --> 00:00:35,430 +how well you tested but once more, + +12 +00:00:35,430 --> 00:00:40,060 +test can only reveal issues, can only reveal problems. You can never show the + +13 +00:00:40,060 --> 00:00:42,530 +absence of problems. And that's something is + +14 +00:00:42,530 --> 00:00:44,377 +important to remember when we do testing. diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/28 - Review Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/28 - Review Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..d6dd40a --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/28 - Review Quiz - lang_en_vs4.srt @@ -0,0 +1,31 @@ +1 +00:00:00,290 --> 00:00:03,220 +Now let's do another quiz considering a slightly different piece + +2 +00:00:03,220 --> 00:00:05,050 +of code. In this case we have five layers of + +3 +00:00:05,050 --> 00:00:08,684 +code. We have a variable i, a variable j. Variable + +4 +00:00:08,684 --> 00:00:11,620 +j is read from the input. And then based on + +5 +00:00:11,620 --> 00:00:14,500 +this predicate, we either print the value of i or + +6 +00:00:14,500 --> 00:00:16,850 +simply exit. And what I want to know from you is + +7 +00:00:16,850 --> 00:00:19,990 +whether you can create a test suite to achieve statement + +8 +00:00:19,990 --> 00:00:22,660 +coverage for this simple piece of code. Yes or no? diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/29 - Review Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/29 - Review Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..1e3228c --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/29 - Review Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,119 @@ +1 +00:00:00,230 --> 00:00:02,520 +And the answer in this case is no. And + +2 +00:00:02,520 --> 00:00:05,480 +the reason for this is because this code is + +3 +00:00:05,480 --> 00:00:08,950 +unreachable. This is dead code because no matter the + +4 +00:00:08,950 --> 00:00:12,560 +value of j, this condition will always be false because + +5 +00:00:12,560 --> 00:00:14,770 +i will always be 0. And notice that this + +6 +00:00:14,770 --> 00:00:17,670 +is a small example, but another important truth is + +7 +00:00:17,670 --> 00:00:22,520 +that any non-trivial program contains dead or unreachable code, + +8 +00:00:22,520 --> 00:00:25,610 +code that no matter how well we test our system, + +9 +00:00:25,610 --> 00:00:28,450 +we will never be able to exercise. Why is that? Various + +10 +00:00:28,450 --> 00:00:31,030 +reasons. For example, defensive programming or, + +11 +00:00:31,030 --> 00:00:33,600 +for example, developing for future releases. + +12 +00:00:33,600 --> 00:00:36,320 +So there might be pieces of code that are added, but they're + +13 +00:00:36,320 --> 00:00:39,380 +still not activated. They're still not invoked by any other part of + +14 +00:00:39,380 --> 00:00:41,970 +the code because of modifications to the code. There are some + +15 +00:00:41,970 --> 00:00:44,480 +parts that were executed before and in the new version of the + +16 +00:00:44,480 --> 00:00:47,915 +program, they are no longer exercised. They are no longer executable. But + +17 +00:00:47,915 --> 00:00:50,760 +they still remain in the code base. And this is a very, + +18 +00:00:50,760 --> 00:00:54,560 +very normal situation for this reason and many more. And this is + +19 +00:00:54,560 --> 00:00:56,790 +an important concept because this affects + +20 +00:00:56,790 --> 00:00:58,760 +the very meaning of coverage measures. If + +21 +00:00:58,760 --> 00:01:01,225 +there is some unreachable code, we will never be able to reach + +22 +00:01:01,225 --> 00:01:04,709 +100% code coverage. And in fact, if you remember, at the beginning of + +23 +00:01:04,709 --> 00:01:07,380 +the lesson, we discussed this concept and asked you why you think + +24 +00:01:07,380 --> 00:01:10,470 +that, in the industry, the target for coverage is not 100% but less + +25 +00:01:10,470 --> 00:01:12,850 +that that. And that's the answer, to account for the fact that there + +26 +00:01:12,850 --> 00:01:15,890 +are infeasibility problems that I have to take into account when I test + +27 +00:01:15,890 --> 00:01:19,920 +the code, infeasible paths, unexecutable statements, conditions that can never + +28 +00:01:19,920 --> 00:01:22,780 +be true, and so on. So most criteria, if not + +29 +00:01:22,780 --> 00:01:24,620 +all, are affected, and we need to take that into + +30 +00:01:24,620 --> 00:01:27,270 +account when we try to achieve a given coverage target. diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/3 - Coverage Criteria Intro - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/3 - Coverage Criteria Intro - lang_en_vs4.srt new file mode 100644 index 0000000..b1a38a7 --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/3 - Coverage Criteria Intro - lang_en_vs4.srt @@ -0,0 +1,171 @@ +1 +00:00:00,320 --> 00:00:04,059 +So let's start our lesson on white docs testing by considering again the + +2 +00:00:04,059 --> 00:00:07,470 +program PrintSum. If you remember, this is the same program that we used when + +3 +00:00:07,470 --> 00:00:10,300 +we were talking about black box testing. It's the program that takes two + +4 +00:00:10,300 --> 00:00:14,050 +integers, A and B, and produces, as a result, the sum of the two. + +5 +00:00:14,050 --> 00:00:16,570 +And when we were looking at this problem in the context of black + +6 +00:00:16,570 --> 00:00:17,760 +box testing, we did not look at + +7 +00:00:17,760 --> 00:00:19,700 +implementation. But that's exactly what we're going to + +8 +00:00:19,700 --> 00:00:22,090 +do now. So we're going to open the box and look at how the + +9 +00:00:22,090 --> 00:00:25,700 +code is implemented. And as you can see, the programmer was kind of creative. + +10 +00:00:25,700 --> 00:00:28,670 +Because instead of just adding the two numbers and printing them, he + +11 +00:00:28,670 --> 00:00:32,080 +or she also decided to print them in a specific color depending + +12 +00:00:32,080 --> 00:00:36,840 +on whether they were positive numbers or negative numbers. So positive results + +13 +00:00:36,840 --> 00:00:40,040 +are printed in red and negative results are printed in blue. And as + +14 +00:00:40,040 --> 00:00:41,970 +you can see by looking at the code we can see some + +15 +00:00:41,970 --> 00:00:45,150 +interesting cases that we might want to test. For instance you can + +16 +00:00:45,150 --> 00:00:48,190 +see that there are two decisions made here. So we might decide + +17 +00:00:48,190 --> 00:00:51,100 +that this is an interesting case and therefore we want to test it. + +18 +00:00:51,100 --> 00:00:53,770 +Similarly we might look at this other case and we might + +19 +00:00:53,770 --> 00:00:56,465 +also decide that this is another interesting case and therefore we + +20 +00:00:56,465 --> 00:00:58,970 +want to test this one as well. So let's discuss this + +21 +00:00:58,970 --> 00:01:01,480 +in a slightly more formal way by introducing the concept of + +22 +00:01:01,480 --> 00:01:05,110 +coverage criteria which are really the essence of why box testing. + +23 +00:01:05,110 --> 00:01:08,930 +First of all coverage criteria are defined in terms of test + +24 +00:01:08,930 --> 00:01:13,460 +requirements where test requirements are the elements, the entities in the + +25 +00:01:13,460 --> 00:01:16,250 +code that we need to exercise. That we need to execute + +26 +00:01:16,250 --> 00:01:18,690 +in order to satisfy the criteria. And we'll see plenty + +27 +00:01:18,690 --> 00:01:21,430 +of examples of that. And normally, when I apply a coverage + +28 +00:01:21,430 --> 00:01:24,810 +criterion, my result is a set of test specifications. And we + +29 +00:01:24,810 --> 00:01:26,540 +already saw test specifications. Those + +30 +00:01:26,540 --> 00:01:29,540 +are basically descriptions, specifications, of how + +31 +00:01:29,540 --> 00:01:32,786 +the tests should be in order to satisfy the requirements. And + +32 +00:01:32,786 --> 00:01:36,210 +they also result in actual test cases, which are instantiations of + +33 +00:01:36,210 --> 00:01:39,470 +the test specifications. And again this is exactly analogous to what + +34 +00:01:39,470 --> 00:01:41,830 +we saw when we were talking about the black box testing. + +35 +00:01:41,830 --> 00:01:43,960 +So let's see what this means by going back to our + +36 +00:01:43,960 --> 00:01:46,680 +example. A minute ago, we looked at the print sum code + +37 +00:01:46,680 --> 00:01:50,000 +and we identified two interesting cases for our code. And those + +38 +00:01:50,000 --> 00:01:53,430 +are exactly our test requirements. So we have a first test + +39 +00:01:53,430 --> 00:01:57,840 +requirement here, which is the execution of this particular statement and + +40 +00:01:57,840 --> 00:02:01,500 +a second requirement here and this one corresponds to the execution + +41 +00:02:01,500 --> 00:02:04,580 +of this other statement. So for this example there are two + +42 +00:02:04,580 --> 00:02:06,920 +things that we need to do in order to satisfy our + +43 +00:02:06,920 --> 00:02:10,100 +coverage requirements. Execute this statement and execute this statement. diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/30 - Summary - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/30 - Summary - lang_en_vs4.srt new file mode 100644 index 0000000..264491d --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/30 - Summary - lang_en_vs4.srt @@ -0,0 +1,127 @@ +1 +00:00:00,190 --> 00:00:02,800 +Now let me conclude the lesson by summarizing a few important + +2 +00:00:02,800 --> 00:00:06,840 +aspects of white-box testing. The first important aspect is that white-box + +3 +00:00:06,840 --> 00:00:09,770 +testing works on a formal model. The code itself are models + +4 +00:00:09,770 --> 00:00:12,430 +derived from the code. So when we do white-box testing, we + +5 +00:00:12,430 --> 00:00:15,160 +don't need to make subjective decision, for example, on the level + +6 +00:00:15,160 --> 00:00:18,890 +of obstruction of our models. Normally, we simply represent what's there. + +7 +00:00:18,890 --> 00:00:22,010 +And so what we will obtain are objective, results and objective + +8 +00:00:22,010 --> 00:00:25,400 +measures. As I also said at the beginning, coverage criteria allows + +9 +00:00:25,400 --> 00:00:28,790 +us to compare different test suites, different sets of tests, + +10 +00:00:28,790 --> 00:00:31,780 +because I can measure the coverage achieved by one test suite + +11 +00:00:31,780 --> 00:00:34,280 +and by the other, and then decide which one to use + +12 +00:00:34,280 --> 00:00:37,400 +based on this measure. And again, remember, these measures aren't perfect, + +13 +00:00:37,400 --> 00:00:40,700 +but they at least give you an objective number, an objective + +14 +00:00:40,700 --> 00:00:44,470 +measure of the likely effectiveness of your tests. So even though + +15 +00:00:44,470 --> 00:00:48,130 +achieving 100% coverage does not mean that you identify all the + +16 +00:00:48,130 --> 00:00:50,710 +problems in the code for sure. If your level of coverage + +17 +00:00:50,710 --> 00:00:53,700 +is 10%, for example, for stemen coverage. That means that + +18 +00:00:53,700 --> 00:00:57,360 +you haven't exercised 90% of your code, and therefore the trouble + +19 +00:00:57,360 --> 00:01:00,565 +is in a piece of software that is inadequately tested + +20 +00:01:00,565 --> 00:01:03,600 +and likely to be of inadequate quality. We also saw that + +21 +00:01:03,600 --> 00:01:07,370 +there are two broad classes of coverage criteria, practical criteria + +22 +00:01:07,370 --> 00:01:10,430 +that we can actually use, and theoretical criteria that are interesting + +23 +00:01:10,430 --> 00:01:13,410 +from a conceptual standpoint, but that they are totally impractical. + +24 +00:01:13,410 --> 00:01:16,170 +They are too expensive to be used on real world software. + +25 +00:01:16,170 --> 00:01:18,350 +And finally, as we also said at the beginning, + +26 +00:01:18,350 --> 00:01:20,820 +one of the great things about white box testing and + +27 +00:01:20,820 --> 00:01:23,910 +coverage criteria, is that they are fully automatable. There are + +28 +00:01:23,910 --> 00:01:27,380 +tools that can take your code, instrument it automatically. And + +29 +00:01:27,380 --> 00:01:29,050 +when you run your test cases, they will tell + +30 +00:01:29,050 --> 00:01:31,330 +you, what is the level of coverage that you achieve + +31 +00:01:31,330 --> 00:01:34,410 +with your test at no cost for you. So there's + +32 +00:01:34,410 --> 00:01:36,763 +really no reason not to measure coverage of your code. diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/4 - Coverage Criteria Intro Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/4 - Coverage Criteria Intro Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..2adce93 --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/4 - Coverage Criteria Intro Quiz - lang_en_vs4.srt @@ -0,0 +1,39 @@ +1 +00:00:00,620 --> 00:00:03,310 +Now let's see if we are all on the same page + +2 +00:00:03,310 --> 00:00:07,180 +on the concept of testing specifications, and we're going to do that through + +3 +00:00:07,180 --> 00:00:09,280 +a quiz. What I would like for you to do is to + +4 +00:00:09,280 --> 00:00:12,830 +tell me, what are some possible test specifications that will satisfy the + +5 +00:00:12,830 --> 00:00:15,380 +requirements that we just saw? And I want you to express this + +6 +00:00:15,380 --> 00:00:17,270 +specification in terms of constraints on + +7 +00:00:17,270 --> 00:00:19,166 +the inputs. Which means, what constraints + +8 +00:00:19,166 --> 00:00:23,130 +should the input satisfy in order for this statement to be executed, + +9 +00:00:23,130 --> 00:00:26,210 +and this statement to be executed, and you can write your answer + +10 +00:00:26,210 --> 00:00:27,510 +here in these two slots. diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/5 - Coverage Criteria Intro Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/5 - Coverage Criteria Intro Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..2a1ff16 --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/5 - Coverage Criteria Intro Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,47 @@ +1 +00:00:00,080 --> 00:00:02,560 +To satisfy our first requirements, we need to find an + +2 +00:00:02,560 --> 00:00:06,300 +input that causes the execution of this statement. Because this statement + +3 +00:00:06,300 --> 00:00:09,080 +is executed only when result is greater than zero, our + +4 +00:00:09,080 --> 00:00:12,815 +test requirement is that a plus b must be greater than + +5 +00:00:12,815 --> 00:00:16,219 +0. When this is satisfied, this statement is executed therefore + +6 +00:00:16,219 --> 00:00:19,960 +any test case that implements this specification will cause the execution + +7 +00:00:19,960 --> 00:00:22,770 +of this statement. Similarly if we want to cover this statement + +8 +00:00:22,770 --> 00:00:25,220 +which is our second requirement we need to have a result + +9 +00:00:25,220 --> 00:00:27,370 +that is less than 0. Again, the result is equal + +10 +00:00:27,370 --> 00:00:29,490 +to a plus b, so all we need to do + +11 +00:00:29,490 --> 00:00:32,450 +is find the test case such that a plus b + +12 +00:00:32,450 --> 00:00:34,700 +is less than 0. So this is pretty straight forward. diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/6 - Coverage Criteria Intro Quiz - lang_en_vs3.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/6 - Coverage Criteria Intro Quiz - lang_en_vs3.srt new file mode 100644 index 0000000..42b5720 --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/6 - Coverage Criteria Intro Quiz - lang_en_vs3.srt @@ -0,0 +1,63 @@ +1 +00:00:00,220 --> 00:00:03,780 +So, now that we have our test specifications. Test specification number one that + +2 +00:00:03,780 --> 00:00:06,740 +says that a plus b must be greater than zero. And test specification + +3 +00:00:06,740 --> 00:00:09,990 +number two, for which a plus b must be less than zero. I'd + +4 +00:00:09,990 --> 00:00:12,580 +like to do another small quiz and ask you to write some test + +5 +00:00:12,580 --> 00:00:16,440 +cases that will implement these specifications. And I want you to write the + +6 +00:00:16,440 --> 00:00:19,780 +test cases in this format. I want you to specify for each one + +7 +00:00:19,780 --> 00:00:22,300 +of the test cases, what is the value of a that you need + +8 +00:00:22,300 --> 00:00:25,160 +to use. What is the value of b that you need to use. + +9 +00:00:25,160 --> 00:00:28,200 +And since a test case, I like to remind you, is + +10 +00:00:28,200 --> 00:00:30,960 +not just a set of inputs. But is the set of + +11 +00:00:30,960 --> 00:00:34,050 +inputs plus expected output? I also want you to specify, what + +12 +00:00:34,050 --> 00:00:37,040 +is the expected output for these test cases? And in particular, + +13 +00:00:37,040 --> 00:00:39,540 +since we have two characteristics of the output, one is the + +14 +00:00:39,540 --> 00:00:41,630 +color of the output and the other one is the actual + +15 +00:00:41,630 --> 00:00:44,040 +value. I want you to specify for each test case, what + +16 +00:00:44,040 --> 00:00:46,790 +is the expected output color and what is the expected value? diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/7 - Coverage Criteria Intro Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/7 - Coverage Criteria Intro Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..749a57e --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/7 - Coverage Criteria Intro Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,87 @@ +1 +00:00:00,090 --> 00:00:02,360 +In this case like in many other cases, there's not just a + +2 +00:00:02,360 --> 00:00:05,550 +single right answer because you can build many test cases that will + +3 +00:00:05,550 --> 00:00:09,730 +satisfy this test specification. So for example, we could pick value 3 + +4 +00:00:09,730 --> 00:00:13,640 +for a and value 9 for b. Those satisfy the specification because a + +5 +00:00:13,640 --> 00:00:16,400 +plus b is equal to 12 and therefore is greater than 0, + +6 +00:00:16,400 --> 00:00:19,470 +and therefore this is a test case that implements this test specification. + +7 +00:00:19,470 --> 00:00:21,960 +And in terms of results, what we expect to see is in + +8 +00:00:21,960 --> 00:00:25,200 +the case of a result greater than 0, the caller should be red, + +9 +00:00:25,200 --> 00:00:28,109 +and the upper value should be 12. And obviously for this test + +10 +00:00:28,109 --> 00:00:30,971 +specification, we just need to pick two inputs such that the sum + +11 +00:00:30,971 --> 00:00:33,674 +of the two inputs is less than 0. So for example, we + +12 +00:00:33,674 --> 00:00:37,125 +could pick minus 5 and minus 8. The output color in this + +13 +00:00:37,125 --> 00:00:40,230 +case is going to be blue, and the output value is going to be + +14 +00:00:40,230 --> 00:00:43,780 +minus 13. So, what we just saw is basically how we can + +15 +00:00:43,780 --> 00:00:47,060 +go from a piece of code to a set of requirements, which + +16 +00:00:47,060 --> 00:00:50,260 +are the interesting aspects of the code that we want to exercise. How we + +17 +00:00:50,260 --> 00:00:52,800 +can satisfy the requirements by finding + +18 +00:00:52,800 --> 00:00:54,700 +the right test specifications, and then how + +19 +00:00:54,700 --> 00:00:58,450 +we can initiate the test specifications into actual test cases. And this is + +20 +00:00:58,450 --> 00:01:01,010 +what we will do in general when doing white books testing. And we'll + +21 +00:01:01,010 --> 00:01:02,520 +do things likely different way, depending on + +22 +00:01:02,520 --> 00:01:04,230 +the specific criteria that we are considering. diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/8 - Statement Coverage - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/8 - Statement Coverage - lang_en_vs4.srt new file mode 100644 index 0000000..23cfb0a --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/8 - Statement Coverage - lang_en_vs4.srt @@ -0,0 +1,291 @@ +1 +00:00:00,270 --> 00:00:03,080 +Now that we saw this overview of white-box testing, I'd like + +2 +00:00:03,080 --> 00:00:06,270 +to start talking about specific coverage criterion. And I'm going to start + +3 +00:00:06,270 --> 00:00:09,010 +with the first one, which is Statement Coverage. This criterion is + +4 +00:00:09,010 --> 00:00:12,355 +going to be characterized by two aspects, the first one is which + +5 +00:00:12,355 --> 00:00:15,580 +are the Test requirements for the criteria and the second one + +6 +00:00:15,580 --> 00:00:18,830 +is how we measure Coverage for that criteria. In the case + +7 +00:00:18,830 --> 00:00:22,200 +of statement coverage, these test requirements are all the statements in + +8 +00:00:22,200 --> 00:00:25,804 +the program. So this is the basic, the first the, the simplest + +9 +00:00:25,804 --> 00:00:29,860 +coverage criteria in the white-box arena. Let me remind you the assumption + +10 +00:00:29,860 --> 00:00:33,280 +that we made at the beginning. White-box testing is based on the assumption + +11 +00:00:33,280 --> 00:00:35,990 +that if there isn't a faulty element in the code, we need + +12 +00:00:35,990 --> 00:00:38,390 +to exercise it. We need to execute it, in order to find the + +13 +00:00:38,390 --> 00:00:41,260 +fault. And that's exactly what statement coverage does. If there is a + +14 +00:00:41,260 --> 00:00:44,450 +statement that is faulty in the code, we need to exercise it, in + +15 +00:00:44,450 --> 00:00:47,490 +order to find the fault. And therefore, a good measure of how well + +16 +00:00:47,490 --> 00:00:51,480 +we exercise the code, is the ratio of the number of executed statements. + +17 +00:00:51,480 --> 00:00:54,950 +So all the statements that my test cases executed, to the total + +18 +00:00:54,950 --> 00:00:58,570 +number of statements in the program. The higher this number, the better + +19 +00:00:58,570 --> 00:01:01,870 +I exercise my code. And we can also look at coverage criterion + +20 +00:01:01,870 --> 00:01:04,290 +in terms of questions. So what is the questions they were trying + +21 +00:01:04,290 --> 00:01:06,940 +to answer when we look at a specific set of test cases + +22 +00:01:06,940 --> 00:01:09,870 +and we assess the statement coverage that they achieved. And the question + +23 +00:01:09,870 --> 00:01:13,440 +is whether each statement in the program has been executed. So, statement + +24 +00:01:13,440 --> 00:01:16,920 +coverage is satisfied when all the statements in the program have been executed. + +25 +00:01:16,920 --> 00:01:19,640 +And we can satisfy to different degrees and the degrees to which it's + +26 +00:01:19,640 --> 00:01:23,320 +satisfied is measured by this value. So now let's go ahead and measure + +27 +00:01:23,320 --> 00:01:27,250 +statement coverage on our printSum example. What I'm going to show down here is + +28 +00:01:27,250 --> 00:01:30,500 +this progress bar in which we show the amount of coverage, the percentage of + +29 +00:01:30,500 --> 00:01:33,060 +coverage achieved. So what this means is that the, if I get to + +30 +00:01:33,060 --> 00:01:36,680 +this point I've covered 25% of the statements in the code. And my goal + +31 +00:01:36,680 --> 00:01:39,160 +is to get up here to cover all the statements in the code. + +32 +00:01:39,160 --> 00:01:42,000 +We have two test cases for this code. The first one that we just + +33 +00:01:42,000 --> 00:01:45,700 +saw, consists of the inputs a equal to 3 and b equal + +34 +00:01:45,700 --> 00:01:48,200 +to 9, and the second one has the inputs a is equal to + +35 +00:01:48,200 --> 00:01:50,840 +minus 5 and b is equal to minus 8. So now let's see + +36 +00:01:50,840 --> 00:01:53,450 +what happens when we run this test case. When we run this test + +37 +00:01:53,450 --> 00:01:56,920 +case, I'm going to show you by highlighting in the code the parts that + +38 +00:01:56,920 --> 00:02:00,430 +we cover when we start executing the code. We cover the first statement, + +39 +00:02:00,430 --> 00:02:01,910 +then we always execute the second + +40 +00:02:01,910 --> 00:02:04,180 +statement, which computes the result, we continue + +41 +00:02:04,180 --> 00:02:07,070 +the execution, we get to the if statement. If the result is greater + +42 +00:02:07,070 --> 00:02:10,038 +than zero, in this case our result is 12 because we + +43 +00:02:10,038 --> 00:02:12,360 +are working with the inputs 3 and 9, and therefore we + +44 +00:02:12,360 --> 00:02:15,710 +execute the true part of the if, we execute the statement. + +45 +00:02:15,710 --> 00:02:18,850 +And at this point, we just jump to the end. Because we + +46 +00:02:18,850 --> 00:02:21,530 +do not execute the else part of the statement, since we + +47 +00:02:21,530 --> 00:02:24,240 +have executed a true one, and therefore, we cover this final + +48 +00:02:24,240 --> 00:02:27,534 +statement. So at the end of the execution of this test + +49 +00:02:27,534 --> 00:02:32,313 +case, we cover one, two, three, four, five statement out of seven + +50 +00:02:32,313 --> 00:02:36,299 +which is roughly speaking 71%. So we can mark in here + +51 +00:02:36,299 --> 00:02:39,779 +that we more or less got to 71% of coverage for + +52 +00:02:39,779 --> 00:02:42,719 +this code. Now let's look at what happens when we execute + +53 +00:02:42,719 --> 00:02:45,700 +test case number two. In this case again, we execute the + +54 +00:02:45,700 --> 00:02:48,660 +first statement, the second statement, the third statement. In this case + +55 +00:02:48,660 --> 00:02:52,010 +though, the first statement, when it evaluates the value of result, + +56 +00:02:52,010 --> 00:02:54,250 +it sees that the result is not greater than zero because + +57 +00:02:54,250 --> 00:02:57,590 +our inputs are minus five and minus eight. Therefore, you will execute + +58 +00:02:57,590 --> 00:03:00,090 +line number five. And because the result is less than + +59 +00:03:00,090 --> 00:03:02,810 +zero, you will also execute line number six. So, at + +60 +00:03:02,810 --> 00:03:05,230 +this point, all of the statements in our code are + +61 +00:03:05,230 --> 00:03:09,360 +executed and therefore, we achieved a 100% statement coverage, which + +62 +00:03:09,360 --> 00:03:13,090 +was our goal. Before looking at other kinds of coverage, + +63 +00:03:13,090 --> 00:03:16,060 +let's see how our statement coverage is used in practice. + +64 +00:03:16,060 --> 00:03:19,170 +First of all, statement coverage is the most used kind + +65 +00:03:19,170 --> 00:03:22,830 +of coverage criterion in industry. Normally for company that uses + +66 +00:03:22,830 --> 00:03:27,200 +statement coverage, the typical coverage target is 80-90%, which + +67 +00:03:27,200 --> 00:03:29,690 +mean the outcome of the test should be such + +68 +00:03:29,690 --> 00:03:32,770 +that 80-90% of the statements are exercised at the + +69 +00:03:32,770 --> 00:03:34,880 +end of testing. So at this point, you might + +70 +00:03:34,880 --> 00:03:36,850 +be wondering, why don't we just shoot for 100%? + +71 +00:03:36,850 --> 00:03:38,580 +Why don't we try to cover all of the + +72 +00:03:38,580 --> 00:03:40,050 +code? We just saw that we could do it. + +73 +00:03:40,050 --> 00:03:41,730 +And so I'm going to ask you the same question. diff --git a/usth/ICT2.7/P4L3 White-Box Testing Subtitles/9 - Statement Coverage Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/9 - Statement Coverage Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..893fe06 --- /dev/null +++ b/usth/ICT2.7/P4L3 White-Box Testing Subtitles/9 - Statement Coverage Quiz - lang_en_vs4.srt @@ -0,0 +1,15 @@ +1 +00:00:00,100 --> 00:00:01,540 +so, I would like to hear from you. Why + +2 +00:00:01,540 --> 00:00:03,850 +do you think that we don't aim normally at + +3 +00:00:03,850 --> 00:00:05,939 +100 % college but, slightly less than that and + +4 +00:00:05,939 --> 00:00:07,560 +I want you to put your answer right here. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/1 - Lesson Overview - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/1 - Lesson Overview - lang_en_vs4.srt new file mode 100644 index 0000000..2e839f9 --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/1 - Lesson Overview - lang_en_vs4.srt @@ -0,0 +1,75 @@ +1 +00:00:00,270 --> 00:00:02,880 +In previous lessons, we covered testing principles and + +2 +00:00:02,880 --> 00:00:06,610 +techniques. In this lesson, we will discuss a + +3 +00:00:06,610 --> 00:00:09,550 +type of software process that is heavily based + +4 +00:00:09,550 --> 00:00:12,812 +on the use of testing. The agile development + +5 +00:00:12,812 --> 00:00:17,310 +process. Also called test-driven development. To do that, + +6 +00:00:17,310 --> 00:00:19,290 +we will revisit some of the assumptions that + +7 +00:00:19,290 --> 00:00:21,490 +led to the definition of the more traditional + +8 +00:00:21,490 --> 00:00:24,030 +software processes. The ones that we discussed so far. + +9 +00:00:25,440 --> 00:00:27,690 +We will see how, when some of these assumptions are + +10 +00:00:27,690 --> 00:00:30,210 +no longer valid, we can change the way in which we + +11 +00:00:30,210 --> 00:00:32,560 +look at software processes. And we can change the way + +12 +00:00:32,560 --> 00:00:36,120 +in which we look at software development in general. We will + +13 +00:00:36,120 --> 00:00:40,250 +discuss how this changing perspective, lets us rethink software processes + +14 +00:00:40,250 --> 00:00:43,520 +and make them more agile and better suited for context in + +15 +00:00:43,520 --> 00:00:46,120 +which changes are the norm and we need to adapt + +16 +00:00:46,120 --> 00:00:50,535 +fast. In particular, we will discuss two processes that apply the + +17 +00:00:50,535 --> 00:00:53,570 +principles of agile software development and that are commonly + +18 +00:00:53,570 --> 00:00:59,170 +used in industry. Extreme programming, also called XP, and Scrum. + +19 +00:00:59,170 --> 00:01:01,560 +[BLANK_AUDIO] diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/10 - Refactoring - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/10 - Refactoring - lang_en_vs4.srt new file mode 100644 index 0000000..800ffb5 --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/10 - Refactoring - lang_en_vs4.srt @@ -0,0 +1,103 @@ +1 +00:00:00,100 --> 00:00:02,469 +A couple of minutes ago we talked about the fact that well, we + +2 +00:00:02,469 --> 00:00:05,260 +might need to change our design a lot, so how we going to do + +3 +00:00:05,260 --> 00:00:08,540 +that, that's going to be expensive. Well it's not very expensive, if we can + +4 +00:00:08,540 --> 00:00:10,876 +do efficient refactoring. Which is another + +5 +00:00:10,876 --> 00:00:13,120 +one of the important xp practices. And + +6 +00:00:13,120 --> 00:00:15,280 +what does it mean to refactor? It means to take a piece of + +7 +00:00:15,280 --> 00:00:19,530 +code who's design might be suboptimal, because for example, we evolved it, we + +8 +00:00:19,530 --> 00:00:22,600 +didn't take into account that from the beginning some of the features that + +9 +00:00:22,600 --> 00:00:25,110 +had to be added later, probably because we didn't even know about this + +10 +00:00:25,110 --> 00:00:28,200 +feature, because the requirements evolved. So we're going to take this piece + +11 +00:00:28,200 --> 00:00:31,870 +of code and we're going to restructure it, so that it becomes simple + +12 +00:00:31,870 --> 00:00:34,070 +and maintainable. Developers are expected to + +13 +00:00:34,070 --> 00:00:35,590 +refactor as soon as opportunities for + +14 +00:00:35,590 --> 00:00:39,530 +improvement, are found. And that happens for example, before adding some code. + +15 +00:00:39,530 --> 00:00:41,730 +You might look at the code that you're about to modify, or + +16 +00:00:41,730 --> 00:00:43,850 +to which you are about to add parts, and say can we + +17 +00:00:43,850 --> 00:00:47,060 +change the program to make the addition simple, that has maintainability or + +18 +00:00:47,060 --> 00:00:50,220 +we can do it after adding some code to our code base. + +19 +00:00:50,220 --> 00:00:52,730 +We might look at the code, the resulting code, and say well + +20 +00:00:52,730 --> 00:00:55,770 +can we make the program simpler? Was the running all the tests + +21 +00:00:55,770 --> 00:00:57,920 +and the key point here is that we don't want to refactor on + +22 +00:00:57,920 --> 00:01:01,580 +speculation, but we want to refactor on demand, on the system, and the + +23 +00:01:01,580 --> 00:01:04,840 +process needed. Again the goal is just to keep the code simple + +24 +00:01:04,840 --> 00:01:07,680 +and maintainable, not to over do it. And as I mentioned before + +25 +00:01:07,680 --> 00:01:10,810 +we're going to have a whole lesson, the next lesson on refactoring. So + +26 +00:01:10,810 --> 00:01:13,470 +we're going to go in more depth in the discussion of this topic. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/11 - Pair Programming - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/11 - Pair Programming - lang_en_vs4.srt new file mode 100644 index 0000000..ad48828 --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/11 - Pair Programming - lang_en_vs4.srt @@ -0,0 +1,99 @@ +1 +00:00:00,100 --> 00:00:02,530 +The next practice I want to discuss is a very important one + +2 +00:00:02,530 --> 00:00:05,750 +in XP, and also one of the scandal, controversial, and it's + +3 +00:00:05,750 --> 00:00:08,390 +the practice of pair programming. What does it mean? It means + +4 +00:00:08,390 --> 00:00:11,790 +that all production code is written with two people looking at one + +5 +00:00:11,790 --> 00:00:15,170 +machine. And not that they're, they're working with one keyboard and + +6 +00:00:15,170 --> 00:00:18,450 +one mouse or they're not just interfering and writing on each other's + +7 +00:00:18,450 --> 00:00:20,920 +code. And the way in which that happens is by playing + +8 +00:00:20,920 --> 00:00:25,180 +different roles at different times. So the two developers alternate between the + +9 +00:00:25,180 --> 00:00:29,080 +role of programming and strategizing, where strategizing means, for example, + +10 +00:00:29,080 --> 00:00:31,660 +looking at the code that has been written and thinking whether + +11 +00:00:31,660 --> 00:00:34,420 +that would work. Or what other tests that are not there + +12 +00:00:34,420 --> 00:00:37,050 +might not work, given the way the code is being written. + +13 +00:00:37,050 --> 00:00:39,300 +Or maybe looking at the code from a, you know, slightly + +14 +00:00:39,300 --> 00:00:42,380 +detached perspective and trying to figure out whether the code can + +15 +00:00:42,380 --> 00:00:46,900 +be made simpler, more maintainable, more efficient. And interestingly, there are + +16 +00:00:46,900 --> 00:00:48,440 +measurements, there are studies that + +17 +00:00:48,440 --> 00:00:50,340 +suggest that development productivity with pair + +18 +00:00:50,340 --> 00:00:52,550 +programming is similar to that of two people + +19 +00:00:52,550 --> 00:00:55,080 +working independently. And that answers one of the + +20 +00:00:55,080 --> 00:00:57,740 +main objections against pair programming, which is why + +21 +00:00:57,740 --> 00:00:59,840 +should I put two developers together, which is + +22 +00:00:59,840 --> 00:01:01,860 +going to cut their productivity in half. It is + +23 +00:01:01,860 --> 00:01:04,390 +not. Studies shows that that does not happen. + +24 +00:01:04,390 --> 00:01:06,380 +And that the resulting code can actually benefit + +25 +00:01:06,380 --> 00:01:08,350 +from the fact that two developers are working together. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/12 - Continuous Integration - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/12 - Continuous Integration - lang_en_vs4.srt new file mode 100644 index 0000000..d40bda6 --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/12 - Continuous Integration - lang_en_vs4.srt @@ -0,0 +1,111 @@ +1 +00:00:00,280 --> 00:00:02,980 +An important practice to get all of this to work is + +2 +00:00:02,980 --> 00:00:05,230 +continuous integration, which means integrating and + +3 +00:00:05,230 --> 00:00:06,770 +testing every few hours, or a + +4 +00:00:06,770 --> 00:00:10,390 +day at most, because we don't want problems to pile up and + +5 +00:00:10,390 --> 00:00:13,060 +to be discovered too late when there are too many of them + +6 +00:00:13,060 --> 00:00:16,020 +to fix. So what goes on here is a cycle. And the + +7 +00:00:16,020 --> 00:00:19,380 +cycle starts with the developer's programming, as soon as the developers are + +8 +00:00:19,380 --> 00:00:22,050 +done modifying the code and they have a stable version they will + +9 +00:00:22,050 --> 00:00:25,380 +run the local tests. If the local tests fail, the developers will + +10 +00:00:25,380 --> 00:00:28,350 +go back to programming to fix their code and possibly add + +11 +00:00:28,350 --> 00:00:31,990 +new code as needed, and this cycle, mini cycle will continue + +12 +00:00:31,990 --> 00:00:35,000 +until all the local tests pass. At that point the developers + +13 +00:00:35,000 --> 00:00:37,960 +can integrate their code with the code of other developers. And they + +14 +00:00:37,960 --> 00:00:41,220 +can run test for the integrated system, and when they run + +15 +00:00:41,220 --> 00:00:44,830 +this test again there are two possibilities. The test might fail, and + +16 +00:00:44,830 --> 00:00:47,160 +if the test fails you broke it, and therefore you'll have + +17 +00:00:47,160 --> 00:00:50,710 +to fix it. So developers will have to go back and modify + +18 +00:00:50,710 --> 00:00:54,010 +the system and again going through the cycle of running the local + +19 +00:00:54,010 --> 00:00:55,900 +tests, integrating, and running the systems + +20 +00:00:55,900 --> 00:00:57,890 +tests. Conversely, if all the systems + +21 +00:00:57,890 --> 00:01:00,150 +tests pass, then at that point the code is good to go + +22 +00:01:00,150 --> 00:01:02,500 +and it is integrated into the system. And it will be the problem + +23 +00:01:02,500 --> 00:01:05,370 +of some other developers if something breaks because at the time you + +24 +00:01:05,370 --> 00:01:09,530 +integrated your code, the code was compiling, running and passing the tests + +25 +00:01:09,530 --> 00:01:12,495 +successfully. So again, if we do this every few hours or every + +26 +00:01:12,495 --> 00:01:15,740 +day, we can find problems very early, and we can avoid the situations + +27 +00:01:15,740 --> 00:01:18,105 +in which we have many different changes coming from + +28 +00:01:18,105 --> 00:01:21,290 +many different developers in a integration nightmare as a result. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/13 - On Site Customer - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/13 - On Site Customer - lang_en_vs4.srt new file mode 100644 index 0000000..a95cc07 --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/13 - On Site Customer - lang_en_vs4.srt @@ -0,0 +1,55 @@ +1 +00:00:00,060 --> 00:00:03,500 +The last practice I want to mention is on-site customer, and what + +2 +00:00:03,500 --> 00:00:07,590 +that means is that literally the customer is an actual member of + +3 +00:00:07,590 --> 00:00:10,310 +the team. So the customer will sit with the team and will + +4 +00:00:10,310 --> 00:00:13,546 +bring requirements to the team and discuss the requirements with them. So + +5 +00:00:13,546 --> 00:00:16,461 +the typical objection to this practice is the fact that it's just + +6 +00:00:16,461 --> 00:00:19,640 +impossible in the real world. There is no way that the customer + +7 +00:00:19,640 --> 00:00:22,550 +can have one person staying with the team all the time, and + +8 +00:00:22,550 --> 00:00:25,130 +the answer to that objection is that if the system is not + +9 +00:00:25,130 --> 00:00:28,700 +worth the time of one customer then maybe the system is not worth building. In + +10 +00:00:28,700 --> 00:00:30,530 +other words, if you're investing tons of + +11 +00:00:30,530 --> 00:00:33,440 +dollars, tons of money in building a system, + +12 +00:00:33,440 --> 00:00:36,870 +you might just as well invest a little more and have one of the people + +13 +00:00:36,870 --> 00:00:39,080 +in the customer's organization stay with the + +14 +00:00:39,080 --> 00:00:41,450 +team and be involved in the whole process. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/14 - Requirements Engineering - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/14 - Requirements Engineering - lang_en_vs4.srt new file mode 100644 index 0000000..7a00887 --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/14 - Requirements Engineering - lang_en_vs4.srt @@ -0,0 +1,139 @@ +1 +00:00:00,210 --> 00:00:02,680 +Now that we saw what the main values and practices + +2 +00:00:02,680 --> 00:00:05,200 +of XP are, I want to go back for a minute + +3 +00:00:05,200 --> 00:00:08,800 +to discussion of requirements engineering in XP. In XP, user + +4 +00:00:08,800 --> 00:00:12,180 +requirements are expressed as scenarios or user stories, as we already + +5 +00:00:12,180 --> 00:00:15,500 +discussed. These are written by customers on cards, and what + +6 +00:00:15,500 --> 00:00:18,550 +the development team does is to take these cards, take these + +7 +00:00:18,550 --> 00:00:22,240 +users stories and break them down into implementation tasks. And + +8 +00:00:22,240 --> 00:00:25,310 +those implementation tasks are then used as a basis for scheduling + +9 +00:00:25,310 --> 00:00:29,210 +cost estimates. So given these estimates, and based on their priorities, + +10 +00:00:29,210 --> 00:00:31,770 +the customer will choose the stories that will be included in + +11 +00:00:31,770 --> 00:00:34,980 +the next release, in the next iteration. And at this point, + +12 +00:00:34,980 --> 00:00:39,220 +the corresponding cards will be taken by the developers and the, + +13 +00:00:39,220 --> 00:00:42,380 +the task will be performed, and the relative, and the corresponding + +14 +00:00:42,380 --> 00:00:44,350 +card will be developed. And just to give an idea of + +15 +00:00:44,350 --> 00:00:47,330 +the order of magnitude, if you consider a few months project, + +16 +00:00:47,330 --> 00:00:50,390 +there might be 50 to 100 user stories for a project of + +17 +00:00:50,390 --> 00:00:52,820 +that duration. So, now let me give you an example of what + +18 +00:00:52,820 --> 00:00:55,630 +the story card might look like, and I'm going to do it using + +19 +00:00:55,630 --> 00:00:58,930 +a story card for document downloading and you can really do all of + +20 +00:00:58,930 --> 00:01:00,780 +this, basically as seeing what the + +21 +00:01:00,780 --> 00:01:03,440 +scenario is, downloading and printing an article. + +22 +00:01:03,440 --> 00:01:06,590 +And it describes basically what happens when you do that, what is + +23 +00:01:06,590 --> 00:01:09,530 +the scenario. First, you select the article that you want from a displayed + +24 +00:01:09,530 --> 00:01:12,760 +list. You then have to tell the system how you will pay for + +25 +00:01:12,760 --> 00:01:15,680 +it. This can either be through a subscription, through a company account or + +26 +00:01:15,680 --> 00:01:18,670 +by credit card, and so on. So what developers do, they take + +27 +00:01:18,670 --> 00:01:22,020 +this story card, and they break it down in to development tasks. + +28 +00:01:22,020 --> 00:01:25,100 +So, here I'm showing you some examples of task cards for the + +29 +00:01:25,100 --> 00:01:28,360 +user story that we just saw. In particular I'm showing three task cards + +30 +00:01:28,360 --> 00:01:30,740 +and if we look at the third one, there is a name + +31 +00:01:30,740 --> 00:01:34,260 +for the task, which is implement payment collection. So this is the development + +32 +00:01:34,260 --> 00:01:37,600 +task that we have the perform and here, there's a description of + +33 +00:01:37,600 --> 00:01:41,240 +what that developed code should do. And notice that, you know, the task + +34 +00:01:41,240 --> 00:01:44,400 +card can even be more. explicit than this, more + +35 +00:01:44,400 --> 00:01:47,450 +specific than this, and talk about actual development tasks. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/15 - Testing Strategy - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/15 - Testing Strategy - lang_en_vs4.srt new file mode 100644 index 0000000..af5ee6c --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/15 - Testing Strategy - lang_en_vs4.srt @@ -0,0 +1,147 @@ +1 +00:00:00,360 --> 00:00:03,320 +As you probably realized by now, at job development, it's a + +2 +00:00:03,320 --> 00:00:06,280 +lot about testing. So there is a lot of emphasis on + +3 +00:00:06,280 --> 00:00:09,420 +testing. Testing first, te, testing early. So that's the reason why + +4 +00:00:09,420 --> 00:00:12,710 +I also want to discuss what is the testing strategy in XP. + +5 +00:00:12,710 --> 00:00:14,820 +So first of all what is the basic principle? The basic + +6 +00:00:14,820 --> 00:00:18,770 +principle is that testing is Coded confidence. You write your test + +7 +00:00:18,770 --> 00:00:22,150 +cases and then you can run them anytime you want. And + +8 +00:00:22,150 --> 00:00:25,540 +if they pass, they'll give you confidence that your code is behaving + +9 +00:00:25,540 --> 00:00:27,920 +the way it's expected. If they don't pass on the other + +10 +00:00:27,920 --> 00:00:30,870 +hand, you'll know that there's something to fix. Another important concept is + +11 +00:00:30,870 --> 00:00:34,600 +that test might be isolated and automated. So both the running and + +12 +00:00:34,600 --> 00:00:37,400 +the checking of the tests has to be automated for all of + +13 +00:00:37,400 --> 00:00:39,830 +this to work. And there are two types of tests. The first + +14 +00:00:39,830 --> 00:00:43,170 +type of test is unit tests, that are created by the programmers, + +15 +00:00:43,170 --> 00:00:45,830 +and they're created by looking at the task cards. The task cards + +16 +00:00:45,830 --> 00:00:48,410 +describe what they implemented, functionality should + +17 +00:00:48,410 --> 00:00:50,740 +do, and therefore allows the developers. + +18 +00:00:50,740 --> 00:00:53,970 +The right test that can test this functionality. That can + +19 +00:00:53,970 --> 00:00:57,000 +check that the code's correctly implemented functionality. And as we + +20 +00:00:57,000 --> 00:01:00,670 +said, you should really test every meaninful feature. So, for + +21 +00:01:00,670 --> 00:01:04,250 +example, you should test every meaningful method in your classes. + +22 +00:01:04,250 --> 00:01:08,490 +You should put specific attention to possibly complex implementations, special + +23 +00:01:08,490 --> 00:01:11,100 +cases or specific problems that you might think of. while + +24 +00:01:11,100 --> 00:01:13,110 +reading the task cards. In some cases, when you do + +25 +00:01:13,110 --> 00:01:15,800 +refactoring, you might also want to write test cases specific + +26 +00:01:15,800 --> 00:01:18,300 +to that refactoring. But we'll say more about that. So this + +27 +00:01:18,300 --> 00:01:20,610 +was for the first kind of tests that are involved in + +28 +00:01:20,610 --> 00:01:23,650 +the, in the XP process. The second kind of tests are + +29 +00:01:23,650 --> 00:01:27,710 +the system tests, also called acceptance tests. And those tests involve + +30 +00:01:27,710 --> 00:01:30,920 +the customer. So basically what happens is that the customer provides + +31 +00:01:30,920 --> 00:01:33,760 +the test cases for their stores and then the development team + +32 +00:01:33,760 --> 00:01:37,630 +transforms those into actual automated tests. So these are tests created + +33 +00:01:37,630 --> 00:01:40,700 +by the developers. They run very quickly and they run very frequently. + +34 +00:01:40,700 --> 00:01:43,120 +These are tests developed with the help, with the + +35 +00:01:43,120 --> 00:01:46,170 +involvement of the customer they run longer. And run less + +36 +00:01:46,170 --> 00:01:48,710 +frequently, they run every time the system is integrated. + +37 +00:01:48,710 --> 00:01:50,890 +According to the cycle we saw a few minutes ago. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/16 - Testing Strategy Quiz - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/16 - Testing Strategy Quiz - lang_en_vs4.srt new file mode 100644 index 0000000..c26e977 --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/16 - Testing Strategy Quiz - lang_en_vs4.srt @@ -0,0 +1,47 @@ +1 +00:00:00,130 --> 00:00:02,776 +Now that we are done discussing XP Extreme Programming, I + +2 +00:00:02,776 --> 00:00:04,612 +would like to have a quiz, in which I make + +3 +00:00:04,612 --> 00:00:06,772 +sure that some of the concepts behind XP are well + +4 +00:00:06,772 --> 00:00:10,040 +understood. So, I'm going to ask you which of the following statements + +5 +00:00:10,040 --> 00:00:13,390 +about Extreme Programming are true, and here are the statements. + +6 +00:00:13,390 --> 00:00:17,700 +Because of pair programming, XP requires twice the number of developers. + +7 +00:00:17,700 --> 00:00:21,260 +In XP, code is rarely changed after being written. XP + +8 +00:00:21,260 --> 00:00:25,200 +follows the test driven development, or TDD, paradigm. The customer does + +9 +00:00:25,200 --> 00:00:27,560 +not need to provide any requirements in XP. + +10 +00:00:27,560 --> 00:00:31,120 +XP is an iterative software development process. So I + +11 +00:00:31,120 --> 00:00:32,700 +would like for you to mark all of + +12 +00:00:32,700 --> 00:00:35,020 +the statements that you think are true about XP. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/17 - Testing Strategy Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/17 - Testing Strategy Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..b60861f --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/17 - Testing Strategy Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,127 @@ +1 +00:00:00,120 --> 00:00:02,600 +The first statement is false. It is not true + +2 +00:00:02,600 --> 00:00:04,840 +that because of pair programming, we need twice as many + +3 +00:00:04,840 --> 00:00:08,039 +developers. In fact that there is some evidence that even + +4 +00:00:08,039 --> 00:00:11,700 +though in pair programming we have two developers working together, + +5 +00:00:11,700 --> 00:00:15,175 +that the overall efficiency of the programmers is not really + +6 +00:00:15,175 --> 00:00:19,080 +affected by use of this practice. In XP, code is + +7 +00:00:19,080 --> 00:00:23,280 +rarely changed after being written. This is also definitely false. + +8 +00:00:23,280 --> 00:00:25,233 +In fact in XP there is a lot of emphasis + +9 +00:00:25,233 --> 00:00:27,879 +on change on the fact that the code can be changed, + +10 +00:00:27,879 --> 00:00:30,462 +it can be resigned, because of the fact when we do + +11 +00:00:30,462 --> 00:00:32,793 +that, we have a set of these cases that we can + +12 +00:00:32,793 --> 00:00:35,439 +use to check right away that the code still works as + +13 +00:00:35,439 --> 00:00:39,850 +expected. So again in XP, it's all about steering rather than + +14 +00:00:39,850 --> 00:00:43,430 +just driving down one fixed direction. And therefore, the code can + +15 +00:00:43,430 --> 00:00:46,580 +be changed. So this statement is false. It is definitely true + +16 +00:00:46,580 --> 00:00:50,950 +that XP follows the test driven development paradigm. In XP we first + +17 +00:00:50,950 --> 00:00:53,320 +write tests, and then we write the code, which is + +18 +00:00:53,320 --> 00:00:55,980 +exactly what TDD is about. It is not true that + +19 +00:00:55,980 --> 00:00:58,740 +the customer does not need to provide requirements in XP. + +20 +00:00:58,740 --> 00:01:02,020 +The customer does provide requirements in the form of user + +21 +00:01:02,020 --> 00:01:04,879 +stories, and the user stories are the starting point of + +22 +00:01:04,879 --> 00:01:09,370 +the development process. Finally, XP is definitely an iterative software + +23 +00:01:09,370 --> 00:01:12,500 +development process. In fact, we saw that XP is based + +24 +00:01:12,500 --> 00:01:16,100 +on subsequent iterations of the same cycle, in which we + +25 +00:01:16,100 --> 00:01:18,110 +select from a set of story cards, or user + +26 +00:01:18,110 --> 00:01:21,270 +stories, the stories that we want to implement in the + +27 +00:01:21,270 --> 00:01:24,250 +next iteration. Based on that we develop task cards, + +28 +00:01:24,250 --> 00:01:26,060 +and then we use the task cards to write this + +29 +00:01:26,060 --> 00:01:28,400 +case and then to write code. And we continue + +30 +00:01:28,400 --> 00:01:31,140 +this cycle in an iterative way until we are done + +31 +00:01:31,140 --> 00:01:33,030 +with all the story cards, and all the user + +32 +00:01:33,030 --> 00:01:36,612 +stories, so definitely XP is an iterative software development process. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/18 - Scrum Intro - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/18 - Scrum Intro - lang_en_vs4.srt new file mode 100644 index 0000000..4d8eab6 --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/18 - Scrum Intro - lang_en_vs4.srt @@ -0,0 +1,99 @@ +1 +00:00:00,220 --> 00:00:02,830 +Before concluding this class on java development, I want to + +2 +00:00:02,830 --> 00:00:06,330 +talk about another process that is very popular these days, and + +3 +00:00:06,330 --> 00:00:09,990 +it's used in many companies, which is called Scrum. Which similar + +4 +00:00:09,990 --> 00:00:13,370 +to XP is another agile development process, and I'm going to + +5 +00:00:13,370 --> 00:00:16,400 +start by discussing what the Scrum actors are. There's three + +6 +00:00:16,400 --> 00:00:19,490 +main kinds of actors. The first one is the product owner, + +7 +00:00:19,490 --> 00:00:22,590 +which means the customer. The product owner is mainly responsible for + +8 +00:00:22,590 --> 00:00:25,460 +the product back log, where the product back log is basically + +9 +00:00:25,460 --> 00:00:27,660 +the list of things that have to be done, the + +10 +00:00:27,660 --> 00:00:30,670 +back log in fact for the project. And that is + +11 +00:00:30,670 --> 00:00:33,640 +analogous to the user stories to be realized in XP, + +12 +00:00:33,640 --> 00:00:36,190 +that we just saw. So what the product owner does is + +13 +00:00:36,190 --> 00:00:39,310 +to clearly express these back log items, and to also + +14 +00:00:39,310 --> 00:00:42,680 +order them by value, so they can be prioritized. The second + +15 +00:00:42,680 --> 00:00:45,680 +actor is the team. The team is responsible for delivering + +16 +00:00:45,680 --> 00:00:48,012 +shippable increments to estimate the + +17 +00:00:48,012 --> 00:00:50,600 +back log items. It's normally self-organized, + +18 +00:00:50,600 --> 00:00:53,055 +consists of four to nine people, and it's what you + +19 +00:00:53,055 --> 00:00:56,180 +would consider normally as the main development team in a + +20 +00:00:56,180 --> 00:00:59,080 +project. And finally we have the Scrum master. The Scrum + +21 +00:00:59,080 --> 00:01:02,860 +master is the person who's responsible for the overall Scrum process, + +22 +00:01:02,860 --> 00:01:05,980 +so he or she has to remove obstacles, facilitate events, + +23 +00:01:05,980 --> 00:01:08,668 +helps communications, and so on. So you you can see + +24 +00:01:08,668 --> 00:01:11,013 +the Scrum master as sort of a manager or the + +25 +00:01:11,013 --> 00:01:15,059 +person who's got oversight, or the supervisor of the Scrum process. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/19 - High Level Scrum Process - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/19 - High Level Scrum Process - lang_en_vs4.srt new file mode 100644 index 0000000..d646b4e --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/19 - High Level Scrum Process - lang_en_vs4.srt @@ -0,0 +1,215 @@ +1 +00:00:00,100 --> 00:00:02,200 +So I want to conclude this lesson by providing a high + +2 +00:00:02,200 --> 00:00:05,790 +level view of this scrum process. The process is represented here, + +3 +00:00:05,790 --> 00:00:07,939 +and as you can see it has several components. We're going to + +4 +00:00:07,939 --> 00:00:09,860 +go through all of them one at a time. We're going to + +5 +00:00:09,860 --> 00:00:13,110 +start with a product backlog. Product backlog is the single source + +6 +00:00:13,110 --> 00:00:17,420 +of requirements, for the process. They're order by value raised priority + +7 +00:00:17,420 --> 00:00:21,110 +necessity, so that all of this characteristics can be taken into + +8 +00:00:21,110 --> 00:00:25,920 +account when selecting which backlog items to consider for the next iteration. + +9 +00:00:25,920 --> 00:00:28,710 +It's a living list in the sense that backlog items + +10 +00:00:28,710 --> 00:00:31,020 +can be added or removed. And it's not really defined + +11 +00:00:31,020 --> 00:00:33,200 +as we just said, by the product owner. In the + +12 +00:00:33,200 --> 00:00:36,260 +sprint planning, what happens is that the next increment or + +13 +00:00:36,260 --> 00:00:40,180 +the next sprint is defined. So basically, the backlog items + +14 +00:00:40,180 --> 00:00:43,348 +of interest are selected based on the characteristics we just + +15 +00:00:43,348 --> 00:00:46,890 +mentioned: value, [UNKNOWN], priority, and necessity. And the items are + +16 +00:00:46,890 --> 00:00:50,950 +converted into tasks and estimated. So the result is this sprint + +17 +00:00:50,950 --> 00:00:54,240 +backlog, which is the set of backlog items that will + +18 +00:00:54,240 --> 00:00:57,650 +be completed during the next sprint. The sprint is an actual + +19 +00:00:57,650 --> 00:01:01,040 +iteration of this scrum process. It's got a main part + +20 +00:01:01,040 --> 00:01:04,730 +that lasts two to four weeks, and within this main part, + +21 +00:01:04,730 --> 00:01:08,150 +there are many daily scrums that last 24 hours. So + +22 +00:01:08,150 --> 00:01:11,260 +let's see how this work. A daily scrum is typically characterized + +23 +00:01:11,260 --> 00:01:13,960 +by a 50-minute meeting at the beginning of the day + +24 +00:01:13,960 --> 00:01:16,220 +for the team to sync, and what happens during the meeting + +25 +00:01:16,220 --> 00:01:19,010 +is that there is a discussion of the accomplishments since + +26 +00:01:19,010 --> 00:01:21,210 +the last meeting. A to do list for the next + +27 +00:01:21,210 --> 00:01:24,210 +meeting is produced, and there is also an obstacle analysis. + +28 +00:01:24,210 --> 00:01:27,690 +So if some problem appear, they're discussing the daily scrum, and + +29 +00:01:27,690 --> 00:01:30,905 +possible solutions are proposed. At the end of the two + +30 +00:01:30,905 --> 00:01:34,840 +four-week cycle, there is a sprint review and retrospective. The sprint + +31 +00:01:34,840 --> 00:01:37,440 +review normally consists of a four hour meeting. In the + +32 +00:01:37,440 --> 00:01:41,270 +meeting, the product owner assesses the accomplishment for the specific sprint, + +33 +00:01:41,270 --> 00:01:44,020 +and the team discusses issues that were encountered and solved. + +34 +00:01:44,020 --> 00:01:46,530 +There is typically a demo of the deliverable for that + +35 +00:01:46,530 --> 00:01:48,810 +sprint. And at that point, the product owner will also + +36 +00:01:48,810 --> 00:01:52,610 +discuss the backlogs. And together with the team they will decide + +37 +00:01:52,610 --> 00:01:56,230 +what to do next. In the retrospective conversely what happens + +38 +00:01:56,230 --> 00:01:59,140 +is there is more focus on the process. So the + +39 +00:01:59,140 --> 00:02:02,010 +goal of that part of the meeting is discussing possible + +40 +00:02:02,010 --> 00:02:04,850 +process improvements. To identify them + +41 +00:02:04,850 --> 00:02:07,140 +and if promising improvements are identified + +42 +00:02:07,140 --> 00:02:10,810 +try to plan how to implement those improvements and use them + +43 +00:02:10,810 --> 00:02:13,790 +in the next iterations. And something else that might happen at + +44 +00:02:13,790 --> 00:02:16,720 +the end of a sprint is that if the product increment + +45 +00:02:16,720 --> 00:02:19,210 +is good enough as it reach the state in which it + +46 +00:02:19,210 --> 00:02:22,660 +can be actually shipped that will result in a release that + +47 +00:02:22,660 --> 00:02:25,730 +is not just internal. To show the product owner the progress + +48 +00:02:25,730 --> 00:02:28,510 +that can also be deployed and actually used in production. So + +49 +00:02:28,510 --> 00:02:32,650 +one final consideration is that as you can see, XP and scrum + +50 +00:02:32,650 --> 00:02:35,340 +are fairly similar, and that's because they're both agile development + +51 +00:02:35,340 --> 00:02:37,930 +processes. So the main thing to keep in mind is that + +52 +00:02:37,930 --> 00:02:40,620 +they both implement and enforce + +53 +00:02:40,620 --> 00:02:44,380 +those ideas, values, practices, and characteristics + +54 +00:02:44,380 --> 00:02:47,600 +that we saw when we discussed agile development process in general. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/2 - Cost of Change - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/2 - Cost of Change - lang_en_vs4.srt new file mode 100644 index 0000000..3b5a261 --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/2 - Cost of Change - lang_en_vs4.srt @@ -0,0 +1,207 @@ +1 +00:00:00,290 --> 00:00:03,500 +We will start our discussion about test written and development by going + +2 +00:00:03,500 --> 00:00:06,790 +back to a softer life cycle to examine a little bit ago + +3 +00:00:06,790 --> 00:00:09,460 +which is the waterfall life cycle. And if you remember, that was + +4 +00:00:09,460 --> 00:00:12,980 +a totally rigid process in which we were preparing documents and we + +5 +00:00:12,980 --> 00:00:16,570 +were not studying any phase before the previous one was finished. And + +6 +00:00:16,570 --> 00:00:19,710 +once a phase was finished, we were really going back to it. + +7 +00:00:19,710 --> 00:00:22,110 +So today we are going to examine how it is possible to go + +8 +00:00:22,110 --> 00:00:25,320 +from such a rigid process to an agile one, in which we can + +9 +00:00:25,320 --> 00:00:27,800 +better deal with changes. So remember what we saw in the + +10 +00:00:27,800 --> 00:00:31,510 +first lesson when Barry Boehm stated that the cost of change + +11 +00:00:31,510 --> 00:00:35,830 +grows exponentially with time. So if we imagine to have time + +12 +00:00:35,830 --> 00:00:39,400 +over here on the x-axis and cost on the y-axis, we + +13 +00:00:39,400 --> 00:00:41,650 +can see the cost that will go up more or less + +14 +00:00:41,650 --> 00:00:44,325 +this way. And what that means is finding a problem while + +15 +00:00:44,325 --> 00:00:47,890 +collecting requirements will cost you much less than finding a problem + +16 +00:00:47,890 --> 00:00:50,830 +in the analysis phase, which in turn, will cost you less + +17 +00:00:50,830 --> 00:00:53,130 +than finding a problem during design, and so on for + +18 +00:00:53,130 --> 00:00:56,110 +the subsequent phases. So if this is the case, and cost + +19 +00:00:56,110 --> 00:00:59,450 +is really growing this fast as we proceed in our process, + +20 +00:00:59,450 --> 00:01:01,530 +what should we do? The key thing is to discover errors + +21 +00:01:01,530 --> 00:01:04,700 +early before they become expensive, which in turn means doing a + +22 +00:01:04,700 --> 00:01:09,420 +lot of upfront planning. And because models are cheaper to modify + +23 +00:01:09,420 --> 00:01:13,150 +in code, we're willing to make large investments in upfront analysis + +24 +00:01:13,150 --> 00:01:16,150 +and design models. And only after we have built and checked + +25 +00:01:16,150 --> 00:01:18,750 +these models, we're going to go ahead and build the code. In + +26 +00:01:18,750 --> 00:01:20,178 +other words, we are following + +27 +00:01:20,178 --> 00:01:23,140 +a waterfall mentality. However, something definitely + +28 +00:01:23,140 --> 00:01:26,510 +changed in the last 30 years. For example, 30 years ago, + +29 +00:01:26,510 --> 00:01:28,770 +we needed to walk down the hall, submit a deck of + +30 +00:01:28,770 --> 00:01:31,490 +cards to an operator, and wait a day for our program + +31 +00:01:31,490 --> 00:01:34,280 +to run and produce some results. Today we can leverage the + +32 +00:01:34,280 --> 00:01:37,820 +computational power of the cloud. Computers used to be very slow + +33 +00:01:37,820 --> 00:01:42,322 +and very expensive. Today, computer are a thousand times faster and + +34 +00:01:42,322 --> 00:01:44,380 +a thousand times cheaper than what they used to be. In + +35 +00:01:44,380 --> 00:01:47,530 +particular, if you think about the compile and test cycle, that has + +36 +00:01:47,530 --> 00:01:51,110 +gone from days to seconds. Now we can change our code, compile + +37 +00:01:51,110 --> 00:01:54,460 +it, run it our tests, all in a matter of instants, something + +38 +00:01:54,460 --> 00:01:57,660 +that was unthinkable before. Finally, developers in the past had to + +39 +00:01:57,660 --> 00:02:01,380 +do a lot of tasks manually in a very time-consuming way and + +40 +00:02:01,380 --> 00:02:04,220 +often in a very painful way. Today, on the contrary, we can + +41 +00:02:04,220 --> 00:02:07,540 +now automate a lot of these tasks. We have high level programming + +42 +00:02:07,540 --> 00:02:11,890 +languages, version control systems, smart ideas. Basically a whole set of tools + +43 +00:02:11,890 --> 00:02:15,110 +that can help developers. And they can make them more efficient. In + +44 +00:02:15,110 --> 00:02:18,440 +general, what that means is, it's easy to change, much easier than + +45 +00:02:18,440 --> 00:02:21,310 +what it was before. So maybe if we take all that into account, + +46 +00:02:21,310 --> 00:02:23,430 +the cost of change can be flat. So if we go back + +47 +00:02:23,430 --> 00:02:26,580 +to our diagram, the one in which we showed the cost with + +48 +00:02:26,580 --> 00:02:29,930 +respect to the project time, maybe instead of having this kind of + +49 +00:02:29,930 --> 00:02:32,740 +curve, we might have a different kind of curve. Maybe the curve is + +50 +00:02:32,740 --> 00:02:36,020 +more like this one. So maybe we can make all of this happen, as long as + +51 +00:02:36,020 --> 00:02:38,440 +we use tools, practices and principles in the + +52 +00:02:38,440 --> 00:02:40,170 +right way. And we're going to see what that means. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/3 - Agile Software Development - lang_en_vs7.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/3 - Agile Software Development - lang_en_vs7.srt new file mode 100644 index 0000000..38fe4c3 --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/3 - Agile Software Development - lang_en_vs7.srt @@ -0,0 +1,159 @@ +1 +00:00:00,150 --> 00:00:03,250 +And assuming that cost is flat that we can really lower that + +2 +00:00:03,250 --> 00:00:06,590 +curve then teher are a few interesting consequences. First of all upfront + +3 +00:00:06,590 --> 00:00:10,330 +work becomes a liability, we pay for speculative work some of which + +4 +00:00:10,330 --> 00:00:13,320 +is likely to be wrong. Some of which we are likely to undo + +5 +00:00:13,320 --> 00:00:16,870 +and the reason for ambiguity and volability for example in requirements then + +6 +00:00:16,870 --> 00:00:19,310 +it's good to delay We don't want to plan for something that + +7 +00:00:19,310 --> 00:00:22,380 +might never happen, to invest resources in something that we might have + +8 +00:00:22,380 --> 00:00:25,170 +to throw away later on. In general, if cost is flat it is + +9 +00:00:25,170 --> 00:00:28,820 +cost effective to delay all decisions until the last possible + +10 +00:00:28,820 --> 00:00:30,990 +moment and only pay for what we use, so to + +11 +00:00:30,990 --> 00:00:34,550 +speak. In other words, there is value in waiting, time + +12 +00:00:34,550 --> 00:00:37,810 +answers questions and removes uncertainty. And we want to take advantage + +13 +00:00:37,810 --> 00:00:40,610 +of that. This and other considerations led to the birth + +14 +00:00:40,610 --> 00:00:44,590 +of Agile Softer Development. Specifically for those of you who are + +15 +00:00:44,590 --> 00:00:47,200 +interested in a little bit of history. In February 2001 + +16 +00:00:47,200 --> 00:00:50,430 +a group of software developers, 17 of them, met to discuss + +17 +00:00:50,430 --> 00:00:53,950 +lightweight development methods and published Manifesto for Agile + +18 +00:00:53,950 --> 00:00:57,630 +Software Developement. Which introduces and defines the concept of + +19 +00:00:57,630 --> 00:01:00,990 +agile software development, or agile methods. In a + +20 +00:01:00,990 --> 00:01:03,770 +nutshell, agile methods aim at flat cost and a + +21 +00:01:03,770 --> 00:01:06,190 +decrease in traditional overhead by following a set + +22 +00:01:06,190 --> 00:01:09,400 +of important principles. Our first principle is to focus + +23 +00:01:09,400 --> 00:01:11,700 +on the code, rather than the design, to avoid + +24 +00:01:11,700 --> 00:01:16,080 +unnecessary changes. Another principle is to focus on people, + +25 +00:01:16,080 --> 00:01:20,100 +value people over process, and make sure to reward people. + +26 +00:01:20,100 --> 00:01:22,990 +In addition agile methods are all based on iterative approaches to + +27 +00:01:22,990 --> 00:01:26,310 +software development, to deliver working software quickly, and to be + +28 +00:01:26,310 --> 00:01:29,230 +evolve it Just as quickly based on feedback. And feedback can + +29 +00:01:29,230 --> 00:01:31,740 +come from many sources, in particular, it'll come from the + +30 +00:01:31,740 --> 00:01:34,500 +customer, it'll be customer feedback. And to be able to do + +31 +00:01:34,500 --> 00:01:38,040 +so, agile methods need to involve the customer throughout the development + +32 +00:01:38,040 --> 00:01:41,260 +process. Finally, there are two more principles I want to mention. + +33 +00:01:41,260 --> 00:01:43,620 +Which are cornerstones of agile methods. The first + +34 +00:01:43,620 --> 00:01:46,520 +one is the expectation that requirements will change, and + +35 +00:01:46,520 --> 00:01:48,010 +therefore, we need to be able to handle some + +36 +00:01:48,010 --> 00:01:50,570 +changes. We can't count on the requirements to be + +37 +00:01:50,570 --> 00:01:52,890 +still and unmutable. And the last principle is + +38 +00:01:52,890 --> 00:01:56,430 +the mentality of simplicity. Simple design and simple code + +39 +00:01:56,430 --> 00:01:58,810 +and so on. But be careful, because simple does + +40 +00:01:58,810 --> 00:02:02,060 +not mean inadequate, but rather, as simple as possible. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/4 - Extreme Programming (XP) - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/4 - Extreme Programming (XP) - lang_en_vs4.srt new file mode 100644 index 0000000..62cc2fa --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/4 - Extreme Programming (XP) - lang_en_vs4.srt @@ -0,0 +1,179 @@ +1 +00:00:00,100 --> 00:00:02,490 +So now let's talk about a specific agile method, which + +2 +00:00:02,490 --> 00:00:05,850 +is also one of the first ones, extreme programming, also called + +3 +00:00:05,850 --> 00:00:08,430 +XP. And to introduce XP, I'm going to start with + +4 +00:00:08,430 --> 00:00:12,520 +a quote. The quote says XP is a lightweight methodology for + +5 +00:00:12,520 --> 00:00:16,180 +small to medium sized teams developing software in the face + +6 +00:00:16,180 --> 00:00:19,770 +of vague or rapidly-changing requirements. And this is a quote from + +7 +00:00:19,770 --> 00:00:23,010 +Kent Beck the American Software Engineer that created extreme programming. + +8 +00:00:23,010 --> 00:00:25,630 +And by the way Beck was one of the original 17 + +9 +00:00:25,630 --> 00:00:29,570 +developers who signed the manifesto in 2001. And as you can see + +10 +00:00:29,570 --> 00:00:31,940 +we are still talking about the methodology. So we are not just + +11 +00:00:31,940 --> 00:00:35,760 +talking about going out and just start writing software. There are principles. + +12 +00:00:35,760 --> 00:00:38,130 +And there are practices that we need to follow, but we're going + +13 +00:00:38,130 --> 00:00:40,330 +to do it in a much more agile, and a much more + +14 +00:00:40,330 --> 00:00:43,720 +flexible ways than we did for our software processes. And also note + +15 +00:00:43,720 --> 00:00:45,340 +that the vague and rapidly changing + +16 +00:00:45,340 --> 00:00:47,190 +requirements are explicitly mentioned, because this + +17 +00:00:47,190 --> 00:00:51,130 +is really one of the important parts about all of this agile methodologies. + +18 +00:00:51,130 --> 00:00:54,780 +so what is XP? XP is a. Lightweight. Humanistic. + +19 +00:00:54,780 --> 00:00:58,250 +Discipline. Of software development. It is lightweight because it doesn't + +20 +00:00:58,250 --> 00:01:02,190 +overburden the developers with an invasive process. So process + +21 +00:01:02,190 --> 00:01:04,510 +is kept to a minimum. It's humanistic because as we + +22 +00:01:04,510 --> 00:01:07,760 +said, it's centered on people. People, developers, customers, are + +23 +00:01:07,760 --> 00:01:10,520 +at the center of the process. It's a discipline, as + +24 +00:01:10,520 --> 00:01:12,870 +we said, it includes practices that we to Follow. + +25 +00:01:12,870 --> 00:01:16,470 +And finally, is of course about software development. Software development + +26 +00:01:16,470 --> 00:01:19,530 +is a key point of the whole method. In XP, developing + +27 +00:01:19,530 --> 00:01:22,910 +is like driving, imagine having a road, a wind road, we need + +28 +00:01:22,910 --> 00:01:25,110 +to able to drive our car down the road, take the + +29 +00:01:25,110 --> 00:01:29,640 +abrupt turns, react promptly to changes, for example obstacles on the road. + +30 +00:01:29,640 --> 00:01:32,610 +So, in a nutshell, change is the only constant. Eyes always + +31 +00:01:32,610 --> 00:01:34,980 +have to be on the road and it's about steering and not + +32 +00:01:34,980 --> 00:01:38,110 +pointing, and XP is trying to do the same thing, while creating + +33 +00:01:38,110 --> 00:01:42,190 +softer systems. In XP we need to adopt a mentality of sufficiency, + +34 +00:01:42,190 --> 00:01:44,820 +what does that mean? How would you program if you had all + +35 +00:01:44,820 --> 00:01:48,010 +the time in the world? No time constraints at all, you will probably + +36 +00:01:48,010 --> 00:01:51,090 +write tests instead of skipping them, because there's no more resources. You + +37 +00:01:51,090 --> 00:01:53,200 +will probably restructure your code often, + +38 +00:01:53,200 --> 00:01:55,210 +because you see opportunities to improve it, + +39 +00:01:55,210 --> 00:01:57,300 +and you will take them. And you will probably talk to fellow + +40 +00:01:57,300 --> 00:02:00,910 +programmers and with the customer, interact with them, and this is actually the + +41 +00:02:00,910 --> 00:02:04,700 +kind of mentality that XP is trying to promote and agile processes + +42 +00:02:04,700 --> 00:02:07,760 +in general. And we will see that the following some of the practices + +43 +00:02:07,760 --> 00:02:11,250 +that XP is advocating, you can actually achieve these goals and you can + +44 +00:02:11,250 --> 00:02:12,840 +actually behave in this way. And the + +45 +00:02:12,840 --> 00:02:15,010 +development process is going to benefit overall. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/5 - XP's Values, Principles, and Practices - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/5 - XP's Values, Principles, and Practices - lang_en_vs4.srt new file mode 100644 index 0000000..d12e73d --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/5 - XP's Values, Principles, and Practices - lang_en_vs4.srt @@ -0,0 +1,151 @@ +1 +00:00:00,218 --> 00:00:03,030 +Next I'm going to go over some of the XP's values + +2 +00:00:03,030 --> 00:00:05,870 +and principles that I just hinted on earlier in the lesson. + +3 +00:00:05,870 --> 00:00:08,820 +The first one, the first important value is communication. There + +4 +00:00:08,820 --> 00:00:12,350 +is no good project without good communication. And XP tries to + +5 +00:00:12,350 --> 00:00:15,470 +keep the right communication flowing and it uses several practices + +6 +00:00:15,470 --> 00:00:18,890 +to do that. It's got practices based on and require information + +7 +00:00:18,890 --> 00:00:21,950 +and in general share the information. For example, pair programming. + +8 +00:00:21,950 --> 00:00:25,140 +And we're going to say more about that. User stories, customer involvement, + +9 +00:00:25,140 --> 00:00:28,240 +all activities that help communication, + +10 +00:00:28,240 --> 00:00:30,440 +that faster communication. Another important + +11 +00:00:30,440 --> 00:00:33,420 +principle that we already saw, is simplicity. And the motto here + +12 +00:00:33,420 --> 00:00:35,680 +is live for today without worrying too much about the + +13 +00:00:35,680 --> 00:00:38,230 +future. When you have to do something, look for the simplest + +14 +00:00:38,230 --> 00:00:40,580 +thing that works. And the emphasis here is on, that + +15 +00:00:40,580 --> 00:00:43,520 +works. We want to build something simple, but not something stupid. + +16 +00:00:43,520 --> 00:00:47,090 +Feedback. That's extremely important in XP, and it occurs at + +17 +00:00:47,090 --> 00:00:50,560 +different levels, and it is used to drive changes. For example, + +18 +00:00:50,560 --> 00:00:53,910 +developers write test cases. And that's immediate feedback. If your test cases + +19 +00:00:53,910 --> 00:00:56,140 +fail, there's something wrong with the code. Or there's something that you + +20 +00:00:56,140 --> 00:00:59,690 +still haven't developed. Developers also estimate new stories right away as soon + +21 +00:00:59,690 --> 00:01:02,060 +as they get them from the customers and that's immediate feedback to + +22 +00:01:02,060 --> 00:01:05,515 +the customer. And finally, on a slightly longer time frame, customers and + +23 +00:01:05,515 --> 00:01:07,820 +tester develop together functional system test + +24 +00:01:07,820 --> 00:01:09,600 +cases to assess the overall system. + +25 +00:01:09,600 --> 00:01:12,100 +And also in this case, that's a great way to provide feedback + +26 +00:01:12,100 --> 00:01:15,850 +and by the way, also to help communication. And finally, courage, the courage + +27 +00:01:15,850 --> 00:01:18,860 +to throw away code if it doesn't work. To change it if you + +28 +00:01:18,860 --> 00:01:21,710 +find a way to improve it. To fix it if you find a problem. + +29 +00:01:21,710 --> 00:01:24,300 +To try out new things if you think that they might work better + +30 +00:01:24,300 --> 00:01:27,410 +than what you have right now. Now, that we can build and test systems + +31 +00:01:27,410 --> 00:01:30,150 +very quickly, we can be much braver than what we were before. So + +32 +00:01:30,150 --> 00:01:33,790 +how do we accomplish all that? And what are XP's practices that are going to + +33 +00:01:33,790 --> 00:01:37,750 +help us follow these principles and adhere to those values? These are some + +34 +00:01:37,750 --> 00:01:40,900 +of XP practices. There are more, but those are the ones that I'd like + +35 +00:01:40,900 --> 00:01:44,240 +to discuss in a little more depth, individually. Incremental planning, + +36 +00:01:44,240 --> 00:01:48,230 +small releases, simple design, test first, refactoring. We will actually + +37 +00:01:48,230 --> 00:01:51,680 +have a whole lesson next on refactoring. Pair programming, continuous + +38 +00:01:51,680 --> 00:01:55,240 +integration, and on-site customer. So let's start with incremental planning. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/6 - Incremental Planning - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/6 - Incremental Planning - lang_en_vs4.srt new file mode 100644 index 0000000..faf25db --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/6 - Incremental Planning - lang_en_vs4.srt @@ -0,0 +1,71 @@ +1 +00:00:00,140 --> 00:00:03,390 +Incremental planning is based on the idea that requirements are recorded + +2 +00:00:03,390 --> 00:00:07,260 +on story cards, sort of use cases or scenarios that the customer + +3 +00:00:07,260 --> 00:00:10,450 +provides. So the first step in incremental planning is to select + +4 +00:00:10,450 --> 00:00:14,120 +user stories for a given release, and which stories exactly to include + +5 +00:00:14,120 --> 00:00:16,975 +depends on the time available and on the priority. For example, + +6 +00:00:16,975 --> 00:00:19,147 +scenarios that we might want to realize right away because they are + +7 +00:00:19,147 --> 00:00:22,110 +particular important for the customer. After we select user stories for + +8 +00:00:22,110 --> 00:00:25,200 +the release, we break stories i to tasks. So what we do, + +9 +00:00:25,200 --> 00:00:29,260 +we take the user stories and we identify specific development tasks + +10 +00:00:29,260 --> 00:00:32,320 +that we need to perform in order to realize these stories. Once + +11 +00:00:32,320 --> 00:00:34,780 +we know our tasks, we can plan our release. And at + +12 +00:00:34,780 --> 00:00:38,050 +that point, we can develop, integrate and test our code. And of + +13 +00:00:38,050 --> 00:00:41,170 +course, this is more kind of an iterative process right here, + +14 +00:00:41,170 --> 00:00:44,250 +so we do this many times. When we're ready, when we accomplish + +15 +00:00:44,250 --> 00:00:46,990 +all of our tasks, all of our tests pass and we're happy, + +16 +00:00:46,990 --> 00:00:50,410 +we release this software. At the point, the released software is evaluated + +17 +00:00:50,410 --> 00:00:53,250 +by us, by the customer, and we can reiterate. We can + +18 +00:00:53,250 --> 00:00:56,360 +continue the process, select more stories and continue it this way. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/7 - Small Releases - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/7 - Small Releases - lang_en_vs4.srt new file mode 100644 index 0000000..0437621 --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/7 - Small Releases - lang_en_vs4.srt @@ -0,0 +1,95 @@ +1 +00:00:00,210 --> 00:00:02,790 +The first practice that we just saw goes together with + +2 +00:00:02,790 --> 00:00:06,320 +small releases practice. This idea that instead of having a big + +3 +00:00:06,320 --> 00:00:09,390 +release at the end of a long development cycle, we try + +4 +00:00:09,390 --> 00:00:12,610 +to release very often. And there are many advantages to small + +5 +00:00:12,610 --> 00:00:15,260 +releases and to releasing often. The first one is that + +6 +00:00:15,260 --> 00:00:18,980 +we deliver real business value on a very short cycle. And + +7 +00:00:18,980 --> 00:00:22,070 +what that means is that we get business value sooner, and + +8 +00:00:22,070 --> 00:00:25,550 +that in turn increase our customer confidence and makes the customer + +9 +00:00:25,550 --> 00:00:29,040 +more happy. So more releases also mean rapid feedback. We + +10 +00:00:29,040 --> 00:00:32,420 +release the software soon, we get feedback from the customer soon, + +11 +00:00:32,420 --> 00:00:34,710 +and we can in this way do exactly what we + +12 +00:00:34,710 --> 00:00:38,510 +were saying before, steer instead of driving, adapt weekly to possible + +13 +00:00:38,510 --> 00:00:41,680 +changes in the requirements. We avoid working for six months + +14 +00:00:41,680 --> 00:00:43,970 +on a project and find out six months later that the + +15 +00:00:43,970 --> 00:00:46,950 +customer wanted something else and we got the wrong requirements. In + +16 +00:00:46,950 --> 00:00:50,610 +addition having small releases, so seeing your product deployed and released + +17 +00:00:50,610 --> 00:00:54,040 +soon produces a sense of accomplishment for the developers. + +18 +00:00:54,040 --> 00:00:57,000 +And in addition, it also reduces risk because again, + +19 +00:00:57,000 --> 00:00:58,640 +if we're going down the wrong path, we will + +20 +00:00:58,640 --> 00:01:00,730 +know right away. If we're late, we will know right + +21 +00:01:00,730 --> 00:01:03,370 +away. So these are just additional advantages of having + +22 +00:01:03,370 --> 00:01:06,140 +this quick cycle and more releases. And finally, as we + +23 +00:01:06,140 --> 00:01:09,130 +also said before, we can quickly adapt in the + +24 +00:01:09,130 --> 00:01:12,540 +case our requirements change our code to the new requirements. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/8 - Simple Design - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/8 - Simple Design - lang_en_vs4.srt new file mode 100644 index 0000000..3a8962c --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/8 - Simple Design - lang_en_vs4.srt @@ -0,0 +1,63 @@ +1 +00:00:00,160 --> 00:00:02,790 +The next practice is simple design. We want to avoid + +2 +00:00:02,790 --> 00:00:07,330 +creating a huge complicated possibly cumbersome design at the beginning of + +3 +00:00:07,330 --> 00:00:09,730 +the project. What we want to have instead is just + +4 +00:00:09,730 --> 00:00:14,580 +enough design to meet the requirements, so no duplicated functionality, fewest + +5 +00:00:14,580 --> 00:00:17,910 +possible classes and methods in general, just the amount of + +6 +00:00:17,910 --> 00:00:20,860 +design that we need to get our system to work. So + +7 +00:00:20,860 --> 00:00:23,012 +one might object that to for designing that way we + +8 +00:00:23,012 --> 00:00:25,210 +will have to change the code a lot, we will need + +9 +00:00:25,210 --> 00:00:27,300 +to adapt the design as the code evolves, + +10 +00:00:27,300 --> 00:00:29,180 +and that's exactly the point. That's what we will + +11 +00:00:29,180 --> 00:00:31,670 +do. XP is all about changing and adapting, + +12 +00:00:31,670 --> 00:00:34,850 +changing your design, changing your code, refactoring. And with + +13 +00:00:34,850 --> 00:00:37,420 +the fact that we have test cases throughout + +14 +00:00:37,420 --> 00:00:39,770 +the development process, we can do that with confidence. + +15 +00:00:39,770 --> 00:00:41,220 +Because if we break something we will know + +16 +00:00:41,220 --> 00:00:43,590 +right away, which leads us to the next practice. diff --git a/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/9 - Test First Development - lang_en_vs4.srt b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/9 - Test First Development - lang_en_vs4.srt new file mode 100644 index 0000000..b2a461b --- /dev/null +++ b/usth/ICT2.7/P4L4 Agile Development Methods Subtitles/9 - Test First Development - lang_en_vs4.srt @@ -0,0 +1,59 @@ +1 +00:00:00,040 --> 00:00:03,610 +Which is test-first development. The key idea is that any program + +2 +00:00:03,610 --> 00:00:07,210 +feature that doesn't have an automatic test simply does not exist. If + +3 +00:00:07,210 --> 00:00:09,430 +there is a feature, you need to write a test for the + +4 +00:00:09,430 --> 00:00:13,630 +feature before. So, what developers do is to create unit tests for + +5 +00:00:13,630 --> 00:00:17,420 +each such piece of functionality even before the functionality is implemented. + +6 +00:00:17,420 --> 00:00:19,720 +And of course, when you run this test, they will fail. But + +7 +00:00:19,720 --> 00:00:22,190 +the beauty of it is that, as you write your code and + +8 +00:00:22,190 --> 00:00:25,680 +you add more and more fractionality to the feature that you're developing, + +9 +00:00:25,680 --> 00:00:27,820 +these test cases are going to start to pass. + +10 +00:00:27,820 --> 00:00:30,190 +And that's extremely rewarding because it gives you immediate + +11 +00:00:30,190 --> 00:00:32,530 +feedback, again feedback on the fact that you're + +12 +00:00:32,530 --> 00:00:34,530 +developing the code in the right way. As soon + +13 +00:00:34,530 --> 00:00:37,000 +as you write it, you will know. And if you write a piece of code and the + +14 +00:00:37,000 --> 00:00:38,550 +test says still fail, that means that the + +15 +00:00:38,550 --> 00:00:40,140 +code is not doing what it's supposed to do. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/1 - Lesson Overview - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/1 - Lesson Overview - lang_en_vs4.srt new file mode 100644 index 0000000..bab48c0 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/1 - Lesson Overview - lang_en_vs4.srt @@ -0,0 +1,71 @@ +1 +00:00:00,140 --> 00:00:02,220 +In the previous lesson, we discussed agile + +2 +00:00:02,220 --> 00:00:05,689 +software development. Its principles and practices. And two + +3 +00:00:05,689 --> 00:00:10,060 +specific agile processes. XP and Scrub. In + +4 +00:00:10,060 --> 00:00:12,230 +this lesson, we will introduce a practice that + +5 +00:00:12,230 --> 00:00:15,020 +is of fundamental importance in the context + +6 +00:00:15,020 --> 00:00:20,120 +of agile software development. Software refactoring. Software refactoring + +7 +00:00:20,120 --> 00:00:22,030 +is the process of taking a program and + +8 +00:00:22,030 --> 00:00:25,040 +transforming it to make it better. That is, + +9 +00:00:25,040 --> 00:00:27,240 +to make it easier to understand, make it + +10 +00:00:27,240 --> 00:00:29,880 +more maintainable, and in general to improve its + +11 +00:00:29,880 --> 00:00:34,300 +design. Specifically, we will discuss what the refactoring + +12 +00:00:34,300 --> 00:00:37,680 +is and why it is important? When to perform + +13 +00:00:37,680 --> 00:00:40,980 +refactoring, and when not to perform refactoring? And + +14 +00:00:40,980 --> 00:00:44,520 +how to perform refactoring in a fully automated way, + +15 +00:00:44,520 --> 00:00:47,293 +using tools. We will also introduce the concept + +16 +00:00:47,293 --> 00:00:50,040 +of bad smells, where a bad smell, in software, + +17 +00:00:50,040 --> 00:00:53,323 +is the indication that there might be something wrong with + +18 +00:00:53,323 --> 00:00:56,890 +the code that might call for the application of refactoring. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/10 - Consolidate Conditional Expression Solution - lang_en_vs3.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/10 - Consolidate Conditional Expression Solution - lang_en_vs3.srt new file mode 100644 index 0000000..89f2722 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/10 - Consolidate Conditional Expression Solution - lang_en_vs3.srt @@ -0,0 +1,55 @@ +1 +00:00:00,080 --> 00:00:03,230 +So the resulting code will be like this. As you can see here, + +2 +00:00:03,230 --> 00:00:06,602 +now I don't have the conditionals any longer, but I just have a call to + +3 +00:00:06,602 --> 00:00:09,938 +this notEligibleForDisability method. And this makes the code so + +4 +00:00:09,938 --> 00:00:14,092 +much clearer, because if I just need to understand how disabilityAmount works, + +5 +00:00:14,092 --> 00:00:17,945 +I can clearly see there is an initial check that is actually checking whether + +6 +00:00:17,945 --> 00:00:22,030 +an employee's eligible for disabilities or not. And if the check is false, so + +7 +00:00:22,030 --> 00:00:26,180 +if the employee's eligible, then I'll just perform the rest of the computation. + +8 +00:00:26,180 --> 00:00:27,710 +Otherwise I'll simply return zero. + +9 +00:00:27,710 --> 00:00:30,500 +So if I don't need to understand the details of this check, + +10 +00:00:30,500 --> 00:00:33,630 +I can simply look at this method and understand it all. And if I need to look at + +11 +00:00:33,630 --> 00:00:36,990 +the details I can just go, and look at the implementation of this method, + +12 +00:00:36,990 --> 00:00:39,600 +and I will get exactly the same information that I have here. But I'm sort of + +13 +00:00:39,600 --> 00:00:43,220 +separating the concerns, and making the code overall more understandable, and + +14 +00:00:43,220 --> 00:00:46,160 +therefore more maintainable, which is the main goal of refactoring. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en-us_vs2.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en-us_vs2.srt new file mode 100644 index 0000000..ef89eb8 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en-us_vs2.srt @@ -0,0 +1,263 @@ +1 +00:00:00,080 --> 00:00:02,740 +Let's now see a related refactoring, which is the + +2 +00:00:02,740 --> 00:00:06,200 +decompose conditional refactoring. What happens here is that in some + +3 +00:00:06,200 --> 00:00:08,980 +cases, the complexity of the conditional logic in a program + +4 +00:00:08,980 --> 00:00:12,040 +can make a method hard to read and understand. Specifically + +5 +00:00:12,040 --> 00:00:15,760 +we might have one or more particularly complex conditional + +6 +00:00:15,760 --> 00:00:18,580 +statements. And similar to what we discussed for the previous + +7 +00:00:18,580 --> 00:00:21,630 +refactoring, the conditional, if it's too complex, might tell you + +8 +00:00:21,630 --> 00:00:25,170 +what happens, but obscure why it happens. To address this + +9 +00:00:25,170 --> 00:00:27,520 +issue, you can do a similar thing to what we did in + +10 +00:00:27,520 --> 00:00:31,800 +the previous refactoring. You can transform the condition into a method and then + +11 +00:00:31,800 --> 00:00:35,260 +replace the condition with a call to that method. And if you give + +12 +00:00:35,260 --> 00:00:37,930 +the right name to the method, as we saw in the last example, + +13 +00:00:37,930 --> 00:00:41,730 +that can make the code much clearer and much easier to understand. In + +14 +00:00:41,730 --> 00:00:44,360 +addition here you can also do something else. Let's assume that those are + +15 +00:00:44,360 --> 00:00:47,430 +the then and else part of the conditional are complex. We can do + +16 +00:00:47,430 --> 00:00:50,180 +the same thing with them. So what we can do, we can modify + +17 +00:00:50,180 --> 00:00:53,570 +the then and else part of the conditional by extracting the corresponding + +18 +00:00:53,570 --> 00:00:57,070 +code, making also that one into a method, suitably naming the method, + +19 +00:00:57,070 --> 00:00:59,930 +and then having the call to the method only in the then + +20 +00:00:59,930 --> 00:01:03,540 +and else part of the conditional statement. So let's see how that works + +21 +00:01:03,540 --> 00:01:06,940 +with an example. Here we have the matter that computes some charge. + +22 +00:01:06,940 --> 00:01:10,350 +And it computes the charge based on some corrective uses of the date + +23 +00:01:10,350 --> 00:01:12,930 +that is provided as input, or it's imagined or is just, you + +24 +00:01:12,930 --> 00:01:15,410 +know, one of the fields in the class. So as you can see, + +25 +00:01:15,410 --> 00:01:18,140 +there is a conditional here that checks that if the + +26 +00:01:18,140 --> 00:01:21,535 +dates is before the beginning of the summer, so before summer + +27 +00:01:21,535 --> 00:01:25,180 +start. Or it's after the summer end. Then it compute + +28 +00:01:25,180 --> 00:01:29,152 +the charge using some winterRate. Otherwise, if we are in the + +29 +00:01:29,152 --> 00:01:32,288 +summer, it will compute the quantity, the charge using a + +30 +00:01:32,288 --> 00:01:35,440 +summerRate. And this is just a small example, so it might + +31 +00:01:35,440 --> 00:01:37,990 +not look that complex. But, you know, just project this on + +32 +00:01:37,990 --> 00:01:40,458 +more realistic code, on larger code. You can end up with + +33 +00:01:40,458 --> 00:01:43,656 +the conditions that are hard to understand. And even in this case, even + +34 +00:01:43,656 --> 00:01:45,944 +such a small piece of code, you have to kind of look at + +35 +00:01:45,944 --> 00:01:48,752 +the conditionals, figure out what does it mean for the date to be + +36 +00:01:48,752 --> 00:01:51,800 +before the summer start and after the summer end. We can make this much + +37 +00:01:51,800 --> 00:01:54,780 +clearer. So, how can we do it? By applying this refactoring as we + +38 +00:01:54,780 --> 00:01:56,190 +described. Let's see what happens when + +39 +00:01:56,190 --> 00:01:58,380 +I apply the decompose conditionals refactoring to + +40 +00:01:58,380 --> 00:02:01,530 +this method. The first thing I will do is to take this condition, + +41 +00:02:01,530 --> 00:02:05,640 +create a method that perform exactly the same check, give it a meaningful name. + +42 +00:02:05,640 --> 00:02:09,380 +In this case I called it notSummer, which is pretty self-explanatory, and then + +43 +00:02:09,380 --> 00:02:12,340 +replacing the condition with a call to that matter. As you can see + +44 +00:02:12,340 --> 00:02:15,230 +here, there's a clear improvement in the code, because here I just need + +45 +00:02:15,230 --> 00:02:17,810 +to look at this statement and I see right away that the check. What + +46 +00:02:17,810 --> 00:02:20,680 +the check is doing is just checking whether the date is in the + +47 +00:02:20,680 --> 00:02:24,320 +summer or not. So, much easier than having to interpret this condition. And + +48 +00:02:24,320 --> 00:02:26,910 +the second thing I do is to take the code that computes the + +49 +00:02:26,910 --> 00:02:28,600 +charge and also in this case, creating + +50 +00:02:28,600 --> 00:02:31,028 +suitable methods that compute the winterCharge and + +51 +00:02:31,028 --> 00:02:34,838 +the summerCharge. And I called them exactly winterCharge and summerCharge which + +52 +00:02:34,838 --> 00:02:38,278 +again is self explanatory. And then I replace this computation with + +53 +00:02:38,278 --> 00:02:40,710 +a call to that method. So again, when I look at + +54 +00:02:40,710 --> 00:02:43,280 +this code, I can clearly see that the charge is computed + +55 +00:02:43,280 --> 00:02:46,570 +using some sort of winterCharge calculation and then using some sort + +56 +00:02:46,570 --> 00:02:50,490 +of summerCharge calculation. And if I don't want to know how + +57 +00:02:50,490 --> 00:02:52,670 +this is exactly computed, that's all I need to know to + +58 +00:02:52,670 --> 00:02:56,100 +understand what this method does. Easier and faster than looking at + +59 +00:02:56,100 --> 00:02:57,970 +this method and figuring out what it does. And if + +60 +00:02:57,970 --> 00:02:59,950 +I need to look at the details, exactly like in the + +61 +00:02:59,950 --> 00:03:01,550 +previous case, I can just go and look at the + +62 +00:03:01,550 --> 00:03:04,170 +implementation of winterCharge and summerCharge. But I will be looking at + +63 +00:03:04,170 --> 00:03:06,980 +that in its specific context. So, without having to understand + +64 +00:03:06,980 --> 00:03:09,760 +everything at once. So in this way, you make it clear + +65 +00:03:09,760 --> 00:03:12,840 +both why you're doing something, because it is notSummer, and + +66 +00:03:12,840 --> 00:03:16,300 +what exactly you're doing. You're computing a winterCharge, or a summerCharge. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en_vs8.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en_vs8.srt new file mode 100644 index 0000000..ef89eb8 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/11 - Decompose Conditionals - lang_en_vs8.srt @@ -0,0 +1,263 @@ +1 +00:00:00,080 --> 00:00:02,740 +Let's now see a related refactoring, which is the + +2 +00:00:02,740 --> 00:00:06,200 +decompose conditional refactoring. What happens here is that in some + +3 +00:00:06,200 --> 00:00:08,980 +cases, the complexity of the conditional logic in a program + +4 +00:00:08,980 --> 00:00:12,040 +can make a method hard to read and understand. Specifically + +5 +00:00:12,040 --> 00:00:15,760 +we might have one or more particularly complex conditional + +6 +00:00:15,760 --> 00:00:18,580 +statements. And similar to what we discussed for the previous + +7 +00:00:18,580 --> 00:00:21,630 +refactoring, the conditional, if it's too complex, might tell you + +8 +00:00:21,630 --> 00:00:25,170 +what happens, but obscure why it happens. To address this + +9 +00:00:25,170 --> 00:00:27,520 +issue, you can do a similar thing to what we did in + +10 +00:00:27,520 --> 00:00:31,800 +the previous refactoring. You can transform the condition into a method and then + +11 +00:00:31,800 --> 00:00:35,260 +replace the condition with a call to that method. And if you give + +12 +00:00:35,260 --> 00:00:37,930 +the right name to the method, as we saw in the last example, + +13 +00:00:37,930 --> 00:00:41,730 +that can make the code much clearer and much easier to understand. In + +14 +00:00:41,730 --> 00:00:44,360 +addition here you can also do something else. Let's assume that those are + +15 +00:00:44,360 --> 00:00:47,430 +the then and else part of the conditional are complex. We can do + +16 +00:00:47,430 --> 00:00:50,180 +the same thing with them. So what we can do, we can modify + +17 +00:00:50,180 --> 00:00:53,570 +the then and else part of the conditional by extracting the corresponding + +18 +00:00:53,570 --> 00:00:57,070 +code, making also that one into a method, suitably naming the method, + +19 +00:00:57,070 --> 00:00:59,930 +and then having the call to the method only in the then + +20 +00:00:59,930 --> 00:01:03,540 +and else part of the conditional statement. So let's see how that works + +21 +00:01:03,540 --> 00:01:06,940 +with an example. Here we have the matter that computes some charge. + +22 +00:01:06,940 --> 00:01:10,350 +And it computes the charge based on some corrective uses of the date + +23 +00:01:10,350 --> 00:01:12,930 +that is provided as input, or it's imagined or is just, you + +24 +00:01:12,930 --> 00:01:15,410 +know, one of the fields in the class. So as you can see, + +25 +00:01:15,410 --> 00:01:18,140 +there is a conditional here that checks that if the + +26 +00:01:18,140 --> 00:01:21,535 +dates is before the beginning of the summer, so before summer + +27 +00:01:21,535 --> 00:01:25,180 +start. Or it's after the summer end. Then it compute + +28 +00:01:25,180 --> 00:01:29,152 +the charge using some winterRate. Otherwise, if we are in the + +29 +00:01:29,152 --> 00:01:32,288 +summer, it will compute the quantity, the charge using a + +30 +00:01:32,288 --> 00:01:35,440 +summerRate. And this is just a small example, so it might + +31 +00:01:35,440 --> 00:01:37,990 +not look that complex. But, you know, just project this on + +32 +00:01:37,990 --> 00:01:40,458 +more realistic code, on larger code. You can end up with + +33 +00:01:40,458 --> 00:01:43,656 +the conditions that are hard to understand. And even in this case, even + +34 +00:01:43,656 --> 00:01:45,944 +such a small piece of code, you have to kind of look at + +35 +00:01:45,944 --> 00:01:48,752 +the conditionals, figure out what does it mean for the date to be + +36 +00:01:48,752 --> 00:01:51,800 +before the summer start and after the summer end. We can make this much + +37 +00:01:51,800 --> 00:01:54,780 +clearer. So, how can we do it? By applying this refactoring as we + +38 +00:01:54,780 --> 00:01:56,190 +described. Let's see what happens when + +39 +00:01:56,190 --> 00:01:58,380 +I apply the decompose conditionals refactoring to + +40 +00:01:58,380 --> 00:02:01,530 +this method. The first thing I will do is to take this condition, + +41 +00:02:01,530 --> 00:02:05,640 +create a method that perform exactly the same check, give it a meaningful name. + +42 +00:02:05,640 --> 00:02:09,380 +In this case I called it notSummer, which is pretty self-explanatory, and then + +43 +00:02:09,380 --> 00:02:12,340 +replacing the condition with a call to that matter. As you can see + +44 +00:02:12,340 --> 00:02:15,230 +here, there's a clear improvement in the code, because here I just need + +45 +00:02:15,230 --> 00:02:17,810 +to look at this statement and I see right away that the check. What + +46 +00:02:17,810 --> 00:02:20,680 +the check is doing is just checking whether the date is in the + +47 +00:02:20,680 --> 00:02:24,320 +summer or not. So, much easier than having to interpret this condition. And + +48 +00:02:24,320 --> 00:02:26,910 +the second thing I do is to take the code that computes the + +49 +00:02:26,910 --> 00:02:28,600 +charge and also in this case, creating + +50 +00:02:28,600 --> 00:02:31,028 +suitable methods that compute the winterCharge and + +51 +00:02:31,028 --> 00:02:34,838 +the summerCharge. And I called them exactly winterCharge and summerCharge which + +52 +00:02:34,838 --> 00:02:38,278 +again is self explanatory. And then I replace this computation with + +53 +00:02:38,278 --> 00:02:40,710 +a call to that method. So again, when I look at + +54 +00:02:40,710 --> 00:02:43,280 +this code, I can clearly see that the charge is computed + +55 +00:02:43,280 --> 00:02:46,570 +using some sort of winterCharge calculation and then using some sort + +56 +00:02:46,570 --> 00:02:50,490 +of summerCharge calculation. And if I don't want to know how + +57 +00:02:50,490 --> 00:02:52,670 +this is exactly computed, that's all I need to know to + +58 +00:02:52,670 --> 00:02:56,100 +understand what this method does. Easier and faster than looking at + +59 +00:02:56,100 --> 00:02:57,970 +this method and figuring out what it does. And if + +60 +00:02:57,970 --> 00:02:59,950 +I need to look at the details, exactly like in the + +61 +00:02:59,950 --> 00:03:01,550 +previous case, I can just go and look at the + +62 +00:03:01,550 --> 00:03:04,170 +implementation of winterCharge and summerCharge. But I will be looking at + +63 +00:03:04,170 --> 00:03:06,980 +that in its specific context. So, without having to understand + +64 +00:03:06,980 --> 00:03:09,760 +everything at once. So in this way, you make it clear + +65 +00:03:09,760 --> 00:03:12,840 +both why you're doing something, because it is notSummer, and + +66 +00:03:12,840 --> 00:03:16,300 +what exactly you're doing. You're computing a winterCharge, or a summerCharge. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/12 - Extract Class - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/12 - Extract Class - lang_en_vs4.srt new file mode 100644 index 0000000..07c93ed --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/12 - Extract Class - lang_en_vs4.srt @@ -0,0 +1,99 @@ +1 +00:00:00,100 --> 00:00:02,890 +We are now going to talk about the extract class refactoring. When a + +2 +00:00:02,890 --> 00:00:06,040 +softer system evolves, we might end up with classes that really do the + +3 +00:00:06,040 --> 00:00:09,210 +work of more than one class because we keep adding functionality to + +4 +00:00:09,210 --> 00:00:11,010 +the class. Therefore also they're too + +5 +00:00:11,010 --> 00:00:13,160 +big, too complicated. In particular, we might + +6 +00:00:13,160 --> 00:00:15,250 +end up with a class that is doing the work of two + +7 +00:00:15,250 --> 00:00:18,890 +classes. Typical examples are classes with many methods and quite a lot of + +8 +00:00:18,890 --> 00:00:22,520 +data, quite a lot of fields. In this case, it's normally good idea + +9 +00:00:22,520 --> 00:00:25,120 +to split the class into two, so what you will do, you will + +10 +00:00:25,120 --> 00:00:28,700 +create a new class and move there the relevant fields and methods from + +11 +00:00:28,700 --> 00:00:31,700 +the original class. So as to have two classes, each one implementing a + +12 +00:00:31,700 --> 00:00:34,900 +piece of the functionality. Let's look at an example. In this case we're + +13 +00:00:34,900 --> 00:00:38,850 +going to use a UML like representation for the class. We have this class Person + +14 +00:00:38,850 --> 00:00:41,769 +that ends up representing also a phone number. And imagine that we add + +15 +00:00:41,769 --> 00:00:44,500 +up these pieces, you know, a little bit at the time so we end + +16 +00:00:44,500 --> 00:00:47,430 +up with something that really is doing the job of the person and + +17 +00:00:47,430 --> 00:00:50,490 +of the phone number. So what we can do, we can actually do exactly + +18 +00:00:50,490 --> 00:00:52,650 +what we described here. We split this class + +19 +00:00:52,650 --> 00:00:55,470 +into a Person class, and the Phone Number class. + +20 +00:00:55,470 --> 00:00:57,440 +And then we establish a use relation, so we + +21 +00:00:57,440 --> 00:00:59,470 +have a reference of the phone number class into + +22 +00:00:59,470 --> 00:01:01,960 +this class. And by separating the telephone number behavior + +23 +00:01:01,960 --> 00:01:04,680 +into its own class, I once more improved the + +24 +00:01:04,680 --> 00:01:06,980 +structure of the code, because now I have classes + +25 +00:01:06,980 --> 00:01:09,070 +that are more cohesive, and do exactly one thing. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/13 - Inline Class - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/13 - Inline Class - lang_en_vs4.srt new file mode 100644 index 0000000..a7f7f2f --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/13 - Inline Class - lang_en_vs4.srt @@ -0,0 +1,75 @@ +1 +00:00:00,150 --> 00:00:03,825 +This new refactoring called inline class is the reverse of the extract class + +2 +00:00:03,825 --> 00:00:06,700 +refactoring. And know that this is kind of a general situation in the + +3 +00:00:06,700 --> 00:00:09,500 +sense that it is often the case that the refactoring also has a + +4 +00:00:09,500 --> 00:00:11,480 +reverse refactoring that does exactly the + +5 +00:00:11,480 --> 00:00:13,202 +opposite. So basically, un-dos, in a sense, + +6 +00:00:13,202 --> 00:00:16,830 +the operation of the other refactoring. In this case, the motivation for the + +7 +00:00:16,830 --> 00:00:19,760 +refactoring is that during system evolution, we might end up with one or + +8 +00:00:19,760 --> 00:00:22,530 +more classes that do not do much. In this case what you want + +9 +00:00:22,530 --> 00:00:25,350 +to do is to take the class that is not doing that much and + +10 +00:00:25,350 --> 00:00:28,740 +move its features into another class. And then delete the original class. + +11 +00:00:28,740 --> 00:00:31,010 +So lets use an example similar to the one we've used for + +12 +00:00:31,010 --> 00:00:34,000 +the previous refactoring to illustrate how this works. Here we have in + +13 +00:00:34,000 --> 00:00:37,750 +this case, two classes, person and office. And the person class is + +14 +00:00:37,750 --> 00:00:40,720 +using the office class, but this latter class, the office class, only + +15 +00:00:40,720 --> 00:00:44,000 +contains a phone number. So it doesn't really do that much. What + +16 +00:00:44,000 --> 00:00:47,020 +we can do is therefore to fold the office class into the + +17 +00:00:47,020 --> 00:00:50,470 +person class, by simply moving its only field into the class. And so + +18 +00:00:50,470 --> 00:00:53,260 +the result will be this person class that also contains the information + +19 +00:00:53,260 --> 00:00:56,600 +about the office number, and overall a simpler design for the code. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/14 - Extract Method - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/14 - Extract Method - lang_en_vs4.srt new file mode 100644 index 0000000..88769e0 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/14 - Extract Method - lang_en_vs4.srt @@ -0,0 +1,163 @@ +1 +00:00:00,060 --> 00:00:02,406 +The next re-factoring which is also the last one that we'll + +2 +00:00:02,406 --> 00:00:05,640 +see, extract method is one of the most commonly used re-factoring. As + +3 +00:00:05,640 --> 00:00:09,080 +it is applicable in many, many situations. The starting point is + +4 +00:00:09,080 --> 00:00:12,720 +a method that is too long and contains cohesive code fragments, that + +5 +00:00:12,720 --> 00:00:16,180 +really serve a single very specific purpose. So we start from + +6 +00:00:16,180 --> 00:00:19,270 +a cohesive code fragment in a large method. What we can do + +7 +00:00:19,270 --> 00:00:22,370 +in this case, is to create a method using that code fragment. + +8 +00:00:22,370 --> 00:00:25,620 +And then replacing the code fragment with a call to that method. + +9 +00:00:25,620 --> 00:00:28,390 +Let's look at this with an example. Here over this method called + +10 +00:00:28,390 --> 00:00:31,070 +print owing, and what it does, imagine that it does a lot + +11 +00:00:31,070 --> 00:00:33,850 +of operations here that I'm just not listing, and then it's got + +12 +00:00:33,850 --> 00:00:37,620 +a set of print statements. That are just printing a lot of details + +13 +00:00:37,620 --> 00:00:41,280 +about the owing information. And then again, a lot of code after + +14 +00:00:41,280 --> 00:00:44,270 +that. So what I could do in this case to simplify. The + +15 +00:00:44,270 --> 00:00:47,940 +method is to transform this set of statements. They are cohesive in + +16 +00:00:47,940 --> 00:00:51,120 +the sense that they do just one thing, they just print these details + +17 +00:00:51,120 --> 00:00:53,890 +into a method, and then I had, replace the statements with a + +18 +00:00:53,890 --> 00:00:56,740 +call to that method. Which is actually something similar to what we did + +19 +00:00:56,740 --> 00:00:59,900 +as part of some the previous re-factoring's. Here I'm showing the result. + +20 +00:00:59,900 --> 00:01:02,770 +So here is the method that I extracted. As you can see. It + +21 +00:01:02,770 --> 00:01:05,790 +contains the code that was previously here. I give you the meaningful + +22 +00:01:05,790 --> 00:01:09,080 +name, I called it printDetails so it's clear what it does. And now + +23 +00:01:09,080 --> 00:01:12,820 +the print owning method is simpler. Because I still have the remaining code + +24 +00:01:12,820 --> 00:01:17,200 +the one I didn't touch. But now this potentially long list of details. + +25 +00:01:17,200 --> 00:01:20,560 +Of prints, of details is not replaced by a single method code. + +26 +00:01:20,560 --> 00:01:23,550 +So a gain similar to the previous refactorings that we saw. If + +27 +00:01:23,550 --> 00:01:26,370 +we just look at the printing method, it's very easy to figure + +28 +00:01:26,370 --> 00:01:29,490 +out what this part does. Oh, print some details. And once more I + +29 +00:01:29,490 --> 00:01:33,060 +really want to stress this. If you don't care about how, this + +30 +00:01:33,060 --> 00:01:36,350 +is implemented and knowing that this print some details is enough. Then + +31 +00:01:36,350 --> 00:01:38,980 +you're done. You don't need to understand anything more. It's clear, it's + +32 +00:01:38,980 --> 00:01:42,430 +self explanatory. And if you'll need to look at what print details does, + +33 +00:01:42,430 --> 00:01:44,390 +you just go and look at print details. And you look at + +34 +00:01:44,390 --> 00:01:47,280 +it in isolation. So it's easier to understand what this does without having + +35 +00:01:47,280 --> 00:01:49,640 +to think the rest of the code. So once more the color we + +36 +00:01:49,640 --> 00:01:52,740 +factor in is just to improve your design, made the code more readable + +37 +00:01:52,740 --> 00:01:56,020 +Make the code more maintainable. And also keep in mind all of these, + +38 +00:01:56,020 --> 00:01:59,080 +are kind of small examples. You also always have to think about the + +39 +00:01:59,080 --> 00:02:02,560 +effect that this can have on larger codebases. It can really improve a + +40 +00:02:02,560 --> 00:02:05,280 +lot. The understandabililty, and maintainability of + +41 +00:02:05,280 --> 00:02:07,220 +your code. So in general, it's design. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/15 - Refactoring Demo - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/15 - Refactoring Demo - lang_en_vs4.srt new file mode 100644 index 0000000..0559c88 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/15 - Refactoring Demo - lang_en_vs4.srt @@ -0,0 +1,599 @@ +1 +00:00:00,090 --> 00:00:03,110 +So now we saw, this set of re-factoring's. They're nice, but + +2 +00:00:03,110 --> 00:00:06,260 +how can we actually perform re-factoring's? In some cases you'll have to + +3 +00:00:06,260 --> 00:00:08,430 +do it by hand. And you'll do it in that case in + +4 +00:00:08,430 --> 00:00:10,880 +small steps, so that you can check at every step that you + +5 +00:00:10,880 --> 00:00:14,180 +didn't introduce any area. But there's also many cases in which at + +6 +00:00:14,180 --> 00:00:17,640 +least for the more standard re-factoring's, you can just apply, you can + +7 +00:00:17,640 --> 00:00:21,530 +just use a tool that actually supports re-factoring. I'm going to show + +8 +00:00:21,530 --> 00:00:24,550 +you how that works, into a specific ID, Eclipse through a demo. + +9 +00:00:26,120 --> 00:00:28,425 +To show you how Eclipse, can help in performing + +10 +00:00:28,425 --> 00:00:31,880 +re-factoring, in an automated way, I just opened the Eclipse + +11 +00:00:31,880 --> 00:00:35,050 +editor and I maximized it. So that we can look + +12 +00:00:35,050 --> 00:00:36,810 +at the code more clearly. And as you can see + +13 +00:00:36,810 --> 00:00:39,551 +here, I have this class. It's called Re-factorable, it's a + +14 +00:00:39,551 --> 00:00:43,550 +pretty indicative name. And what we're going to do, we're going to + +15 +00:00:43,550 --> 00:00:47,840 +try to apply the extract method re-factoring to this class. + +16 +00:00:47,840 --> 00:00:51,060 +And in particular, to parts of this print owing method. + +17 +00:00:51,060 --> 00:00:54,090 +So this is a matter than will print owing's, + +18 +00:00:54,090 --> 00:00:56,160 +as the name says. And it will do several things + +19 +00:00:56,160 --> 00:00:59,180 +such as, for example, printing a banner first, then + +20 +00:00:59,180 --> 00:01:03,650 +calculating the outstanding debts, and then printing some details. So + +21 +00:01:03,650 --> 00:01:06,980 +the starting point for an extract method re-fractoring, is + +22 +00:01:06,980 --> 00:01:10,650 +the identification of some cohesive code fragment. And here, for + +23 +00:01:10,650 --> 00:01:12,970 +instance, we can see that, if we can see there, + +24 +00:01:12,970 --> 00:01:16,350 +these three print statements. They are basically printing some banner, + +25 +00:01:16,350 --> 00:01:18,530 +for the method. And I also put a comment here + +26 +00:01:18,530 --> 00:01:21,160 +just to make that even more explicit. So this is a + +27 +00:01:21,160 --> 00:01:23,970 +perfect case in which we might want to just extract + +28 +00:01:23,970 --> 00:01:27,220 +this part, create an independent method, so that we can make + +29 +00:01:27,220 --> 00:01:31,410 +the code more readable and maintainable. So I select, the + +30 +00:01:31,410 --> 00:01:33,320 +part of the code, that I want to put in my + +31 +00:01:33,320 --> 00:01:37,080 +method. I invoke the contextual menu, and as you can see + +32 +00:01:37,080 --> 00:01:41,287 +there is a re-factor entry here. Here are some re-factoring's [UNKNOWN], + +33 +00:01:41,287 --> 00:01:45,039 +re-factoring's that I can apply, and I'm going to select extract + +34 +00:01:45,039 --> 00:01:48,120 +method. When I do that, Eclipse is going to ask me to + +35 +00:01:48,120 --> 00:01:51,610 +specify a method name. I'll just call this one print + +36 +00:01:51,610 --> 00:01:54,260 +banner. And as you can see, as soon as I do + +37 +00:01:54,260 --> 00:01:57,310 +that, Eclipse will show me the preview, for the method + +38 +00:01:57,310 --> 00:02:01,010 +that will be generated. I'm going to leave the access modifier. To + +39 +00:02:01,010 --> 00:02:03,290 +public and I'm not going to change anything else. So, + +40 +00:02:03,290 --> 00:02:07,760 +now when I click Ok. As you can see Eclipse modified + +41 +00:02:07,760 --> 00:02:10,669 +my code so that now I have the Print Banner method + +42 +00:02:10,669 --> 00:02:14,050 +down here that does exactly what that piece of code was doing + +43 +00:02:14,050 --> 00:02:16,090 +before. And I just have an invocation of the Print Banner + +44 +00:02:16,090 --> 00:02:19,440 +method, up here, where the code was before. And of course, this + +45 +00:02:19,440 --> 00:02:21,830 +is something that we could have done by hand. It's pretty + +46 +00:02:21,830 --> 00:02:25,480 +easy to do, but it's even easier, to do it using Eclipse's + +47 +00:02:25,480 --> 00:02:29,040 +capabilities. And this will become even more apparent, when we consider slightly + +48 +00:02:29,040 --> 00:02:32,866 +more complex case. So here, if we look at this piece of + +49 +00:02:32,866 --> 00:02:35,234 +code for instance, we can that see this code + +50 +00:02:35,234 --> 00:02:38,264 +prints some details, about the always. And the reason + +51 +00:02:38,264 --> 00:02:41,351 +why this case is likely more complicated, is because + +52 +00:02:41,351 --> 00:02:45,210 +this code needs to know about the value of outstanding. + +53 +00:02:45,210 --> 00:02:49,130 +And whereas that underscore name, is a member of + +54 +00:02:49,130 --> 00:02:51,150 +the class, and therefore will be available to the + +55 +00:02:51,150 --> 00:02:55,110 +method. Outstanding is a locker variable, so a method + +56 +00:02:55,110 --> 00:02:58,310 +different from print, oh it wouldn't know anything about outstanding. + +57 +00:02:58,310 --> 00:03:00,070 +So let's see what happens when we try to apply + +58 +00:03:00,070 --> 00:03:03,460 +a re-factoring for this code. So we go again here + +59 +00:03:03,460 --> 00:03:06,410 +to the re-factor menu, we select extract method, we will + +60 +00:03:06,410 --> 00:03:10,080 +pick a name again. So let's call it [SOUND] print details, + +61 +00:03:10,080 --> 00:03:12,660 +since this is what the code does. And as you + +62 +00:03:12,660 --> 00:03:17,270 +can see here, Eclipse was able to figure out, that outstanding + +63 +00:03:17,270 --> 00:03:20,290 +has to be a parameter, of this method. So if + +64 +00:03:20,290 --> 00:03:23,340 +you look at the signature here, this will be very clear. + +65 +00:03:23,340 --> 00:03:26,270 +So outstanding has to be passed to the matter because + +66 +00:03:26,270 --> 00:03:29,230 +it's a locker variable of the print owing method. so + +67 +00:03:29,230 --> 00:03:32,600 +it will not be visible to the other methods otherwise. + +68 +00:03:32,600 --> 00:03:34,990 +So since eclipse figured it out, all I have to do, + +69 +00:03:34,990 --> 00:03:37,630 +is to press Ok. And at this point what I + +70 +00:03:37,630 --> 00:03:41,280 +will have here is my new method, for in details + +71 +00:03:41,280 --> 00:03:45,140 +that takes outstanding as a parameter. And does exactly what + +72 +00:03:45,140 --> 00:03:48,880 +the code was doing before. And here, where the code was, + +73 +00:03:48,880 --> 00:03:51,630 +I will have my print details invocation, with outstanding + +74 +00:03:51,630 --> 00:03:54,930 +as a parameter. So now, let's continue to extract methods. + +75 +00:03:54,930 --> 00:03:58,470 +And let's look at a even more complex case. which + +76 +00:03:58,470 --> 00:04:01,550 +is, the one involving this piece of code. So this + +77 +00:04:01,550 --> 00:04:03,900 +piece of code, as you can see, will calculate + +78 +00:04:03,900 --> 00:04:07,820 +the value of the outstanding debt. Will calculate the owing's, + +79 +00:04:07,820 --> 00:04:09,600 +and the way in which it does that, is by + +80 +00:04:09,600 --> 00:04:14,080 +considering all the orders, that are part of this enumeration. + +81 +00:04:14,080 --> 00:04:16,519 +That is the declared here, and it will + +82 +00:04:16,519 --> 00:04:20,769 +compute for each one, of these orders, the amount, + +83 +00:04:20,769 --> 00:04:23,520 +and then added to outstanding. So what is the + +84 +00:04:23,520 --> 00:04:26,160 +additional complication here? Well, the additional complication here is + +85 +00:04:26,160 --> 00:04:29,520 +that this code needs to know, not only + +86 +00:04:29,520 --> 00:04:33,220 +about outstanding. It also needs to know, about this + +87 +00:04:33,220 --> 00:04:36,160 +enumeration, because this one is also a local variable. + +88 +00:04:36,160 --> 00:04:39,140 +And in addition to that, this code also has + +89 +00:04:39,140 --> 00:04:43,280 +some side effects. So outstanding, is modified as a + +90 +00:04:43,280 --> 00:04:46,600 +consequence of the execution of this code. So how can + +91 +00:04:46,600 --> 00:04:49,120 +we do that in the extracted method? Well lets + +92 +00:04:49,120 --> 00:04:51,000 +see what the clips will do and what the clips + +93 +00:04:51,000 --> 00:04:53,950 +will suggest. It will try to again re-factor this + +94 +00:04:53,950 --> 00:04:58,030 +code and extract the method. In this case as you + +95 +00:04:58,030 --> 00:05:01,160 +can see. The clips does two things. First of all, + +96 +00:05:01,160 --> 00:05:04,180 +it figures out as before, that there are some parameters, + +97 +00:05:04,180 --> 00:05:07,650 +that are needed for this method to operate correctly. The + +98 +00:05:07,650 --> 00:05:11,600 +enumeration e, as we said, and the outstanding variable. In + +99 +00:05:11,600 --> 00:05:14,880 +addition, if you look at the method signature Eclipse will + +100 +00:05:14,880 --> 00:05:17,490 +also figure out that this method has to return, a + +101 +00:05:17,490 --> 00:05:21,530 +double value. So what does this value correspond to? This + +102 +00:05:21,530 --> 00:05:24,700 +value corresponds to a new value of outstanding. So if + +103 +00:05:24,700 --> 00:05:27,490 +we, give a name to this method, so we just + +104 +00:05:27,490 --> 00:05:29,620 +use the name, [SOUND] that I put in the comment + +105 +00:05:29,620 --> 00:05:33,510 +over there. We click Ok, and this will create + +106 +00:05:33,510 --> 00:05:36,560 +a method by extracting the code. And here, where the + +107 +00:05:36,560 --> 00:05:39,100 +method used to be, we will have that the + +108 +00:05:39,100 --> 00:05:43,169 +value of outstanding is updated. Based on the return value + +109 +00:05:43,169 --> 00:05:46,260 +of calculate outstanding. So in the end if we + +110 +00:05:46,260 --> 00:05:48,730 +look at this code, you can see that if we + +111 +00:05:48,730 --> 00:05:51,980 +just focus, on this code it's very easy to + +112 +00:05:51,980 --> 00:05:55,150 +understand what it does. It prints the banner, it calculates + +113 +00:05:55,150 --> 00:05:59,180 +an outstanding value, and then it prints some details. And + +114 +00:05:59,180 --> 00:06:01,520 +in case we don't care, as I said before, about the + +115 +00:06:01,520 --> 00:06:04,840 +details of what these methods do, we're done. And if we + +116 +00:06:04,840 --> 00:06:07,740 +care about the details we can look at each matter individually. + +117 +00:06:07,740 --> 00:06:10,580 +And get exactly the same information that we got before, + +118 +00:06:10,580 --> 00:06:13,650 +in a sort of a separation of concerns kind of way, + +119 +00:06:13,650 --> 00:06:16,420 +by focusing on one problem at a time. So now let + +120 +00:06:16,420 --> 00:06:19,345 +me do one last thing. So let me modify the code, + +121 +00:06:19,345 --> 00:06:23,170 +slightly. So i'm going to go back, to the version of + +122 +00:06:23,170 --> 00:06:25,610 +the code before re-factoring. So this is what we had. + +123 +00:06:25,610 --> 00:06:32,480 +And I'm going to add, an additional variable here, [SOUND] called count, + +124 +00:06:32,480 --> 00:06:38,870 +which I initialize to zero. Here I'm going to increase, [SOUND] + +125 +00:06:38,870 --> 00:06:41,360 +the value of count at every iteration. And + +126 +00:06:41,360 --> 00:06:44,570 +finally, here I'm going to print out the value + +127 +00:06:44,570 --> 00:06:50,130 +of count. Okay, now that I have this code up. So let's imagine that I + +128 +00:06:50,130 --> 00:06:55,665 +want to, again as I did before, extract this matter. So, I'm going to + +129 +00:06:55,665 --> 00:06:58,430 +give you a second. Have a look at this and see, if you see + +130 +00:06:58,430 --> 00:07:02,170 +any problem with that. Feel free to stop the video, if you need more time. + +131 +00:07:07,350 --> 00:07:11,440 +So the problem here is that I have two side effects. + +132 +00:07:11,440 --> 00:07:14,820 +Both outstanding and count are modified. And therefore it's not really + +133 +00:07:14,820 --> 00:07:19,600 +possible to extract this method, and preserve the semantics of this + +134 +00:07:19,600 --> 00:07:23,260 +code. Let's see if Eclipse will be able to figure that out. + +135 +00:07:26,130 --> 00:07:28,950 +And it does. If we try to extract the matter here, + +136 +00:07:28,950 --> 00:07:32,250 +you'll tell us that's an ambiguous return value. The selected block + +137 +00:07:32,250 --> 00:07:35,800 +contains more than one assignment to look at variables. And the + +138 +00:07:35,800 --> 00:07:40,170 +affected variables are outstanding, just a Double and Count which is + +139 +00:07:40,170 --> 00:07:44,780 +an integer. So it will refuse to extract the method. So + +140 +00:07:44,780 --> 00:07:46,470 +at this point if we wanted to do that we have + +141 +00:07:46,470 --> 00:07:48,650 +we'll have to do the re-factoring a different way, but I + +142 +00:07:48,650 --> 00:07:51,110 +don't really want to get there. I want to conclude here, + +143 +00:07:51,110 --> 00:07:53,440 +and I hope this this little demo helped you + +144 +00:07:53,440 --> 00:07:55,310 +realize how useful it can be to use an + +145 +00:07:55,310 --> 00:07:58,270 +id that supports re-factoring that can automate this important + +146 +00:07:58,270 --> 00:08:00,160 +task. And I also encourage you to try to play + +147 +00:08:00,160 --> 00:08:03,170 +with this, and try to use different re-factoring's, on + +148 +00:08:03,170 --> 00:08:05,480 +your code. So as to get familiar with the kind + +149 +00:08:05,480 --> 00:08:08,060 +of re-factoring's that are supported by the ID. And + +150 +00:08:08,060 --> 00:08:10,800 +also with the re-factoring's themselves and how should be used. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/16 - Extract Method Refactoring Quiz - lang_en_vs5.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/16 - Extract Method Refactoring Quiz - lang_en_vs5.srt new file mode 100644 index 0000000..07f5e44 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/16 - Extract Method Refactoring Quiz - lang_en_vs5.srt @@ -0,0 +1,31 @@ +1 +00:00:00,160 --> 00:00:02,580 +After the demo I would like to have a little quiz + +2 +00:00:02,580 --> 00:00:05,430 +about the extract method refactoring. And I would like to ask you + +3 +00:00:05,430 --> 00:00:08,910 +when is it appropriate to apply the extract method refactoring. Here I + +4 +00:00:08,910 --> 00:00:11,890 +have a set of possible scenarios. First one is when there is + +5 +00:00:11,890 --> 00:00:14,730 +duplicated code in two or more methods. When a class is too + +6 +00:00:14,730 --> 00:00:17,730 +large. When the names of two classes are too similar. Or when + +7 +00:00:17,730 --> 00:00:20,840 +a method is highly coupled with a class other than the one + +8 +00:00:20,840 --> 00:00:24,370 +where it is defined. So as usual, please mark all that apply. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/17 - Extract Method Refactoring Quiz Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/17 - Extract Method Refactoring Quiz Solution - lang_en_vs4.srt new file mode 100644 index 0000000..6545de0 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/17 - Extract Method Refactoring Quiz Solution - lang_en_vs4.srt @@ -0,0 +1,83 @@ +1 +00:00:00,110 --> 00:00:03,000 +The first scenario is the typical case in which it is + +2 +00:00:03,000 --> 00:00:07,040 +recommended to use the extract method refactoring, when there is duplicated code + +3 +00:00:07,040 --> 00:00:09,190 +in two or more methods and we want to take this + +4 +00:00:09,190 --> 00:00:12,420 +code and factor is out, and basically have the two methods called + +5 +00:00:12,420 --> 00:00:14,960 +a third method, which is the one we create using the + +6 +00:00:14,960 --> 00:00:18,060 +refactoring. When a class is too large, normally we don't want to + +7 +00:00:18,060 --> 00:00:21,330 +apply the extract. Extract method. Instead, in this cases, it is + +8 +00:00:21,330 --> 00:00:22,900 +usually more appropriate to use the + +9 +00:00:22,900 --> 00:00:26,420 +extract class or extract subclass refactorings. + +10 +00:00:26,420 --> 00:00:29,750 +Analogously, when the names of two classes are too similar, extracting a + +11 +00:00:29,750 --> 00:00:32,729 +method will normally not help much. And all we need to do + +12 +00:00:32,729 --> 00:00:35,810 +in case having too similar names is actually a problem. Is to + +13 +00:00:35,810 --> 00:00:39,600 +rename one of the two classes, or both, if we wish. Finally, + +14 +00:00:39,600 --> 00:00:42,530 +it is definitely appropriate to apply the extract method of refactoring in + +15 +00:00:42,530 --> 00:00:45,900 +cases in which a method is highly coupled with a class other + +16 +00:00:45,900 --> 00:00:48,330 +than the one where it is defined. In this case, which we + +17 +00:00:48,330 --> 00:00:51,740 +will discuss also later in the lesson, the extract method of refactoring + +18 +00:00:51,740 --> 00:00:55,710 +allows us to extract part of the metal to With the other class. + +19 +00:00:55,710 --> 00:00:58,690 +Then we can take the matter that we just extracted and move it + +20 +00:00:58,690 --> 00:01:01,880 +to the class where it actually belongs. So the extract method is one + +21 +00:01:01,880 --> 00:01:05,560 +of the two refactorings that it is appropriate to apply in these cases. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/18 - Refactoring Risks - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/18 - Refactoring Risks - lang_en_vs4.srt new file mode 100644 index 0000000..0aae00c --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/18 - Refactoring Risks - lang_en_vs4.srt @@ -0,0 +1,143 @@ +1 +00:00:00,150 --> 00:00:02,520 +Now that we saw a number of refactorings, we also saw + +2 +00:00:02,520 --> 00:00:05,950 +how refactorings can be performed automatically within an ID, I'd like + +3 +00:00:05,950 --> 00:00:09,230 +to make you aware of some risks involved with the user + +4 +00:00:09,230 --> 00:00:12,510 +refactorings. Refactorings are a very powerful tool, but you also have to + +5 +00:00:12,510 --> 00:00:15,820 +be careful, first of all when you do more complex refactorings, + +6 +00:00:15,820 --> 00:00:18,540 +you may also introduce subtle faults. What, we don't really call + +7 +00:00:18,540 --> 00:00:21,040 +regression errors. You might change something in the class. You might + +8 +00:00:21,040 --> 00:00:23,140 +think that that's a behavior preserving + +9 +00:00:23,140 --> 00:00:25,200 +transformation when considering the whole code, + +10 +00:00:25,200 --> 00:00:27,860 +and instead your change is affecting the behavior of some of the + +11 +00:00:27,860 --> 00:00:30,980 +other parts of the code. So, it's introducing a regression that will cause + +12 +00:00:30,980 --> 00:00:32,670 +some other functionality, some other piece + +13 +00:00:32,670 --> 00:00:34,320 +of functionality some other feature, to + +14 +00:00:34,320 --> 00:00:37,190 +work incorrectly. So you always have to be careful, and as we saw + +15 +00:00:37,190 --> 00:00:39,750 +at the beginning one way to avoid that is to run tests. + +16 +00:00:39,750 --> 00:00:43,080 +Every time you make a refactoring every time you change your code and + +17 +00:00:43,080 --> 00:00:46,280 +refactor your code. So is to get the least some confidence in + +18 +00:00:46,280 --> 00:00:47,540 +the fact that your refactoring is + +19 +00:00:47,540 --> 00:00:50,290 +indeed behavior preserving. Also consider the refactoring + +20 +00:00:50,290 --> 00:00:54,680 +should not. Be abused. Refactoring should be performed when it's needed. It's + +21 +00:00:54,680 --> 00:00:57,570 +useful to improve the design of your code when you see problems + +22 +00:00:57,570 --> 00:00:59,680 +with the design of the code. Shouldn't just be applied for the + +23 +00:00:59,680 --> 00:01:02,720 +final code because you can apply, for example, easily within a tool. + +24 +00:01:02,720 --> 00:01:06,030 +So be careful not over doing it when you refactor. And for + +25 +00:01:06,030 --> 00:01:08,310 +the same reason that we mentioned at the beginning, you should be + +26 +00:01:08,310 --> 00:01:10,600 +particularly careful when you're using refactoring + +27 +00:01:10,600 --> 00:01:12,290 +for systems that are in production. + +28 +00:01:12,290 --> 00:01:15,260 +Because if you introduce a problem, before the system goes in production, + +29 +00:01:15,260 --> 00:01:16,750 +then you might be able to catch it earlier, + +30 +00:01:16,750 --> 00:01:19,780 +with testing. Or before it's released. But, if you introduce + +31 +00:01:19,780 --> 00:01:21,750 +a problem for a system in production, then you have + +32 +00:01:21,750 --> 00:01:24,440 +to issue a new version of the code. You'll be + +33 +00:01:24,440 --> 00:01:26,860 +affecting, you might be affecting some users, because the code + +34 +00:01:26,860 --> 00:01:29,050 +fails on their machine. So, you have to be twice + +35 +00:01:29,050 --> 00:01:31,190 +as careful, when you are doing refactoring, when you're changing + +36 +00:01:31,190 --> 00:01:33,010 +your code for a system that is already in production. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/19 - Cost of Refactoring - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/19 - Cost of Refactoring - lang_en_vs4.srt new file mode 100644 index 0000000..e09868d --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/19 - Cost of Refactoring - lang_en_vs4.srt @@ -0,0 +1,127 @@ +1 +00:00:00,080 --> 00:00:03,800 +Let's also talk about the cost of refactoring. Refactoring might be + +2 +00:00:03,800 --> 00:00:06,750 +free or almost free if you're using a tool to do refactoring + +3 +00:00:06,750 --> 00:00:08,570 +as we did in our demo. But that's not always the + +4 +00:00:08,570 --> 00:00:12,530 +case. In many cases, refactoring involves quite a bit of manual work + +5 +00:00:12,530 --> 00:00:16,309 +if you're doing some manual refactoring. And how much that costs + +6 +00:00:16,309 --> 00:00:19,460 +depends on how well the operations on the source code are supported. + +7 +00:00:19,460 --> 00:00:22,379 +You might have partial support from an ID. You might have complete + +8 +00:00:22,379 --> 00:00:25,017 +support, in which case it's greater. Or you might have no support, + +9 +00:00:25,017 --> 00:00:26,879 +in which case you have to be very careful about + +10 +00:00:26,879 --> 00:00:28,888 +how you change your code and how you check that you + +11 +00:00:28,888 --> 00:00:32,030 +didn't change the behavior of the code. There's also an additional + +12 +00:00:32,030 --> 00:00:34,460 +cost associated with refactoring. Remember + +13 +00:00:34,460 --> 00:00:36,990 +that refactoring relies heavily on testing + +14 +00:00:36,990 --> 00:00:39,808 +after each small step of refactoring. So you might have + +15 +00:00:39,808 --> 00:00:43,451 +to develop test cases, specifically to check your refactoring. And even + +16 +00:00:43,451 --> 00:00:47,163 +if you have an existing test because, for example, you're working + +17 +00:00:47,163 --> 00:00:50,235 +some agile context and therefore you develop a lot of UNIX + +18 +00:00:50,235 --> 00:00:53,550 +test cases before writing your code. And therefore you have a good + +19 +00:00:53,550 --> 00:00:56,635 +regression test with it you can use every time you modify your code. + +20 +00:00:56,635 --> 00:00:59,550 +Nevertheless, when you refactor and you change your code, you might need + +21 +00:00:59,550 --> 00:01:03,255 +to update your test so it's not only the development of the test + +22 +00:01:03,255 --> 00:01:05,379 +cases but also it's maintaining the test cases. And if you have + +23 +00:01:05,379 --> 00:01:07,970 +a lot of test cases, you have to maintain more test cases. So + +24 +00:01:07,970 --> 00:01:12,460 +that's a cost that is not directly visible but can affect quite + +25 +00:01:12,460 --> 00:01:15,800 +a bit the overall cost of refactoring and the overall cost of system + +26 +00:01:15,800 --> 00:01:18,342 +development therefore. And finally, you should not + +27 +00:01:18,342 --> 00:01:21,191 +under estimate the cost of documentation maintenance. + +28 +00:01:21,191 --> 00:01:24,241 +Applying refactoring may involve changes in interfaces, + +29 +00:01:24,241 --> 00:01:26,528 +names, for example, names of classes. And + +30 +00:01:26,528 --> 00:01:29,384 +when you make this kind of changes, you might need to update the documentation, + +31 +00:01:29,384 --> 00:01:30,890 +and that's also cost. It's something that + +32 +00:01:30,890 --> 00:01:32,900 +takes effort and therefore should be considered. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/2 - Introduction - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/2 - Introduction - lang_en_vs4.srt new file mode 100644 index 0000000..a50a2e5 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/2 - Introduction - lang_en_vs4.srt @@ -0,0 +1,127 @@ +1 +00:00:00,090 --> 00:00:02,790 +Let me start this lesson by discussing what is refactoring. + +2 +00:00:02,790 --> 00:00:06,590 +Refactoring is the process of applying transformation or refactoring to a + +3 +00:00:06,590 --> 00:00:09,320 +program. So as to obtain a refactor program. With an + +4 +00:00:09,320 --> 00:00:12,850 +improved design but with same functionality as the original program. So + +5 +00:00:12,850 --> 00:00:15,520 +key aspect of refactoring is the fact that refactoring should + +6 +00:00:15,520 --> 00:00:18,150 +be somatic to perserving So what is the main goal of + +7 +00:00:18,150 --> 00:00:22,030 +refactoring? The goal is to keep the program readable, understandable, and + +8 +00:00:22,030 --> 00:00:25,260 +maintainable as we evolve it. And to do this by eliminating + +9 +00:00:25,260 --> 00:00:28,530 +small problems soon, so that you can avoid big trouble later. And + +10 +00:00:28,530 --> 00:00:31,750 +I want to stress once more a key feature of refactoring, which + +11 +00:00:31,750 --> 00:00:34,790 +is the fact that it is behavior per serving. But how can + +12 +00:00:34,790 --> 00:00:38,130 +we ensure that the refactoring is behavior per serving? In other words, + +13 +00:00:38,130 --> 00:00:40,980 +how can we ensure that the program does the same thing before + +14 +00:00:40,980 --> 00:00:43,560 +and after applying a refactoring. So what we would like to do + +15 +00:00:43,560 --> 00:00:47,160 +is to have some guarantee that, that happens. And unfortunately in general, + +16 +00:00:47,160 --> 00:00:50,360 +there are no guarantees. But something we can do is to test + +17 +00:00:50,360 --> 00:00:53,690 +the code. For example, we can write tests that exercise the + +18 +00:00:53,690 --> 00:00:56,390 +parts of the program affected by the refactoring, and if we're in + +19 +00:00:56,390 --> 00:00:59,430 +a [INAUDIBLE] context, we might already have plenty of test cases + +20 +00:00:59,430 --> 00:01:01,914 +that exercise that part of the code. So we might just have + +21 +00:01:01,914 --> 00:01:04,780 +to rerun the test cases after the refactoring. And in fact, + +22 +00:01:04,780 --> 00:01:07,930 +that's a very advantageous situation, and that's a very good use of + +23 +00:01:07,930 --> 00:01:10,970 +existing test cases. And I want to make sure that you remember, + +24 +00:01:10,970 --> 00:01:15,500 +and that you beware that tests provide no guarantees. Testing can only + +25 +00:01:15,500 --> 00:01:18,990 +show the presence of defects, but cannot demonstrate their absence. + +26 +00:01:18,990 --> 00:01:21,090 +So we can use testing to get confidence in our + +27 +00:01:21,090 --> 00:01:23,990 +refactorings, but we can't really guarantee that the refactorings are + +28 +00:01:23,990 --> 00:01:26,820 +behavior preserving. I'd also like to point out that for some + +29 +00:01:26,820 --> 00:01:30,100 +simple refactoring, we can use a static analysis to actually + +30 +00:01:30,100 --> 00:01:33,160 +provide these guarantees. And in fact we will see examples of + +31 +00:01:33,160 --> 00:01:37,050 +such refactorings that are incorporated into IDs and that leverage + +32 +00:01:37,050 --> 00:01:40,070 +these kinds of analysis to perform refactoring in a safe way. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/20 - When Not To Refactor - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/20 - When Not To Refactor - lang_en_vs4.srt new file mode 100644 index 0000000..53938de --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/20 - When Not To Refactor - lang_en_vs4.srt @@ -0,0 +1,103 @@ +1 +00:00:00,088 --> 00:00:02,860 +Now I want to conclude this discussion on refactoring by telling you + +2 +00:00:02,860 --> 00:00:07,190 +when you should not refactor. One first clear case is when + +3 +00:00:07,190 --> 00:00:10,410 +your code is broken. I want to make it very clear, refactoring + +4 +00:00:10,410 --> 00:00:13,450 +is not a way to fix your code in terms of its + +5 +00:00:13,450 --> 00:00:16,250 +functionality. It's a way to improve the design of your code. + +6 +00:00:16,250 --> 00:00:19,040 +So if your code does not compile or does not run + +7 +00:00:19,040 --> 00:00:21,780 +in a stable way, it's probably better to throw it away + +8 +00:00:21,780 --> 00:00:25,250 +and rewrite it rather then trying to refactor it. By definition refactoring + +9 +00:00:25,250 --> 00:00:26,780 +should maintain the functionality of the + +10 +00:00:26,780 --> 00:00:28,360 +system. It should be behavior preserving. + +11 +00:00:28,360 --> 00:00:31,100 +So if the code was broken before, it, it's probably going to be broken + +12 +00:00:31,100 --> 00:00:33,950 +afterwards as well. You may also want to avoid refactoring when a + +13 +00:00:33,950 --> 00:00:37,370 +deadline is close. Well, first of all, because refactoring might take a long + +14 +00:00:37,370 --> 00:00:41,360 +time and therefore might introduce risks of being late for the deadline. + +15 +00:00:41,360 --> 00:00:44,555 +And also, because of what we said before about introducing problems, you don't + +16 +00:00:44,555 --> 00:00:47,780 +want to introduce problems that might take you time to fix right before a + +17 +00:00:47,780 --> 00:00:50,660 +deadline. So if the deadline is too close, you might want to avoid + +18 +00:00:50,660 --> 00:00:54,310 +refactoring the code at that point. And finally, do not refactor if there + +19 +00:00:54,310 --> 00:00:58,430 +is no reason to. As we said before, you should refactor on demand. You + +20 +00:00:58,430 --> 00:01:00,960 +see a problem with the design of your code, with the structure of your + +21 +00:01:00,960 --> 00:01:03,790 +code, it's okay to refactor. If the code is fine, there is no reason + +22 +00:01:03,790 --> 00:01:06,470 +to refactor. I know that refactoring is fine, but you don't want to do + +23 +00:01:06,470 --> 00:01:09,280 +it all the time. The next thing I want to discuss, after discussing when + +24 +00:01:09,280 --> 00:01:12,970 +not to refactor, is when to refactor without an indication that will tell us + +25 +00:01:12,970 --> 00:01:15,820 +that it's time to refactor the code. And that leads us to the discussion + +26 +00:01:15,820 --> 00:01:17,280 +of a very interesting concept. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/21 - Bad Smells - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/21 - Bad Smells - lang_en_vs4.srt new file mode 100644 index 0000000..240d37b --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/21 - Bad Smells - lang_en_vs4.srt @@ -0,0 +1,99 @@ +1 +00:00:00,070 --> 00:00:03,450 +The concept of bad smells. What are bad smells? Well, we + +2 +00:00:03,450 --> 00:00:06,700 +mentioned earlier that refactoring is typically applied when there is something + +3 +00:00:06,700 --> 00:00:09,130 +that does not look right, does not feel right in the + +4 +00:00:09,130 --> 00:00:12,260 +code. And that's exactly what bad smells are. Bad smells, or + +5 +00:00:12,260 --> 00:00:15,320 +code smells if you wish, are symptoms in the code of + +6 +00:00:15,320 --> 00:00:18,868 +a program that might indicate deeper problems. So there might be + +7 +00:00:18,868 --> 00:00:21,775 +parts of my system, classes in my systems, that just don't + +8 +00:00:21,775 --> 00:00:25,309 +smell right, and it feels like there's, there might be something wrong + +9 +00:00:25,309 --> 00:00:29,010 +with them. And if you are an experienced developer just like Brad, + +10 +00:00:29,010 --> 00:00:31,320 +you'll be able to figure out there is something wrong with the + +11 +00:00:31,320 --> 00:00:33,950 +classes. You'll be able to smell that there's something wrong and you'll + +12 +00:00:33,950 --> 00:00:36,880 +do something about it. And I want to mention one more, just to make + +13 +00:00:36,880 --> 00:00:39,270 +sure that we're all on the same page here. That these bad + +14 +00:00:39,270 --> 00:00:43,070 +smells are usually not bugs and don't prevent the program from functioning. They + +15 +00:00:43,070 --> 00:00:46,190 +however indicate weaknesses in the design of the system that might cause + +16 +00:00:46,190 --> 00:00:48,480 +problems during maintenance. In other words, + +17 +00:00:48,480 --> 00:00:50,440 +they might make the code less maintainable, + +18 +00:00:50,440 --> 00:00:53,650 +harder to understand, and so on. Just like refactorings, + +19 +00:00:53,650 --> 00:00:56,610 +there's also many possible different bad smells. So what + +20 +00:00:56,610 --> 00:00:59,160 +I'm providing here is just a possible list of + +21 +00:00:59,160 --> 00:01:02,190 +some very common bad smells. And you can find plenty + +22 +00:01:02,190 --> 00:01:04,349 +of information on this online. So what I want + +23 +00:01:04,349 --> 00:01:06,910 +to do next is just to cover before finishing the + +24 +00:01:06,910 --> 00:01:08,700 +lesson a few of those to show you some + +25 +00:01:08,700 --> 00:01:11,140 +examples of smells and what you can do about them. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/22 - Bad Smell Examples - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/22 - Bad Smell Examples - lang_en_vs4.srt new file mode 100644 index 0000000..b26a698 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/22 - Bad Smell Examples - lang_en_vs4.srt @@ -0,0 +1,263 @@ +1 +00:00:00,100 --> 00:00:03,080 +The first example I want to mention is this called duplicated + +2 +00:00:03,080 --> 00:00:06,950 +code. So what happens here what the symptom is, is that you + +3 +00:00:06,950 --> 00:00:10,400 +have the same piece of code. The same fragment of code or + +4 +00:00:10,400 --> 00:00:14,570 +code structure replicated in more than one place. And that's pretty common + +5 +00:00:14,570 --> 00:00:16,880 +when we do for example copy and paste programming. Is something + +6 +00:00:16,880 --> 00:00:19,730 +that we mention at the beginning of the lessons. So for example + +7 +00:00:19,730 --> 00:00:22,780 +we are just instead reimplementing a piece of functionality we know we + +8 +00:00:22,780 --> 00:00:25,510 +already have. We simply copy from a different part of the code. + +9 +00:00:25,510 --> 00:00:27,760 +So what do you do if you have duplicated code? This can + +10 +00:00:27,760 --> 00:00:30,100 +be a problem over time because we might end up with a lot + +11 +00:00:30,100 --> 00:00:34,480 +of duplication in your system. You can use the extract method. Refactoring that + +12 +00:00:34,480 --> 00:00:37,610 +we just saw, and basically create a method that has exactly the same + +13 +00:00:37,610 --> 00:00:40,700 +function as this fragment of code and then replace the fragment of code + +14 +00:00:40,700 --> 00:00:43,030 +with an invocation to run and you will do it in all the + +15 +00:00:43,030 --> 00:00:47,520 +places where the code is duplicated. That simply finds the code and favors + +16 +00:00:47,520 --> 00:00:48,660 +reuse, because there can be more + +17 +00:00:48,660 --> 00:00:51,050 +places that benefit from that additional method. + +18 +00:00:51,050 --> 00:00:54,960 +Especially if it implements some popular piece of functionality. Another example + +19 +00:00:54,960 --> 00:00:57,930 +of best mal a typical one is the long method. So you + +20 +00:00:57,930 --> 00:01:00,530 +have a very long method with a lot of statements. And we + +21 +00:01:00,530 --> 00:01:03,570 +know that the longer procedure, the more difficult it is to understand + +22 +00:01:03,570 --> 00:01:05,650 +it and maintain it. So what I'm going to do in this + +23 +00:01:05,650 --> 00:01:08,690 +case is to factor in such as an extract method or a + +24 +00:01:08,690 --> 00:01:12,900 +decompose conditional to make the code simpler, shorten it. And extract some + +25 +00:01:12,900 --> 00:01:16,450 +of the functionality into other methods. So basically break down the method + +26 +00:01:16,450 --> 00:01:20,180 +in smaller methods that are more cohesive. Another typical example + +27 +00:01:20,180 --> 00:01:22,380 +of best mail which is something that can happen very + +28 +00:01:22,380 --> 00:01:25,720 +commonly during maintenance, is that you keep adding functionality to + +29 +00:01:25,720 --> 00:01:28,470 +a class and you end up with a large class. So + +30 +00:01:28,470 --> 00:01:32,410 +class is clearly to big. It contains too many fields + +31 +00:01:32,410 --> 00:01:35,620 +too many methods, and is just too complex to understand. This + +32 +00:01:35,620 --> 00:01:37,990 +case the obvious solution is to use the extract class + +33 +00:01:37,990 --> 00:01:42,230 +or subclass and basically break down the class in multiple classes. + +34 +00:01:42,230 --> 00:01:45,390 +Each one with a more cohesive piece of functionality. So, the + +35 +00:01:45,390 --> 00:01:46,930 +classes are more cohesive, are more + +36 +00:01:46,930 --> 00:01:48,360 +understandable, and the overall structure The + +37 +00:01:48,360 --> 00:01:52,440 +structure of the system is improved. Shotgun surgery is an interesting smell + +38 +00:01:52,440 --> 00:01:55,980 +and the case here is we are in a situation and you, + +39 +00:01:55,980 --> 00:01:58,270 +probably will happen to you, it definitely happened to me, in + +40 +00:01:58,270 --> 00:02:01,110 +which every time you make some kind of change to the system + +41 +00:02:01,110 --> 00:02:03,850 +you have to make many little changes. All over the place to + +42 +00:02:03,850 --> 00:02:07,280 +many different classes. And this can be a symptom of the fact + +43 +00:02:07,280 --> 00:02:11,080 +that the functionality is spread among these different classes. So + +44 +00:02:11,080 --> 00:02:13,610 +there's too much coupling between the classes and too little + +45 +00:02:13,610 --> 00:02:16,540 +cohesion within the classes. Also in this case you can + +46 +00:02:16,540 --> 00:02:19,540 +use refactoring, for example by using the move method or move + +47 +00:02:19,540 --> 00:02:22,650 +field or inline class to bring the pieces of related + +48 +00:02:22,650 --> 00:02:26,470 +functionality together. So that your resulting classes are more cohesive, you + +49 +00:02:26,470 --> 00:02:29,220 +reduce the dependencies between the different classes, and you address + +50 +00:02:29,220 --> 00:02:32,305 +this problem. Because at this point, each class is much more + +51 +00:02:32,305 --> 00:02:34,020 +self-contained and therefore it can be + +52 +00:02:34,020 --> 00:02:36,100 +modified by itself without having to affect + +53 +00:02:36,100 --> 00:02:38,560 +the rest of the system. The last smell I want to mention is + +54 +00:02:38,560 --> 00:02:42,040 +one I really like, is the feature envy, and it refers to a + +55 +00:02:42,040 --> 00:02:45,340 +method that seems more interested In a class other than the one it + +56 +00:02:45,340 --> 00:02:48,370 +belongs to. So for example this method is using a lot of public + +57 +00:02:48,370 --> 00:02:51,030 +fields of another class, is calling a lot of methods of the other + +58 +00:02:51,030 --> 00:02:53,830 +class. And so in this case the solution is really clear. What you + +59 +00:02:53,830 --> 00:02:57,420 +want to do it to perform the extract method refactoring and then the move + +60 +00:02:57,420 --> 00:02:59,680 +method refactoring so as to take the jealous + +61 +00:02:59,680 --> 00:03:01,210 +method out of the class where it doesn't + +62 +00:03:01,210 --> 00:03:04,770 +belong and get it home. To the class where it really belongs and once more the + +63 +00:03:04,770 --> 00:03:06,790 +effect of this is that you decrease the + +64 +00:03:06,790 --> 00:03:09,990 +coupling between the two classes and therefore you + +65 +00:03:09,990 --> 00:03:11,910 +have a better system and also you eliminate + +66 +00:03:11,910 --> 00:03:13,150 +the envy. Which is always a good thing. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/23 - Bad Smell Quiz - lang_en_vs3.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/23 - Bad Smell Quiz - lang_en_vs3.srt new file mode 100644 index 0000000..971d639 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/23 - Bad Smell Quiz - lang_en_vs3.srt @@ -0,0 +1,31 @@ +1 +00:00:00,100 --> 00:00:01,620 +So now, I would like for you to tell me + +2 +00:00:01,620 --> 00:00:04,810 +which of the following can be considered bad smells in + +3 +00:00:04,810 --> 00:00:07,320 +the context of refactoring. The fact that the program takes + +4 +00:00:07,320 --> 00:00:10,070 +too long to execute? The fact that method M in class + +5 +00:00:10,070 --> 00:00:12,460 +C is very long? Or the, the fact that Class + +6 +00:00:12,460 --> 00:00:16,120 +Cat and Dog are subclasses of class Animal? Or finally the + +7 +00:00:16,120 --> 00:00:18,960 +fact that every time we modify method M1 we also + +8 +00:00:18,960 --> 00:00:22,120 +need to modify method M2? So please mark all that apply. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/24 - Bad Smell Quiz Solution - lang_en_vs3.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/24 - Bad Smell Quiz Solution - lang_en_vs3.srt new file mode 100644 index 0000000..2773116 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/24 - Bad Smell Quiz Solution - lang_en_vs3.srt @@ -0,0 +1,75 @@ +1 +00:00:00,110 --> 00:00:03,090 +So let's look at this one by one. The fact the program takes + +2 +00:00:03,090 --> 00:00:06,620 +too long to execute is not really a bad smell. It probably indicates + +3 +00:00:06,620 --> 00:00:08,800 +some problem with the code and the fact that we might need to + +4 +00:00:08,800 --> 00:00:11,420 +modify the code to make it more efficient, but it's not something that + +5 +00:00:11,420 --> 00:00:14,030 +we will normally classify it as a bad smell, so we're not going to + +6 +00:00:14,030 --> 00:00:17,850 +mark it. The second one, conversely, is definitely a bad smell. The fact + +7 +00:00:17,850 --> 00:00:21,700 +that the method is too long is a typical example of bad smell + +8 +00:00:21,700 --> 00:00:25,000 +and one in which we might want to apply some refactoring, for example, + +9 +00:00:25,000 --> 00:00:26,450 +the extract method or the + +10 +00:00:26,450 --> 00:00:29,240 +decomposed conditional refactorings. There's definitely + +11 +00:00:29,240 --> 00:00:32,159 +nothing wrong with the fact that the classes cat and dog + +12 +00:00:32,159 --> 00:00:35,600 +are subclasses of class animal. Actually, that sounds pretty appropriate, so + +13 +00:00:35,600 --> 00:00:38,270 +this is not a problem and definitely not a bad smell. + +14 +00:00:38,270 --> 00:00:40,990 +Whereas the fact that every time we modify method M1, + +15 +00:00:40,990 --> 00:00:44,210 +we also need to modify method some other method M2 as + +16 +00:00:44,210 --> 00:00:46,690 +a typical example of bad smell. So this can actually be + +17 +00:00:46,690 --> 00:00:50,590 +considered a specific example of what we just called "shotgun surgery." + +18 +00:00:50,590 --> 00:00:52,500 +So it is a case in which we might want to + +19 +00:00:52,500 --> 00:00:55,750 +use, for instance, the move method refactoring to fix the issue. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/3 - Introduction - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/3 - Introduction - lang_en_vs4.srt new file mode 100644 index 0000000..7631180 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/3 - Introduction - lang_en_vs4.srt @@ -0,0 +1,27 @@ +1 +00:00:00,120 --> 00:00:04,280 +So let's have a small quiz and see whether you can remember why can testing + +2 +00:00:04,280 --> 00:00:06,250 +guarantee that that a refactoring is behavior is + +3 +00:00:06,250 --> 00:00:08,590 +preserving. So why testing can only show the + +4 +00:00:08,590 --> 00:00:11,080 +absence of defects and not their presence? + +5 +00:00:11,080 --> 00:00:12,960 +Is that because testing and refactoring are different + +6 +00:00:12,960 --> 00:00:15,980 +activities? Because testing is inherently incomplete? Or, just + +7 +00:00:15,980 --> 00:00:19,560 +because testers are often inexperienced? Make your choice. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/4 - Introduction Solution - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/4 - Introduction Solution - lang_en_vs4.srt new file mode 100644 index 0000000..7888f8d --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/4 - Introduction Solution - lang_en_vs4.srt @@ -0,0 +1,39 @@ +1 +00:00:00,220 --> 00:00:03,180 +And the reason for this is because testing is inherently + +2 +00:00:03,180 --> 00:00:06,080 +incomplete. So let me re-size this a little bit, so that + +3 +00:00:06,080 --> 00:00:08,340 +I can make room for an illustration. And what I'm + +4 +00:00:08,340 --> 00:00:11,170 +going to show you here is just a reminder, that when we + +5 +00:00:11,170 --> 00:00:15,380 +test, we have a huge virtually infinite input domain, and + +6 +00:00:15,380 --> 00:00:17,956 +we have to derive from this input domain a few test + +7 +00:00:17,956 --> 00:00:21,330 +cases. By picking specific inputs in the domain, and of + +8 +00:00:21,330 --> 00:00:25,260 +course, corresponding outputs. And so what happens normally is that these + +9 +00:00:25,260 --> 00:00:28,280 +test cases represent the teeny tiny fraction of + +10 +00:00:28,280 --> 00:00:30,920 +the domain, and therefore testing is always incomplete. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/5 - Reasons to Refactor - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/5 - Reasons to Refactor - lang_en_vs4.srt new file mode 100644 index 0000000..1da50e6 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/5 - Reasons to Refactor - lang_en_vs4.srt @@ -0,0 +1,131 @@ +1 +00:00:00,230 --> 00:00:02,000 +We saw at the beginning of the lesson, what are the + +2 +00:00:02,000 --> 00:00:05,490 +goals of refactoring? Or what are the reasons ,why we need to + +3 +00:00:05,490 --> 00:00:09,130 +refactor in the first place? The first reason is that requirements + +4 +00:00:09,130 --> 00:00:12,370 +change, and when the requirements change, we often need to change our + +5 +00:00:12,370 --> 00:00:16,356 +design accordingly. In other cases if any of the requirements unchange, + +6 +00:00:16,356 --> 00:00:19,690 +we might need to improve our design. And this happens for many + +7 +00:00:19,690 --> 00:00:22,300 +reasons. For example, we need to add a new feature, we + +8 +00:00:22,300 --> 00:00:25,330 +want to make the code more maintainable, and also in general programmers + +9 +00:00:25,330 --> 00:00:28,110 +don't come up with the best design the first time. So they might + +10 +00:00:28,110 --> 00:00:31,130 +need to adapt it after the fact. And the final reason I want to + +11 +00:00:31,130 --> 00:00:33,040 +mention is sloppiness, and to some + +12 +00:00:33,040 --> 00:00:35,700 +extent laziness, of programmers. And a typical + +13 +00:00:35,700 --> 00:00:38,520 +example of this is something that we all have done, which is copy + +14 +00:00:38,520 --> 00:00:41,890 +and paste programming. So instead of rewriting a new piece of code, because + +15 +00:00:41,890 --> 00:00:44,620 +we know that there is some code in some other parts for the + +16 +00:00:44,620 --> 00:00:47,900 +program that does a similar thing, we'll just copy the code over. And + +17 +00:00:47,900 --> 00:00:51,080 +before we know, we end up with tons of copies of the same functionality. + +18 +00:00:51,080 --> 00:00:54,150 +And when that happens, a good way of consolidating that code and + +19 +00:00:54,150 --> 00:00:57,580 +extracting that functionality is to use refactoring, for example, by creating a + +20 +00:00:57,580 --> 00:01:01,080 +method or a class that provides the functionality. And we'll see specific + +21 +00:01:01,080 --> 00:01:03,830 +examples of that. A question I would like to ask at this + +22 +00:01:03,830 --> 00:01:07,330 +point of the class is whether you have used refactoring before? So + +23 +00:01:07,330 --> 00:01:09,690 +I want you to take a second and think about it. And + +24 +00:01:09,690 --> 00:01:12,590 +no matter what you're history is, if you ever coded I bet + +25 +00:01:12,590 --> 00:01:16,180 +you any money that the answer is yes, you have done refactoring. + +26 +00:01:16,180 --> 00:01:17,300 +What do I mean? I'm going to give you an + +27 +00:01:17,300 --> 00:01:19,610 +example. I'm sure you renamed the class or a + +28 +00:01:19,610 --> 00:01:22,190 +method or change the name of some variables in + +29 +00:01:22,190 --> 00:01:25,490 +the code before. That's refactoring. Even something as simple as + +30 +00:01:25,490 --> 00:01:28,030 +renaming a class is refactoring, because, for example, it + +31 +00:01:28,030 --> 00:01:30,230 +might help you making your code more understandable. And of + +32 +00:01:30,230 --> 00:01:32,520 +course I'll admit that in this case, this is + +33 +00:01:32,520 --> 00:01:35,690 +a trivial refactoring, and there are much more interesting ones. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/6 - History of Refactoring - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/6 - History of Refactoring - lang_en_vs4.srt new file mode 100644 index 0000000..3405b65 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/6 - History of Refactoring - lang_en_vs4.srt @@ -0,0 +1,171 @@ +1 +00:00:00,110 --> 00:00:02,340 +So if you follow my class so far, you know that + +2 +00:00:02,340 --> 00:00:04,570 +I like to give a little bit of history when I talk + +3 +00:00:04,570 --> 00:00:06,900 +about a specific topic. So I'm going to do the same also + +4 +00:00:06,900 --> 00:00:09,900 +in this case for refactoring. I'm going to start by mentioning, the fact + +5 +00:00:09,900 --> 00:00:13,440 +that refactoring is something that programmers have always done. I gave + +6 +00:00:13,440 --> 00:00:16,300 +you a trivial example just a minute ago of what refactoring is. + +7 +00:00:16,300 --> 00:00:18,080 +So even more complicated refactorings are + +8 +00:00:18,080 --> 00:00:20,880 +something that are commonplace for developers. + +9 +00:00:20,880 --> 00:00:23,110 +Somehow refactoring is especially important in + +10 +00:00:23,110 --> 00:00:25,240 +the context of object-oriented languages and + +11 +00:00:25,240 --> 00:00:28,080 +probably it's because the object-oriented features are well suited to + +12 +00:00:28,080 --> 00:00:31,640 +make designs flexible and reusable. Because of the fact that help + +13 +00:00:31,640 --> 00:00:35,120 +encapsulation, information hiding, and so they make it easier to + +14 +00:00:35,120 --> 00:00:38,330 +modify something without changing the functionality that it provides to the + +15 +00:00:38,330 --> 00:00:40,960 +outside world. However, you should keep in mind that refactoring + +16 +00:00:40,960 --> 00:00:44,330 +is really not specific to object oriented languages, you can also + +17 +00:00:44,330 --> 00:00:47,320 +refactor other languages, it's just more common to see it in + +18 +00:00:47,320 --> 00:00:50,450 +that context. So one of the first examples of a specific + +19 +00:00:50,450 --> 00:00:53,630 +discussion of what the refactorings are is Opdyke's PhD + +20 +00:00:53,630 --> 00:00:57,710 +thesis in 1990. Which discusses refactorings for small talk. + +21 +00:00:57,710 --> 00:00:59,360 +And some of you might be familiar with small + +22 +00:00:59,360 --> 00:01:02,600 +talk, which is a specific objectory language. And in + +23 +00:01:02,600 --> 00:01:06,590 +more recent times, refactoring's becoming increasing popular due to + +24 +00:01:06,590 --> 00:01:10,370 +lightweight development methodoogies, due to agile development, which is + +25 +00:01:10,370 --> 00:01:12,630 +something that we just discussed in this class. For + +26 +00:01:12,630 --> 00:01:15,830 +example, when we talked about extreme programming, we mentioned refactoring + +27 +00:01:15,830 --> 00:01:17,950 +a few times. And the reason why its so popular + +28 +00:01:17,950 --> 00:01:20,690 +is because re-factoring is one of the practices that help. + +29 +00:01:20,690 --> 00:01:24,780 +Making changes less expensive. And therefore adapt to changing requirements + +30 +00:01:24,780 --> 00:01:26,980 +and changing environments more quickly. + +31 +00:01:26,980 --> 00:01:29,140 +And continuing with historical perspective, one + +32 +00:01:29,140 --> 00:01:31,760 +of the milestones in the history of re-factoring [INAUDIBLE] is + +33 +00:01:31,760 --> 00:01:34,660 +a book by Martin Fowler. This is a book entitled + +34 +00:01:34,660 --> 00:01:37,610 +Improving the Design of Existing [INAUDIBLE]. And it contains a + +35 +00:01:37,610 --> 00:01:41,320 +catalog of refactorings, a list of bad smells, in code, and + +36 +00:01:41,320 --> 00:01:43,450 +we're going to see what that mean exactly. Nothing to + +37 +00:01:43,450 --> 00:01:45,570 +do with other kinds of bad smells. It talks about + +38 +00:01:45,570 --> 00:01:48,900 +guidelines on when to apply refactoring. And finally, which is + +39 +00:01:48,900 --> 00:01:52,540 +very useful, it provides example of code, before and after. + +40 +00:01:52,540 --> 00:01:54,660 +Applying the refactoring and we're going to use more of the + +41 +00:01:54,660 --> 00:01:57,190 +same style when discussing refactoring in the rest of this + +42 +00:01:57,190 --> 00:02:01,090 +lesson. More specifically what we're discussing next, are some examples + +43 +00:02:01,090 --> 00:02:05,130 +of refactoring and also some examples of code bad smells. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/7 - Types of Refactorings - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/7 - Types of Refactorings - lang_en_vs4.srt new file mode 100644 index 0000000..b646b14 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/7 - Types of Refactorings - lang_en_vs4.srt @@ -0,0 +1,43 @@ +1 +00:00:00,170 --> 00:00:03,630 +There are many refactorings in Fowler's book, and what I'm + +2 +00:00:03,630 --> 00:00:06,480 +showing here is just a partial list. And we're not going to + +3 +00:00:06,480 --> 00:00:08,930 +have time to go through the complete list of refactorings, + +4 +00:00:08,930 --> 00:00:10,830 +so what I'm going to do instead, I'm just going to pick a + +5 +00:00:10,830 --> 00:00:13,870 +few of those, but I'm going to explain in more depth, + +6 +00:00:13,870 --> 00:00:16,600 +and for which I'm going to provide some examples. In particular, we're + +7 +00:00:16,600 --> 00:00:18,000 +going to talk about the collapse + +8 +00:00:18,000 --> 00:00:20,630 +hierarchy refactoring, the consolidate conditional + +9 +00:00:20,630 --> 00:00:23,600 +expressions, the decompose conditionals, extract + +10 +00:00:23,600 --> 00:00:25,418 +method, extract class, and inline class. + +11 +00:00:25,418 --> 00:00:29,420 +And we're going to see each of those individually in the rest of the lesson. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/8 - Collapse Hierarchy - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/8 - Collapse Hierarchy - lang_en_vs4.srt new file mode 100644 index 0000000..8711182 --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/8 - Collapse Hierarchy - lang_en_vs4.srt @@ -0,0 +1,67 @@ +1 +00:00:00,110 --> 00:00:03,080 +The first refactoring we're going to see is the collapse hierarchy + +2 +00:00:03,080 --> 00:00:06,340 +refactoring. When a software system undergoes a number of changes, over + +3 +00:00:06,340 --> 00:00:09,730 +time the collapse hierarchy may become, let's say, sub-optimal. There are + +4 +00:00:09,730 --> 00:00:11,300 +several refactorings that address this + +5 +00:00:11,300 --> 00:00:13,200 +issue for example, refactorings that allow + +6 +00:00:13,200 --> 00:00:15,900 +you to move methods and fields up and down the class + +7 +00:00:15,900 --> 00:00:18,360 +hierarchy. So what happens when you apply a number of these + +8 +00:00:18,360 --> 00:00:22,360 +refactorings, is that a subclass might become too similar to its + +9 +00:00:22,360 --> 00:00:25,878 +superclass and might not be adding much value to the system. + +10 +00:00:25,878 --> 00:00:28,010 +In this case, it is a good idea to merge + +11 +00:00:28,010 --> 00:00:31,300 +the classes together. That's exactly what the Collapse Hierarchy refactoring + +12 +00:00:31,300 --> 00:00:34,600 +does. Imagine, for instance, that we have two classes: employee + +13 +00:00:34,600 --> 00:00:38,210 +and salesman. And that salesman is just so similar to + +14 +00:00:38,210 --> 00:00:40,380 +employee that it does not make sense to keep them + +15 +00:00:40,380 --> 00:00:43,870 +separated. In this case, you could merge the two classes, + +16 +00:00:43,870 --> 00:00:46,730 +so that at the end of the refactoring, only employee + +17 +00:00:46,730 --> 00:00:50,070 +is left. And the resulting structure of the system is improved. diff --git a/usth/ICT2.7/P4L5 Software Refactoring Subtitles/9 - Consolidate Conditional Expression - lang_en_vs4.srt b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/9 - Consolidate Conditional Expression - lang_en_vs4.srt new file mode 100644 index 0000000..be2b3fe --- /dev/null +++ b/usth/ICT2.7/P4L5 Software Refactoring Subtitles/9 - Consolidate Conditional Expression - lang_en_vs4.srt @@ -0,0 +1,131 @@ +1 +00:00:00,070 --> 00:00:00,860 +We're now going to talk about + +2 +00:00:00,860 --> 00:00:03,390 +the consolidate conditional expression refactoring. + +3 +00:00:03,390 --> 00:00:05,730 +A common situation in code is that you have a set + +4 +00:00:05,730 --> 00:00:08,530 +of conditionals with the same result. What that means that + +5 +00:00:08,530 --> 00:00:12,090 +sometimes the code contains a series of conditional checks in which + +6 +00:00:12,090 --> 00:00:14,760 +each check is different, yet the resulting action is the + +7 +00:00:14,760 --> 00:00:18,440 +same. In these cases, the code could be improved by combining + +8 +00:00:18,440 --> 00:00:22,100 +the conditionals using, for example, and, and or, as connectors. So + +9 +00:00:22,100 --> 00:00:25,390 +as to have a single conditional check, with a single result. + +10 +00:00:25,390 --> 00:00:28,500 +At that point you can also extract those conditional into a + +11 +00:00:28,500 --> 00:00:32,310 +method. And replace the conditional with a call, to debt matter consolidating + +12 +00:00:32,310 --> 00:00:35,110 +the conditional code in this way can make the checks clearer + +13 +00:00:35,110 --> 00:00:38,170 +by showing that you're really making a single check rather than multiple + +14 +00:00:38,170 --> 00:00:41,150 +checks, and extracted that condition and having that matter instead of + +15 +00:00:41,150 --> 00:00:44,550 +a condition can clarify your code by explaining why you're doing a + +16 +00:00:44,550 --> 00:00:47,350 +given check, rather than how you're doing it. You can see an + +17 +00:00:47,350 --> 00:00:52,020 +example of that situation in this code, which is the disabilityAmount method. + +18 +00:00:52,020 --> 00:00:54,580 +As the name of the method says, the purpose of this code + +19 +00:00:54,580 --> 00:00:58,300 +is to compute the disability amount for a given, for example, employee. + +20 +00:00:58,300 --> 00:01:01,250 +And there is a set of initial checks in the methods whose + +21 +00:01:01,250 --> 00:01:05,090 +goal is to decide whether there's this disabilityAmount should be instead zero. + +22 +00:01:05,090 --> 00:01:07,750 +And as you can see, there's multiple conditions. For example, there's a + +23 +00:01:07,750 --> 00:01:10,630 +check about the seniority level, and about the number of months that + +24 +00:01:10,630 --> 00:01:14,350 +the employee's been disabled. So far, whether the employee is part time + +25 +00:01:14,350 --> 00:01:17,060 +and the outcome of all these check is always the same. If they're + +26 +00:01:17,060 --> 00:01:19,740 +true, if the check is satisfied then there is no disability + +27 +00:01:19,740 --> 00:01:22,564 +amount. So the disabilityAmount is zero. So what I will do + +28 +00:01:22,564 --> 00:01:25,986 +if I apply the consolidate conditional expression to this matter, is + +29 +00:01:25,986 --> 00:01:29,690 +that I will take these three conditionals. I will put them together + +30 +00:01:29,690 --> 00:01:32,772 +by saying basically that if seniority is less than 2 or + +31 +00:01:32,772 --> 00:01:36,524 +monthsDisabled is greater than 12 or isPartTime is true then the + +32 +00:01:36,524 --> 00:01:40,170 +return should be zero. And once I have this combined conditional, + +33 +00:01:40,170 --> 00:01:42,601 +as I see here, I will just extract that into a method. diff --git a/usth/ICT2.7/fuzzy-find b/usth/ICT2.7/fuzzy-find new file mode 100755 index 0000000..70f14de --- /dev/null +++ b/usth/ICT2.7/fuzzy-find @@ -0,0 +1,26 @@ +#!/usr/bin/env python3.8 +from glob import glob +from itertools import islice +from os import path +from textwrap import wrap + +from fuzzywuzzy import fuzz, process + + +transcripts = {} +for filename in glob(path.join('*', '*')): + with open(filename) as f: + subtitles = ' '.join(' '.join(islice(f, 2, None, 4)).split()) + transcripts[filename] = subtitles.replace('.', '. ').replace('?', '? ') + +while query := input('>>> '): + bests = process.extractBests(query, transcripts, scorer=fuzz.partial_ratio) + for index, (transcript, score, filename) in enumerate(bests): + print(index, filename) + while index := input('... '): + try: + chosen = bests[int(index)] + except (IndexError, ValueError): + pass + else: + print(chosen[2], *wrap(chosen[0], 80), sep='\n') |