Chapter 4 - BA Toolkit The Business Analyst's Handbook by Howard Podeswa

C engage L earning 2009 Citation

R e com m e nd?

Class Diagrams and Static Model

Table 4.8: Class Diagrams at a Glance Open table as spreadsheet What? A business-perspective class diagram describes business nouns and concepts and the rules associated with them. It is often referred to as a Business Entity Diagram or a Domain Diagram. Its main modeling elements are classes and relationships. A class is a category of business object, such as Life Policy, Amendment, and Benefit. The diagram indicates relationships that the solution is required to implement, for example, the requirement that the solution be able to connect a Life Policy to its Amendments and Benefits. The diagram may also indicate the multiplicities (numerical rules) that apply to a relationshipfor example, that a Life Policy may have zero or more Amendments. Relationships and multiplicities in business-perspective class diagrams represent business rules that need to be captured, enacted, and tested. The business-perspective class diagram is the key diagram used by the BA to express the static modelthe abstract representation of non-time-based business rules related to objects. The business-perspective class diagrams are used by the technical system analyst (software designer) as input in the creation of technical-perspective class diagrams that specify the design of the IT system. Initiation: BA creates initial class diagrams describing key business concepts and business objects (such as Customer, Supplier, Product Category, and Transaction Type) within the scope of the project, their relationships, and their multiplicities. Discovery: BA adds modeling elements (classes, relationships, multiplicities, etc.) as they are discovered during requirements elicitation. For example, noun phrases appearing in system usecase descriptions (steps within flows, etc.) are modeled as classes if they represent something that the business area requires the IT system to track. The BA documents attributes at this time, if there is risk they will not be handled properly by the developers or to standardize rules associated with them that apply across a number of use cases. Construction: BA models are used by the SA as input to the design of software classes (coding units) and the database. Relationships and multiplicities are enacted. Final V & V: BA models are used as input to the design of test cases. Tests must ensure that each of the relationships and multiplicities is implemented and tested in the software, for example, a multiplicity rule that requires a sale to be able to be credited to more than one salesperson. Where? Business Architecture: Domain diagrams (business-perspective entity/class diagrams)to define enterprise-wide business rules related to categories (classes) of business objects.

When?

to categories (classes) of business objects. BRD: IT requirements/static model BRD: User requirements/system use cases/domain (business entity) diagrams (a subsection of the use-case template) to indicate the static modeling elements (business rules) relevant to the use case. Why?

During requirements meetings, helps BA understand new business terms introduced by stakeholders. Helps ensure complete requirements (e.g., missing multiplicities indicate the need to go back to stakeholders). Helps ensure internal consistency in business requirements documentation by providing a single place to document across-the-board business rules. Enables future changes to be verified for compliance with existing business rules. Minimizes errors due to miscommunication with developers: Provides developers with business rules in an unambiguous format that is consistent with the one they use to design the software solution.

What to show stakeholders

Full symbol set. Do not show these diagrams to business stakeholders. Translate them into text by creating two sentences for each association and aggregation relationship. For example, each underwriter approves zero or more amendments; each amendment is approved by one and only one underwriter. For more examples, see Notes on Figure 4.39. Also see the Multiplicity Rules Table in the Static Model section of the BRD Template in the Templates chapter. Full symbol set UML Use cases: Add class diagrams to use-case documentation to highlight across-theboard business rules that govern a specific use case. See the Domain (Business Entity) Diagrams section in the System Use-Case Description Template in the Templates chapter. ERD, IDEF1[12]

What to show team members Standard Complementary tools

Alternatives

[12]The IDEF standard is not covered in this book.

Class Diagram Example

Figure 4.39: Class diagram example Notes on Figure 4.39 : When communicating with stakeholders, translate class diagrams into text, as shown here for the Life Policy class diagram example. Each Underwriter approves zero or more Amendments. Each Amendment is approved by one and only one Underwriter. Each Amendment is a change to one and only one Life Policy. Each Life Policy is changed through zero or more Amendments. Each Life Policy has zero or more Benefits. Each Benefit may be part of zero or more Life Policies. There are two kinds of Life PoliciesTerm and Whole Life. For all types of Life Policies, the system must track the following information: face amount and policy number. For Term policies only, the system must track start date and end date (in addition to face amount and policy number). For Whole-Life policies, the system must track the level premium (in addition to face amount and policy number).

Symbol Glossary: Class Diagram

Figure 4.40: Symbol Glossary: Class diagram symbols Notes on Figure 4.40 : The figure contains the following modeling elements: Class: (Depicted as a rectangle with two optional compartmentsone for attributes and one for operations.) A class [13] is a category that a group of objects may belong to, such as Employee, Electronic Financial Transaction, or Product. All objects in a class share the same operations and attributes (though the values of the attributes may differ). (See Figure 4.41.)

Figure 4.41: Class Attribute: (Optional; listed in the attributes compartment.) An attribute is a property that the system tracks for each object in the class. Attributes are often stored and displayed as fields. (See Figure 4.42.)

Figure 4.42: Attribute

Operation: [Optional; listed in the operations compartment, with parentheses () following the name; parameters may be placed inside the parentheses.] An operation is a function that an object can carry out or that is carried out on an object. (See Figure 4.43.)

Figure 4.43: Operation Generalization [14]: (Depicted as an arrow with a hollow, closed triangular arrowhead.) Used to indicate subtyping. The relationship points from the specialized class (the subtype) to the generalized class (the larger category)for example, a generalization that points from the specialized class Mortgage to the generalized class Loan Product. The relationship from specialized class to generalized class is translated to stakeholders as Is a kind offor example, A Mortgage is a kind of Loan Product. Any objects belonging to a specialized class automatically inherit all attributes, operations, and relationships of its generalized class. Inherited attributes and operations can be overridden, however, by a different definition of them in the specialized class. (This is an example of a property referred to as polymorphism in OO.) This means that the specialized classes are not stuck with their inherited definitions; it allows general definitions to be described in the generalized class, with more specific definitions provided in the specialized class. (See Figure 4.44.)

Figure 4.44: Generalization Transient role (plays role): (Depicted as an arrow with an open arrowhead, labeled <<plays role>>.) An extension to the UML,[15] used to indicate part-time subtypes. In a part-time subtype, an object belongs to the type for some of (but not necessarily throughout) its lifespan.[16] The arrow points from the base class to the role class. The base class contains attributes, operations, and so forth that apply to the object regardless of the role it is playing. The role class contains attributes, operations, and so on that are specific to each role; each time an object of the base class adopts a role, a new set of role attributes is tracked for it. For example, a Participant plays the role of Policy Holder and the role of Life-Insured each time he or she is associated in one of those ways to an Insurance Policy. (See Figure 4.45.)

Figure 4.45: Transient role Aggregation: (Depicted as a line between two classes, with a small hollow diamond at one end.) Denotes a whole-part relationship, for example, between an Order and its Line Items or between an Organization and its Members. The diamond is connected to the aggregate (whole); the other end of the line is connected to the component (part). The UML provides a means for the modeler to indicate that a whole completely owns its part (as is the case, for example, between an Order and its Line Items) by indicating it as a composition (solid diamond). The BA may indicate all whole-part

relationships as aggregation (hollow diamond); the distinction between aggregation and composition is typically indicated by the systems analyst, rather than the BA.[17] (See Figure 4.46.)

Figure 4.46: Aggregation Association [18]: (Depicted as a solid line; see Figure 4.47.[19]) An association between two classes indicates that the business area needs to be able to track objects of one class against objects of another class. Use a verb phrase to name the association. For example, a Sales Rep is assigned to Clients, an Account is billed to Customers. Follow the name with a small triangle to indicate the direction in which to read the association. Figure 4.47: Association Role name: (See Figure 4.48.) (Optional; depicted as a noun-phrase at an end of an association, adjacent to a class.) Names the role that objects of the class it is adjacent to are playing during the association. For example, a customer service reps role is Prime Contact in the association, User mak es initial report to customer service rep.

Figure 4.48: Role name Multiplicity: The number of objects that may participate in a relationship, indicated at each end of each relationship (other than generalizations). (See Figure 4.49.) Allowable multiplicities are as follows: 0..1 0..* * a..* a..b a Zero or one Zero or more Zero or more (same as 0..*) a or more; for example, 1..* (one or more), 2..* (2 or more) a through b; for example, 1..3 (one through 3) a and only a; for example, (one and only one)

Figure 4.49: Multiplicity Association class: (Depicted as a class symbol [box] attached to an association by a dashed line.) May be used by a BA as a means of dealing with many-to-many relationships. For example, in Figure 4.50, each account may be co-owned by many customers and each customer may coown many accounts. The association class Customers Account has been tied to the relationship

between customer and account. An occurrence of the association class represents one customer tied to one account and can be used to track attributes specific to the link between the two, such as the date the customer signed up for the account and the individual customers purchases to date against the account. (See Figure 4.50.)

Figure 4.50: Association class

Figure 4.51: Additional Symbol Glossary and examples: Class diagramunary and binary associations Notes on Figure 4.51 : An association may be reflexive or binary. A reflexive (also referred to as unary) association indicates that the system is required to track objects against objects that belong to the same class. In the reflexive-association

example, an employee (acting in the role of manager) manages other employees (acting as team members). Most associations are binary, indicating the requirement to link objects belonging to different classes, such as between flights and customers, as shown in the binary-association example.
[13]The formal UML definition is, Class: A classifier that describes a set of objects that share the same

specifications of features, constraints, and semantics.

[14]The formal UML definition is, Generalization: A taxonomic relationship between a more general classifier and

a more specific classifier. Each instance of the specific classifier is also an indirect instance of the general classifier. Thus the specific classifier indirectly has features of the more general classifier.
[15]The modeling element is described in further detail in the book UML for the IT Business Analyst (by this

author).
[16]Specialization classes cannot be used to model the roles, since they apply to the object throughout its

lifespan.
[17]With aggregation, a part may belong to more than one whole at the same time and exists independently of its

whole. With composition, a part is contained within the whole; when the whole is destroyed, so are its parts.
[18]The UML definition is, Association: A relationship that may occur between instances of classifiers. [19]An association may be adorned with an arrow at either end (or both) to indicate navigabilitythe direction in

which references may be made. This feature is not widely used in a BA context.

Use of content on this site is expressly subject to the restrictions set forth in the Membership Agreement. Books24x7 and Referenceware are registered trademarks of Books24x7, Inc. Copyright 1999-2013Books24x7, Inc. - Feedback | Privacy Policy (updated 03/2005)