1 / 11

Article Summary of The Structural Complexity of Software: An Experimental Test

Article Summary of The Structural Complexity of Software: An Experimental Test. By Darcy, Kemerer, Slaughter and Tomayko In IEEE Transactions of Software Engineering November, 2005 issue. Software Complexity. There are problem complexity and solution complexity

taffy
Download Presentation

Article Summary of The Structural Complexity of Software: An Experimental Test

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. Article Summary ofThe Structural Complexity of Software:An Experimental Test By Darcy, Kemerer, Slaughter and Tomayko In IEEE Transactions of Software Engineering November, 2005 issue

  2. Software Complexity • There are problem complexity and solution complexity • We are interested in solution complexity when we speak about software complexity • For software solution there are: • Algorithmic complexity • Structural complexity • We are interested more in structural complexity when we discuss the construction and maintenanceof software because structural complexity deals with organization of program elements --- which touches upon people’s decision making. • Algorithmic complexity is more interesting for execution ofcode --- that is the reduction of number of steps to solve the problem directly affects computational time, which is more machine oriented than human oriented (even though it does also affect human)

  3. Interest in Structural Complexity • Some main reasons of studying structural complexity is to more clearly outline: • What constitute better or worse structure • Ways to aid in creating structurally optimal solutions to influence other attributes such as maintainability, testability, re-usability, etc. In software, we already know the concepts of cohesion and coupling affect structural complexity ---- from past studies, we want: - high cohesion and - low coupling

  4. Using Wood’s Task Complexity Modelto Aid in Studying Structural complexity • Has 3 essential concepts: • Products : things created by acts and behaviors • Acts: pattern of behavior that has a purpose or direction • Information cue ; information about attributes of stimuli that affect the decision making needed to perform the tasks • Also has 3 sources of task complexity associated with the above concepts: • Component complexity : number of distinct acts and the number of distinct information cues needed in the performance of the acts to produce the product. • Coordinative complexity: relationships between task inputs and task outputs such as the form, strength, and sequence of the relationships. • Dynamic complexity: changes in the state of the world that has an effect on the relationship between tasks and products

  5. Making Trade-offs • Draw from Cognition studies on how people make trade-offs between dimensions of complexity • People have primary storage called short term memory (STM) where all the needed information must be available for people to think. • People will access information from secondary storage called long term memory (LTM) to help the thinking process. The problem is that accessing LTM takes a lot more time and effort. This suggests that we should work with small chunks of information and that thinking that requires the usage of LTM will take longer or more effort.

  6. Drawing Analogy to Wood’s Task Complexityand Cognitive Science’s STM and LTM • Wood’s Complexity : • Component Complexity – related to the acts and the information cues need for each of the acts • This is similar to software cohesion • Coordinative Complexity – related to the precedence, form and strength of relationships between the input to a task and the product • This is similar to software coupling • Short Term and Long Term Memory: • In comprehension and thinking, all the information must be brought into STM and when there is too much some of that information is moved to LTM. • This is similar to looking at Cohesion of a component (STM) and Coupling (LTM) among components, because coupling requires one to look at more than one thing and thus require more memory --- (LTM).

  7. Research Hypotheses • Hypothesis 1: For the more highly cohesive programs, maintenance effort is lower • Hypothesis 2: For the more highly coupled programs, maintenance effort is higher • Hypothesis 3: For the more highly coupled programs, higher levels of cohesion reduce maintenance effort. Why would people think of Hypothesis 3? This 3rd Hypothesis seems like something added after the experimental results were known. (I am being a bit cynical here.)

  8. Experimental Test of Hypotheses • Used 17 professional software engineers • Performed “perfective” maintenance task on two types of problems: • Regression analysis enhancement written in procedural style with C language • Database functionality enhancement written in OO style with C++ language • There were 4 code variations set up for the enhancement task: • High coupling – High cohesion • High coupling – Low cohesion • Low coupling – High cohesion • Low coupling – Low cohesion • Measured the time required to complete the maintenance task.

  9. Experimental Results • Covariate factors such as previous experience with language and length of work experience had no significant correlation to task time. • Hypothesis 1 : more cohesive programs should take less maintenance effort - - - could not be accepted • Hypothesis 2:more coupled programs should take more maintenance effort - - - could not be accepted • Hypothesis 3: For more highly coupled programs, higher levels of cohesion reduce maintenance effort - - - could be accepted The two attributes, coupling and cohesion, together shows a relationship where coupling is the main and cohesion is the moderator of that relationship in bringing down the maintenance effort.

  10. Results Says? • In case of high coupling we are saturated at STM and need to use LTM because coupling brings in chunks (programs) of information that need to be processed. • Within that situation, when the chunk (program) isitself very cohesive, then maintenance effort is actually less compared to when the chunk is less cohesive.

  11. Now Look carefully at Figure 6 of the Article • Observations: • With low cpl, effort is higher as we get less cohesive - (OK) • 2. With high cpl, effort went up as we get more cohesive -(Not OK) • With high cohesion, effort goes down with low cpl - (OK) • 4. With low cohesion, effort goes up with low cpl - (Not OK) high (low cpl; low coh) effort (high cpl; high coh) The anomaly ! (but H3 was Acceptable !!) (high cpl; low coh) (low cpl; high coh) high coupling The experimental results did NOT come out with high cohesion is always better (e.g. high coupling with low cohesion required less effort than high coupling with high cohesion!)

More Related