Review of my OOP design for simple password manager

Question

I'm going to write a simple password manager, which is going to store my accounts encrypted. Here is description of the classes ,
LoginManager - This class will be responsible for authenticating the user, since the data on the harddrive will be encrypted, it will succeed only if the data is succesfully decrypted, the first line of the data file will be [DECRYPTED], so that the program can understand that the data is succesfully decrypted and allow the user to procced to the user interface. Dependecies:

• DataChecker
• CryptographyManager
• StorageManager
• UserInterface

UserInterface - This class will be responsible for editing, searching, viewing and adding data(accounts). Dependecies:

• DataManager

DataManager - The responsability of this class is to manage the data, it will containg an tree or hash table of the data. It must be able to search, edit and add new data to the data structure. Dependecies:

• Data

Data - This class contains the data splitted into fields - ID, accout, comment, password. It should provide proper encapsulation.

DataChecker - The responsability of this class is to verify that the first line of given file is [DECRYPTED], said in another way to check if the data is succesfully decrypted, and encrypted(before closing the program the file must be encryptd).

StorageManager - This class is responsible for reading and writing data from the disk.

CryptographyManager - this class is responsible for storing the cryptography algorithm Dependecies:

• CryptographyAlgorithm

CryptograpghyAlgorithm - This is interface for different cryptography algorithms, every class should implement methods for encrypting and decrypting.

And here is UML diagram:

I think I've made this design over complicated. The program isn't so complicated to make use of any design pattern, so I tried to follow the solid principles. What bothers me the most is that CryptographyManager seems useless. I would like to know if I'm violating the SOLID principles.

Answer 1

Either some important SOLID concepts are being missed here or some UML concepts are.

First lets settle on a vocabulary:

anotherchris.net: umlcheatsheet

Let me break down the diagram.

For now I'm simply taking the text in the boxes as gospel and trying to reconcile that with what the arrows tell me. They aren't agreeing with each other.

1. Backwards arrow, the UserInterface does not have a LoginManager or even know it exists
2. When connecting many objects to one try to do it together
3. Backwards and wrong kind of arrow <|--- is not for association ...
4. ---> is
5. What's the point of even having these interfaces if you talk directly to the implementations? Swap these columns.
6. Same as 5
7. Just being picky, since AES isn't one of LoginManager's 4 things let's not mix visually mix it with them. Moving the two UserInterface boxes somewhere above CrytographyManager nicely cleans that up.
8. DataManager has a one way associate with Data that's been missed.

Also, Interfaces and implementations should not have the same names. The c# people like to put an I prefix on every interface. Others prefer an 'Default' suffix if there is only one implementation or better yet something meaningful.

Infact I don't see what good these single implementations are doing us in this diagram. They don't show any behavioral choices like they would if there were multiple implementations. They just clutter it up. Even if you plan to do it this way, showing me here isn't helping.

UserInterface - This class will be responsible for editing, searching, viewing and adding data(accounts). Dependecies:

This is where a lot of real problems are hiding.

In what way is this a user interface? No users were mentioned in the design of this class. Seems like some DataHandler to me.

Also, how does UserInterface learn of DataManager? You don't have some hinky service locator hijinks or static globals planned do you? Why isn't DataManager in the constructor?

Most importantly, what does UserInterface really do that the other data objects don't do?