I want some help in understanding what we need to write when we are justifying design decisions. Is it justifying the patterns, the introduction of new classes, or general interaction of sequence diagram needs explaination to clarify it further. Should the justification explaination be such that it should be explained such that a developer who is looking at it from implementation stand point can grasp the lower level concepts. I dont want to put too much together and I dont want to leave too much out. Can some one please help.
Yong, Thanks for the information. with the what and why, Is it necessary to explain something as common as the usage of composite entity bean. Some parts of the pattern usage like u said are common body of knowledge which accomplish a known functionality so it becomes confusing which aspect of my implementation would require justification which wouldnt.
For example .. Why I used a composite entity instead of a POJO .. Does that qualify for an explaination. ?
Dhiren, I want to upload the assignment by the end of the weekend. So I am also busy with the documentation.
In the requirements they only ask a list with assumptions. So i think If you submit anything more you should keep it short and clear.
So i don't think a explanation is required where you evaluate all options that are available with all cons and pros and then come to your conclusion. I do think this would be too much.
I think a design decision might look like this: copied from petstore: SFSB is used because " 1. Thread safety 2. Lifecycle management 3. Client type Neutral 4. Scalable "
I will do the following: 0. A list with links to all paragraphs 1. A list with assumptions 2. I list with design decisions. (e.g explain why you used SFSB) 3. Scope 4. Add some appendixes (could be: 1 definitions used; 2. List with JSPs + function; 3. List with Classes+function; 4. Patterns uses; 5. something about each element in QoS requirements)
I think this will make the document easy to navigate. probably the grader will be most interested in: - assumptions - design decisions - Qos - Patterns Used
what do you think? Am I missing something important?
When we are digging deep and getting our hands dirty, we tends to forget the most important thing, satisfying the requirements. Whatever we do, it does not matter if we use POJO or Composite Entity, any project can only be labelled as completed and successful if our design can satify the requirements using the most appropriate technology.
So as long as your design can satisfy the requirements of the SCEA project, and you can justify it is most appropriate, then you will do no wrong.
Of course using J2EE in this assignment is a MUST, but dont forget that ALL requirement is important to the user.
What I am trying to say earlier is that while trying to design a architectural design for the client, we must never forget why we are doing this. It does not matter how wonderful or how advance you design is, but when it does not FULLY satify the ALL the requirements, the client will consider the design as crappy.
Back to basic... Satifsy FULLY ALL the requirement.