In this exercise, you identify the main objects that comprise the PiggyBank online banking system. You can describe these objects as classes, because UML classes provide a convenient template for describing the attributes and relationships of an object. You can discover the main PiggyBank objects by analyzing the project requirements documentation and highlighting all the nouns. You can group the common nouns into a list, and then identify them as an entity, controller, or boundary type class. These classes create the domain diagrams, which then form the foundation for the design model.
An important output of the analysis model is the domain model. The domain model attempts to model the static structure of the application by modeling the main actors and entities that participate in the functional tasks. The domain model consists of one or more basic class diagrams that describe the name of the class and one or two main attributes that describe its behavior. The domain diagrams are the rough blueprints for the system.
Before you create your domain diagram, you must identify the main classes of the PiggyBank online banking system that are described in the project use case documentation. Generally, this step is iterative because it can be difficult to identify and model the proper structure of a system before you understand how the parts of the system interact with each other. You create the list of objects during the analysis pass of the use case documentation, and then you modify your list by adding, removing or reorganizing classes when you build the dynamic model of your system. In this tutorial, the main classes that are described in the requirements documents are identified for you.
To identify the main PiggyBank objects, you must first analyze the use case documentation and list all the nouns that occur. This list provides the basis for the entity, controller, and boundary elements that comprise the domain diagram. The following list contains all the nouns that are described in the PiggyBank use case documentation:
You can refine the list by eliminating the nouns that represent instances of objects, objects that are attributes of other objects, duplicate or related objects, and any other object that represents an insignificant part of the system. Remember that this is an iterative process. In a real-world situation, you would refine this list as you complete your domain model and as you begin to model the dynamic elements of your analysis model. In this tutorial, the refined list of candidate classes is provided below:
These four classes form the basis of the domain model. It is likely that this refined list of objects represents entity classes, because entity classes are often the easiest to discover. The remaining classes, which are either instances or attributes of these classes, describe the details of the main classes and provide information about the relationships that exist between them.
After you identify the list of classes, you can organize them according to their behavior by applying stereotypes. Stereotypes generalize objects by organizing them according to similar traits or functionality. RUP® analysis stereotypes describe the behavior of the class by classifying it into one of three stereotypes: entity, boundary, or controller. You can use these stereotyped classes to create domain diagrams for your system. The following table describes the RUP analysis elements:
Element | Description |
---|---|
![]() |
Boundary classes describe the interfaces between the system and the actors. If the actors are human, the boundary classes often describe the software or hardware interfaces that access the system. If the actors are systems, such as computers or other software applications, the boundary classes often represent software interfaces, such as APIs. |
![]() |
Control classes contain the implementation of the business rules and logic. Control classes are purposefully absracted from the user and are accessed only by the boundary classes. Control classes interact with one or more entity classes. |
![]() |
Entity classes capture the data in the system. |
You can better understand the structure and functionality of a system by applying these basic stereotypes to your list of classes. When you organize your classes according to their function, you can begin to differentiate between the domain of your system and the details of the implementation. You can use these stereotypes to create domain diagrams and sequence diagrams in the following exercises.
To continue, proceed to Exercise 2.3: Creating the PiggyBank domain model diagram.