about summary refs log tree commit diff
path: root/usth/ICT2.7/P2L2 OO Software Engineering and UML Subtitles/14 - Class Diagram: Attributes - lang_en_vs5.srt
blob: e1230c9ad85cedf96652f5081375c23aa913cdb7 (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
1
00:00:00,090 --> 00:00:02,435
Now that we identify the classes in my system,

2
00:00:02,435 --> 00:00:04,930
let's see how we can identify the attributes for

3
00:00:04,930 --> 00:00:08,680
these classes. First of all let's recall what attributes

4
00:00:08,680 --> 00:00:12,355
are. Attributes represent the structure of a class the individual

5
00:00:12,355 --> 00:00:15,530
data items that compose the state of the class.

6
00:00:15,530 --> 00:00:18,530
So how do we identify these attributes? Attributes may be

7
00:00:18,530 --> 00:00:21,070
found in one of three ways. By examining class

8
00:00:21,070 --> 00:00:25,330
definitions, by studying the requirements, and by applying domain knowledge.

9
00:00:25,330 --> 00:00:28,400
And notice that I want to stress, that this is always

10
00:00:28,400 --> 00:00:31,800
a very important aspect. No matter what kind of system you're

11
00:00:31,800 --> 00:00:35,670
developing. Domain knowledge tends to be fairly important to identify things

12
00:00:35,670 --> 00:00:38,200
Which might not be provided in the descriptions of the system

13
00:00:38,200 --> 00:00:41,070
that tend to be incomplete. And that you can derive by

14
00:00:41,070 --> 00:00:44,390
the fact that you are familiar with the domain. So always

15
00:00:44,390 --> 00:00:47,340
keep in mind the domain knowledge is important for analysis, for

16
00:00:47,340 --> 00:00:50,430
design, for requirements gathering and so on. So now let's go

17
00:00:50,430 --> 00:00:53,530
back to our description of the system. As I said,

18
00:00:53,530 --> 00:00:55,450
I will bring you back for each step of our

19
00:00:55,450 --> 00:00:58,200
analysis. And in this case, we're going to focus on

20
00:00:58,200 --> 00:01:01,550
course offering. And we can say that the course offering, according

21
00:01:01,550 --> 00:01:04,610
to the description, has a number, a location, and a

22
00:01:04,610 --> 00:01:08,140
time. So this is a pretty clear indication that these are

23
00:01:08,140 --> 00:01:11,650
important aspects of the course offering. So they probably should

24
00:01:11,650 --> 00:01:15,600
become attributes of the course offering class. So now if we

25
00:01:15,600 --> 00:01:19,400
report here that sentence, and once more, we underline

26
00:01:19,400 --> 00:01:22,330
the information that we underlined in the description. We can

27
00:01:22,330 --> 00:01:25,540
clearly see how this can be mapped into the definition

28
00:01:25,540 --> 00:01:28,730
of the class. So our class course offering after this

29
00:01:28,730 --> 00:01:32,900
step the analysis will have 3 attributes: number, location, and

30
00:01:32,900 --> 00:01:35,270
time. And as you can see here, I'm not specifying

31
00:01:35,270 --> 00:01:37,540
the type or any other additional information. So in this

32
00:01:37,540 --> 00:01:40,640
first step I'm just interested in having a first draft.

33
00:01:40,640 --> 00:01:42,170
of the class diagram, that I can then

34
00:01:42,170 --> 00:01:44,440
refine in the next iterations of my analysis.