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