Grade: P
Score: 81
Comment: This report shows the total points that could have been awarded in each section and the actual amount of points you were awarded. This information is provided in order to give you feedback on your relative strengths on a section basis. The maximum number of points you could have received is 100, minimum to pass is 70.
Class Diagram (44 maximum) ............................... 42
Component Diagram (44 maximum) ........................... 29
Sequence/Colloboration Diagrams (12 maximum) ............. 10
I guess I saved myself a $150 re-submission after all
I know my solution was functional enough for real-life implementation but the submission itself was half-baked as I had to rush through preparing the documentation - the score is not at all disappointing considering how appalled I was when I reviewed my submission a couple of weeks after I submitted it.
Class Diagram - definitely did not deserve 42/44 - it had at least 1 glaring error and a couple of ambiguous relationships apart from being very convoluted in the way it was laid out. Frankly, developers would kick me if I gave them a Class diagram like the one I submitted
I had also changed the BDM quite significantly (removed relationships, introduced new classes, added new relationships, modified cardinality, modified requirements but I explained everything in detail, so maybe that helped). The original requirements are c-r-a-p - sorry, but that's the harsh truth. I don't mind if requirements are vague or ambiguous, but if they are contradictory, you bet I am going to fix them before attempting to architect a solution for them!
Component Diagram - I don't blame myself for this debacle! I somewhat followed Mark Cade's examples as well as the suggestions from the folks here. However, I honestly wouldn't use Cade's paradigm for drawing Component Diagrams. I've reverse-architected legacy systems and I think I have an excellent understanding of what Component Diagrams are and what purpose they serve. What I saw in Cade's book might actually be applicable somewhere - but not in any of the workplaces I have been in.
Sequence Diagrams - this was a bit puzzling to me because my sequence diagrams were perfectly functional. Perhaps I gave too much detail, but I know for sure that my sequence diagrams will result in a system that fully meets the functional requirements. I did use option and loop interaction frames, so I wonder if that took some points away.
I submitted 1 Class Diagram, 1 Component Diagram and 8 Sequence Diagrams.
Class Diagram had 18 classes - actually, it originally had only around 14 - I forced myself to tack on a few more because I got nervous seeing people submit 30-35 classes :roll: Did you guys show a class for every variable or something
Followed Cade style and showed the service classes also. In the real-world, I would show much less detail.
Component Diagram had 26 components - in retrospect, I should have had at least 2 more components for the external systems - at the time I felt they were outside the scope of the architecture, but now feel they should still have been represented. I just had notes to indicate the presence of those systems. The components were laid out by tier and the Application Client was also represented in the diagram. But hey, with 29 marks, feel free to ignore that I even had a Component Diagram
Sequence Diagrams - 1 for Web Request and 1 for each Use Case. Showed both Customer and Travel Agent flows in the same diagram using opt interaction frames. I didn't have a sequence diagram for the Application Client - frankly, I just didn't know how to do it - app client development is not exactly my strong point and nor am I particularly interested in it - I just fail to see the value in a stand-alone app client.
Actually, I spent a lot of time tightening the flow of messages, the way I would in a real implementation - I would be very satisfied with this effort in the real-world, never mind what Sun thinks
I submitted one document per diagram, explaining the diagram (yeah, I know it defeats the purpose of using UML to a certain extent, but since I was doing so many things outside my comfort zone, I felt obligated to write these documents). I submitted 3 additional documents - Software Requirements Specification (I even changed the Use Case Model and put that in my SRS!), Assumptions and Architectural Decisions.
On the whole, if I had to re-do it (which I thankfully don't!), I would probably structure my submission better. My solution was fine, IMO, but the submission was a travesty of my professionalism and I do feel bad about that. Given that fact, I am quite happy with 81%, perhaps even a tad embarrassed
[ February 15, 2006: Message edited by: Sri Jag ]
[ February 15, 2006: Message edited by: Sri Jag ]
