1 / 23

CSC 395 – Software Engineering

CSC 395 – Software Engineering. Lecture 11: Object-Oriented Goals –or– Who Moved My #$&@! Cheese?. Today’s Goal. Discuss object-orientation approach Goals of OO-based languages Important features of OO-based software How OO goals used in software engineering

briana
Download Presentation

CSC 395 – Software Engineering

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. CSC 395 –Software Engineering Lecture 11: Object-Oriented Goals –or– Who Moved My #$&@! Cheese?

  2. Today’s Goal • Discuss object-orientation approach • Goals of OO-based languages • Important features of OO-based software • How OO goals used in software engineering • Begin thinking about next stage of project • You should have complete set of requirements • Time to start moving on to next workflow: analysis

  3. Software Engineering CPL • Unstructured Programming • SE Concept: What’s software engineering? • Examples: Early assembly language, BASIC • SE Effects: Eeek! Run for the hills! • Functional Programming • SE Concept: λ-calculus makes generating correctness proofs easy • Examples: Lisp, Scheme, Prolog • SE Effects: Programming becomes as easy and intelligible as λ-calculus

  4. Software Engineering CPL • Structured Programming • SE Concept: Break process up into generic actions; hope actions are reusable • Examples: Pascal, C/C++ (non-OO) • SE Effects: Does problem divide into independent actions?

  5. Software Engineering CPL • OO Programming • SE Concept: Create independent data classes; assume data types are reused • Examples: Java, C++/C#, Ada • SE Effects: Can data be split into independent reusable actors?

  6. Software Engineering CPL • Aspect-Oriented Programming • SE Concept: “Cross-cutting” concerns (e.g., data includes Students, Employees, & Matt G.) are common, but do not fit into normal OO languages • Examples: Aspect-Oriented Java, AspectL • SE Effects: Are programmers really able to keep track of the additional complexity? • AOP still early in its infancy

  7. Software Engineers Role • The most likely way for the world to be destroyed… is by accident. That's where we come in; we're computer professionals. We cause accidents. -- Nathaniel Borenstein • Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers… -- Jef Raskin • In a few minutes a computer makes a mistake so great that it would have taken many men many months to equal it. -- Unknown • Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. -- Rick Cook

  8. To Err is Human; To Really Foul Things up Takes a Computer • After entering maintenance workflow, users call computer programs: • Fragile • Unreliable • Many worse terms that I will not put in slides • (Imagine if they saw the works-in-progress!) • Why is delivery & updating code so hard? • Cohesion & coupling between modules

  9. What is a “Module”? • (Supposedly) Independent unit of code • Languages written & organized differently • What a module is also differs between languages • Most languages also have multiple levels at which module can be defined • Examples of potential module definitions: • Java: method, class, or package • C: function or file (*.h) • C++: class or namespace • Assembly: any block of code starting with a label

  10. Strengthor Cohesion • Measure of interaction within a module • Ideally each module should do single thing • Ideal modules are simple & easy to debug • Few people actually think this way, though • Cohesion discussed using 7 possible levels • Scale is relative one and changes over time • OO tries keeping cohesion at highest levels • Critically, OO tries making cohesion easy • To be useful, important to understand why levels are good or bad

  11. The Bad & the Ugly • Coincidental cohesion: “platypus module” • Module combines completely unrelated ideas • At best, solves current problem; used only once • Logic, proofs, design cannot be used with module • Logical cohesion: “Bassomatic 4000 module” • Does many (logically connected) tasks • One big if/else or switch statement! Hooray! • Don’t we all like reading 1000 line methods? • What happens when the requirements change?

  12. Getting There… • Temporal Cohesion: “steamroller module” • Performs long series of time-dependent tasks • Tasks connected only in that they are performed one after another • What happens when the process changes? • Procedural Cohesion: “breadmaker module” • Starting from scratch performs entire operation • Often “optimized” into unintelligible spaghetti code • May be reused, but rarely able to be rewritten • What happens when requirements changes?

  13. Best of Breed Approaches • Communicational Cohesion: “Spork module” • Combines temporal & procedural cohesion • Reuse of this code is iffy • Functional Cohesion: “one-time pad module” • Module does one task and does it well • Ideal module in structured programming languages • Informational Cohesion: “String module” • Contains set of related, but independent, operations centered on single datum • Reuse is maximal by ignoring unneeded operations

  14. Cohesion Review • Measures of interaction within a module • Describes how easy module is to debug & reuse • Higher the level of cohesion the better • When a module matches multiple levels, assigned to the lowest one • View of cohesion is limited, however • Only considers operation at the unit level • Ignores problems at integration or system level • Pile of Picassos on the floor still looks like trash

  15. Binding or Coupling • Measure of interaction between modules • Ideally modules independent of each other • Ideal world would involve 1 HUGE module • Examines how to get modules to play nicely • Coupling has 5 possible levels • Scale is relative though fairly static • OO can restrict attempts at bad coupling levels • Ultimately relies on intelligence of programmers • Unfortunately, coupling rarely stated explicitly • Proper OO methodology make this explicit

  16. Use of public & static Fields Considered Harmful • Content Coupling: “Rube Goldberg Linking” • Modules refers to contents inside a module • Both modules are completely intertwined • Changing one module crashes… something • Common Coupling: “Commune Linking” • Modules read & write single global (static) value • Generates many assumptions of values meaning • Provides many opportunities for mischief or worse

  17. Good, Better, & Best • Control Coupling: “Wingman Linking” • Modules actions dictated by & relied upon others • Modules rely on detailed working of each other • Stamp Coupling:Too-Much-Information Linking • Module uses only part of the module passed in • Requires more depth when debugging modules • Like common coupling, but w/o statics (& explicit) • Data Coupling:Ideal Linking • Sharing between modules is minimal and overt • Depends on the values only, not the modules

  18. Coupling Review • Measure of interaction between modules • Are module relationships between equals who have their own lives? • Suggests when counseling (e.g., reprogramming) is needed • Good OO keeps coupling at highest levels • Proper documentation also important • Even more important for multi-threaded programs • Consider the coupling between objects of similar types also

  19. Documenting Relationships • Want to discover problems before implementation • Need approach of documenting class designs • Should highlight relationships between classes • Provide means to examine whether design works • UML Class Diagrams to the rescue • Shows relationships between classes • Includes space for writing down methods and fields

  20. UML Class Diagrams • Each class drawn as 3-part box • Class name written in top portion of box • Fields written in middle portion of box • (public) Methods written in bottom portion of box

  21. UML Class Diagrams • Show relationships between objects • Generalization uses open triangle • Aggregation/Composition uses diamonds • Also list multiplicity when that is appropriate

  22. UML Class Diagram • Can also establish other relationships • Include interface definitions • Show calls between classes

  23. For Next Lecture • Why reusability & portability are important • What this has to do with OO goals • How OO can improve reuse & portability • Begin thinking about next stage of project • Must develop analysis & design from your requirements document • These are make-or-break parts of any project

More Related