Re: check funtion and password show in UML

From: H. S. Lahman <vze2zxnu_at_verizon.net>
Date: Tue, 30 Jul 2002 23:14:26 GMT
Message-ID: <3D471E67.2090607_at_verizon.net>

Responding to van Amelaan...

> I am a real beginner in UML and I've got a 2 (simple) cases, which I
> am not sure if I do it right (my possible solution is insterted):
>
> First one:
> Person X is registering in a database that he send a letter to person
> Y.
> If person Y received the letter, he should confirm this by check a box
> behind the register information (made by Person X).
>
> Second one:
> Somebody has to log into a system with a loginname and password/
>
> How can I show this in UML?
>
> Possible solution first case(?):
> There is a class "Person" and a class "Letter". Should I draw just
> these two classes with a normal association and add special
> operations? Or should I add a remark which explains the situation?

What about the registration itself? That seems to be a concrete entity that gets updated. There are actually several possibilities, depending on what else is relevant about Person and Letter.

        1                       1
Person ------------------------- Registration
   | 1           records sending       | 1
   |                      letter       | records letter reception
   |                                   |
   +-----------------------------------+

In this case Letter is incidental and the focus is on the notion of registration. The problem with this is that the relationships don't capture the idea that they are tied to the same letter. One way around this is via an associative object:

        1                       1
Person ------------------------- Registration
   | 1         | records sending       | 1
   |           |          letter       | records letter reception
   |           |                       |
   |        Letter                     |
   |           |                       |
   |           |                       |
   +-----------------------------------+

Now the same Letter is associated with each relationship. This also suggests that the Letter itself isn't very significant (i.e., it just provides referential integrity for the registration).

However, is the sending an receiving of a letter is important, the following might be better.

             Person
                A
                | R1
       +--------+--------+
       |                 |
    Sender            Receiver
     |  |              |    |
     |  | R2        R3 |    |
     |  +---- Letter --+    |
     |          |           |
     |          | R4        |
     |          |           |
     +----- Registration ---+
      R5                  R6

where the relationships are:

R1: is-a
R2: Sender (1) MAILS Letter (*)
R3: Receiver (1) RECEIVES Letter (*)
R4: Letter (1) IS TRACKED BY Registration (1)
R5: Sender (1) CREATES Registration (*)
R6: Receiver (1) RECORDS RECEPTION IN Registration (*)

The 1:1 R4 relationship enforces the fact that there is exactly one Registration for a Letter. Now there must be constraints on the R2, R4, R5 and R3, R4, R6 loops that require that Sender and Receiver get to the same instance of Registration via R5 or R5 as they would get to via R2/R4 or R3/R4. One can do this with an OCL tag or the notation R5(R2,R4) and R6(R3,R4).

At the OOA level this essentially says that in the OOP implementation the relationship navigation mechanism musty enforce referential integrity. For example, when Sender R2 and R5 are collection relationships since a Person can send several Letters. So at the OOP level some mechanism must be provided to ensure that the members are matched up. That can be done by ordering the collection or providing a Find mechanism. The constraint simply identifies that the collections are not independent.

>
> Possible solution second case(?):
> Just use the class "person" with attributes loginname and password
> with operations like insertLogin, insertPassword, checkPassword. Or
> something?

That's possible, but should Person be responsible for those activities?   If the only reason one has a Person class is to validate logins, that is probably reasonable.

But if Person has other characteristics relevant to the problem, it probably represents a lack of cohesion in the Person subject matter. Whenever one has a class with totally unrelated behaviors it often indicates one is missing objects in the model.

In this case insertLogin and insertPassword sound like GUI activities for controls like text boxes. And checkPassword sounds like some sort of system level responsibility. That is, enforcing security is an application responsibility, not a user responsibility (e.g., who watches the watchers?). So I would be very much inclined to look for another class for those responsibilities -- something like SecurityCop with a checkLogin method that took ID and password as arguments.

So where does one get ID and password? Good question. It is probably overkill for this sort of homework problem, but nontrivial applications usually encapsulate the UI in a subsystem. That subsystem would put up the appropriate dialog box and get the values. It would then send a message to some other subsystem that did security things. That interface would dispatch the message to the SecurityCop instance in its implementation with the ID and password parameters.

If valid, SecurityCop would route a message to whoever cared that they should wake up because there was a new user about to make a nuisance. If invalid, SecurityCop would route a message back to the UI subsystem to announce that the user is a miscreant and should be castigated.

One also does the same sort of subsystem isolation thing with persistence mechanisms. So the way your Registration is represented in the application solution may be quite different than in the DB schema (though unlikely in this simple case).

---

There is nothing wrong with me that could not be cured by a capful of Drano.

H. S. Lahman
hsl_at_pathfindersol.com
Pathfinder Solutions -- We Make UML Work http://www.pathfindersol.com
(888)-OOA-PATH Received on Wed Jul 31 2002 - 01:14:26 CEST