Concerns

A concern is a particular set of information that affects the code of a computer program

• A section of conceptual information
• Want to identify concerns
• Want to separate concerns
• Separating concerns is the primary tool we have to reduce complexity and complications

srcFacts: Concerns

• srcFacts report - The source code counts
• Markdown - Markdown syntax, table format
• srcML - An XML application consisting of XML elements specifically for source code
• XML concepts - The parts of XML
• XML parsing - What is valid XML, how to actually parse at a low level

srcML & XML

• srcML is an XML application and one of many, e.g., XHTML
• To use srcML, you must know about the XML format and an interface to an XML parser
• However, to use XML, you do not have to know anything about srcML
• To use an XML parser, you should not have to know anything about low-level XML parsing

Count Articles

CountArticles

Count Articles: Concerns

• English-language articles
  • i.e., "the", "a", "an"
• PDF content
  • e.g., a PDF contains text
• PDF format
  • e.g., how PDF stores content

Count Articles: Separate Concerns

• English-language articles
  • -> CountArticles.cpp
• PDF content
  • -> PDF interface declared in pdf_reader.hpp
• PDF format
  • -> PDF implementation in pdf_reader.cpp

Why Separate Concerns?

• Focus on one part at a time (modularity)
• Work with very complex formats (e.g., a PDF) or systems by only understanding the interface (usability)
  • "usability, not just for end users"
• Test separately
• Use for other purposes (reusability)
• Focus on fault tolerance, reliability, performance, scalability, robustness, extensibility, maintainability, security, portability

Count Articles Design

• Does the current design of CountArticles completely separate concerns?
• No
• Why?

Improve Design: Separate Concerns

srcFacts: Concerns

• srcFacts report
• Markdown
• srcML
• XML concepts
• XML parsing

Goal: Separate srcFacts Concerns

• srcFacts report -> srcFacts.cpp
• Markdown -> srcFacts.cpp
• srcML -> srcFacts.cpp
• XML concepts -> xml_parser.hpp
• XML parsing -> xml_parser.cpp

Overall srcFacts Project Goal

• Get as much of the XML parsing details out of srcFacts.cpp
• Isolate srcML to srcFacts.cpp -> No knowledge of srcML in xml_parser
• Isolate srcML to srcFacts.cpp -> No use of srcML element names in xml_parser, e.g., xml_parser cannot contain the srcML element name "return"
• At this point, without additional language features, unable to fully separate XML parsing from srcFacts (No, I am not just talking about classes)

Why Separate srcFacts Concerns

• Reuse of xml_parser for non-srcML projects
• Test xml_parser (untestable in current state)
• Write other source-code reports by reusing xml_parser

srcFacts Design

Separate XML Concerns

• Contains all details of the XML format
• Does not depend on srcML
• Has no knowledge of srcML
  • Does not know that there is a srcML element "return"
  • Does not know that there is a srcML element "literal"
  • Does not know that there is a srcML attribute of "type"
• Can be reused in other programs which access XML data

Sequence Diagrams

• srcFacts calls the functions in xml_parser
• Control shifts from srcFacts to xml_parser until the function returns
• Control goes back to srcFacts
• Comparison to srcML and incrementing counters can be viewed separately

What is possible with a separate XML parser?

• Test parser in isolation
• Time the parser
• Replace with another XML parser
• Write lots of source reports
• Perform a source-code transformation, e.g., convert from an index-based for to range-based for
• Use for any application which needs XML parsing