UML - Robustness Analysis
Robustness analysis plays several essential roles within the ICONIX process, a method for bridging the gap between analysis and design. Robustness analysis reduces the ambiguity in use case descriptions, by ensuring that they are written in the context of an accompanying domain model. This process makes the use cases much easier to design, test and estimate.
It classifying the objects based on the roles they play, and it helps in partition objects within a Model-View-Controller paradigm. Robustness analysis enables the ongoing discovery of objects, and helps to ensure that had identified most of the major domain classes before starting any additional design or development. As the robustness diagrams depict several types of concepts:
The concepts are boundary object which also called as interface, boundary are the objects with which the actors (for instance, the users) will be communicating in the software system. These might be any windows, screens, dialogs and menus and etc. If there have a GUI prototype in place, there will be what many of the primary boundary objects will be.
The other concepts are control object which can be called as a controller or process. As a control in boundary analysis, it serves as the connecting tissue between boundary elements and entity elements, implementing the logic required to manage the various elements and their interactions.
Entity objects are the things we need to keep track of and the classes from the domain model. Entity object often map to the database tables and files that contain the information that needs to "outlive" use case execution.
To 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. It should be able to fit the basic course and all of the alternate courses on one diagram. Four basic rules apply:
Firstly actors can only talk to the boundary objects. Secondly is Boundary objects can only talk to controllers and actors. Thirdly entity objects can only talk to controllers and lastly controllers can talk to boundary objects and entity objects, and to other controllers, but not to actors. To construct a robustness diagram need to add a boundary element for each major UI element, add a controller to manage each Use Case or add a controller for each business rule and add a controller for any activity that involves and also coordination of several other elements. Add an entity for each business concept
We need robustness diagram to Sanity Check which uses to test the language in the Use Case description. Nouns from the Use Case get mapped onto objects
Verbs from the Use Case get mapped onto actions. Completeness checks for discover the objects you need to implement the use cases and identify alternative courses of action. Object Identification is to decide which methods belong to which objects.
Robustness analysis plays several essential roles within the ICONIX process, a method for bridging the gap between analysis and design. Robustness analysis reduces the ambiguity in use case descriptions, by ensuring that they are written in the context of an accompanying domain model. This process makes the use cases much easier to design, test and estimate.
It classifying the objects based on the roles they play, and it helps in partition objects within a Model-View-Controller paradigm. Robustness analysis enables the ongoing discovery of objects, and helps to ensure that had identified most of the major domain classes before starting any additional design or development. As the robustness diagrams depict several types of concepts:
The concepts are boundary object which also called as interface, boundary are the objects with which the actors (for instance, the users) will be communicating in the software system. These might be any windows, screens, dialogs and menus and etc. If there have a GUI prototype in place, there will be what many of the primary boundary objects will be.
The other concepts are control object which can be called as a controller or process. As a control in boundary analysis, it serves as the connecting tissue between boundary elements and entity elements, implementing the logic required to manage the various elements and their interactions.
Entity objects are the things we need to keep track of and the classes from the domain model. Entity object often map to the database tables and files that contain the information that needs to "outlive" use case execution.
To 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. It should be able to fit the basic course and all of the alternate courses on one diagram. Four basic rules apply:
Firstly actors can only talk to the boundary objects. Secondly is Boundary objects can only talk to controllers and actors. Thirdly entity objects can only talk to controllers and lastly controllers can talk to boundary objects and entity objects, and to other controllers, but not to actors. To construct a robustness diagram need to add a boundary element for each major UI element, add a controller to manage each Use Case or add a controller for each business rule and add a controller for any activity that involves and also coordination of several other elements. Add an entity for each business concept
We need robustness diagram to Sanity Check which uses to test the language in the Use Case description. Nouns from the Use Case get mapped onto objects
Verbs from the Use Case get mapped onto actions. Completeness checks for discover the objects you need to implement the use cases and identify alternative courses of action. Object Identification is to decide which methods belong to which objects.
Figure 1.0 is an incorrect diagram which the Home Page boundary object is talking to the Login Page boundary object and the Account Table entity object.
The Account Table object has a method assigned to it.
The Account Table object has a method assigned to it.
Figure 1.0
There aren't any alternate courses (what happens if the passwords don't match, for instance?) associated with the Validate Login Info control object and the Intercept Request object is a construct that belongs to detailed design.
Figure 1.1 is the correct diagram that putting a control objects between boundary and entity as a connection and with the correct basic rule.
Figure 1.1 is the correct diagram that putting a control objects between boundary and entity as a connection and with the correct basic rule.Figure 1.1
This simple but highly useful technique serves as a crucial link between analysis-the what-and design-the how.This is the purpose of robustness analysis.
Figure 2
The diagram portrays the essence of a streamlined approach to software development that includes a minimal set of UML diagrams and some valuable techniques that take you from use cases to code quickly and efficiently.
Figure 3 The "Big Picture" for Use Case Driven Object Modelling
You will refine both your use case text and your static model as a result of robustness analysis.
Figure 4 The Essential Roles of Robustness Analysis
Within the ICONIX process, this simple but highly useful technique serves as a crucial link between analysis—the what—and design—the how, as shown in Figure 2. Figure 3 shows where robustness analysis resides within the "big picture" for the ICONIX process
Reference
http://www.agilemodeling.com/artifacts/robustnessDiagram.htm
http://iconixprocess.com/iconix-process/analysis-and-preliminary-design/robustness-analysis/
http://en.wikipedia.org/wiki/ICONIX
http://web.cs.toronto.edu/Page4.aspx
http://www.agilemodeling.com/artifacts/robustnessDiagram.htm
http://iconixprocess.com/iconix-process/analysis-and-preliminary-design/robustness-analysis/
http://en.wikipedia.org/wiki/ICONIX
http://web.cs.toronto.edu/Page4.aspx
