Artifact:
|
A Business Entity represents a significant and persistent piece of information that is manipulated by business actors and business workers. Business Entities are passive; that is, they do not initiate interactions on their own. A Business Entity might be used in many different Business Use-Case Realizations and usually outlives any single interaction. Business Entities provide the basis for sharing information (document flow) among Business Workers participating in different Business Use-Case Realizations. | |
Other Relationships: |
Part Of Business Analysis Model
|
Role: | Business Designer |
Optionality/Occurrence: | Can be excluded. Business Entities are very useful for providing a single point of reference for terms and definitions used between departments or projects. |
Templates and Reports: | |
Examples: | |
UML Representation: | Class, stereotyped as <<business entity>>. |
More Information: |
Input to Activities: | Output from Activities: |
Business Entities represent an abstraction of important persistent information within the business. Any piece of information that is a property of something else is probably not a Business Entity in itself. For example, ContactDetails is a property of Customer and therefore not a Business Entity in itself. Information that is not stored but is created or determined on-demand (when necessary) is also probably not a Business Entity. For example, product inventory is certainly significant information, but this is not persistent information. Anytime somebody needs to know how many instances of a particular bar code are currently on the shelves (or in the warehouse), this information will be calculated and then discarded.
Stakeholders use Business Entities to ensure that the information created and required by the organization is present in the Business Analysis Model. A business designer is responsible for identifying and describing Business Entities, as well as for assessing the impact of organizational changes on the information created and required by the business. Business Entities are also used by systems analysts and designers when describing system use cases and identifying software entities, respectively.
Property Name | Brief Description | UML Representation |
---|---|---|
Name | The name of the Business Entity. | The attribute "Name" on model element. |
Brief Description | A brief description of the role and purpose of the Business Entity. | Tagged value, of type "short text". |
Responsibilities | A survey of the responsibilities defined by the Business Entity. This may include the Entity's lifecycle, from being instantiated and populated until the job is finished. | A (predefined) tagged value on the superclass "Type". |
Relationships | The relationships, such as generalizations, associations, and aggregations, in which the Business Entity participates. | Owned by an enclosing package, via the aggregation "owns". |
Operations | The operations defined by the Business Entity. | Owned by the superclass "Type" via the aggregation "members". |
Attributes | The attributes defined by the Business Entity. | Owned by the superclass "Type" via the aggregation "members". |
Diagrams | Any diagrams local to the Business Entity, such as interaction diagrams or class diagrams. | Owned by an enclosing package, via the aggregation "owns". |
The most significant Business Entities are identified during the Inception phase. The remaining Business Entities are identified during the Elaboration phase, in which Business Entities are further refined and described.
A business designer is responsible for the integrity of the Business Entity, ensuring that:
If you are doing domain modeling, meaning that you identify Business Entities only, you can use the stereotype <<domain class>> instead of <<business entity>>.
This content developed or partially developed by Empulsys BV. |
Rational Unified Process |