LECTURE 12: COHESION CSE 442 Software Engineering Sprint 1 Demo - - PowerPoint PPT Presentation

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

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

Software Engineer’s Role

¨ 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

To Err is Human; To Really Foul Things up Takes a Computer

¨ (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

What is a Module?

¨ Describes strength of relationship between actions

Module Cohesion

High Subroutine Cohesion High Subroutine Cohesion

¨ Describes strength of relationship between actions

¤ Can be evaluated at multiple granularities within module

Module Cohesion

High Subroutine Cohesion Low Overall Cohesion High Subroutine Cohesion High Overall 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

Module 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

Coincidental 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

Logical 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

Temporal 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

Procedural 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

Communicational 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

Functional 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

Informational Cohesion

¨ Describes important properties for modules to have

¤ Ensures efforts spent creating smaller, simpler modules ¤ Describes ideal usages so code becomes more portable

Why Cohesion Matters (I)

¨ Describes important properties for modules to have ¨ Studies found only 15% of "new" code actually new

¤ 85% previously developed, but hard to find or update

¨ Best organizations have reuse rates about 40%

¤ Huge gains possible for those who can design modules ¤ Take new way of thinking to go beyond immediate need

¨ Ease of reuse another property of higher cohesion

Why Cohesion Matters (I)

Why Cohesion Matters (II)

¨ Describes important properties for modules to have ¨ Everybody wants code that easily testable & fixable

¤ Highlights ways to think about code that is robust

¨ Clearly have problems testing lower-level modules

¤ Lower-levels lack planning & often prevent any testing ¤ But not just planning, higher-levels takes contemplation

¨ Many benefits when cohesion high within module

¤ Narrow focus helps code avoid overspecialization ¤ Easier to understand since actions strongly connected ¤ Few reasons to change, so testing & debugging cheaper

Module Cohesion

Low Overall Cohesion High Overall Cohesion

For Next Lecture

¨ Get first sprint submission ready within your team

¤ No work "submitted"; grading done in group meeting

¨ Process used stolen from Sprint release meetings

¤ Team starts app, shows user stories implemented... ¤ … and then lets grading manager run acceptance tests

¨ Software engineering grading follows that step

¤ Built around the (already available) grading rubric ¤ Team opens repo & scrum board for grading manager ¤ Then uses this to demonstrate each criteria satisfied