1 / 14

On a “Buzzword” Hierarchical Structure

On a “Buzzword” Hierarchical Structure. D. L. Parnas. “Hierarchical” as a Buzzword. The term “hierarchical” has been used in many different ways to describe the design of operating systems “Hierarchically” structured systems have a good connotation

goodwinrichard
Download Presentation

On a “Buzzword” Hierarchical Structure

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. On a “Buzzword” Hierarchical Structure D. L. Parnas

  2. “Hierarchical” as a Buzzword • The term “hierarchical” has been used in many different ways to describe the design of operating systems • “Hierarchically” structured systems have a good connotation • Researchers consistently overload this term, using “hierarchical” in many different ways • Parnas argues that this term has been used in ways that have different meanings

  3. Paper Objectives • Clearly define what is meant by a hierarchically structured system • Examine 3 operating system examples where this term was used, and provide better definitions • T.H.E • MULTICS • RC4000

  4. Paper Objectives – Actually… • Parnas wrote this paper not only to point out the ambiguity in the term “hierarchically structured”, but also to point out that we should not use buzzwords in an engineering context • Consider “High Level” also… • Parnas is making a point!

  5. Hierarchically Structured • Level i is the set of partssuch that: • There exists a  on leveli-1 such that R(, ) • If R(,) then  is on leveli-1 or lower • Level 0 is the set of  suchgiven that there are no  such that R(, ) A B C Formal D E F • Level i is the set of partssuch that: • All nodes have at least 1parent. • The graph has no cycles • Level 0 is a root in the hierarchy. To have a hierarchy youneed to define appropriateconstraints on a relation… Informal

  6. What does “Hierarchically Structured” Mean? • Any program can be hierarchically structured • Everything is a single part • Easy to arbitrarily divide a program such that the “parts” are hierarchically structured • If the “parts” are not hierarchically structured, just redefine the “parts” • Thus, by itself the formal definition of a hierarchy carries no meaning at all when used in a software engineering context

  7. How and When to use Hierarchies… • You need to define “which” hierarchy and clearly specify the “relation” used to define the hierarchy • You then need to validate that the “relation” used as a constraint actually forms a hierarchy • You need to validate that the hierarchical constraint provides some value – don’t make it an unnecessary constraint

  8. Hierarchies 101 • Hierarchies are based on mathematical formalism • Hierarchies make things easier for humans (divide and conquer) • Hierarchies have the connotation of being a “good thing”, so we strive to use them wherever possible • However, sometimes we say we have a hierarchy when we don’t, and sometimes forcing a hierarchy introduces unnecessary and unwanted constraints

  9. Some Hierarchical Relations – “Maybe” • “uses” (Program Hierarchy) • A calling program should be able to ignore the internal workings of a called program • The called program should not make any assumptions about the internal structure of the calling program • “gives work to” (Resource Allocation) • A process can assign part of a workload to another process in the system

  10. Some Hierarchical Relations – “Maybe” • “Part Of” (Program Structure) • Small modules recursively grouped into larger modules (subsystems) • Helpful for human comprehension • Need criteria for establishing this hierarchy, will be hard to do based on the program call structure • Sometimes the criteria is heuristic based • Software Architecture Example: High coupling, low cohesion…

  11. Some Hierarchical Relations – “Maybe” • “can be accessed by” (visibility / security) • Adding layers of indirection – good for security • Core data at the center ring, protected by functions and interfaces • Each subsequent layer has data that it manages, but must call down to a lower level to work with more “sensitive” data • Forcing a hierarchy here may not be good, the “can be accessed by” relation has value in one direction but not the other… • Why can’t an inner ring use the services of an outer ring?

  12. Some Hierarchical Relations – “Maybe” • Top-Down Design • Start with the user visible features of the system • “drill down” in verifiable steps to refine and implement these features • Is Top-Down design really possible? • Is it a hierarchy? • Is the design of a system hierarchical? Can’t clearly define a relation for this one – might be trouble here…

  13. Another Buzzword – “High Level” • Example – High-Level Language • What is the relation for this example? • “has fancier syntax” • “has stronger typing” • … • Need a definition for “high level”, although it is used in practice often.

  14. Summary: Hierarchy as a Buzzword • This paper is not about hierarchies, its about how buzzwords are used in research • This is just an example • Other example provided is “high level” • Buzzwords are dangerous because they convey no meaning at all, however authors who use buzzwords are trying to imply something…

More Related