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,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.
|
