3e.+Validation+&+Discussion+of+Analysis+Models

 __Validation & Discussion of Use Case Context Diagram (by Lucheng Yao) __ This use case describes general behavior from the Audio Lunchbox OnCD system to user. It includes all steps that are the same no matter what kind of actions the system does. After analyze the flow of operation system, our use case came out with four actors which were customer, administrators, clerks and the system itself. The use case we created can be used during many stages of system development. It will capture the requirements of the system, act as a spring board for the system design, validate the system design against, be used for system test and quality assurance. We thought it can be potentially act as an initial framework for the online shopping and user manual. Needless to say, it is very important that the Use Cases are validated thoroughly. We followed the rule that use case model elements must be unique and cannot be any duplicate use case or actor. The only include relation was pay by credit card and it referred to normal use case. We named our use cases in scope by listing them and associating them with actors. We had a discussion and ensure each one is necessary to meet the process of OnCD system. In additional, we came up with the following questions to check the use cases: By following the outline and detailing use cases, we can make better decisions on priorities which start by identifying actors. This will lead to the identification of the use cases. Therefore, we could capture the actors and use cases in the usecase model along with a brief description.  **-** = = __ Validation & Discussion of Domain Model (by Stephen Slaughter) __ This model was perhaps the most challenging yet, and each of our diagrams reflected similarities and differences. It turns out that our models were more similar semantically than different.
 * Does this use case address some aspect of the problem in our problem statement?
 * Does this use case differentiate our product in some way?
 * What is the main purpose this actor would like to use the system?
 * Are there any procedural or requirement changes we can suggest that would simplify the process depicted in the use case?
 * Are there any additional goals of the actors that are not addressed?

We each followed the approach described in Dr. Song’s “Taxonomic Class Modeling Methodology.....” and identified nearly the same number of classes, with the same names. We found that each of our diagrams were missing a small number of concepts within the domain. Those differences seemed to stem from our use of the different use case specifications we created as the basis of our analysis of the domain; since these specifications modeled different behavior of the system, we were confronted with a slightly different set of nouns for analysis. We each had slightly different names for the knowledge responsibilities (attributes) within our classes, but 90% of our attributes represented the same responsibilities.

The associations we identified were very similar as well (with minor variation). We disagreed in terms of the cardinality of certain need-to-know associations (e.g. between User and Shopping Cart), but resolved this through discussion. We felt that one of our diagrams was more comprehensive than the alternatives, or “more complete”, so we chose to analyze this diagram further. We discussed the model’s issues and prepared it for inclusion into our set of deliverables. Our team added a digital library class, the vendor class, verbs to the need-to-know associations, and modified the cardinality of a few associations (e.g. between User and Shopping Cart, etc).

Given more time, we would have liked to analyze each of the alternative models produced by team members with more scrutiny, in order to develop each of these conceptions of the domain more completely. = =