1 | |
---|
2 | .. |n0| replace:: n\ :sub:`0` |
---|
3 | .. |m0| replace:: m\ :sub:`0` |
---|
4 | |
---|
5 | .. _label-data-entities: |
---|
6 | |
---|
7 | Data Entities |
---|
8 | ============= |
---|
9 | |
---|
10 | These are the data entities the new system is supposed to model. Each |
---|
11 | of these entities should be addable, editable, and removable as |
---|
12 | covered in more detail in :ref:`label-use-cases`. |
---|
13 | |
---|
14 | For each entity we give a short description to tell what it means, |
---|
15 | what its purpose is and in what regards (and how) it should be handled |
---|
16 | by the system. Again the more detailed actions on these entities |
---|
17 | provided by the system are described in the :ref:`label-use-cases` |
---|
18 | section. |
---|
19 | |
---|
20 | The data entities are sorted alphabetically, not by importance or |
---|
21 | similar. Used description terms should link to other respective |
---|
22 | entities/terms where possible. |
---|
23 | |
---|
24 | Each data entitiy description provides a list of use cases and other |
---|
25 | data entities connected. Connections to other data entities contain a |
---|
26 | relationship telling how many instances of the described entity are |
---|
27 | connected to how many instances of the related entity. |
---|
28 | |
---|
29 | The following relation types may occur (in both directions): |
---|
30 | |
---|
31 | - 1:1 (one on one) |
---|
32 | - n:1 (many on one) |
---|
33 | - n:m (many on many) |
---|
34 | - p:1 (many or none on one) |
---|
35 | - p:q (many or none on many or none) |
---|
36 | - p:n (many or none on many) |
---|
37 | - b:1 (one or none on one) |
---|
38 | |
---|
39 | with |
---|
40 | |
---|
41 | - n, m element of {1, 2, ...}, |
---|
42 | - p, q element of {0, 1, 2, ...} |
---|
43 | - b element of {0, 1} |
---|
44 | |
---|
45 | Examples: |
---|
46 | |
---|
47 | 1:p service-contract relation means that each service |
---|
48 | offered can result in various contracts, but each contract is |
---|
49 | only based on one service. |
---|
50 | |
---|
51 | p:q user-userrole relation means that each user can have no role or |
---|
52 | several roles and each role can be assigned to no user or several users. |
---|
53 | |
---|
54 | Relations can always be read in two directions. |
---|
55 | |
---|
56 | .. _label-contact-address: |
---|
57 | |
---|
58 | Contact Address |
---|
59 | --------------- |
---|
60 | |
---|
61 | A postal address. |
---|
62 | |
---|
63 | Connected to: :ref:`label-contact-data` (p:1) |
---|
64 | |
---|
65 | Used in the following use cases: |
---|
66 | |
---|
67 | |
---|
68 | .. _label-contact-data: |
---|
69 | |
---|
70 | Contact Data |
---|
71 | ------------ |
---|
72 | |
---|
73 | The data neccessary to contact some :ref:`label-customer`, |
---|
74 | :ref:`label-officer` or similar entity. Contact data might contain several |
---|
75 | addresses, phone numbers, emails, etc. |
---|
76 | |
---|
77 | Connected to: :ref:`label-customer` (1:1), |
---|
78 | :ref:`label-contact-address` (1:p), :ref:`label-contact-email` |
---|
79 | (1:n), :ref:`label-contact-phone` (1:p) |
---|
80 | |
---|
81 | Used in the following use cases: |
---|
82 | |
---|
83 | |
---|
84 | .. _label-contact-email: |
---|
85 | |
---|
86 | Contact Email |
---|
87 | ------------- |
---|
88 | |
---|
89 | An email address with optional additional clear name. For email |
---|
90 | addresses we store some timestamp that indicates when the respective |
---|
91 | email address was last checked successfully (thus marking it a 'valid' |
---|
92 | one). No timestamp means, the email address has never been checked. |
---|
93 | |
---|
94 | Connected to: :ref:`label-contact-data` (n:1), |
---|
95 | :ref:`label-timestamp` (1:q) |
---|
96 | |
---|
97 | Used in the following use cases: |
---|
98 | |
---|
99 | |
---|
100 | .. _label-contact-phone: |
---|
101 | |
---|
102 | Contact Phone |
---|
103 | ------------- |
---|
104 | |
---|
105 | Mobile phone number which is capable of receiving sms text messages. |
---|
106 | |
---|
107 | Connected to: :ref:`label-contact-data` (p:1) |
---|
108 | |
---|
109 | Used in the following use cases: |
---|
110 | |
---|
111 | |
---|
112 | .. _label-contract: |
---|
113 | |
---|
114 | Contract |
---|
115 | -------- |
---|
116 | |
---|
117 | A contract is created whenever a :ref:`label-customer` orders some |
---|
118 | :ref:`label-service` from the system. It is always connected to a |
---|
119 | :ref:`label-customer` and a :ref:`label-service` . |
---|
120 | |
---|
121 | A contract is not necessarily written on paper and signed by |
---|
122 | people. Instead it is an abstraction used inside the system. |
---|
123 | |
---|
124 | It is always created from a :ref:`label-service`, which tells about |
---|
125 | the basic data, with additional parameters set that depend on the type |
---|
126 | of :ref:`label-service` ordered. |
---|
127 | |
---|
128 | Contracts can trigger :ref:`label-transaction`\ s. For instance if some |
---|
129 | :ref:`label-customer` orders a service. When the service charges |
---|
130 | become due, a respective :ref:`label-transaction` is triggered. |
---|
131 | |
---|
132 | Contracts can have multiple :ref:`label-contract-addon`\ s. |
---|
133 | |
---|
134 | Connected to: :ref:`label-service` (p:1), :ref:`label-customer` (p:1), |
---|
135 | :ref:`label-contract-addon` (1:p), :ref:`label-transaction` (1:p), |
---|
136 | :ref:`label-meter` (1:b) |
---|
137 | |
---|
138 | Used in the following use cases: |
---|
139 | |
---|
140 | |
---|
141 | .. _label-contract-addon: |
---|
142 | |
---|
143 | Contract Addon |
---|
144 | -------------- |
---|
145 | |
---|
146 | Kind of 'sub contract' that always belongs to some already existing |
---|
147 | :ref:`label-contract` but comes with an own set of |
---|
148 | parameters. Contract addons are created by :ref:`label-contract`\ s. |
---|
149 | |
---|
150 | Connected to: :ref:`label-contract` (p:1), |
---|
151 | :ref:`label-service` (p:1), :ref:`label-customer` (p:1), |
---|
152 | :ref:`label-transaction` (1:p) |
---|
153 | |
---|
154 | |
---|
155 | .. _label-customer: |
---|
156 | |
---|
157 | Customer |
---|
158 | -------- |
---|
159 | |
---|
160 | Beneficiary of :ref:`label-contract`\ s. |
---|
161 | |
---|
162 | Customers are added to the system by initial import (migration phase), |
---|
163 | being created by staff or can self-register themselves to the system. |
---|
164 | |
---|
165 | Customers have to provide :ref:`label-contact-data` and get |
---|
166 | :ref:`label-login-credentials` to login to the system. |
---|
167 | |
---|
168 | Once logged in, customers get a 'My Eko-Disco' page where they can |
---|
169 | |
---|
170 | - see their current orders |
---|
171 | |
---|
172 | - watch their consumption |
---|
173 | |
---|
174 | - order more services |
---|
175 | |
---|
176 | - handle contractual problems |
---|
177 | |
---|
178 | - get help if problems arise |
---|
179 | |
---|
180 | - retrieve bills |
---|
181 | |
---|
182 | - change their passwords |
---|
183 | |
---|
184 | Customers can order :ref:`label-service`\ s and pay these (kinds of |
---|
185 | payment depend on the type of service/good ordered and the available |
---|
186 | payment methods). |
---|
187 | |
---|
188 | Customers and their data can be managed by customers themselves (for |
---|
189 | instance when postal addresses change), and by officers. |
---|
190 | |
---|
191 | Connected to: :ref:`label-contract` (1:p), |
---|
192 | :ref:`label-contact-data` (1:1), :ref:`label-login-credentials` (1:1), |
---|
193 | :ref:`label-user` (b:1) |
---|
194 | |
---|
195 | |
---|
196 | .. _label-location: |
---|
197 | |
---|
198 | Location |
---|
199 | -------- |
---|
200 | |
---|
201 | A real-world location. Used for instance for meters to store |
---|
202 | information about their place. The location of a meter does not necessarily |
---|
203 | correspond with one of the :ref:`label-contact-address`\ es. |
---|
204 | Locations can either be less formal, for instance describing a location |
---|
205 | in words, or very precise by using GPS data. |
---|
206 | |
---|
207 | Connected to: :ref:`label-meter` (1:p) |
---|
208 | |
---|
209 | |
---|
210 | .. _label-login-credentials: |
---|
211 | |
---|
212 | Login Credentials |
---|
213 | ----------------- |
---|
214 | |
---|
215 | A set of username/password assigned to system users. Passwords are |
---|
216 | stored inside the system using strong cryptographic hash functions. |
---|
217 | |
---|
218 | Passwords can be reset on request. |
---|
219 | |
---|
220 | Connected to: :ref:`label-customer` (1:1) |
---|
221 | |
---|
222 | |
---|
223 | .. _label-meter: |
---|
224 | |
---|
225 | Meter |
---|
226 | ----- |
---|
227 | |
---|
228 | A meter measures power consumption. It has a place where it is |
---|
229 | installed and might be connected to one or several contracts. For a |
---|
230 | given time a meter can be connected to one or zero contracts. |
---|
231 | |
---|
232 | Each meter has to provide a :ref:`label-location` that tells, where it |
---|
233 | is installed. |
---|
234 | |
---|
235 | Meters also contain a history of meter values |
---|
236 | (:ref:`label-meter-value`), which is basically a list of meter values |
---|
237 | at a given time. |
---|
238 | |
---|
239 | Connected to: :ref:`label-contract` (b:1), |
---|
240 | :ref:`label-meter-value` (1:n), :ref:`label-location` (p:1) |
---|
241 | |
---|
242 | |
---|
243 | .. _label-meter-value: |
---|
244 | |
---|
245 | Meter Value |
---|
246 | ----------- |
---|
247 | |
---|
248 | The value of a :ref:`label-meter` at a certain point in time |
---|
249 | (providing a :ref:`label-timestamp`) authorized by some |
---|
250 | :ref:`label-user` or device. |
---|
251 | |
---|
252 | It serves mainly for computing power consumption of |
---|
253 | :ref:`label-customer`\ s. |
---|
254 | |
---|
255 | When a new meter value is added to the system (the respective |
---|
256 | :ref:`label-meter` is 'updated'), the system also registers how the |
---|
257 | the new value was entered, i.e. by whom and when. |
---|
258 | |
---|
259 | The system will be prepared to collect meter values in two ways: |
---|
260 | |
---|
261 | a) (push-method): by being fed with respective data by authorized |
---|
262 | users (officers) |
---|
263 | |
---|
264 | b) (pull-method): by polling dedicated hardware that provides the |
---|
265 | neccessary interface (automatic remote-reading). |
---|
266 | |
---|
267 | The second choice requires appropriate hardware to be in place, which |
---|
268 | in detail is not part of this specs. The system will, however, be |
---|
269 | prepared to collect meter data from external devices. |
---|
270 | |
---|
271 | Connected to: :ref:`label-meter` (n:1), :ref:`label-timestamp` (1:1), |
---|
272 | :ref:`label-user` (p:1) |
---|
273 | |
---|
274 | |
---|
275 | .. _label-officer: |
---|
276 | |
---|
277 | Officer |
---|
278 | ------- |
---|
279 | |
---|
280 | Officers are staff members with certain permissions to manage portal data. |
---|
281 | |
---|
282 | Actors are called :ref:`Manager <label-actors>` if they are officers with local |
---|
283 | managing permission. |
---|
284 | |
---|
285 | Connected to: :ref:`label-login-credentials` (1:1), |
---|
286 | :ref:`label-user` (b:1), |
---|
287 | :ref:`label-user-role` (1:p) |
---|
288 | |
---|
289 | |
---|
290 | |
---|
291 | .. _label-report: |
---|
292 | |
---|
293 | Report |
---|
294 | ------ |
---|
295 | |
---|
296 | Administrative report or list to give overviews over current state of |
---|
297 | business. Includes lists of customers sorted by various categories |
---|
298 | (type of contract, amount of fees paid, etc.), lists of services |
---|
299 | sorted by various categories, etc. |
---|
300 | |
---|
301 | Reports are generated as PDF documents and are available for download |
---|
302 | by authorized :ref:`label-user`\ s. |
---|
303 | |
---|
304 | Connected to: (almost everything else) |
---|
305 | |
---|
306 | |
---|
307 | .. _label-service: |
---|
308 | |
---|
309 | Service |
---|
310 | ------- |
---|
311 | |
---|
312 | The system will provide different services to |
---|
313 | :ref:`label-customer`\ s. These can have arbitrary forms, including |
---|
314 | one-time services (like installation of meters) and open-ended |
---|
315 | long-time services (like delivering power based on contract). Services |
---|
316 | are managable by staff like goods offered in a shop. |
---|
317 | |
---|
318 | Services define the conditions under which they can be ordered by |
---|
319 | :ref:`label-customer`\ s, including prices, runtimes, etc. |
---|
320 | |
---|
321 | Services also serve as factories for :ref:`label-contract`\ s. |
---|
322 | |
---|
323 | Connected to: :ref:`label-contract` (1:p) |
---|
324 | |
---|
325 | Used in the following use cases: |
---|
326 | |
---|
327 | |
---|
328 | .. _label-timestamp: |
---|
329 | |
---|
330 | Timestamp |
---|
331 | --------- |
---|
332 | |
---|
333 | A timestamp can be a calendar date or a calendar date plus some day |
---|
334 | time. |
---|
335 | |
---|
336 | The system will internally use UTC-based timestamps only to minimize |
---|
337 | ambiguities. In menus, frontends, etc. timestamps are displayed in |
---|
338 | local Lagos time. |
---|
339 | |
---|
340 | Connected to: :ref:`label-meter-value` (1:1), |
---|
341 | :ref:`label-contact-email` (p:1) |
---|
342 | |
---|
343 | |
---|
344 | .. _label-transaction: |
---|
345 | |
---|
346 | Transaction |
---|
347 | ----------- |
---|
348 | |
---|
349 | A transaction is some business-relevant action taken. A transaction |
---|
350 | means basically, that something happened, that leads to increased or |
---|
351 | decreased customer accounts. Normally this is something like a |
---|
352 | payment, some service order or similar. |
---|
353 | |
---|
354 | Transactions do always belong to one certain customer account. They |
---|
355 | also contain some amount of money which is thereby transfered to or |
---|
356 | from a customer's account. They also always reference a service which |
---|
357 | is consumed, purchased, or (pre-)paid by the respective customer. |
---|
358 | |
---|
359 | Connected to: :ref:`label-customer` (p:1), :ref:`label-service` |
---|
360 | (p:1), :ref:`label-contract` (p:1) |
---|
361 | |
---|
362 | Used in the following use cases: |
---|
363 | |
---|
364 | |
---|
365 | .. _label-user: |
---|
366 | |
---|
367 | User |
---|
368 | ---- |
---|
369 | |
---|
370 | A system user. |
---|
371 | |
---|
372 | Users can have :ref:`label-user-role`\ s managed by the |
---|
373 | system. Real-world officers (staff members) and customers are different to the |
---|
374 | system as they will have different roles. Also anonymous users are |
---|
375 | accepted by the system to provide marketing pages, service offers, |
---|
376 | etc. |
---|
377 | |
---|
378 | Each user has one set of :ref:`label-login-credentials` to authenticate |
---|
379 | against the system. |
---|
380 | |
---|
381 | Users can be blocked or removed from the system. |
---|
382 | |
---|
383 | Connected to: :ref:`label-login-credentials` (1:1), |
---|
384 | :ref:`label-customer` (1:b), |
---|
385 | :ref:`label-user-role` (p:q) |
---|
386 | |
---|
387 | |
---|
388 | .. _label-user-role: |
---|
389 | |
---|
390 | User Role |
---|
391 | --------- |
---|
392 | |
---|
393 | A set of permissions assigned to a group of :ref:`label-user`\ s. |
---|
394 | |
---|
395 | Connected to: :ref:`label-user` (p:q) |
---|
396 | |
---|