Main Concepts

This article focuses on robustness analysis, which involves analyzing the narrative text of use cases and identifying a first-guess set of objects that will participate in each use case, then classifying these objects into three types:

Boundary objects, which actors use in communicating with the system. Boundary objects are the objects with which the actors (for instance, the users) will be interacting in the new system. These frequently include windows, screens, dialogs and menus. If you have a GUI prototype in place, you can see what many of your primary boundary objects will be, and you can also easily pick boundary objects out of your use case text.
Entity objects, which are usually objects from the domain model. Entity objects often map to the database tables and files that contain the information that needs to "outlive" use case execution. Some of your entity objects are "transient" objects, such as search results, that "die" when the use case ends, and many of your entity objects will come from your domain model.
Control objects (which we usually call controllers because they often aren't real objects), which serve as the "glue" between boundary objects and entity objects. Control objects (controllers) embody much of the application logic and serve as the connecting tissue between the users and the stored data. This is where you capture frequently changing business rules and policies, and localize changes to these objects without disrupting your user interface or your database schema down the line. Once in a while (perhaps 20 percent of the time), controllers are "real objects" in a design, but controllers usually serve as placeholders to assure that you don't forget any functionality and system behavior required by your use cases.

En la siguiente figura, podemos observar la función de pegamento, o paso intermedio, necesario para asociar elemntos del análisis a detalles del diseñoi implementación. Nótese que disponemos de las interfaces ya diseñadas(balsamiq), los casos de uso y también los diagramas de secuencia. Ante esta situación se antoja, a prioiri, fácil el poder identificar los elementos utilizados dentro de los diagramas de robustez.

Analisys/design glue that introduces the robustness diagram

En la siguiente figura observamos la hoja de ruta a seguir para la obtención del diagrama. Nótese que el nombre con el que se ha denominado este diagrama lo que denota es la obtención de todos los elementos que serían necesarios para que tuviéremos todos los elementos necesarios para su implmentación. En otras palabras, con los elementos contenidos por nuestro diagrama de robustez, el diseño del sistema sería completo (Objetos, Funciones y Atributos)???

How to para la obtención del diagrama de robustez, desde ahora DOR, a partir del diagrama de Caso de Uso

You perform robustness analysis for a use case by walking through the use case text, one sentence at a time, and drawing the actors, the appropriate boundary, entity objects and controllers, and the connections among the various elements of the diagram. You should be able to fit the basic course and all of the alternate courses on one diagram. Four basic rules apply:

Actors can only talk to boundary objects.
Boundary objects can only talk to controllers and actors.
Entity objects can only talk to controllers.
Controllers can talk to boundary objects and entity objects, and to other controllers, but not to actors

En la siguiente figura se resume las posibles conxiones entre elementos comentadas anteriormente:

TODO.........