MathCast Practice – the End

I’ve worked on the MathCast practice for at least one month in total. Four weeks ago, I drew the code structure (my purpose was to find out its architecture) by viewing its C++ source code, and three weeks ago I again tried to find out what kind of architecture it had by using the reverse engineering feature in Enterprise Architect which imported the C++ source code and provided its corresponding UML model class diagram. However, the resulted class diagram had even more dependencies among its classes than my first hand-drawn structure. After some attempts to analyse its architecture so far, I think it’s time to put an end to this practice.

Here are some facts about the MathCast I worked on I think it would be better for you to know. The latest version is 0.92, mainly implemented in JavaScript, XUL, and CSS, which is ported from C++ (version 0.75 – 0.90). I didn’t know how to find out the architecture from such a mixture of different coding languages, especially that they are not object-oriented. I am too familiar with architectures implemented in object-oriented languages and totally unfamiliar with others so as to feel overwhelmed when facing this situation. Then I think a good architecture implemented by C++ or JAVA is also possible to be implemented by C without changing the architectural structure, as the structure won’t be changed if we keep the services and functions a component should provide and perform unchanged while just using C to implement them. Well, as it’s too difficult to work out the architecture of version 0.92, I found the C++ code of version 0.83 to proceed the practice.

After some analysis about the real architecture from the code of version 0.83, I conclude the practice with the following points: 1. What really constitutes software architecture? Though I don’t have a definite and comprehensive answer, I believe that components are an essential part of architecture, no matter whether the component is a function block or a class or something else. And so is the connections among components. But in some views of software architecture, the view might show no connections among its components, not explicitly, whereas somehow it still could disclose some underlying interactions among some components through its hierarchy or something similar. 2. Software architecture should have a fine granularity of functional decomposition, and functionality/responsibility should be classified appropriately, otherwise there’s a great risk that the resulted architecture would have lots of messy dependencies. 3. Software architecture manifests an abstract summary of the software. It should give viewers a general understanding of the software.

I didn’t do much work attempting to relate requirements to architecture as the architecture is not ideal enough and I guess this architecture is not intentionally designed as well. But maybe it is worth trying to see what they result in when there are architecturally significant requirements that haven’t been considered into or reflected in the architecture. Well, because of my limited knowledge about software architecture so far, I can’t dig out any more valuable discoveries in this practice. But I hope in my later research I could find something more interesting and I am looking forward to it.

A Practice on MathCast


I’ve been working on a practice based on MathCast Equation Editor for a month so far. MathCast is an open source application on sourceforge.net that allows you to input mathematical equations. The main tasks of the practice are to create a requirements specification using Volere template after using the application, later to compare it with the requirements specification for this project provided by Mr. George Kalaitzoglou which is also written after implementation, and then to find out its architecture by examining its source code, finally and most importantly, to relate the requirements to the architecture and see what the relationship between them is. It’s obvious that this practice could benefit me at least in the following two aspects: enhance my understanding of software requirements and architecture, and have a taste of what the interrelationship between software requirements and architecture could be.

Volere requirements specification template has very rich and comprehensive guidance about what to consider and write in every part of the document, which is really a good learning resource indeed. However, Volere lacks of hierarchy. One big problem I frequently encountered during writing the requirements document was that there were some ‘facts/features’ that I was always confused whether they belonged to requirements or design decisions. My supervisor Norah said, this was a problem inherent in writing requirements ‘after the fact’. Yes, I agree. But it somehow reveals the fact that at least some design decisions are requirements that have been decided. And in another context, if a customer comes with a solution/design decision, I think such a solution/design decision is going to be treated as a requirement as well. In this two situations, design decisions have no difference to requirements in terms of their meanings. The requirements document written by Mr. George Kalaitzoglou is very different compared to mine as it mainly emphasizes the tasks/process flow, strictly adhere to the current implementation.

Then I checked the C++ source code of MathCast version 0.83 (the latest version is 0.92 but it’s been ported from C++ to XUL, JavaScript and CSS). Well, the architecture I got after examining the source code is not that architectural, but it still could stimulate my thoughts about what constitutes an architecture. Bearing all these in mind, I started to draw my own architecture for this application. I didn’t intentionally follow the three step architecture design process in Gorton’s book – Essential Software Architecture, but in fact I did start with determining architectural requirements and then architecture design intuitively. One question that came into my mind during the architecture design is to which degree of detail should I reach to, in another words, how architecture differs from other design artefacts. Though I have created an architecture, those questions are still what I need to work on at the moment.

The last task is more difficult but more attractive as well. I am working on it now.