about summary refs log tree commit diff
path: root/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/8 - OO Analysis Overview - lang_en_vs4.srt
blob: fccd722755be7c208c9c016da9c96bb55dc53bcc (plain) (blame)
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
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
1
00:00:00,110 --> 00:00:02,540
So let's look at the object-oriented analysis in a

2
00:00:02,540 --> 00:00:05,540
little more detail. As I said earlier, traditional analysis

3
00:00:05,540 --> 00:00:08,890
and design techniques were functionally oriented. What that means

4
00:00:08,890 --> 00:00:11,980
is that they concentrated on the functions to be performed,

5
00:00:11,980 --> 00:00:14,510
whereas the data upon which the functions operated were

6
00:00:14,510 --> 00:00:18,900
secondary to the functions themselves. Conversely, object oriented analysis, is

7
00:00:18,900 --> 00:00:22,100
primarily concerned that with a data objects, so we

8
00:00:22,100 --> 00:00:25,500
went from a functional oriented view to a data oriented

9
00:00:25,500 --> 00:00:28,070
view, what that means is that during the analysis phase,

10
00:00:28,070 --> 00:00:30,770
we define a system first in terms of the data

11
00:00:30,770 --> 00:00:34,380
types and their relationships, and the functions or methods are

12
00:00:34,380 --> 00:00:38,130
defined only later and associated with specific objects which are sets

13
00:00:38,130 --> 00:00:40,380
of data. So let's see how we can perform object

14
00:00:40,380 --> 00:00:44,040
orientated analysis in practice, so the basic idea is to be

15
00:00:44,040 --> 00:00:47,060
focused on the objects of the real world. So to

16
00:00:47,060 --> 00:00:51,310
go from a real world objects to a set of requirements.

17
00:00:51,310 --> 00:00:55,340
And we can describe this as a four-step process. The first

18
00:00:55,340 --> 00:00:57,790
step is to obtain or prepare a textual description of the

19
00:00:57,790 --> 00:01:00,400
problem to be solved. So obviously, we need to start from

20
00:01:00,400 --> 00:01:03,300
some description of the system that we need to build. And

21
00:01:03,300 --> 00:01:06,120
this is a very practical oriented approach, so that the next

22
00:01:06,120 --> 00:01:08,390
thing we do is that we take the description and we

23
00:01:08,390 --> 00:01:12,670
underline nouns. In this description. And the nouns that we underline

24
00:01:12,670 --> 00:01:16,710
will become classes in my analysis. We then look at adjectives in

25
00:01:16,710 --> 00:01:19,530
the document. We underline those, and we use that

26
00:01:19,530 --> 00:01:23,130
information to identify the attributes of the classes that we've

27
00:01:23,130 --> 00:01:26,370
previously identified. At this point we focus on active

28
00:01:26,370 --> 00:01:29,610
verbs in the description, and the analysis of the active

29
00:01:29,610 --> 00:01:32,710
verbs will give us the operations that we'll need

30
00:01:32,710 --> 00:01:36,830
to define for our classes. So, again, underline nouns, and

31
00:01:36,830 --> 00:01:38,950
those will become the classes in my system. Then,

32
00:01:38,950 --> 00:01:42,150
objectives. And, those will be the attributes of the classes.

33
00:01:42,150 --> 00:01:46,650
And, finally, active verbs that will become the operations of my classes. And

34
00:01:46,650 --> 00:01:48,840
of course, this is a high level view to take this with a

35
00:01:48,840 --> 00:01:51,790
grain of salt. But we will see that it's a very good pragmatic

36
00:01:51,790 --> 00:01:54,760
approach to identifying requirements, starting from a

37
00:01:54,760 --> 00:01:56,570
description of the system to be built.