For my final blog, I will give an example of an Information System Development Process 😀
A class is the description for a set of objects with the same attributes and operations. It serves as a template for object creation. Each object created from the template contains the attribute values that conform to attribute types defined in the class.
The step in finding the classes involve analyzing the narrative text of use cases, identifying a first-guess set of objects that will participate in those use cases and classifying these objects based on the following stereotypes:
Boundary or Interface objects are what actors use in communicating with the system.
Entity objects are usually objects from the 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.
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.
Entity objects often map to the database tables and files that contain the information that needs to “outlive” use case execution. Other than persistent, some of your entity objects are transient objects, such as search results, that “die” when the use case ends.
Control objects (controllers) embody much of the application logic and serve as the connecting element 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. Examples of control classes include transaction managers, resource coordinators and error handlers.
We do this 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. However, four basic rules must be obeyed for this process:
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.
Those rules can be summarized in the following Figure.
Figure 2.6: Rules in building the sequence diagram
Keep in mind that both boundary objects and entity objects are nouns, and that controllers are verbs. We may need to rewrite our use case text many times to remove ambiguity and to explicitly reference boundary objects and entity objects. There is no perfect use case text in the first draft and the process must be done iteratively.
Thank you and goodbye! 🙂