UML (Unified Modeling Language)

[ACCtuary]

I am interested in finding out more about this area. It is not necessarily related to actuarial work requirements, but I have been curious if anybody has tried it and what benefits it has on the development process? Which books are good for a first read?

I would be curious to know, especially from actuaries who work closely with I/T or have some responsiblity for application development how you or your colleagues regard UML.

[Arlie_Proctor]

Just my opinion:

If you are developing a front end, it seems to work quite well in helping the analyst record and communicate the interactions between users and systems. It does not serve very well for computationally intensive system activities.

[Mitzy3K]

I agree that UML is most useful for tracking interactions - and not just between users and systems, but for discrete components within a system. I disagree that it is ill suited for computationally intensive systems.

If a computationally intensive system had discrete components interacting, then UML could be very useful - especially if you had closely related but distinct systems sharing components (which is possible: consider a valuation system and a forecasting system might share some computations, but still be distinct.)

UML is also very useful for any system that has multiple programmers, each working on discrete components that interacted. An example of such might be a component that reads assumptions tables, another that reads policy input data, and another that performs calculations.

The reason one might want to create discrete components for each of these tasks is to localize the code that needs to change whenever sourcing changes. Also, in the aforementioned example, the assumption reading and data loading components could be shared by both the valuation system and the projection system, but the computational component would be distinct – perhaps a deterministic calculation engine for the valuation system and a stochastic one for the projection system.

[BassFreq]

I do work closely with I/T and have direct responsiblity for application development. The folks on the I/T side of the house use UML a lot. Its pretty intuitive stuff, very easy to understand, so I've never bothered to study it. I don't want to write or draw any of it (espescially since I'm not going to be the one coding).

However, we do have reviews of all of the uml for each release of the particular application we are working on. I do look closely at most of the drawings the developers provide. I generally look to ensure that:
- all of the connections are present that need to be present
- all of the actors are present in the use case models
- all of the requirements for the software that are in my mind are represented somewhere in the pertinant diagrams

Some of the diagrams are too technical for me to bother with, for example, architechtural diagrams showing the types of servers and services that will be used to form the application's environment. Personally, I don't care whether a server is AIX, Windows, Unix or an Apple ][e! If that stuff doesn't work right, its I/T's problem. But, for example, I make a big fuss when I notice they left out the ability to bring data back into the actuarial data warehouse.

Alongside the UML, we spend a lot of time working on the requirements for the software. These are broken out into high level functional requirements, detailed functional requirements and non-functional requirements. In my experience, at my company, the requirements are more important than the UML. I'll sit down with the people who write the requirements and describe in detail the requirements from an actuaries perspective. The uml is derived from the requirements. When we get to coding, if the uml does not include a requirement, the uml is deemed "defective". If someone has the time, the uml is rewritten, but usually what happens is that I just point to a requirement and say they missed it in the code and they go back and fix the code.

If you google "uml tutorial", you'll find plenty of online tutorials.

[ACCtuary]

One thing I often don't get from google is the perspective, or I get lots of attempts to sell me a UML solution, or whatever. But your overview was a great start and now I may poke around and see what's out there.

Since you don't care 'what's out there', you can have my old TRS-80 for your server farm

[ACCtuary]

Here are my meta-questions.

Is UML designed to make the requirements process easier? Is it designed to facilitate ongoing change to the requirements process? Is it something done alongside it? Is it a visual version of the requirements process, effectively supplanting it?

Basically, what is the reason for a rigorous process for defining how a drawing is done?

[BassFreq]

Is UML designed to make the requirements process easier?
-- Yes, but that's not its main focus. It eases requirements writing by putting things a visual form which for some people is easier to deal with. However, its really is not that helpful in building an app with lots of calculations that you, the actuary, are trying to supply.


Is it designed to facilitate ongoing change to the requirements process?
-- Not really. It all depends on how you and your I/T group use it. It can slow the process down some since now you have to make changes to the requirements AND the uml. But it can be helpful in identifying defects in requirements.


Is it something done alongside it?
--Yes


Is it a visual version of the requirements process, effectively supplanting it?
--It supplants many of the requirements, but its not designed to represent all types of the requirements. In a recent app release, a developer told me to "translate all of the calculations in the spreadsheet into plain English." We never attempted to put those calculations into any sort of uml representation.


Basically, what is the reason for a rigorous process for defining how a drawing is done?
--The rigor is there to ensure that the representation of the requirements is complete and unambiguous. If there is any way that a developer can misinterpret a requirement, they will misinterpret it in the worst way. For example, we also create sample screenshots of how we want each screen to look. Without the uml that defines all of the data and classes, etc., a programmer might hard code any numbers they see on the screenshot since we didn't specify that its an inputed, looked up or calculated value.