Object-Oriented Programming


Michael L. Collard, Ph.D.

Department of Computer Science, The University of Akron


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


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

What We Have

What We Want

srcFacts: Concerns

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

Adhoc Design

Improved 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