Entity, Boundary, Control taxonomy is similar to that of the MVC architecture where Entity = Model, Control = Controller, Boundary = View.

Objects representing system data, often from the domain model.

Objects that interface with system actors (e.g. a user or external service). Windows, screens and menus are examples of boundaries that interface with users. Note:

• Each actor interacts with at least one boundary object
• They transform the actor information to be used by entity and control objects

Objects that mediate between boundaries and entities. These serve as the glue between boundary elements and entity elements, implementing the logic required to manage the various elements and their interactions. It is important to understand that you may decide to implement controllers within your design as something other than objects – many controllers are simple enough to be implemented as a method of an entity or boundary class for example.

	Entity	Boundary	Control
Entity	X		X
Boundary			X
Control	X	X	X

One of the main motivations of using this taxonomy is that it helps to deal with change: Entity classes (describing primarily real-world concepts) are unlikely to change, control classes are more likely to change (the logic of a use case), and boundary classes are most likely to change (interfaces with users and other systems).

This implies that changes to the system will usually affect a small part of the code base.

In your first diagram, you will just have entity classes. The others evolve as you progress into analysis and then design (Evolution)

• Recurring nouns in use cases, e.g., Incident
• Real world entities that the system needs to keep track of, e.g., FieldOfficer, Dispatcher
• Real world procedures that the system needs to keep track of, e.g., EmergencyOperationsPlan
• Find terms that developers or users need to clarify in order to understand the flow of events, e.g., “information submitted by FieldOfficer”
  • Clarify as “EmergencyReport”

• Forms and windows the users need to enter data into the system e.g., EmergencyReportForm
• Notices and messages the system uses to respond to the user, e.g., AcknowledgmentNotice
• Data sources or sinks (eg. Printer)

Note: Beware: Model the user interface at coarse level. Do not model the visual aspects at this stage. Visual aspects are dealt with by a GUI subsystem, e.g., based on SWING in Java, which is the intermediary between the user and the interface class.

• Responsible for coordinating boundary and entity objects e.g., ElevatorController in Elevator class diagram
• Do not have usually a counterpart in real world
• Creation/Destruction (usually):
  • created when a user session or a use case scenario starts
  • ceases to exist at the end of the session or use case scenario
• Collect information from boundary objects and dispatch them to entity and application logic objects
• Collect information from entity or other control objects and dispatch them to boundary objects.

• Identify one control object per use case or more if the use case is complex
• Identify one control object per actor in the use case e.g., FRIEND: ReportEmergencyControl for the FieldOfficer and ManageEmergencyControl for the Dispatcher.
• The life span of a control object should be determined by the use case or extent of user session

Note: The decision to model the control flow of the ReportEmergency use case with two control objects stems from the knowledge that the FieldOfficerStation and the DispatcherStation are actually two subsystems communicating through an asynchronous link (wireless). Though this is related to architectural design, this is a constraint that is not avoidable and is therefore know early on.