1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
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.
|
