Presentation on theme: "1 CS427: Software Engineering I Darko Marinov (slides from Ralph Johnson)"— Presentation transcript:
1 CS427: Software Engineering I Darko Marinov (slides from Ralph Johnson)
CS42716-2 Comments on class zTHANK you to everyone who submitted zPositive: S.E. talks about real practice y“I like how I see a lot of the processes I experienced on past internships--but never knew they had titles” y“The real world examples [given] in class are useful.” y“I can use [the processes] at my real job, and show how process and techniques have been made to fit within the real world.”
CS42716-3 More comments zControversial: amount of reading y“Too many books! Pick one or two AT MOST.” y“We need more reading.” zControversial: usefulness of reading y“The midterm did not test the material from the 500+ pages of reading, or the lecture notes. People who attended class and read the books did the same as people who never attended and never read.” y“The class seems to rely more on the books rather than the actual lectures. If you read the books you're fine, elsewise you're not.”
CS42716-4 S.E. is broad but shallow zMany processes to develop SW yE.g., video games vs. banking application vs. flight-control software yEverything we teach (through lectures or reading) will be useful to some of you yNone of you will need everything we teach zExample at interviews: UML, other topics? yHow many lectures to cover all details of UML? yCan we cover everything in lectures?
CS42716-5 Communication zIf you have questions, please do feel free to ask! zYou can attend office hours yJeff on Mondays 3-4 yValas on Tuesdays 10-11 yDarko on Thursdays 2-3 zYou can post on the newsgroup zYou can email any of us zDo you want anonymous communication?
CS42716-6 Homework 2 zPostponed for a week: due Tue, Oct 31 zUse this time to work more on the project yProject is more than homework assignment yProject asks you to follow a process yHomework asks you to do some of the steps
CS42716-7 Topics on design zPrevious: component-level design zToday: modularity and abstraction yhttp://www.acm.org/classics/may96/http://www.acm.org/classics/may96/ yOptional: http://www.toa.com/pub/abstraction.txt http://www.toa.com/pub/abstraction.txt zNext: refinement yHamlet and Maybee, chapter 15 yTwo optional papers zOptional: exam won’t ask you anything beyond lectures (but interviews?)
CS42716-8 Modularity Myers 1978: “Modularity is the single attribute of software that allows a program to be intellectually manageable.” Split a large program into smaller modules
CS42716-9 What is a module? zProcedure zClass zFile zDirectory
CS42716-10 Functional independence zCohesion: Each module should do one thing yWe want high cohesion zCoupling: Each module should have a simple interface yWe want low coupling
CS42716-11 Cohesion zMeasure of interconnection within a module zThe degree to which one part of a module depends on another zMaximize cohesion
CS42716-12 Types of cohesion zCoincidental – avoid meaningless relations zLogical - same idea zTemporal - same time zProcedural - calls zCommunicational - shared data zChange together
CS42716-13 Coupling zMeasure of interconnection among modules zThe degree to which one module depends on others zMinimize coupling
CS42716-16 Information hiding zEach module should hide a design decision from others zIdeally, one design decision per module, but usually design decisions are closely related zD.L. Parnas, "On the Criteria To Be Used in Decomposing Systems Into Modules," CACM, Vol. 5, No. 12, December 1972
CS42716-17 Trade-offs Suppose moving functionality from one module to another will yDecrease coupling between modules yIncrease cohesion in one module yDecrease cohesion in another Should you do it?
CS42716-18 How to get modularity zReuse a design with good modularity zThink about design decisions – hide them zReduce coupling and increase cohesion yRefactor: make small changes zReduce impact of changes yIf adding a feature requires changing large part of the system, refactor so change is easy
CS42716-19 Modularity: summary zModularity is key to managing complexity zModularity is about managing dependencies zModularity should be based on hiding design decisions zNo perfect answer yTrade-offs yIteration
CS42716-20 Abstraction Abstract 1: disassociated from any specific instance 2: difficult to understand Abstraction: ignoring unimportant details and focusing on key features, usually repeating
CS42716-21 Example of abstraction zUnix file descriptor zCan read, write, and (maybe) seek zFile, IO device, pipe zWhich network abstraction did we cover in the previous lecture?
CS42716-22 Kinds of abstraction in S.E. zProcedural abstraction yNaming a sequence of instructions yParameterizing a procedure zData abstraction yNaming a collection of data yData type defined by a set of procedures zControl abstraction zPerformance abstraction
CS42716-24 Degrees of abstraction zC: Queue module specifies contents zC++: Template classes let you instantiate many Queues, each with a different type of content zSmalltalk: Queue class can contain any kind of object
CS42716-25 Interfaces zModules but not objects yClient knows which module it is using but not details of its implementation zObject-oriented programming yClient knows the interface of an object, but not which class it is in
CS42716-27 Facts about abstraction zPeople think about concrete details better than abstractions zPeople learn abstractions from examples zIt takes many examples to invent a good abstraction zAbstractions are powerful, but focus on facts first
CS42716-28 How to get good abstractions zGet them from someone else yRead lots of books xOops, is it okay to suggest reading? yLook at lots of code zGeneralize from examples yTry them out and gradually improve them zEliminate duplication in your program
CS42716-29 Abstractions can fool you Suppose collection has operation getItemNumbered() How do you iterate? For i := 1 to length, getItemNumbered(i) But what if collection is a linked list? How much would the iteration take?
CS42716-30 Abstraction: summary zModules should implement abstractions zBest modularization is based on ADTs zNot all abstractions can be implemented by modules