1 files changed, 131 insertions, 0 deletions
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.