LECTURE 12: COHESION CSE 442 – Software Engineering
Sprint 1 Demo Prep
What Have We Done? ¨ Chose work to complete over current project sprint ¤ Reviewed stories & selected ones client thinks important ¤ Ensured stories stable & "delayed" work when uncertain ¤ Evaluated efforts so stories completable during sprint ¤ With client, write acceptance tests proving when "done" ¨ Huddled with developers & plotted out sprint efforts ¤ Stories broken into tasks & estimated time for each ¤ Also considered need to (re-)fix any "technical debt" ¤ Reset scrum board & made any additions & updates
Waterfall Lifecycle Review ¨ Many projects use "wagile" approach ¤ Best of waterfall & agile used in project ¨ Once target fixed, waterfall efficient ¤ No continuous contact distracting client ¤ Analysis & design uses "complete" info ¤ Rollout less frequent, so fewer disruptions ¨ During implementation, be more Agile ¤ Flexible code encouraged by short sprints ¤ Delivering incomplete features avoided ¤ Deadlines help limit procrastination
Waterfall Lifecycle Review Project (Could Be) Here
Communication ¨ Documents purpose communicating ideas to team ¤ Requirements detailed by describing user's interactions ¤ Stories include acceptance tests to verify expectations ¤ Tasks break down stories to ensure clear for developers
Communication Breakdown ¨ If differences occur in documents, what to do? ¤ Completely rely on one & define it as “controlling” ¤ Use common ground that exists in all documents ¤ Look through notes to reconstruct what answer really is ¤ Restart process from scratch & avoid similar mistakes
Communication Breakdown ¨ If differences occur in these things, what to do? ¨ Better idea: verify documents with each other ¤ Use similar terms to describe action across requirements ¤ As they are made, walk client through tests to validate ¤ Check how tasks interact & ensure they all align
Software Engineer’s Role Programming today is a race between software engineers striving to build bigger and better idiot-proof programs & the Universe trying to produce bigger and better idiots. -- Rick Cook
Software Engineer’s Role Programming today is a race between software engineers striving to build bigger and better idiot-proof programs & the Universe trying to produce bigger and better idiots. So far, the Universe is winning. -- Rick Cook
To Err is Human; To Really Foul Things up Takes a Computer ¨ Terms people use when discussing software: ¤ Fragile ¤ Unreliable ¤ Unpredictable ¤ Crappy ¤ I am curious to know what you came up with ¤ Terms I could not put on slides ¨ Why is delivering & updating code so hard? ¤ Cohesion & coupling between modules
What is a Module ? ¨ (Theoretically) Independent unit of code ¤ Concept of a module independent of language ¤ Actual definition depends on specifics of the language ¤ Most languages have multiple levels to define module
Module Cohesion ¨ Describes strength of relationship between actions High Subroutine Cohesion High Subroutine Cohesion
Module Cohesion ¨ Describes strength of relationship between actions ¤ Can be evaluated at multiple granularities within module High Subroutine Cohesion High Subroutine Cohesion Low Overall Cohesion High Overall Cohesion
Module Cohesion ¨ Cohesion often discussed using 7 possible levels ¤ Scale is qualitative & relative; "best" depends on system ¤ Object-orientation goal was helping improve cohesion ¤ Never automatic , but possible no matter language used ¨ Important to understand why high cohesion good ¤ Easier to write strongly cohesive modules once learned ¤ Never becomes "easy"; time & thought always required ¤ Creating robust, reusable modules worth the investment
Coincidental Cohesion ¨ Code resembles platypus in natural world
Coincidental Cohesion ¨ Code resembles platypus in natural world ¤ No thinking involved, but looks like hackathon result ¤ Starting to code without tests or plans also creates this ¤ Actions valuable when written, but reasons now lost
Coincidental Cohesion ¨ Coincidental cohesion : no connection in actions ¤ Not planned, just combines completely unrelated ideas ¤ Reuse nearly impossible since intertwines many actions
Coincidental Cohesion ¨ Coincidental cohesion : no connection in actions ¤ Not planned, just combines completely unrelated ideas ¤ Reuse nearly impossible since intertwines many actions
Coincidental Cohesion ¨ Coincidental cohesion : no connection in actions ¤ Not planned, just combines completely unrelated ideas ¤ Reuse nearly impossible since intertwines many actions
Coincidental Cohesion ¨ Coincidental cohesion : no connection in actions ¤ Values have many uses & often relies on side effects ¤ Hard to debug or optimize without breaking other code ¤ Including module within proof or plans impossible
Logical Cohesion ¨ Logical cohesion selects from many actions or data ¤ Still contains of actions, but work logically connected
Logical Cohesion ¨ Logical cohesion selects from many actions or data ¤ Still contains of actions, but work logically connected ¨ Hooray! if/else if containing thousands of lines ¤ Could also be huge switch with fall-thru paths
Logical Cohesion ¨ Logical cohesion emphasizes writing over reading ¤ Single callback function makes adding actions trivial ¤ Must read module to find code before debugging starts ¤ Bugs also more likely; easy to forget or miss special case
Logical Cohesion ¨ Changes will occur & then modules not useful ¤ With each change, must find & update that specific code ¤ Retest everything , as changes can will have side-effects ¨ Reuse limited, since rarely need or want every option
Temporal Cohesion ¨ Temporal Cohesion performs long series of actions ¤ Work performed in sequence, but not really connected ¤ Good for developers, but prevents outsiders helping
Temporal Cohesion ¨ Temporal Cohesion performs long series of actions ¤ Work performed in sequence, but not really connected ¤ Good for developers, but prevents outsiders helping ¨ After needs explained will reasoning become clear
Temporal Cohesion ¨ Changes will occur & creates one problem source ¤ Reuse of code limited, since little binds module together ¨ Testing & debugging code sucks due to this structure ¤ Need to isolate action, but requires everything before it ¨ Reuse very limited, since cannot split actions out
Temporal Cohesion ¨ These types of modules operates like steamroller ¤ Get it done emphasized without thought to next steps ¤ No effort at intricacies; just flattens everything in path ¤ Cannot adapt, change, fix; neither nimble nor flexible
Procedural Cohesion ¨ Procedural Cohesion also has long series of actions ¤ Unlike temporal cohesion actions logically connected ¤ Process still complex, but possible for outsiders to read
Procedural Cohesion ¨ Procedural Cohesion also has long series of actions ¤ Unlike temporal cohesion actions logically connected ¤ Process still complex, but possible for outsiders to read
Procedural Cohesion ¨ These types of modules operate like assembly line ¤ Actions thought to be linked, but linkage not universal ¤ Cannot use individual steps, so future reuse limited ¤ Testing & debugging still hard with many steps involved
Communicational Cohesion ¨ Communicational Cohesion focused on data set ¤ Connected only by data; actions unrelated to each other ¤ Often found to handle I/O, but could also be data struct ¨ Handle data processing with one-size-fits-all module ¤ Testing & debugging hard, since side-effects surprising ¤ But any problem using data will be able to reuse module
Communicational Cohesion ¨ Handle data processing with one-size-fits-all module ¤ Testing & debugging hard, since side-effects surprising ¤ But any problem using data will be able to reuse module
Communicational Cohesion ¨ By doing everything, modules not good at anything ¤ Overly general approach creates ¤ By going too far into details may lose chances for reuse ¨ Very easier to test & write, problems only later on
Functional Cohesion ¨ Functional Cohesion focuses module on single task ¤ All data and actions in module center on completing task ¤ Maximizes use & reuse by reducing users cognitive load ¤ With only 1 action performed, testing & debugging easy ¨ Impossible to "just happen", but takes careful plans ¤ Design work needs to extend beyond current project ¤ Task must be broken down to avoid procedural cohesion
Functional Cohesion ¨ Cohesion ideal for structured code (C & Python) ¤ Organization centered on actions in these programs
Informational Cohesion ¨ Informational Cohesion focuses on single concept ¤ Module work centers on defining how concept acts ¤ Maximizes use & reuse since concept already known ¤ Since actions independent, testing & debugging easy ¨ Impossible to "just happen", but takes careful plans ¤ Design work needs to extend beyond current project ¤ Actions must be refined to ensure work done by concept
Informational Cohesion ¨ Cohesion ideal for OO languages (C++ & Java) ¤ Organization centered on data in these programs
Recommend
More recommend
