Analysis Model

Analysis Model

V1.1

Requirements/Functions

The software is required to render HTML documents. That is, it has to read an HTML document, translate it, and then display the translated version. The following functions are to be provided:

- A command line interface that accepts the name of a file to be rendered.

- The ability to read an HTML document.

- The ability to identify all standard HTML tags and extensions added by Netscape.

- Write a document to its own window by translating the HTML tags.

- The ability to move/re-size the document window.

- Vertical and horizontal scroll bars.

- Program termination via closing of document window.

- Error messages to be given if file’s specified in the command line cannot be found or if they are not HTML files (i.e. the extension is not .html).

- When a document had been fully rendered, the window should inform the user whether or not the document conforms to the HTML specification.

Class composition

With the requirements and the main functionality of the system established, we can now begin to create some potential classes. The classes will be established using the following characteristics:

- Retained information. Does information about the class need to be remembered for the system to function?

- Needed Services. Does the class have a set of identifiable operations that can change the values of its attributes?

- Multiple attributes. Does the class contain information that warrants its own class?

- Common Attributes. Do the attributes defined for the class apply to all instances of the class?

- Common operations. Do the operations defined by the class apply to all instances of the class?

Document reader вЂ" The process of reading an HTML document is basically 50% of the majority of the work that will be performed by the program. The class will be responsible for essential information, that is, tags and blocks of text in the HTML document, easily important enough to warrant its own class.

Document writer вЂ" An essential class to the program, this class will be responsible for outputting the final document to the user, without a class to do this the program would only be able to read, and therefore be pointless.

GUI вЂ" At this point, the graphical interface consists of a command line interface for the user to specify a filename, and a slightly modified window, in that it has some way of indicating to the user whether or not the document conforms to the HTML specification.

Now we have established these potential classes, analysing them is likely to lead to the emergence of other classes.

The document reader class is responsible for reading a document, recognising the tags, and then sending this information to the document writer. As there are lots of tags that will be recognised by the program, tag recognition warrants its own class. So now, instead of just a reader and a writer, we will have the classes, Parser, Tag and Writer. The Tag class is an essential link between Parser and Writer. The Parser reads the HTML document, recognising different HTML tags, when it recognises the tag, it can send blocks of texts and names of tags identified to the Tag class. The Tag class will contain all the information on what a specific tag means. The Tag class can then translate this tag, adding it to the block of text and sending it to the Writer class. The Writer class can store all the blocks of text until the whole document has been parsed, then output the final version to the interface. At this point the GUI class will remain the same. So now we have four classes:

Parser

Tag

Writer

GUI

UML Use case diagram

Using the functionality as a base, we can establish the following use-case diagram for a typical user of the system.

CRC вЂ" Class and object diagrams

With the main functionality and use cases of the system established, as well as potential classes, we can discuss several primary scenarios and a few secondary scenarios and how the classes and objects collaborate with each other. The following scenarios will be explored:

Primary

- The user inputs a filename to be rendered. The file follows the HTML specification exactly.

- The user inputs a filename to be rendered. The file does not follow the HTML specification exactly, but is still an HTML file.

- The user closes the document window to terminate the program.

Secondary

- The user inputs a filename that does not exist

- The user inputs a filename whose extension type isn’t HTML (e.g. filename.txt)

Before working through the scenarios, we must draw up CRC cards for all the classes.

Class: Parser

Responsibility: Collaborator:

Accept file/path from user GUI

Read file

Identify HTML tags

Group tags with blocks of text and output them. Tag

Identify end of file. Writer

Class: Tag

Responsibility: Collaborator:

Receive tag types with blocks of text Parser