The Application Layer is all about behaviour. What is the functionality that is being provided?
We capture the actual systems that we know in our architecture using the Application Provider class. So, we'd create an Application Provider instance for your Oracle HR system and one for your FirstClass Email system. Note that these represent YOUR configuration of these Technology Products to provide the specific behaviour in your organisation. We recommend that you name these according to how they are know in the organisation rather than just the name of the product that it is based on - whilst recognising that in some cases these are the same names!
I'll park any further discussion of the whole Application / Technology thing just now and focus on your question about Application and Information.
In terms of the databases themselves, we capture those as Information Stores (which could be things other than databases as well) and we can describe the types of information that exists in each Information Store and even things like the organisational scope of the information and data in there. E.g. Oracle HR Database X contains Person data for department A, whilst Oracle HR Database Y contains Person data for department B.
We relate the Applications to the Information that they use (produce and consume) via the Uses Information field on the Application Provider class. This actually uses a relationship class that enables us to add additional contextual information about how the Application uses the Information (e.g. the CRUD) and in that context, what Data elements are used.
Note that we separate Information and Data and this works really nicely to support things like Master Data Management and other Information and Data Management activities. This forum post explains the
"what is Information, what is Data" approach that we have taken.
In your scenario, we have a couple of options. Which one to use depends on what you mean by "call it different names". Where it is people (typically business users) who call the same Data element by different names, we can define Synonyms for that element to capture all the different terms by which it is known.
However, I think what you're describing is how the application knows the Person_ID element. In this case (the most common), we use our abstraction layers to model what the application means by, e.g. EmplID or Username. We do this in the logical information layer, using the Data Object / Data Object Attribute classes to capture the element as it 'should' be known in the Information Architecture and the Data Representation / Data Representation Attribute classes to capture what the specific applications are using and then relate the Representations to the Objects. Note the same principle applies to the Information View / Information Representation classes for Information things.
So, we might create a Data Object called Person_ID and then three Data Representations for each of EmplID, Username, OperatorID and relate each of these back to the Person_ID object.
As I mentioned before, we relate the Applications to the Information that they are consuming and / or providing. In the context of each of those relationships, we relate the Data elements that are being used in that context. This approach provides a lot of power in particular for accurately capturing what is going on, which gives us high fidelity in the model.
Don't forget that we can model all this at as coarse or as fine-grained as we need - we don't always need to get down to attribute level to provide a lot of value. It depends on your scenario.
Finally, you mention Software and this is managed as a part of the Application Layer, using the Software Component classes. Note that this is not about UML modelling the classes in the Application but provides a connection to the Technology that is supporting the Application Provider. In particular this can be important for distributed applications. What we capture is the main software elements or components - typically identified by what bits of software would you install. e.g. client component, server component and so on.
However, the key relationships are between the Application things, which are focussed on the behaviour of your systems (the functionality - what do they do?) which are then supported by a technology platform (in terms of hardware and software infrastructure technologies as well as packaged application technologies). Our applications might be completely home grown, in which case we might be more interested in capturing the software components or off-the-shelf products. In the case of application products, it is our configuration of that product that is the Application Provider.
Jonathan