1
00:00:00,690 --> 00:00:04,080
Architecture fundamentals here,
in the JPL-Caltech Virtual Summer School.

2
00:00:04,080 --> 00:00:04,670
Big Data Analytics.

3
00:00:05,750 --> 00:00:06,510
Hi, I'm Chris Mattmann.

4
00:00:07,810 --> 00:00:10,980
So in the first part of big
data architecture we covered,

5
00:00:12,110 --> 00:00:13,240
covered two main things.

6
00:00:13,240 --> 00:00:16,110
We covered sort of an introduction
to software architecture.

7
00:00:16,110 --> 00:00:21,010
Its principles, some of its research,
some families of understanding of what we

8
00:00:21,010 --> 00:00:23,850
should be thinking about in
terms of self architecture.

9
00:00:23,850 --> 00:00:27,410
And we sort of wrapped up thinking
about things like styles, patterns, and

10
00:00:27,410 --> 00:00:28,430
reference architectures.

11
00:00:29,690 --> 00:00:33,340
Today or
in this next sort of lecture here,

12
00:00:33,340 --> 00:00:37,270
we going to be covering architectural
modeling and visualization.

13
00:00:37,270 --> 00:00:41,900
These are higher level, sort of
architectural operations, that operate

14
00:00:41,900 --> 00:00:45,590
based on, capturing information
about components and connectors and

15
00:00:45,590 --> 00:00:49,750
configurations, and then figuring out how
to visualize them, and interact with them.

16
00:00:49,750 --> 00:00:53,340
And we'll talk about, another,
thing that you see quite often and,

17
00:00:53,340 --> 00:00:56,500
which is another real good
applicability of software architecture.

18
00:00:56,500 --> 00:01:00,230
When you have code and you have software
architecture just making sure or

19
00:01:00,230 --> 00:01:03,730
understanding how consistent they
are between one another, and

20
00:01:03,730 --> 00:01:06,310
identifying when they aren't and
what those impacts are and

21
00:01:06,310 --> 00:01:08,390
what types of things you can
do to sort of mitigate that.

22
00:01:10,440 --> 00:01:14,300
So, let's talk a little bit about
architectural modeling basically as I

23
00:01:14,300 --> 00:01:19,169
stated in, in the sort of first part of
this series on big data architecture.

24
00:01:20,340 --> 00:01:24,660
The Medvidovic, Taylor and Dashofy
definition of software architecture as

25
00:01:24,660 --> 00:01:27,690
the principle design decisions,
in a software system.

26
00:01:27,690 --> 00:01:31,410
So, architectural modeling, if you think
about it within that context, is really

27
00:01:31,410 --> 00:01:35,850
the capture, right, or the recording,
of those, principle design decisions.

28
00:01:35,850 --> 00:01:38,200
You may build a UML model.

29
00:01:38,200 --> 00:01:40,940
And what are you doing,
when you capture those components or

30
00:01:40,940 --> 00:01:42,420
you capture the interactions between them?

31
00:01:42,420 --> 00:01:45,250
You're capturing the principle
design decisions.

32
00:01:45,250 --> 00:01:50,010
You're creating an architectural model,
of a Big Data system, okay?

33
00:01:50,010 --> 00:01:52,780
So, so architectural models defined,
it captures and

34
00:01:52,780 --> 00:01:56,260
records the principle design decisions
about a software system, right?

35
00:01:56,260 --> 00:01:59,130
So, there are several notations
that have been developed to

36
00:01:59,130 --> 00:02:03,570
capture architectural models and
instances of architectural models.

37
00:02:03,570 --> 00:02:06,720
Probably the most popular that you
guys are all familiar with is UML.

38
00:02:06,720 --> 00:02:10,110
If you take a undergraduate
course in software engineering,

39
00:02:10,110 --> 00:02:11,960
you've been exposed to UML.

40
00:02:11,960 --> 00:02:15,726
A lot of times if you take graduate
courses you're exposed to UML.

41
00:02:15,726 --> 00:02:18,960
And there are deri, derivatives
of it that exist nowadays, SCML,

42
00:02:18,960 --> 00:02:22,610
which is the systems
engineering modeling language,

43
00:02:22,610 --> 00:02:27,080
a number of other modeling languages end
in ML for modeling language as so forth.

44
00:02:27,080 --> 00:02:32,680
UML was the unified one, Sort of, was
pioneered by, Grady Booch and the number

45
00:02:32,680 --> 00:02:36,640
of other folks who were thinking about
how TO model software back in the day.

46
00:02:38,510 --> 00:02:42,380
CML is by far kind of the most prevalent
architectural modeling notation you

47
00:02:42,380 --> 00:02:43,260
might be familiar with.

48
00:02:43,260 --> 00:02:47,130
It's also by far not the best and
it has it's issues and it's problems and

49
00:02:47,130 --> 00:02:50,030
we'll, potentially talk about some of
those, depending on how much time we have.

50
00:02:51,330 --> 00:02:55,020
But it's worth pointing out that
UML was also emergent out of

51
00:02:55,020 --> 00:02:58,980
sort of a heyday of architectural
modeling research back in the day,

52
00:02:58,980 --> 00:03:00,490
especially during the 90s and the 2000s.

53
00:03:00,490 --> 00:03:04,330
This is sort of the golden age of
software architectural research.

54
00:03:04,330 --> 00:03:07,580
Right, this is the days when
Roy Fielding was at East Irvine, and

55
00:03:07,580 --> 00:03:10,030
Jim Whitehead were there and
a number of people were, you know,

56
00:03:10,030 --> 00:03:13,150
in a high powered software engineering,
that this was when there was tons of

57
00:03:13,150 --> 00:03:16,170
research by David Garland and
through Mary Shots, see, to me,

58
00:03:16,170 --> 00:03:20,330
this is when lots of things were going
on at CU Boulder with Alexander Wolf.

59
00:03:20,330 --> 00:03:22,000
And Andre Van der Vulk and

60
00:03:22,000 --> 00:03:27,500
lots of, sort of work going on in
architectural modelling, back in the day.

61
00:03:27,500 --> 00:03:31,380
So out of that came a series of different
architectural description language,

62
00:03:31,380 --> 00:03:35,280
which are really the predecessor to
common architectural modeling tools.

63
00:03:35,280 --> 00:03:38,860
ADLs, or
Architecture Description Languages, okay?

64
00:03:38,860 --> 00:03:42,270
And we need ways of understanding even
though many of these aren't still in

65
00:03:42,270 --> 00:03:43,790
existence to today, elements and

66
00:03:43,790 --> 00:03:46,670
principles from them have made
their way into things like UML.

67
00:03:46,670 --> 00:03:49,700
And they've made their way into other
modeling languages and notations.

68
00:03:49,700 --> 00:03:50,390
And it's important for

69
00:03:50,390 --> 00:03:54,720
you to think about ways of evaluating
architectural modeling notations.

70
00:03:54,720 --> 00:03:58,100
So if you go out and think that you
need to develop your own, or even if

71
00:03:58,100 --> 00:04:02,820
you're trying to pick, you know, amongst
UML versus simply doing PowerPoint or,

72
00:04:02,820 --> 00:04:05,450
you know, recording an architectural
model in text, you know.

73
00:04:05,450 --> 00:04:06,990
All of these are viable means for

74
00:04:06,990 --> 00:04:09,781
capturing those principal
design decisions.

75
00:04:09,781 --> 00:04:12,670
You need ways of evaluating why,
when, how,

76
00:04:12,670 --> 00:04:14,830
where, why you should,
you know, do it or not.

77
00:04:14,830 --> 00:04:17,270
And the ways that we typically
evaluate them are the ability or

78
00:04:17,270 --> 00:04:21,250
the capability of an architectural
modelling notation to capture things like,

79
00:04:21,250 --> 00:04:23,790
the structure, the components and
the connectors.

80
00:04:23,790 --> 00:04:28,680
The behavior of the architecture and to
model that, like it's interactions and for

81
00:04:28,680 --> 00:04:33,940
example, what states components transfer
between what type of data they have,

82
00:04:33,940 --> 00:04:37,510
what data is shared between those states,
the workflow and things like that.

83
00:04:37,510 --> 00:04:40,930
So, this is how we evaluate architectural
modelling and it's effectively why we

84
00:04:40,930 --> 00:04:44,700
need architectural modelling notations,
and architecture description languages.

85
00:04:44,700 --> 00:04:50,070
So, these ADLs which again kind of
came out of the 90's and, and

86
00:04:50,070 --> 00:04:54,180
the 2000's, and have since sort of emerged
into architectural modeling notations.

87
00:04:54,180 --> 00:04:59,150
Some of them back in the day in terms of
software architectural research you can

88
00:04:59,150 --> 00:05:01,210
kind of break them down between
what they were focusing on.

89
00:05:01,210 --> 00:05:05,830
There are things like Darwin which was
really focused on modeling components and

90
00:05:05,830 --> 00:05:06,580
their structures.

91
00:05:06,580 --> 00:05:08,360
And when you modeled
all the components and

92
00:05:08,360 --> 00:05:11,600
their structures, you did it in such a way
that you could use a pie calculus to

93
00:05:11,600 --> 00:05:15,990
analyze things simplistically like
reachability of one component to another.

94
00:05:15,990 --> 00:05:18,490
Is this, are these two components
going to be able to communicate?

95
00:05:18,490 --> 00:05:20,420
It's really nice to have that
in something like Darwin,

96
00:05:20,420 --> 00:05:24,690
because you didn't even need to build your
software system, per say, or implement it,

97
00:05:24,690 --> 00:05:27,130
but from an architectural model,
you could determine whether or

98
00:05:27,130 --> 00:05:30,440
not two components had reach ability and
could communicate with one another,

99
00:05:30,440 --> 00:05:32,745
simply by capturing one of
these architectural models.

100
00:05:32,745 --> 00:05:35,250
Ra-peed took that sort
of to the next level and

101
00:05:35,250 --> 00:05:37,380
really started to focus on interaction.

102
00:05:37,380 --> 00:05:38,100
Having a capability,

103
00:05:38,100 --> 00:05:42,820
capture not just structure in terms of
components and connectors, but then,

104
00:05:42,820 --> 00:05:48,120
interaction and having an understanding
of the effects of interaction, which led,

105
00:05:48,120 --> 00:05:51,330
we'll talk about visualization later,
to things that effect visualizations.

106
00:05:52,350 --> 00:05:57,090
Wright focused on components,
connectors, structure and behavior 'kay?

107
00:05:57,090 --> 00:05:59,930
Then we had some architecture description
languages that were specific to

108
00:05:59,930 --> 00:06:05,410
a particular domain, like Koala which was
used very heavily to model product lines.

109
00:06:05,410 --> 00:06:09,550
Okay, so large numbers of product lines
for televisions, or for television

110
00:06:09,550 --> 00:06:13,010
software systems and controllers that
were modeled by things like Koala.

111
00:06:13,010 --> 00:06:17,920
Okay, avionics, in the avionics domain,
you had things come out like,

112
00:06:17,920 --> 00:06:23,980
the avionics architecture description,
like, okay, or the AADL for them.

113
00:06:23,980 --> 00:06:27,500
All the way to the sort of the kind
of common modern predecessor in,

114
00:06:27,500 --> 00:06:31,470
in even today, still now used extensible
architectural description languages,

115
00:06:31,470 --> 00:06:35,840
or and there are two sort of three
kind of main examples of that.

116
00:06:35,840 --> 00:06:38,835
ACME, which came out of David Garlan and
Mary Shaw's group.

117
00:06:38,835 --> 00:06:39,800
Okay, and

118
00:06:39,800 --> 00:06:44,060
it supported components, component types,
connectors, connector types.

119
00:06:44,060 --> 00:06:47,200
An arbitrary properties about those
components and connector types.

120
00:06:47,200 --> 00:06:50,740
Because what they quickly realized with
early architecture description languages,

121
00:06:50,740 --> 00:06:53,390
is you were limited to the information
that you were capturing in them.

122
00:06:53,390 --> 00:06:55,500
Them, If you only knew about components,
but

123
00:06:55,500 --> 00:06:58,760
you didn't know about connectors,
you couldn't do downstream analyses of

124
00:06:58,760 --> 00:07:01,410
your architectural models that
had to do with interaction.

125
00:07:01,410 --> 00:07:05,430
You could only do limited analyses that
had to do with structure, or computation.

126
00:07:05,430 --> 00:07:06,180
Okay?

127
00:07:06,180 --> 00:07:07,370
So, what people, and

128
00:07:07,370 --> 00:07:11,150
then in avionics, they were modeling
a bunch of avionics properties.

129
00:07:11,150 --> 00:07:13,470
In terms of ADL and other things.

130
00:07:13,470 --> 00:07:17,850
Well that might not have done as great of
job as modeling properties relevant to

131
00:07:18,950 --> 00:07:22,720
say data movement in those Avionic
systems, but it might have done a great

132
00:07:22,720 --> 00:07:26,915
job at modeling properties, properties
related to architectural reliability.

133
00:07:26,915 --> 00:07:28,930
Because that was really
important in the domain.

134
00:07:28,930 --> 00:07:32,230
So what people started to realize looking
across all the architecture description

135
00:07:32,230 --> 00:07:33,090
language is,

136
00:07:33,090 --> 00:07:37,120
they are being developed in sort of
this hay day of architecture research.

137
00:07:37,120 --> 00:07:40,520
Is that they really wanted to kind
of pick the best of all of them.

138
00:07:40,520 --> 00:07:43,164
And so then came this sort
of notion of extensible,

139
00:07:43,164 --> 00:07:45,630
architecture description languages, okay.

140
00:07:45,630 --> 00:07:48,610
And ACME was sort of
the first example of that.

141
00:07:48,610 --> 00:07:53,310
ADML was ACME, that canonical model,
represented as XML.

142
00:07:53,310 --> 00:07:55,990
Okay, and there was an ACME
studio that came along with that,

143
00:07:55,990 --> 00:07:59,760
which was this sort of eclipse looking
studio on which you can author and

144
00:07:59,760 --> 00:08:05,030
create these architectural model instances
that were ADML instances, that had

145
00:08:05,030 --> 00:08:12,000
these ability to capture, for example
in a component, its memory footprint.

146
00:08:12,000 --> 00:08:16,540
And when have to maybe specify
its bandwidth requirements.

147
00:08:16,540 --> 00:08:20,410
To specify on a connector what type
of interaction protocol it has.

148
00:08:20,410 --> 00:08:23,070
So, arbitrary properties
specified per component,

149
00:08:23,070 --> 00:08:27,650
per connector, per canonical
architectural element, and and

150
00:08:27,650 --> 00:08:30,399
really recorded in this
architectural modeling instance.

151
00:08:31,870 --> 00:08:36,530
xADL or xADL is,
very similar to AC, to ADML.

152
00:08:36,530 --> 00:08:40,470
And it came out of UC Irvine,
XADL did, and the screen shot here is

153
00:08:40,470 --> 00:08:45,610
actually a screen shot of Arch Studio 4,
which is, the environment in which you

154
00:08:45,610 --> 00:08:50,465
author architectural modeling instances
that are guided by xADL or, xADL.

155
00:08:50,465 --> 00:08:50,965
'Kay?

156
00:08:53,030 --> 00:08:56,980
So now we're moving from architectural
models and its be, it being important to

157
00:08:56,980 --> 00:09:00,710
sort of capture these properties so that,
eventually we can do downstream analyses.

158
00:09:00,710 --> 00:09:04,640
And I don't cover architectural
analysis here in this in this

159
00:09:04,640 --> 00:09:06,630
summer school 'because we
simply don't have time.

160
00:09:06,630 --> 00:09:10,110
But I encourage you to take a look at some
of my architectural analysis slides on

161
00:09:10,110 --> 00:09:13,730
my website my USC website
that I linked earlier.

162
00:09:13,730 --> 00:09:18,190
The whole goal of capturing these
architectural modeling instances is really

163
00:09:18,190 --> 00:09:22,790
ultimately to have, the ability to
understand a lot of properties and

164
00:09:22,790 --> 00:09:25,750
elements in our software system
long before we implement the code.

165
00:09:25,750 --> 00:09:30,290
Well one thing that can really help
us with sort of just interacting and

166
00:09:30,290 --> 00:09:32,640
looking at architectural modeling.

167
00:09:32,640 --> 00:09:36,290
Are architectural model notations,
driven by these architectural description

168
00:09:36,290 --> 00:09:39,180
languages and
these architectural modeling languages.

169
00:09:39,180 --> 00:09:42,920
One of the things that can really help
us is architecture visualization.

170
00:09:42,920 --> 00:09:44,190
Okay?
And visualization is more than

171
00:09:44,190 --> 00:09:47,650
simply putting a pretty picture of
an architecture up on a screen, like for

172
00:09:47,650 --> 00:09:49,632
example the one that I showed
you with Tika earlier.

173
00:09:49,632 --> 00:09:53,380
But it's, it's not just depicting
the architectural model, but

174
00:09:53,380 --> 00:09:57,240
it's interacting with it okay, so this
is what separates visualizations from,

175
00:09:57,240 --> 00:10:02,510
architectural visualization from simple
static diagrams or simple drawings.

176
00:10:02,510 --> 00:10:03,020
Okay?

177
00:10:03,020 --> 00:10:06,730
And there are sort of four kind of common
approaches to architectural visualization.

178
00:10:06,730 --> 00:10:10,630
There's textual, yes, some people capture
architectural moral instances and

179
00:10:10,630 --> 00:10:14,230
then visualize them in text files,
in the text editor.

180
00:10:14,230 --> 00:10:14,790
Right?

181
00:10:14,790 --> 00:10:19,100
We write a bunch of text, you know,
you publish a paper on an architecture and

182
00:10:19,100 --> 00:10:19,700
big data, or

183
00:10:19,700 --> 00:10:23,880
whatever, and we've got text, which has
a lot of information about the components,

184
00:10:23,880 --> 00:10:27,440
the connectors, those principal design
decisions about the software system, so

185
00:10:27,440 --> 00:10:31,020
text is a completely valid way to
visualize, an architectural model.

186
00:10:31,020 --> 00:10:35,200
And you know what, there's a textual
visualization even for things like UML.

187
00:10:35,200 --> 00:10:35,760
Right?

188
00:10:35,760 --> 00:10:39,011
It's called XMI,
[LAUGH] it's called interacting, the X,

189
00:10:39,011 --> 00:10:41,250
the XML MetaData interchange language.

190
00:10:41,250 --> 00:10:43,015
It's called interacting
with the EML model,

191
00:10:43,015 --> 00:10:45,710
[INAUDIBLE] in largely
a textual representation.

192
00:10:45,710 --> 00:10:46,370
Okay?

193
00:10:46,370 --> 00:10:48,810
There's graphical,
yes people make PowerPoints.

194
00:10:48,810 --> 00:10:52,990
And there's architectural model,
principle design decisions in there.

195
00:10:52,990 --> 00:10:53,980
Okay?

196
00:10:53,980 --> 00:10:57,610
Hybrid which is sort of what happens when
you meld you bring together text and

197
00:10:57,610 --> 00:10:59,990
sort of these informal
graphical notations.

198
00:10:59,990 --> 00:11:02,490
And then there are things called
effect visualizations, and

199
00:11:02,490 --> 00:11:06,340
you saw these, you see these when you
build early on, when you build models and

200
00:11:06,340 --> 00:11:08,220
things like Rapide, but what they are is.

201
00:11:08,220 --> 00:11:12,240
Basically building an architectural model,
and then running it through a simulator.

202
00:11:12,240 --> 00:11:14,070
And we see these in big
data systems sometimes.

203
00:11:14,070 --> 00:11:18,024
We take an architectural model that
represents a detailed specification of

204
00:11:18,024 --> 00:11:22,100
the system, maybe some interactions,
and then we simulate different data or

205
00:11:22,100 --> 00:11:25,681
operational profiles into the system,
to then see what types of

206
00:11:25,681 --> 00:11:29,410
maybe the degradation of memory
over time or things like that.

207
00:11:29,410 --> 00:11:32,432
So, sort of effect visualizations
are visualizations,

208
00:11:32,432 --> 00:11:36,752
what if scenarios visualizations on your
architectural model that you capture for

209
00:11:36,752 --> 00:11:40,329
that, a lot of times when you
are thinking about visualization there

210
00:11:40,329 --> 00:11:43,105
are multiple views of the same
architectural model or

211
00:11:43,105 --> 00:11:47,390
server architectural even, these are two
views of the Tika library right.

212
00:11:47,390 --> 00:11:50,680
You'll notice a different number,
cardinality of components and

213
00:11:50,680 --> 00:11:52,940
connectors from the left diagram.

214
00:11:52,940 --> 00:11:56,850
From the one of the right okay and
we typically call the differences even

215
00:11:56,850 --> 00:12:00,350
though there are multiple views and
architectural visualization.

216
00:12:00,350 --> 00:12:04,920
Two views of the same thing or the fact
that architectural models typically have

217
00:12:04,920 --> 00:12:07,070
potentially multiple visualizations, and

218
00:12:07,070 --> 00:12:10,870
potentially multiple visualizations
represent different architectural views.

219
00:12:10,870 --> 00:12:14,760
A component view, a view not
being architectural components to

220
00:12:14,760 --> 00:12:17,960
the physical hardware, deployment view,
for example, and things like that.

221
00:12:19,250 --> 00:12:23,920
So, again, just to sort of review,
architectural model captures, some or

222
00:12:23,920 --> 00:12:27,170
all of the principle design decisions
about the software are conjecture, right?

223
00:12:27,170 --> 00:12:30,640
So, you might have an architectural model
that simply focused on the behavior of

224
00:12:30,640 --> 00:12:31,390
your software system.

225
00:12:31,390 --> 00:12:34,430
You might have an architectural model
that simply focused on the structure, and

226
00:12:34,430 --> 00:12:37,130
so it may subset or
capture just the subset of

227
00:12:37,130 --> 00:12:39,660
principal design decisions
that have to do with that.

228
00:12:39,660 --> 00:12:43,250
Okay, an architectural
view is a further filter.

229
00:12:43,250 --> 00:12:44,070
Okay?

230
00:12:44,070 --> 00:12:48,880
A further filter of that model
that you want to visualize.

231
00:12:48,880 --> 00:12:51,030
That is, depict and interact with.

232
00:12:51,030 --> 00:12:52,110
Okay?
It's some subset or

233
00:12:52,110 --> 00:12:54,450
collection or filter,
further filter on the model.

234
00:12:54,450 --> 00:12:57,580
So, maybe we've got the entire
architectural model and

235
00:12:57,580 --> 00:12:59,600
we want to show the deployment view so

236
00:12:59,600 --> 00:13:03,390
it's some filter of the principal design
decisions that have to do with that.

237
00:13:03,390 --> 00:13:06,890
Now the deployment view is
actually the deployment viewpoint,

238
00:13:06,890 --> 00:13:11,600
because the viewpoint is the name of that
filter, the name of that sort of subset of

239
00:13:11,600 --> 00:13:14,190
the principal design decisions
that we're talking about.

240
00:13:14,190 --> 00:13:17,880
So, the way I like to think about is we've
got an architectural model, it may or may

241
00:13:17,880 --> 00:13:21,670
not be a subset of all of the principal
design decisions of the software system.

242
00:13:21,670 --> 00:13:24,810
A view is a further subset of that model,
and

243
00:13:24,810 --> 00:13:26,780
the viewpoint is the name of that view,
okay.

244
00:13:29,620 --> 00:13:33,190
So we're going to move just real
quickly into thinking about,

245
00:13:33,190 --> 00:13:38,320
some, higher level processes for
this in terms of, architectural recovery.

246
00:13:38,320 --> 00:13:40,610
Now that we've covered
architectural modeling,

247
00:13:40,610 --> 00:13:43,280
architectural modeling notations,
architectural visualizations.

248
00:13:43,280 --> 00:13:46,810
We're going to shift gears a little bit,
and talk about architectural recovery.

249
00:13:46,810 --> 00:13:52,150
What you find is that no matter what
you do, to record architectural models,

250
00:13:52,150 --> 00:13:54,720
and do your best to think about
the principle design decisions,

251
00:13:54,720 --> 00:13:57,060
to visualize them,
before you implement the code.

252
00:13:57,060 --> 00:14:00,260
Is that when someone goes and
implements the code, that code may be

253
00:14:00,260 --> 00:14:04,230
different then ones you originally
theorized or, or prescribed if you will.

254
00:14:04,230 --> 00:14:08,220
We called this process architect,
architectural drift.

255
00:14:08,220 --> 00:14:11,130
Well we call it two different things,
we call it either drift or erosion.

256
00:14:11,130 --> 00:14:15,900
Drift is basically when the code,
the as implemented architecture,

257
00:14:15,900 --> 00:14:20,340
varies from the prescribed, or the,
you know sort of thought of, or

258
00:14:20,340 --> 00:14:25,460
software design or based on architecture
modeling notations or, or whatever.

259
00:14:25,460 --> 00:14:28,570
If that code varies from that, but
that it varies in such a way that it

260
00:14:28,570 --> 00:14:31,520
doesn't violate any of the core
assumptions of the architecture.

261
00:14:31,520 --> 00:14:34,900
We call that drift, and it's subtle
difference between that an erosion.

262
00:14:34,900 --> 00:14:38,840
Erosion is pretty much the same,
that same case except the variations in

263
00:14:38,840 --> 00:14:43,160
the code from the actual
prescribed architectural model,

264
00:14:43,160 --> 00:14:47,440
cause such a difference that it actually
does violate like a core requirement or

265
00:14:47,440 --> 00:14:50,650
it violates sort of a core fundamental
principal in the software system.

266
00:14:50,650 --> 00:14:54,020
Either way, there are processes for
dealing with architectural drift and

267
00:14:54,020 --> 00:14:56,560
erosion, and that process is
called architectural recovery.

268
00:14:57,900 --> 00:15:02,900
Basically architectural recovery is the
the act of recovering the architectural or

269
00:15:02,900 --> 00:15:06,170
architectural model, and
instance of an architectural model

270
00:15:06,170 --> 00:15:09,030
from the as implemented architecture or
from the code.

271
00:15:09,030 --> 00:15:12,440
This is the sort of best way
to insure we actually know

272
00:15:12,440 --> 00:15:15,100
what the true architecture of
the system is, because the code is

273
00:15:15,100 --> 00:15:20,430
the most living canonical representation
of your software system period.

274
00:15:20,430 --> 00:15:22,050
Right it's what you
are constantly are working on.

275
00:15:22,050 --> 00:15:25,330
You may even have great architectural
design and all of these documents, but

276
00:15:25,330 --> 00:15:26,540
eventually you get to the code and

277
00:15:26,540 --> 00:15:30,440
that's really what the invest is going
to go into in terms of maintaining.

278
00:15:30,440 --> 00:15:34,380
So the best way is to have some
process for automatically sort of, or

279
00:15:34,380 --> 00:15:38,040
as automatically as possible, recovering
an architectural model from that.

280
00:15:38,040 --> 00:15:40,160
And that's the process of
architecture recovery,

281
00:15:40,160 --> 00:15:43,010
there are various processes for
doing this that have been developed in

282
00:15:43,010 --> 00:15:45,621
the architecture research
literature over the years.

283
00:15:45,621 --> 00:15:49,172
Including ones by Kazman et al,
Jakobac and Medvidovic et al and

284
00:15:49,172 --> 00:15:51,950
various other researchers and
things like that.

285
00:15:51,950 --> 00:15:55,850
Typically this involves looking at
the code, doing static analysis on it,

286
00:15:55,850 --> 00:15:59,980
determining what pieces of code talk to
one another, looking at dynamic statement

287
00:15:59,980 --> 00:16:03,620
analysis, what states are these classes,
or are these components in.

288
00:16:03,620 --> 00:16:06,810
Component connector analysis
which are groupings typically,

289
00:16:06,810 --> 00:16:11,140
of kind of common classes and file and
object oriented code are functions and

290
00:16:11,140 --> 00:16:14,148
procedures, and procedural oriented code.

291
00:16:14,148 --> 00:16:16,940
And then eventually potentially mapping
it to an architectural style and

292
00:16:16,940 --> 00:16:18,530
things like this.

293
00:16:18,530 --> 00:16:21,760
So, we going to wrap up in this module
with architectural recovery and

294
00:16:21,760 --> 00:16:26,450
so, in the next module here in terms of
big data architectural fundamentals I'm

295
00:16:26,450 --> 00:16:29,210
going to actually illustrate
in the context of big data.

296
00:16:29,210 --> 00:16:33,440
Architecture recovery, some of these core
architectural elements, components and

297
00:16:33,440 --> 00:16:36,610
connectors and discuss it in the,
in the context of a real world example.

298
00:16:36,610 --> 00:16:37,160
So, thanks.