From 8a7dfa0972c83fd811a4296e7373574bea4a28d0 Mon Sep 17 00:00:00 2001 From: Nguyễn Gia Phong Date: Sun, 19 Jul 2020 20:34:40 +0700 Subject: [usth/ICT2.7] Remove Udacity transcribes --- .../9 - Architecture Centric - lang_en_vs5.srt | 131 --------------------- 1 file changed, 131 deletions(-) delete mode 100644 usth/ICT2.7/P3L4 Unified Software Process Subtitles/9 - Architecture Centric - lang_en_vs5.srt (limited to 'usth/ICT2.7/P3L4 Unified Software Process Subtitles/9 - Architecture Centric - lang_en_vs5.srt') 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 deleted file mode 100644 index b0f5487..0000000 --- a/usth/ICT2.7/P3L4 Unified Software Process Subtitles/9 - Architecture Centric - lang_en_vs5.srt +++ /dev/null @@ -1,131 +0,0 @@ -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. -- cgit 1.4.1