Class Note for CMPSCI 220 at UMass(3)
Class Note for CMPSCI 220 at UMass(3)
Popular in Course
Popular in Department
This 6 page Class Notes was uploaded by an elite notetaker on Friday February 6, 2015. The Class Notes belongs to a course at University of Massachusetts taught by a professor in Fall. Since its upload, it has received 14 views.
Reviews for Class Note for CMPSCI 220 at UMass(3)
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 02/06/15
Highly Skilled Programming CMPSCI 220 291A I Pro cient with Programming Methodology T0015 Spring 2009 I Methods I The two are often interrelated 21 Design The CRCBased Approach I E39gquot deSign methOds and Programming language I Specifically 00 language features and design Unlvnslnnr Massunmins Amman Devannmlnlnnvulu x L um nrl nssnmuins Am Dwannu nlnnv u mun Tools and Methods What39s the Bigger Picture I Thus far we ve focused on I Xhat makes code goodbetter I Tools I Are there dimensions of code quality I java W Effectivejava usage guidelines 21 we measure code qughtygt Eclipse SubverswmlUmt 211d EasyMock Which tactics design patterns or others lead to I Methods improvements on which dimensionsgt 39 1355181 Patterns and desgn PmQPles I Xhat strategy guides choice use of tactics I Refactonng I How do we decide what code to wntegt I Tactical approaches to goodbetter code I HOW do we go about mmg Unlvnslnnr Massunmins Amman Dwa nu nlnnvulu x i um nrl nssnmuins Am Dwannmlnlnnwlu mun CMPSCI 220 Picture Code Quality I Prograrnmingeinetheemedium I One dimension focuses on overall system function I Asmgned task evolving code base I Individual mall groups 173 of programmers 39 REhablhty I Efficiency I Evolving program I Maintainability I Skills needed in future courses I Usability I These and similar referred to as ilities I anarily relevant to prograrnmingeinetheelarge Unlvnslnnr Massunmins Amman Dwa nu nlnnvulu x r A r um nrl nssnmuins Am Dwammlnlnnwlu mun Maintainability Some Facet I Abstraction eases understanding I Hidden dependencies inhibit change I Premature commitment limits choices I Consistency eases understanding I Similar things are done in similar ways I Role expressiveness eases understanding I Purpose of a component readily inferred I Measuring any of these is dif cult Uulvnslnnr Massunmrns Amman Dwa nuilnlnnvulu x Design Principles I 1311542511141 aspects of your application that vary I Frugali t0 M d f not an implementations I Farm DI400sz over inheritance I Classes should be 3 107303er but ared m madztzmi um I Strive for dwell ragged designs between obiects that interact I Deznd awn abmtm mn not concrete classes Uulvnslnnr Massunmrns Amman Dwa nuilnlnnvulu x Code Quality The Design Dimension I Three standard faces I Simplicity vs complexity measurable I Modularity coupling and cohesion I Information hiding I Strong connection to maintainability I And especially to abstraction I How can these be measured I How can they be achieved I Design principles design patterns refactonng umquot nrmnssnmuins Am Dwa nuilnlnnwlu x More Design Principles I Talk only with your immediate friends I Don t call us we ll call you I Allow lowilevel components to hook into a system I But highilevel components determine when and how they are needed I A class should have only one reason to change I More generally Strive for high cohesion I Module or class designed around a set of related functions has high cohesion Uulvnslnnr Massunmrns Amman Dwa nuilnlnnvulu x Design Patterns Strategy De nes a family of encapsulated algorithms Decorator Attaches additional responmbilities to an obiect dynamically Observer De nes a oneitoimany publishsubscnbe dependency between obiects Factory Method De nes an interface for creating an obiect Abstract Factory Method Pattern Provides an interface for creating families of related or dependent obiects umquot nrmnssnmuins Am Dwa nuilnlnnwlu x More Design Patterns I Adapter Converts the interface of a class into another interface the clients expect I Facade Provides a uni ed interface to a set of interfaces in a subsystem I Template Method De nes the skeleton ofan algorithm in a method deferring some steps to subclasses I Iterator Provides away to access the elements of an agregate obiect sequentially I Compomte Allows compomng obiects into tree structures to represent partiwhole hierarchies umquot nrmnssnmuins Am Dwa nuilnlnnwlu x Still More Design Patterns Where39s the Strategy I State Encapsulates stateebased behav1ors and uses I Design Pn39nciples md Pattems are good Tactics delegation to decide which one to use I Motivated by code quality goals I But what strategy guides their application I Flyweight One instance ofa class provides many I HOW do we demde what code to Wtegt virtual instances I How do we go about wntingitgt I When and how do we apply demgn principles I Memento Returns an obect to one ofits previous and patternsgt states as for an Mala I Refactoring is one answer to last question I Software demgn methodologies address all Unwinslnnr lulnssanmsins Amman Dwamuilnlnnvulu m L mum nrmnssnmuins AM Dwamuilnlnnwlu Xusz Software Design Methodologies Extreme Programming I Many methodologies have been proposed I Very codeecentiic like code and fix I We summarized four representative examples 39 BUt imposes IDUCh more diSCipliIlei I Code and x I Pair programming I Waterfall I Continuous refactoring I Unit tests wntten before code untested code I Uni ed process does not exist testing is heavily automated 39 Etheme Progmg I Only build what is needed try not to anticipate future extensions no bOIIOVJlI ig trouble I Some evidence Applicable for small projects Uulvnslnnr lulnssaomsins Amman Dwamuilnlnnvulu m r i Ullvnsln nrl nssnmuins mm Dwamuilnlnnv u Xusz Thirteen Practices of XP Thirteen Practices of XP I Xhole Team I Pair Programming I Metaphor I TesteDriven Development I Planning Game I Design Improvement formerly Refactoiing I Simple Design I Collective Code Ownership I Small Releases I Continuous Integration I Client Tests I Sustainable Pace formerly 40 hour week I Coding Standards Uulvnslnnr lulnssaomsins Amman Dwamuilnlnnvulu m A r Ullvnsln nrl nssnmuins mm Dwamuilnlnnwlu Xusz Thirteen Practices of XP I Simple Design I System design always as simple as current level of functionality allows I No extraneous detail needed or allowed I Design only encompasses next iteration s added features I Cumbersome or unwieldy code 7gt refactor I OK1 but how do we felte on midwayz 9 Uulvnslnnr lulnssanmsins Amman Dwamuilnlnnvulu x Settling on Functionality CRC Analysis I ClasseResponsibiliterollaborator CRC model I Collection of standard index cards or electronic equivalent representing classes I Each card divided into three or more sections I Name of class at top of card I List ofresponsibilities on left I List of collaborators on right I Back of card for description of class I Public information on front private on back Uulvnslnnr lulnssanmsins Amman Dwamuilnlnnvulu x Settling on Functionality User Stories and CRC Analysis I Xhat functionality does the client want I User stories Capturing bits of demred function I Client s words restated on an index card I Example Checking Out Materials Each borrower may check out up to five items I Collection of stories constitutes requirements I Given requiremenE CRC analysis enables I Identifying and organiZing classes relevant to requirements mmquot nrmnssnmuins Am Dwamuilnlnnwlu x CRC Card Creating Classes I Based on user stories requirements I Identify classes needed for application I One approach find all nouns and 135 in the requirements I Nouns are candidates for classes I Verbs sugest their responsibilities I Brainstorm for candidate classes filter later I One card per class each assigned to one team member Uulvnslnnr lulnssanmsins Amman Dwamuilnlnnvulu x Example CRC Card Responsibilities Collaborators mmquot nrmnssnmuins Am Dwamuilnlnnwlu x CRC Card Adding Responsibilities I Attributes and operations relevant to class I Anything the class knows or does Ambler I Add responsibilities that are obvious to card I From name of class I From requirements I Scenarios stories will help to identify more later mmquot nrmnssnmuins Am Dwamuilnlnnwlu x CRC Card Adding Collaborations CRC Analys39 Scenario Execution I Scenario execution walkethrough of system function I Based on required functionality from user stories I Classes ful ll responsibilities in two way I Umng own operations to manipulate own attributes I Collaborating With other classes I Three generic relationships between classes I Normal Operauon rst the exceptional cases I ISPZIPOf hasiknowledgeiof dependsiupon I First decide which class responsible for function I Collaborator class name recorded on CRC card I er Ofthat C1255 Picks up card next to the responsibility that gave rise to it I So list of responsibilities and corresponding collaborations that enable them to be ful lled I While in air card is an obiect can do things I Card owner states need to ful ll responsibilities I May be ful lled by that class or another obiect I Otherwrse need to create anew class Uulvnslnnr lulnssaomsnvs Minus Dwamuilnlnnvulu m Ullvnsln nrmnssnmuins mm Dwamuilnlnnwlu Xusz CRC Analysis A Class Exercise CRC Analysis A Class Exercise I Requirements User Story summary I Support operations of a technical library I Identify candidate classes I Assign each to a group class member I Who makes a CRC card for it I Try some scenarios I User A one book out not overdue no unpaid ne want to borrow book X W what happensgt I User Areturns book X two days late I User B searches for book Y two copies available I User C searches for book Z database down I Searching for and lendingbooks videos Journals I Users enter their ID numbers to use system I Users enter material ID numbers to borrow return I Each user may borrow up to ve items at a time I Each type of item lent for different length of time I Fines of different amounts for overdue items I User eligible to borrow if fewer than ve currently borrowed items no overdue items or unaid nes Uulvnslnnr lulnssaomsnvs Minus Dwamuilnlnnvulu m Ullvnsln nrmnssnmuins mm Dwamuilnlnnwlu Xusz Class Exercise An Example CRC Card Class Exercise Proposed Classes Collaborators Uulvnslnnr lulnssaomsnvs Minus Dwamuilnlnnvulu m Ullvnsln nrmnssnmuins mm Dwamuilnlnnwlu Xusz CRC From Analysis to Design CRC From Analysis to Design I Strengths of CRC Analysis I Strengths of CRC Cards for design I Common proiect vocabulary 39 DESlgi IEVlEWS I Framework for implementation I Spreading domain knowledge I f m t u I n o no a on I Live prototyping identifies holes in requirements I Considerations during design phase I Target environment I Shift to design when all responsibilities in place I System description stable little change in cards I Language 39 Handling normal 93d exceptional 555mm I Choice ofsupporhng software components I Performance requirements I Secun etc New CRC Card Information to CRC Elements during Design Phase Record during Design Phase I Classes I Subresponsibilities I ClaSSES DEEdEd to make SYStEfD W013 commU35 I Break responmbilities into subresponsibilities exception hwdlers wrappers em I List them indented under IESPODSLlelty 39 scenarios and RESPOHSIb mes I Move collaborators next to subresponsibilities I Classobiect distinction blurry during analyms I Now think about obiects creationdestruction etc I Attributes I What information does obiect hold vs compute or request from othersgt I Record attributes found on back of card I Collaborating responsibilities I ldentify speci c collaborator responsibility used I Data passed I List data passed back by collaboratoi s responsibility next to it in parentheses Uulvnslnnr lulnssaomsins Amman Dwamuilnlnnvulu m ummm nrmnssnmuins mm Dwamuilnlnnwlu Xusz CRC Design Phase Activities I Revise cards I Based on demgn phase considerations I Adding classes responsibilities collaborators and attributes I Considering additional scenarios I Add new card infoiination I SUbIeSPODSlbllltieS collaborating responsibilities data passed I Reedo analysisrphase scenarios and add new ones I Taking designephase additions into account Uulvnslnnr lulnssaomsins Amman Dwamuilnlnnvulu m
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'