Slide #4
A business model is an abstract representation of a clearly delimited area of business. It may take many forms – plain text, wireframe, pictures etc. Many organizations are excellent at developing good software products. Where they are often weak is in developing the right software product. The mismatch between what the user wants and what the developers deliver can often be traced to poor practices in business analysis and quality control. Right modeling provides a step-by-step procedure that helps ensure the completeness, correctness, and clarity of the requirements documentation. In addition, many IT projects experience time and cost overruns due to the difficulty in responding to a rapidly changing business environment.
A major contributing factor to this problem is the “ripple effect”—one change in the business that leads to many changes in project deliverables. B.O.O.M. helps by using OO techniques to minimize redundancies in the requirements. With “one fact in one place,” the requirements are easier to revise. Finally, many project failures are due to faulty communication between those who know the business and those who write the software. With B.O.O.M., the PM documents business rules and requirements using the same types of diagrams, concepts, and terminology used by OO developers, thus reducing the risk of miscommunication.
Slide #8
As a product manager, your job is to get inside the heads of your stakeholders so that you can extract what they know about a piece of the real world—a business system—and pass it on to the developers, who will simulate that system on a computer. If you were choosing an approach for doing all this, you’d want something that goes as directly as possible from the stakeholders’ heads to the IT solution. This approach would have to begin with an understanding of how people actually think about the world, and would have to be broad enough to take the project from requirements gathering right through to construction of the software. Object orientation is one such approach. It begins by proposing that the object is the basic unit by which we organize knowledge. In the following discussion, we’ll see how OO takes this simple idea and builds an entire edifice of powerful concepts that can be used to understand and build complex systems.
Slide #9
Objects
OO begins with the observation that when you perceive the world, you don’t just take it in as a blur of sensations. Rather, you distinguish individual objects, and you have internal images of them that you can see in your mind’s eye. Taken together, these internal objects model a segment of the real world.
You begin to analyze a business area by asking stakeholders to describe the business objects it encompasses. A business object is something the business (and the IT system that automates it) must keep track of or that participates in business processes. Examples of such an object might include an invoice, a customer-service representative, or a call.
Slide #10
Attributes and operations
OO theory continues by examining the kind of knowledge that is attached to each internal object. Because we can recognize an object again after having seen it once, our internal representation of an object must include a record of its properties. For example, we remember that a shirt object’s color is blue and its size is large. In OO, color and size are referred to as attributes; blue and large are attribute values. Every object has its own set of attribute values.
Something else we remember about an object is its function. For example, the first time you saw a crayon, it took you some time to learn that it could be used to scribble on the walls. Unfortunately for your parents, the next time you saw that crayon, you knew exactly what to do with it. Why? Because you remembered that scribble was something you could do with that object. In OO, scribble is referred to as an operation.
To sum up what we’ve established so far: Two things we remember about objects are
- The values of their attributes
- The operations that we can do with them
The next step in analyzing a business system is to find out what attributes and business operations apply to each object. For example, two attributes that apply to an account object are balance and date last accessed; two operations that relate to the object are deposit and withdraw.
An object’s operations usually change or query the values of its attributes. For example, the withdraw operation changes the value of the object’s balance attribute. But this is not always the case. For example, view transaction history—another operation that applies to the account object—displays information about all the transaction objects tied to the account; however, it might not refer to any of the account’s attributes.
Slide #11
Going one step further, you don’t just remember what you can do with an object, you also remember how you do it. For example, you know that you can place a call with a particular mobile phone—but you also remember that to do so, you must follow a particular procedure: First you enter the phone number and then you press the Send key. In OO terms, place a call is an operation; the procedure used to carry it out is called a method.
Next, you take each operation and ask stakeholders what procedure they use to carry it out. You document the procedure as a method. For example, you ask stakeholders what procedure they follow when withdrawing funds from an account. They tell you that they first check to see if there is a hold on the account and whether there are sufficient funds available for withdrawal. If everything is in order, they reduce the balance and create an audit trail of the transaction. You document this procedure as the method used to carry out the withdraw operation.
Slide #12
Every day you use objects without knowing how they work or what their internal structure is. This is a useful aspect of the way we human objects interact with other objects. It keeps us from having to know too much. It also means that we can easily switch to another object with a different internal structure as long as it behaves the same way externally. This is the OO principle of encapsulation: Only an object’s operations are visible to other objects.
Attributes and methods remain hidden from view. When you describe the method of an object, don’t mention the attributes of another object or presume to know how another object performs its operations. The benefit to this approach is that if the methods or attributes related to a business object ever change, you’ll have to make corrections to only one part of the model.
Slide #13
You have seen that our ability to internally model an object allows us to use it the next time we encounter it without relearning it. This does not automatically mean, however, that we can apply what we’ve learned to other objects of the same type. Yet we do this all the time. For example, once we’ve learned how use one iPhone X, we know how to use all iPhone X objects. We can do this because we recognize that all these objects belong to the same type: iPhone X. In OO, the category that an object belongs to is called its class.
The minute you know that two objects belong to the class, iPhone X, you know a number of things about them:
- The same attributes apply to both objects. For example, you know that both objects will have a serial number, a phone number, and various camera settings
- Each object will have its own values for these attributes
- The same operations apply to both objects. For example, you can place a call and take a picture with each of these objects
- The same methods apply. For example, the procedure for placing a call is the same for both phones
To summarise: A class is a category. All objects that belong to the same category have the same attributes and operations (but the values of the attributes may change from object to object).
Despite the name object-oriented analysis, you’ll be spending most of your time defining classes, not objects. The classes you’ll be interested in are those that relate to the business. These are termed entity classes. For example, in a banking system, you’d define the characteristics of an Account entity class and a Customer entity class.
Slide #14
We often define one class in terms of another class. For example, a Car is a kind of a Vehicle. Both Car and Vehicle are classes. The phrase “a kind of” describes a relationship between the two classes. The UML defines a number of types of relationships that are useful to the PM: generalization, association, aggregation, and composite aggregation.
Slide #15
OO concept: Generalisation The concept of a class allows us to make statements about a set of objects that we treat exactly the same way. But sometimes we run into objects that are only partially alike. For example, we may own a store that has a number of iPhone X objects and a number of Samsung S8+ phone objects. The iPhone Xs are not exactly like the Samsung S8+ phones, but they do share some characteristics—for example, the ability to place a mobile call. We treat this situation by thinking of these objects not only as iPhone X or Samsung S8+ phones but also as mobile phones. A particular phone object, for example, might be able to run a particular iPhone application by virtue of being an iPhone X—but it can also place a mobile call by virtue of being a mobile phone. In OO, Mobile Phone is referred to as the generalized class; iPhone X and Samsung S8+ are referred to as its specialized classes. The relationship between the Mobile Phone class and either of its subtypes (iPhone X or Samsung S8+) is called generalization.
Why do we generalize? It allows us to make statements that cover a broad range of objects. For example, when we say that a mobile phone can receive a text message, we are stating a rule that applies to all of its specializations.
When an object belongs to a specialized class (for example, iPhone X), this automatically implies that it belongs to a generalization of that class (for example, Mobile Phone). Any attribute or operation that applies to the generalized class also applies to the specialized class. Furthermore, any relationships specified for the generalized class also apply to the specialized class. (For example, the relationship “Customer OWNS [one or more] Accounts,” though specified for the Account class, applies also to Checking Account, Savings Account, and all other Account types [specialized classes of Account].)
Other terms in use
Generalized class_____________|Specialized class …………………………………………………………………………………………………………… –Superclass____|Subclass –Base class____|Derived class –Parent_______|__________Child
The idea that a specialised class automatically adopts the attributes, operations, and relationships of its generalized class is given a special name in OO: inheritance.
How to apply? You look for classes of business objects that are subtypes of a more general type. For example, Checking Account and Savings Account are two kinds (specialized classes) of Accounts. Then you document which attributes and operations apply to all Accounts, which apply only to Checking Accounts, and which to Savings Accounts. By structuring your requirements this way, you only have to document rules common to all account types once. This makes it easier to revise the documentation if these business rules ever change. It also gives you the opportunity to state rules about Accounts that must apply to all future account types—even ones you don’t know about yet.
Slide #16
OO concept: Association Another way that classes may be related to each other is through association. When you connect a mouse to a PC, you are associating mouse with PC.
An association between two classes indicates that objects (instances) of one class may be related (linked) to objects of the other class. You specify an association at the class level; you specify a link at the object level.
How to apply? You analyze how the business links objects of one class with those of another (or, some- times, with other objects of the same class). For example, the military needs to track which mechanics serviced each piece of equipment, what the maintenance schedule is for each one, and so on. As a PM, you document these types of rules as associations. This is a critical part of your job. Miss an association—or document it incorrectly—and you may end up with software that does not support an important business rule.
Slide #17
OO concept: Aggregation Aggregation is the relationship between a whole and its parts. For example, an insurance policy is an aggregation of a basic policy and amendments to the policy, and a stamp collection is an aggregation of stamps.
Formally, in the UML, aggregation is considered to be a specific type of association, where the class on one end of the association represents a whole and the class at the other end represents a part. Aggregation may be used by the PM as an alternative to modeling an association with the name “is a part of”.
How to apply? You look for business objects that are made of other business objects. You model these relationships as aggregations. Then you focus on which rules (attributes, operations, and relationships) apply to the whole and which apply to the parts. One thing this process enables you to do is reuse the requirements of a part object in a new context. For example, you model an ATM card as an aggregate, one of whose parts is a PIN. You define the attributes and operations of a PIN. Later you reuse the PIN requirements for a credit-card system that also uses PINs.
Slide #18
OO concept: Composite Aggregation Composite aggregation, also known as composition, is a special form of aggregation wherein each part may belong to only one whole at a time.
Formally, composition is a specific kind of aggregation. In aggregation, a part may belong to more than one whole at the same time; in composite aggregation, however, the object may belong to only one whole at a time. The parts are destroyed whenever the whole is destroyed—except for those parts that have been removed prior to the deletion of the whole.
What If You’re Not Sure What Type of Whole-Part Relationship to Use? Don’t get too worried if you are unable to decide whether a particular whole-part relationship is best described as an aggregation or composite aggregation. While the distinction (from a PM perspective) is helpful, it is not critical. If you have any problem deciding, specify the whole-part relationship as aggregation. If you’re not even sure whether the relationship is best described as a whole-part relationship, then model it as an association. In fact, there is nothing wrong with the PM modeling all whole-part relationships as simple associations. You lose a little bit of nuance in the model – but it will make no difference to the resulting solution.
How to apply? You model strong whole-part relationships between classes of business objects as composite aggregation. For example, in analyzing an ERP (enterprise resource planning) system for a diamond trader, I modeled a Diamond Case Report Form as a composite aggregation of Modules. The Case Report Form was a record of everything that was recorded about a diamond with respect to the trade being conducted; each Module was a record of one interaction with the diamond. The developers understood from this model that each Module could only belong to one Case Report Form at a time and that when a Case Report Form was removed from the system, all of its Modules needed to be removed as well.
Slide #19
OO concept: Polymorphism Polymorphism means the ability to take on many forms. The term is applied both to objects and to operations.
Polymorphic Objects Suppose a financial company handles different subtypes of Funds, such as an Asia Fund, Domestic Fund, and so on, each with its own idiosyncrasies. The PM models this situation using a generalized class, Fund, and a specialized class for each subtype of Fund. Next, the PM moves on to capture investment rules in an Investment class. Checking with the stakeholders, the PM finds that one of its operations, invest capital, deals with all Funds the same way, regardless of subtype. The PM handles this by ensuring that the documentation for the invest capital operation refers exclusively to the generalized class Fund—not to any of its specializations. When the operation is actually executed, though, the Fund object will take on one of many forms—for example, an Asia Fund or a Domestic Fund. In other words, the Fund object is polymorphic.
Polymorphic Operations Continuing with the same example, since all the Fund subtypes have to be able to accept deposits, the PM defines a Fund operation called accept deposit. This operation is inherited by all the specializations. The PM can also specify a method for this Fund operation that will be inherited by the specializations. But what if one or more of the specializations— for example, the Asia Fund—uses a different procedure for accepting deposits? In this case, the PM can add documentation to the Asia Fund class that describes a method that overrides the one inherited from the generalized class. For example, the method described might involve supplementary charges. In practice, when capital investment causes a Fund to perform an accept deposit operation, the method that is used to carry out the operation will take on one of many forms. This is what is meant by a polymorphic operation. With polymorphic operations, the selection of the method depends on which particular class (Asia Fund, Domestic Fund, and so on) is carrying it out.
How to apply? When you define operations for a generalized class, you look for those that all specializations must be able to support. If you can, you define a method that describes how the operation is typically carried out. If any specialized classes have different ways of doing the operation, you define a new method for it at the specialized class level. This simplifies the documentation. You don’t need to write, “If the type is X, then do one method; if it is Y, do another one.” Instead, you get this across by where you document the method in the model.
One Interface, Many Implementations Polymorphism means “one interface, many possible implementations.” Cars, for example, are designed with polymorphism in mind. They all use the same interface—an accelerator pedal—to change speed, even though the internal method may differ from model to model. The auto industry designs cars this way so that the drivers do not have to learn a new interface for each new model of car.
Slide #21
A use case is a usage of the system that provides an observable and (usually) meaningful result. The use-case documentation (diagrams and/or text) should delineate the series of steps that take place during the interaction and include different ways that this interaction could play out. A scenario is one path through a use case—one way that it might play out. To give an example of use case, some of the use cases that customers need in a Web-based banking system are Make bill payment, Stop payment, and Order checks. To give an example of scenarios, the Make bill payment use case may play out in one of the following ways: Scenario 1: Attempt to make a payment from an account and succeed in doing so. Scenario 2: Attempt to make a payment from an account and fail because there is a hold on the account. During behavioral analysis, you identify and document the use cases of the system—what the users want to do with it. You do this by identifying and describing its scenarios— all the ways the interaction could play out. These use cases and scenarios are your user requirements.
Slide #22
Used Plantext.com to get this diagram. Try it yourself: @startuml title Activity Diagram \n start :Identify business use cases; note left Focus on Business aspect of proposed changes end note :Analyze business use case; note left Look for activities that the product will cover end note :Group activities into system use cases; note left Ensure that each system use case gives the user something of real benefit. end note :System use cases drive whole dev process; note left For example, in each release, a planned set of system use cases is analyzed (unless this was done up front), designed, coded, and implemented. With this use case–centered approach, users get features that add real value to their jobs with each software release. end note stop @enduml