Natural Language Modeling
The next step is to turn the requirements document into a data model. For a simple system, it is not really difficult to figure out where to start. However, in a real-world setting, converting a requirements document to a data model can be an extremely daunting task. The natural language modeling approach makes this conversion much easier. Natural language modeling looks at the requirements document as a discourse on the final state of the app. From this discourse, you can filter various elements, much like straining spaghetti. To do this, you need to be able to recognize which parts of the document to filter and which to leave intact.
|
Noun Sets
Your data model is the noun set of your app. If you pour the requirements document through the "major noun strainer," you will find the data model of the app. The major nouns are simply the words that define business concepts, such as account or customer. Once you have identified these nouns, start organizing them into hierarchies of objects. Meanwhile, toss out the nonessential items that will inevitably seep in, and you're off to a flying start. By filtering parts of the requirement document, you begin to develop large chunks of your program. The initial picture will not be complete, but it will get you started. In fact, you should actually draw a picture at this point. Grab your modeling tool and start structuring classes and associations.
|
An app of Natural Language Modeling
Let's explore an actual app of how to build a data model. For the purposes of this example, you will create a data model to encapsulate a small subset of functionality used in the banking industry. Here is a small requirements document for your data model:
Online Only Bank, Inc. System Specification The goal of this document is to describe the system that will control the financial aspects of Online Only Bank, Inc. The software to be built from this document will be the interface for internal and online customer banking. 1. The system will support the online checking, savings, loan, and credit card account types. 2. Online checking accounts will not pay interest to account holders. 3. Online checking accounts will allow account holders to execute a transfer of funds from their accounts to any other account within the system electronically. 4. Payment of bank fees or automatic payments will be processed in the following order. First, an attempt will be made to obtain the payment from the account holder's online checking account. Upon failure, the payment will be applied versus the account holder's savings account. Upon failure of this payment, a notice will be emailed to the customer requesting funds to be deposited to account for the payment. 5. Online checking accounts will allow the account holder to execute an external transfer of funds to an external entity, given a bank routing number and account number. 6. Online checking accounts will have a variable credit limit that will allow the account holder to temporarily hold the account under zero. A bank officer will be needed to set this limit. 7. Savings accounts will allow only transactions conducted by bank employees. These employees can transfer money only from the savings account to other accounts held by the savings account holder. No transactions from a savings account may go directly to a third party. 8. The bank will offer phone support for personal interaction with customers. 9. Savings account holders will be paid interest for the amounts in their account. 10. Loan accounts are special accounts for repayment of credit extending to the customer. These accounts have a duration of payments and an interest rate charged by the bank for the loan. Loan payment will be collected in accordance with requirement 4 of this specification. 11. Credit card accounts will have a credit limit set by a banking official. 12. Normal banking tellers will not be able to set credit card limits. 13. Credit card accounts will automatically pay the minimum payment, calculated as a percent of balance, according to requirement 4 of this specification. 14. Account holders will be issued monthly statements detailing the status of their accounts and the transactions of the preceding month. Due to ecological concerns, these transactions will be delivered by email only. 15. Customers will be able to apply for a loan online. 16. An online loan app will require the account holder's ID and information relevant to processing the loan. The required information will include the purpose for the loan, a description of any collateral offered, the required amount of the loan, and the duration of the loan in months. 17. Only a bank officer can approve an online loan app. This bank officer will assign either a fixed or variable interest rate to the loan depending on his sole judgment. 18. Customers will be informed by email as to their approval or rejection status for loans. 19. Customers will be informed yearly of the amount of interest paid on a loan. 20. Online access to the banking system will be protected by appropriate security measures to prevent unauthorized access. 21. On the phone, all customers will be required to have a pass phrase in addition to their online password to identify themselves to bank personnel. 22. Customers will be able to change their password online. 23. Bank fees will be administered via transfer to the bank's own internal accounts. 24. Each officer will have an administrative code for payroll issues not related to this product. This code will be a positive 8-digit number.
If you are a professional programmer, this requirements document probably looks familiar. For some of you, these requirements may look a bit overwhelming, but they aren't too bad when you apply your natural language modeling approach.
Creating the noun set
Whenever you find a major noun—which is a noun that stands alone without help and represents a business concept—write it down in your list of candidate objects. After working through the requirements, the resulting list would look something like the following:
- Online Checking Account
- Savings Account
- Credit Card Account
- Loan Account
- Transfer of Funds
- External Transfer of Funds
- Automatic Payment
- Transaction
- Employee
- Bank Officer
- Account Holder
- Customer
- Loan app
|
Although most of the elements in this noun list are fairly clear, the "Transfer of Funds" and "External Transfer of Funds" elements require additional explanation. For every transfer of funds that takes place, you need to record data that specifies the transfer information, such as source and destination. Therefore, you need an object to hold this information. By inheritance, External Transfer of Funds is a noun because it is a special type of Transfer of Funds. On the other hand, the action in requirement 22 does not require any extra support. Since the password is stored in the user's account, and changing it is simply a matter of providing an interface to accomplish the task, you do not need to create a helper object to store data. However, if the document required that you store the date that the user changed the password, then you would need to implement some support. While working through the document, make sure you keep an eye out for verb helper objects and handle them appropriately.
Moving to a data model
Once the requirements document is signed, you may want to start planning the database tables and entity-relationship diagram. However, at this stage, the data model should be the prime focus, not the database. The database should be viewed as just another storage mechanism, which is irrelevant at this stage of planning. Therefore, you should define the data model using object-oriented principles and then figure out a way to actually store the data. With the list of major nouns, the proposed system doesn't look so complex anymore. Now that you have a list, you can start creating some classes in your unified modeling language (UML) modeling tool.
|
Start planning the data model by creating empty classes, one for each major noun, and have your modeling tool leave content for later. Once you have your empty classes, try to organize the objects into hierarchies and groups. While organizing the objects, make sure you remove any conceptual duplicates. For example, you can eliminate AccountHolder because it is the same as Customer. Continue to refine the structure and look for commonalties among the objects until a cohesive model emerges. While refining, remember not to worry about the details of the model. At this point, you should just try to get the skeleton of your data model in place; once this is done, the skeleton will give you a much better platform for incorporating the details of the model.
Relationships and attributes
Now that the skeleton is complete, you can fill in your data model with relationships and attributes. Again, consult the requirements document and note each occurrence of the core objects in the document. For example, consider requirement #5:
Online checking accounts will allow the account holder to execute an external transfer of funds to an external entity, given a bank routing number and account number.
From this requirement, you know that there should be a relationship between the OnlineCheckingAccount and ExternalTransaction classes. Furthermore, the External-Transaction class requires that the bank routing number and account number be added as attributes. As you work through the document, fill in the data model of the app with details such as these. Once you are done analyzing the requirements document, begin the second pass, in which you examine each of your objects and consider them separately. For example, you never mention in the requirements document that a Person needs to have a first and last name. However, this data is implied, so you should add it. Continue this type of analysis until you feel that you have a fairly complete data model. In this case, a sample data model is shown in Screenshot-1.
Screenshot-1. Online bank data model
The first draft
Now that you have a draft of the model, take the model back to the customer and let him pick it to pieces. At this point, it is absolutely critical that you don't forget that your customers are not programmers. If you email this diagram to the customer and ask for his input, I guarantee you will be greeted with silence. All of the symbols used in UML are second nature to you, but often look like Greek to a customer. Instead, present the data model to the customer in small pieces that focus on individual concepts. The best way to do this is to meet face-to-face with the customers at a location where he can focus on the data model and not be distracted by other concerns. The meeting will also give him a chance to ask questions. You will also be able to ask any questions you have, and ensure that the customer sticks to concepts that are realistically achievable.
|
During the data model presentation, be sure to explain the symbols and notation in the simplest terms possible. It isn't important that the difference between aggregation and composition is clear; what is important is that your customers understand why there is a line connecting two objects. As I said, your goal should be to get verbal or, preferably, written approval. Once the customer signs off on the requirements and data model, the story is not over. In fact, the analysis and modification of the requirements and data model will be a recurring theme throughout the development as the requirements change, new concepts are discovered, and old questions are answered. It is a simple reality of business that your model and requirements will be altered while you complete the project. Even after the software is released, there will be more requirements and data model changes. New requirements should go in their own section of the requirements document to separate them from the original requirements. You will have to integrate data model changes constantly, but try not to do so without a requirements specification. It is much easier to change a sentence in a document or a line in a drawing than to change code.