In the case of Object-Oriented Analysis Design (OOAD) with UML, your models consist primarily of diagrams: static diagrams that depict the structure of the system, and dynamic diagrams that depict the behavior of the system. The dynamic diagrams allow you to trace through the behavior and analyze how various scenarios play out. With the static diagrams, you can ensure that each component or class has access to the interfaces and information that it needs to fully carry out its responsibilities. The best part is that it’s very easy to make changes to these models, such as: adding, moving, or deleting a line. It is also great for reviewing the change in a diagram which takes only minutes. Contrast that with actually building the code, which can take hours to simply implement the change and hours more to test and review it.
Your core artifact of the OOAD process is the model. In fact, you will likely have multiple models:
• Analysis Model. This is a model of the existing system, the end user’s requirements, and a high-level understanding of a possible solution to those requirements.
• Architecture Model. This is an evolving model of the structure of the solution to the requirements defined in the Analysis Model. Its primary focus is on the architecture which includes: the components, interfaces, and structure of the solution; the deployment of that structure across nodes; and the trade-offs and decisions that led up to said structure.
• Component (Design) Models. This is a number of models (roughly, one per component) that depict the internal structure of the pieces of the Architecture Model. Each Component Model focuses on the detailed class structure of its component, and allows the design team to precisely specify the attributes, operations, dependencies, and behaviors of its classes.
Depending on your development process, you may have even more models: a business model, a domain model, and possibly even others. The major benefit of models is that you can make model changes far earlier in the development cycle than you can make code changes, and this is also far easier. Due to the fact that you can make changes early, you can also make corrections early. And that’s a good thing, because early detection and correction is cheap detection and correction.
Modeling will let you catch your most costly bugs sooner which can save you a factor of 50–200 on the cost and schedule of a bug fix.
6.3.1 Analysis Object Models
Analysis modeling provides a representation of the software system from the point of view of the user. To achieve this, a model is created based on the interactions between the user and the system, and the responses that the system generates. This model, known as the analysis object model, describes the individual classes, attributes, and operations that are manipulated by the system through the use of UML class diagrams. These diagrams create a visual representation of the system that is made up of the various portions of the system that are seen and interacted with by the user (Bruegge and Dutoit2004).
A complementary portion of the analysis model focuses on what takes place within the system in response to user interaction and changes in the system’s state.
This model, called the dynamic model, depicts the behavior of the software system through the use of sequence diagrams and statecharts. The sequence dia-grams are used to describe a single use case based on the interactions that occur among a set of objects. The resulting image details object relationships. The statecharts, on the other hand, are used to represent the behavior of a single object, or the ways in which it responds to stimuli (Bruegge and Dutoit 2004). The dynamic model pinpoints classes, attributes, and relationships in the software system, and can also be used to indicate where, when and for what purpose new ones should be created and instituted.
110 6 Object-Oriented Analysis
6.3.2 Entity, Boundary, and Control Objects
Entity objects are classes that encapsulate the business model, including rules, data, relationships, and persistence behavior, for items that are used in your business application. For example, entity objects can represent the logical structure of the business, such as product lines, departments, sales, and regions. They could also be used to represent business documents, such as invoices, change orders, and service requests. In another scenario, entity objects could be used to depict physical items, such as warehouses, employees, and equipment. From an object-oriented perspective, an entity object represents an object in the real-world problem domain. From a relational database perspective, an entity object provides a Java representation of data from a database table. Advanced programmers can map entity objects to other types of data sources, such as spreadsheets, flat files, and XML files. Depending on how you want to work, you can automatically create entity objects from existing database tables or define entity objects and use them to automatically create database tables.
Business logic should be written into entity objects, because they consistently enforce information for all viewing of any data, accessed via any type of client interface. Business logic can include the following items:
• Business Rules and Policy: When adding or modifying data, you should ensure that the data complies with your organizations’ procedures before adding it to the database. For example, you could increase the salary when an employee is promoted, give an employee 3 weeks of vacation after they have been at a company 3 years or change the status of an order to shipped after all items in an order have been mailed to a customer.
• Validation Logic: When adding new data, you should ensure that the data is valid before storing it in the database. For example, you could ensure that a job code is an existing valid job code.
• Deletion Logic: You should make sure that data is deleted only when appro-priate and that any dependencies are handled. For example, you could prevent an on-leave employee from being wrongly removed.
• Calculations: You should efficiently perform data calculations in the business logic tier. For example, you could calculate an employee’s monthly pay based on a given hourly rate.
• Default Value Logic: When creating new data, you should add appropriate default values. For example, you could provide a default benefit plan based on an employee’s job code.
• Security: You should make sure that data is read and modified only by users with the appropriate authority. For example, you could ensure that only the direct manager of a given employee can change said employee’s salary.
Boundary Objectsrepresent the interactions between the user and the system.
These often represent input/output systems which the user utilizes (Schach2008).
For example, if a user needs to extract information from the system, boundary
objects will be used to define the ways in which the user communicates with the system in order to make his or her request, and the ways in which the system responds directly back to the user.
Control Objects are used to model the internal workings of the software system itself. That is, they represent the complex algorithms and computations used to process information and perform actions (Schach2008). Control objects are the means by which use cases are fully realized from start to finish. They handle all of the activity that the system is responsible for carrying out.