UML modeling angular controllers / factories and services

Question

I have to create UML documentation for my upcoming project. Now I have previously worked with Java which as an object orientated language is relativly easy to design UML class diagrams for. For my next project I will have to design an AngularJs Application.

As some of you might know an Angular application consists of many things including Controllers Factories Services and many more.

My question is when designing these using UML should Controllers / Factories / Services be seen as classes in a class diagram even though they are never defined as classes nor have any constructor but merely consists of variables and functions?

Answer 1

** Short Quick Technical Answer **

You can model Controllers, Factories, and Services as a class, with a stereotype.

..........................
..+--------------------+..
..| <<Controller>> |..
..| SomeController |..
..+--------------------+..
..........................
..+--------------------+..
..| <<Factory>> |..
..| SomeFactory |..
..+--------------------+..
..........................
..+--------------------+..
..| <<Service>> |..
..| SomeService |..
..+--------------------+..
..........................

** Long Boring Conceptual Answer **

U.M.L. is a modeling tool, altought, was originally designed with Object Orientation, is not "glued" to it.

You can still use U.M.L. for concepts that are not strictly objects. In a matter of fact, many Software Application Developers may design an object in U.M.L., that does not traslates exactly, as an object in an specific Programming Language.

For example, the people that interact in a System, a.k.a. "Actors", they are not specifically objects, yet some U.M.L. diagrams allow to use a class or object diagram for an Actor, instead of the Standard icon.

Answer 2

UML models are intended to be useful, so the answer will depend largely on the question 'what would be the most useful description of my system to the person reading this'. You might want to consider object interaction diagrams, component diagrams and sequence diagrams instead of class diagrams.

Depending what you are trying to communicate, you could define a controller stereotype and declare classes for the fields you are binding.

Ultimately though, talk to the person who will be using the documentation and find out what they would find useful.