Outline for EECS 448 with Professor Niehaus at KU
Outline for EECS 448 with Professor Niehaus at KU
Popular in Course
Popular in Department
This 19 page Class Notes was uploaded by an elite notetaker on Friday February 6, 2015. The Class Notes belongs to a course at Kansas taught by a professor in Fall. Since its upload, it has received 27 views.
Reviews for Outline for EECS 448 with Professor Niehaus at KU
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
Dr Douglas Niehaus EECS 448 Overview Design Chapter 13 EECS 448 Dr Douglas Niehaus 2009 Some design techniques have a theoretical basis Many are pragmatic descriptions of what has worked for their inventors Very often generalizations of methods developed by practitioners through years of experience Some are manual and some use automated support for various activities One drawback of automation is that automated support makes assumptions about what kind of support you want Excellent when it matches your wishes Not so good when it does not EECS 448 3 Dr Douglas Niehaus 2009 Overview Transition from requirements and their analysis to software implementation Design must be capable of two things Satisfying the needs of the client as formulated during requirements extraction and analysis Assertions constraints UML class diagrams UML class interaction diagrams use cases Implementation as complete operational and correct object oriented software implementation Design techniques are varied Hundreds over the last 40 years A few used by many thousands and a few only by their authors EECS 448 2 Dr Douglas Niehaus 2009 Overview Strong tendencies across many methods Operationoriented design Emphasis on operations eg Data flow analysis Dataoriented design Emphasis on data eg Jackson s Technique Objectoriented design Combination of both data and operations Roughly equal weight to operations and data EECS 448 4 Dr Douglas Niehaus 2009 Design and Abstraction Design and Abstraction Design Process Input specification of what a product should do Output design describing how a product doing it can be built Classical approach to design contains 3 activities 1Architectural Design Also called general logical or highlevel design Modular decomposition of the product Output list of modules and their interactions 2Detailed design Also called modular physical or lowlevel Each module designed in detail EECS 44B 5 Dr Douglas Niehaus 2009 Data Flow Analysis 3 Design Testing Still inspection driven as there is nothin executable but clearly usecases provi e a detailed framework within which to evaluate design Operation Oriented Design Product is decomposed into modules with high cohesion and low coupling Data flow analysis and transaction analysis are practical techniques for achieving this Good 00 orientation in design is an excellent way to achieve this in most cases Objects provide excellent encapsulation and publish data and method access only as required EECS 44B 6 Dr Douglas Niehaus 2009 Data Flow Analysis DFA is a classical design technique for describing a problem solution in terms of modules exhibiting high cohesion Can be used in conjunction with most analysis methods so it is not usually exclusive Input to DFA is a data flow diagram DFD Begins with point of highest input and output abstraction Describes transition point from input to internal data structures and from internal DS to output Product described at highest level of abstraction in 3 modules Input Data Transform Output EECS 44B 7 Dr Douglas Niehaus 2009 Refinement of three toplevel modules continues until each module defined for the product is performing a single well defined data transformation that is easy to implement DFA generally results in modules with high cohesion DFA does not take module coupling into account Sometimes a painful oversight Minor modifications can be required or helpful in reducing coupling amount or badness Eg modify modules so that data is passed between them not just control Consider a word counting example EECS 44B 8 Dr Douglas Niehaus 2009 Data Flow Analysis Data Flow Analysis Iterative refinement pipeline data flow SW arch 39quotE quotiEt W input module Lramlorm module I output module PuinL Di Point of highest abstraction highest abstraction of input of output EECS 44a 9 Dr Douglas Niehaus 2009 Design and Abstraction 39IleA val dared vDrd lormalled dairei raid rams wg ate liename count tum term word dismanluumur e e Illa l name rameJ Mme number word Ward J ktwordsJ count J quotum L mum It pttl toilet 7 OulJuL hum Irma F ol39il or Point or highest abstraclicn higheit abstracton ul i pul d autuut 5525 44a 10 Dr Douglas Niehaus 2009 Design and Abstraction Refactor component pipeline stages into generic inputtransformoutput decomposition perfomL word statusflag mum validatecL f n me name wordicount 7 I validated word quot filena me v COUnI readand count fo rmat validate numberof anddisplay filename words wordcount gt gt Data 0 Control EECS 448 11 Dr Douglas Niehaus 2M9 Further elaboration of initial refactoring produces subordinate modules perluruL word stalusjlag cum validatett n c filename mndarmi wad wordcoun r r iilename QquH count get 7 product numberioL Input words output C r r A tormaued me name le name status rlag word count formatted wcrimum word count t read validate fortrat display file file word ward name name count count 0 Data t gt Control 5525 443 12 Dr Douglas Niehaus 2009 Design and Abstraction Detailed Design Architectural design lays out the higherlevel logic Lower level details await detailed design Lower level details can be crucially important Unpleasant surprises relating to data access and use can motivate refactoring designs Less frequent with experience Detailed Design Determines data structures and algorithms Detailed design of each module is largely independent of others High cohesion and low coupling Likely to be implemented by different programmers EECS 44B 13 Dr Douglas Niehaus 2009 Detailed Design Design can be largely independent of the programming language but at this level of detail target language can have a significant influence Dictionaries in Python make organizing some kinds of information simple Similar design targeting C would require library support or Significantly more programming In general whether a target language is known or not pseudocode more officially known as Program Description Language PDL is the best way to describe a detailed design and algorithms f target language is known PDL can be comments connected by control statements in target language EECS 44B 14 Dr Douglas Niehaus 2009 Detailed Design Advantage of pseudocode is that it is generally clear and concise Close enough to an implementation language that relatively few details can be left out and thus left ambiguous during implementation Implementation step Translating PDL into a programming language Filling in details Data Types structure definitions additional mechanisms such as counters and pointers Mismatch of PDL and target language semantics can add levels of confusion EECS 44B 15 Dr Douglas Niehaus 2009 Weakness of PDLpseudocode is that designers tend to go into too much detail Closer to code implementation than PDL design description After the detailed design is documented and tested it is handed over to the implementation team for coding EECS 44B 16 Dr Douglas Niehaus 2009 Detailed Design Standard specification template for modules often reflected in standard comments for each module Module narre Mutl tie type Return type input arguments Output arguments hr39or messages File guessqu Flies mange Modules called lan39atrvp EECS 448 readifile ame Function string None None None Nme Nu lt None The a aduct iS invoked by toe user by means of the Cumilln39id 3U mg word count ltfileinamegt Usin an ooerating sySien all this module 305865 the Luliluztl39 the rrm rnand string input by tl e t ser extracts ltle7namegt and returns it as Utt w tie ir39 rlie muduic 17 Dr Douglas Niehaus 209 Detailed Design High level assertions about what a module does remain in others as how to count the words involves many details Module name Moduli type Returr type lnpu arguments Output arguments Error messages Files accessed cilcs changed aniults ca led N lldilvt39 EECS 448 countnumbernl7wn rds Funct on integer validatedjileiname string lonc ltm L None None None This module determines Wi39m39lcf valldatedjilegname is a text tile that is divided into lines of charar39e s It sir tin module returns the number or Wolds in the text tile otherwise the module vellum 39l 19 Dr Douglas Niehaus 209 Detailed Design Some detailed designs are quite simple because they correspond strongly to basic capabilities of the support framework Eg checking files for existence and permissions Module name Murillie type Return type input arguments Output arguments Error mcssages Files ELIESXHi Hin Llianqed Modules called Narrative EECS 448 validatei le ame Function Boolean file name string None None None None None This module makes an tl39lijlillg s stem call to determine whetherfila file name DXiSiSTi1F module reurrs true if the file exists and false otherwise 18 Dr Douglas Niehaus 2009 Detailed Design Module coupling is noted for higherlevel components EECS 448 Module name Module type RELLJ39I type Input argumunls Output arguments Error messages l39iles accessed Files changed Mouules called Narrative producemitput Func on void wordicount integer None None Ntme None formatwordtuunl arguments wordcount integer formattedwnrdcount string displayiword munt arguments formattedwordcount string The module take the integer wordicount passed r0 it by tlit tuiing module and calls forn1atwordgmunt u have that integerformatted an ording to the specifications Then it tells display wordicount to Have the lint printed 20 Dr Douglas Niehaus 2009 Detailed Design PDL assume Cish target language How different if Python target assumed void performiwordicomlo String validate fileiname int wordgcounl if getiinput validatejileiname 12v false prim error 1 file does not existquot else i set word count Lilnu a mJntinnmheLanordls validatefiename if wordicount ix Uzllu m i pl lill error 2 file is not a text file else produceoutput wordcount l EECS 448 21 Dr Douglas Niehaus 2009 Detailed Design There can be multiple input and output streams in many applications Easier to manage them separately although in principle data can often be combined in structures Find the point of highest abstraction along each input and output stream Decompose the data flow diagram into modules with fewer or simpler IO streams than in the original diagram using these points of abstraction Continue until each resulting module has high cohesion May require backtracking to refactor earlier decisions in some cases Consider coupling and retry refactoring if coupling is too high or of disturbing types EECS 448 Dr Douglas Niehaus 2009 Detailed Design Some PDL statements impy more target language work than others readfiename vs validatefiename Is separation of format and display of word count necessary A generally good idea Boolean geLinpu String validate file name i void displayyvo39dJouI39L Strirg formatted word ounl Stung fileiname prim im inrdAWnli LCC ilnt drumfwd file name read llltr llllt I if validate file fame filejame is rue smng formatiwcrdAcnunr Int wmu mini mva dalejllemarremrunfm lile name 39 39m39 I return quotFile contains word count words i l else return false 1 EECS 448 22 Dr Douglas Niehaus 2009 Detailed Design IO structure is often fairly complex with multiple source of input andor output Same principles apply a find point of highest IO abstraction for module decomposition i4 dogQ 3 Q 04 EECS 448 24 Dr Douglas Niehaus 2009 Transaction Analysis Transaction Analysis Transaction analysis is appropriate for the important sub class of application that are transaction oriented A number of related actions are performed on data as part of a transaction A transaction is usually atomicfrom the user s p0lnt of View Atomic all or nothing Operations in transaction based systems are similar outline but different in detail Transaction systems Automatic Teller Machine Ticket purchase kiosk on line purchase at Amazon LL Bean etc EEcs ME 25 Dr Douglas Mlenaus 2009 Transaction Analysis How to perform transaction analysis Design the architecture in terms of two components Analyzer Determines transaction type Dispatcher Performs designated transaction For each set of related operations Design one basic module embodying common components of performing all transactions Instantiatelnherit from it as many times as necessary to implement each transaction Transactions strongly foster encapsulation and decomposition Atomic commitabort support palt of this EEcs ME 26 Dr Douglas Mlenaus 2009 DataOriented Design Strong parallel structure and encapsulation based on transaction type is common in such applications dltz x l lmnsuninn 9 update wanle lllev P Bf li updale 39 7 a ram 767W b 39 7 1 raw arm aquot I gmn Y 7 anvrlinnj gnud k update J M d39lr Wfileiloz trans l3 lranst llle x Informatan and an r V L3 T i 7 VJ M WNW V d39 W P a quot swd update s mom aha m at 4 J A updaler file determine ransamon tram L wt l 33132 9mquot r Vans 5 L5 EEcs ME 27 Dr Douglas Mlenaus 2009 This approach emphasizes the structure of the data upon which the product operates in determining the structure of the product Some developed early on in computer technology development and several techniques named after their inventors were developed Jackson Warnier Orr Generalization as Data oriented came later Data oriented design was never as popular as operation oriented design Data oriented design has become less popular as Object Oriented design has gained in popularity EEcs 448 2 Dr Douglas Mlenaus 2009 Data Oriented Design Data Oriented Design Jackson System Development Based on realworld modelling Created by Michael Jackson 1983 Sold as seminars for many years Graphical and textual notation for describing SW Products are built out of actions and action connections operating on data Data Streams an action sends a stream of data to another action State Vectors an action inspects the state vector of another action EECS 44B 29 Dr Douglas Niehaus 2009 Data Oriented Design Jackson Development System Steps 1 Entity Action entities and actions are listed 2Entity Structure actions are displayed 3lnitial Model entities and actions displayed mapping between the model and realworld 4Function Functions are specified 5Product Timing time constraints of product are specified 6lmplementation mapping actions to processors Basic dataFlow model created through individual insight before a more general DataFlow model became popularized EECS 44B 30 Dr Douglas Niehaus 2009 ObjectOriented Design Warnier Structure of action should be the same as that of the data Hierarchical diagrams describing product structure Orr Extension of Warnier EECS 44B 31 Dr Douglas Niehaus 2009 As with any design method ObjectOriented Design OOD uses a theme to organize the design process Objects are the theme in this case obviously Objects are instantiations of classes extracted during objectoriented analysis Some classes are abstract and not instantiated Obg39ectoriented languages explicitly support class de inition and object instantiation OOD can in principle still be used in nonOO languages by defining ADTs Somewhat tedious and conventionbased OO langua es Smalltalk C Eiffel Java Ada95 Python Ru y EECS 44B 32 Dr Douglas Niehaus 2009 ObjectOriented Design ObjectOriented Design Two key steps of COD Assign methods to classes Complete class diagram Methods are specific implementations of perform detailed design classmodule operations specified during analysis workflow 39 completmg Class D39agram Correspond to interactions within interaction 39 MethOds are assigned to releVant Classes Could be determined earlier but again each Format of attributes is deduced from analysis iteration would require changes artifacts Specifying these as late as possible is generally Could be added to class diagram during analysis eaSIeS E and most effICIent I I workflow but not necessary and Methods of classes support specrerd class Each iteration would result in changes 39nteraCtlons I I I Thus easier to add attribute format to UML as late 39 SorTI e flex39bgjl39ty 39nhhohw rlnany methOds are as possible in design process imp emente In w IC c asses to support an Interaction EECS44B 33 Dr Douglas Niehaus 2009 EECS44B 34 Dr Douglas Niehaus 2009 ObjectOriented Design ObjectOriented Design Each use of a method has two contexts Three principles helpful in guiding action placement Calling client of the object requesting service 1 Information Hiding Called object context available to called method 2 Number of ActionObject Clients Some work of a product is often best expressed 3 ResponsibilityDriven design using a function rather than a class method lnformation Hiding Embodies logic that lies outside any obvious State Variables of an Object should be product objects Some languages essentially require definin objects for all contexts Java but that can 0 scure the logic of the product in some cases Constant global goal is to express product semantics as clearly as possible Private accessible only within an object of a specific class Protected accessible only within a specific class or subclass Operations on or using state variables must be local to that class EECS 44B 35 Dr Douglas Niehaus 2009 EECS 44B 36 Dr Douglas Niehaus 2009 ObjectOriented Design ObjectOriented Design Elevators Number of ActionObject Clients Step 1 Complete the class diagram 39 if a particular action on a particular Object is Design workflow class diagram is obtained from Invoked by more than one client an Analysis workflow class diagram by adding Strong indication that action should be a method methods Otherwise separate clients would Generallyz methods are assigned using I Invoke a common function accessing the object responSI liltY39deren des39Q supplemented With the Different clients would implement parallel code prinCipie 0f information hiding ResponsibiityDriven Design cIoseDoors and openDoors methods assigned to If a client sends a message to an object then EIeVatOrDOOrS Class for example Receiving object is responsible for satisfying 39 RequeStlbeinlg Performed by the Class I service request contained in the message Information hIdIng of door control Information Client does not know how service is performed Control returned to client on completion EECS 44B 37 Dr Douglas Niehaus 2009 EECS 44B 38 Dr Douglas Niehaus 2009 ObjectOriented Design Elevators ObjectOriented Design Elevators moveDownOneFIoor and moveUpOneFIoor methods turnOffButton and turnOnButton are declared assigned to Elevator Class abstract methods of Button Class No need for an explicitlinstruction to stop if neither Making use of dynamic binding and polymorphism 0f its two methOds are 39nVOked At runtime correct method of called object will be Might this result in jerkyslow movement invoked Perhaps setDestinationFIoor might be easier to Detailed Class Design use in the case of an elevator already in motion Design of each Class is developed in detail turnOffButton and turnOnButton methods assigned to Any suitable method can be used both EIevatorButton and FIoorButton Responsibilitydriven design buttons control onoff Information hiding Button state variable private May also need getEuttonState method Dr Douglas Niehaus 2009 EECS 44B 40 Dr Douglas Niehaus 2009 Stepwise refinement PDL or tabular representation PDL constructed from statechart Also class interaction diagrams EECS 448 ObjectOriented Design Elevators Methods assigned to classes ElevatovAppllutlolI Button l ElevaturUtlll es l l llllmlnatedzlmlenn l tumulllsullun ammo lumOnBuuun abstract i levnoraunon rlonrnunon turnOffEuum turnC Buuon ulmnrlilluol lllmDn Butan mnl Pm e 7 will mix rm39mh 39 ElevatorController Elavatorhaors nnro3 reuueslsnequemrpe i thchuasb updalBRequesls surmmer n doolsopeu booleall closeDcors openDoorx Elevalnr 1 mownuwnmenwr mowUpOneHnor EECS 448 41 Dr Douglas Niehaus 2009 00 Design Art Dealer Step 1 complete the class diagram Final class diagram contains a dashed Date class because it was needed in C but not in Java Java had builtin classes for dates Python has datetime module Formats for class attributes are deduced from the requirements Methods appear as actions in various interaction diagrams Designer decides which actions correspond to which methods associated with which classes EECS 448 43 Dr Douglas Niehaus 2009 ObjectOriented Design Elevators void slash 39Z Il llLLUOP voldj l else if elevator is Imumg down whlle TRUE lumillll n on Law else if elevator n mum Hz J y when n lbIrI39iig l I l w mil fE1MD l1 e r elevatnl DaogzxoseDcors If Ibutton rt lfrflm utm l upliateREquuzh buttgutrn0nls mun l eleyeatormovel else if elevator I l m and not maven r else if elevator l quot74 ring up M i 39C MEDCD else y rweuwww 1mm elevat w l l l u mt w l If mm M U mmV wan N quot th n v on pm my lggvamrbo u I ur a plevalurrznnox sLpOneFIDOr l else i ml elevatpl law a tritium nh u lzg H mm elevalleroor522CenDQOrS startTlmel39 it elLatgLButton l w QIEVEIIOI39BHEIDQTIDJl an Bll l39lli chntchrlucsts l l EECS 448 42 Dr Douglas Niehaus 2009 00 Design Art Dealer Step 2 Detailed Design Consider each method in each class and determine what it does PDL in general or for target language if known EECS 448 44 Dr Douglas Niehaus 2009 00 Design Art Dealer f omen Dglethy r0 Oxbul aquiy 7 um lllllnlulh Applknlml am an gt lt i l Cnmpiln umpul ovnpull Compul mmmm Mannpix Fulure onquot mumlg mu ms Mquot mu mum um mu mm mmm quotmum mum mquotg an 0 am Lm raining hm Pdnllng CI 0 0 O sale Purchuu hmquot end hshlunhlllly um napm nepun Report class In class EECS 448 45 Dr Douglas Niehaus 2009 00 Design Art Dealer oat ComputeMasterpiecei cet etAlgoritan rice Calleryr aintinq must masterpicce Jewrva rm mmmmmpz39iuz In 395 Lizzur djm v n mpmw xfu39 wv that higw float algl Iigh float hig lDale oat Irmp lugwry MIMIAll f w 1 m1 warl dam a mlr39imi af39nwst wmi ur w yuccamosh quotmu7N nIlmn39hm ml medium m 1igh I u 00 w ngHigl mm H 00 l nigl39lDalr will m mayquot mw 1W nilm m Manny39qu om mm the mm sauna wk 1 am l for mu n m v39jl 39ll squot temp equal r 00 I39 IIIL39VL39 n 39 m 39IrstName wrastName m m Me gmilarv39rv as u39l mws39 l EEcs 443 47 Dr Douglas Niehaus 2009 00 Design Art Dealer mm 09MB AyylkIlcn a umm a lamxananlkriy 21 m r v 5mm mt Mg whim diam mmum hm iced mun Gallery Dalling In aluminium lDrMu imamquot mmquot mm mm 1w wznvvx nvPmamlnm 2mm a mm m We Immune mg imam lDLluu quotimam 4m mmmngm m mam PImllg um uduliDalt39WLhn mm x m Manarplx a mm Filming um yummynun lt1 w mama muvm mmmoum mum mammal v mm Mixtemarl 1m EECS 448 46 Dr Douglas Niehaus 2009 00 Design Art Dealer If llVl39 it u mum nu mpdiilm 1 n Lama if f39mt39 iv a mun n on sublect er i m tern gr39lllu Ill39t39tllJtwr nmlzm m39liy39llb39lugW heightMr widt39i rimlip Le39np by 1 m qr lurgu painting divide by mt rzfumleyummg if eITu l gwum 11 high l W l9mp n ln hinn L Id i L m wallamm mm Vi 4 1 1 M Ingleale Luqu m 1qu 1 m Mug 1 cu in lmmxrvitu mum uxoluum fur r rgt high 7 nmin plquot lgHigh fry l 085 return algH g 39CompuleAasteroiecel rice getAlgc39ithmPrl e a rim EECS 448 48 Dr Douglas Niehaus 2009 00 Design Art Dealer Design WorkFlow float CompuleMasleMorkI ricegemlgorilhmPrice GalleryParnling39 cons masterwork rlcmmiuv my unmimirm ivn 390 Iu umu fur u masterwork airarmor in century mimry m Irhulrpummrg nm39 femur uat masterpiecep ie pm wa Imiuir39ng um unmetVim m unnprm Ilrr m39w u m Ivtiilrli39ng m r r wu n ma r u inuslcrpichPrict Cu39npuluMdslcrpieLcl nLu clAlgurllhml rice maslerwurk Imu nlimm 1 enlury m mm m pumlinlu um I39mllwl umlnn nx39l Iwii39izrgt Imch mi Im munu m39 atmuquot 1 Century H mm m 21 return masierpiecei rice 025 else return masterpiecel rice quot 2 7 century22 7 century lComputeMasierworkPricexgetAIgorilhmPrize EECS us as Dr coughs menaus 2009 Design WorkFlow Input to the Design WF is Analysis WF artifacts During design WF analysis artifacts may need to be iterated and refined until they can be translated into design artifacts that can be used by programmers Two ObjectOriented Design OOD component of the design workflow Identification of methods and their allocation to appropriate classes Perform the detailed design Many other decisions lie outside OOD Selection of programming language How much of existing products to use Portability targets ms us 50 Dr coughs Mlelais 2009 Design WorkFlow Allocation of software components to hardware components For large applications on distributed platforms in a network Major motivation behind Unified Process Methodology for developing largescale products 500K lines of code or more Many aspects are not applicable to small products Important part of Analysis WF is partition of product into analysis packages Each package is a set of related classes Relevant to a small set of actors Can be implemented as a single unit EECS us 51 Dr coughs menaus 2009 General idea of taking large workflows and decomposing them into smaller workflows Applied to Design WF as all others Objective is to break implementation workflow into manageable subsystems Low coupling and highcohesion Relativer independent and thus relatively amenable to independent implementation Easierto implement a number of smaller subsystems than one large system Independent subsystems can be implemented by programming teams working in parallel Parallelism can speed product completion ms us 52 Dr coughs Mlelais 2009 Design WorkFlow Design WorkFlow Architecture of the product addresses set of Architecture must permit product creation within cost components and how they fit together and time constraints Major part of architectural task is assigning Design problem is almost always overconstrained components to SUbSyStemS Impossible to satisfy all constraints in practice Individual specialists often called software Schedule slipsI cost overrunsI feature cuts architects or analysts often produce architecture Software architect Technical Expert with extensive experience CompromiseIs are common in architecture and schedule revrsion as a proiect progresses Clients may relax some requirements increase Must know how to make tradeoffs I buddetI ease deadlines Must ensure arch satisfies functional requrrements Architect must assist Client and developers by 39 use cases I I I clearly mapping out tradeoffs and contingencies 39 MUSt ensttte arch Set39St39es non39tunCt39onat reg Eg Pointing out that satisf ing requirement X Portability reliability performance security etc might cost an extra 2 mont s EECS 44B 53 Dr Douglas Niehaus 2009 EECS 44B 54 Dr Douglas Niehaus 2009 Design WorkFlow Test WorkFlow Design Architecture has a vital role in determining if a Goal of testing the design is product is a success or failure To verify spIecifications have been accurately and Importance increases with product scale completely Incorporated Into the oeSIIgn pro uced provideS global View and guide to component To ensure correctness of the design Itself relations as well as guiding tradeoffs DesIgn should be complete Critical architecture decisions are made during 39 DeSIQn SnOUId naVe no toglcat taUttS Design WF All Interfaces must be correctly and completely If architecture is inferior it can be difficulty for a de ned I project to recover DeSIgnIfaults may be detected through design Architecture may need to be redesigned which is 39nspeCt39ons and des39gn Walk39throughs usually very expensive May also be detected by difficulty during im Iementation 39 Important that a proteCt team mCIUde and arChlteCt DifficElt for nontechnical people to understand Technical expertise and human relation skills design documents EECS 44B 55 Dr Douglas Niehaus 2009 EECS 44B 56 Dr Douglas Niehaus 2009 Test WorkFlow Design Formal Techniques Design inspection should reflect transaction Formal techniques applied to detailed design can orientation of transaction based designs help in 3 ways Consider all transaction types State of the art in correctness proofs is that they Specificationdriven inspections are always essential are appl39cab39e to mOdU39e39s39Zed components Goal is to ensure that no statement of specification 39 Geger lly quotQt yet able to scale up to a WhOIe document has been either overlooked or pro UC misinterpreted ObVIously context dependent Developing a proof in parallel with detailed design generally leads to design with fewer faults Two parallel views of same problem Increases programmer confidence if they are also responsible for the design Confident that design is correct EECS 44B 57 Dr Douglas Niehaus 2009 EECS 44B 58 Dr Douglas Niehaus 2009 Design Method Comparisons Design Method Comparisons Topdown vs BottomUp Maintenance Dataflow analysis is topdown decompostional Jackson s method is not maintenance oriented Jackson s method is bottomup compositional Dataflow analysis has advantages Combination of both sandwich technique is often GOD is strongly recommended for maintainability stronger Reuse Proofofconcept or actual module implementation for components designers are sure will be needed is bottomup DataFIOW of OO topdown decompositional Overall GOD IS the state of the art With advantages over other approaches approach elaborates components and tries to S connect to bottomup components 39 urp39se surpnse surprlse Adaptations obviously required from both sides to create final design EECS 448 59 Dataflow and OOD have an advantage over Jackson s method Dr Douglas Niehaus 2009 EECS 44B 60 Dr Douglas Niehaus 2009 Design Method Comparisons Design Method Comparisons RealTime Design techniques Wide range of uses of the term realtimequot with widely varying semantics all of which are Valid Importantly different from each other Key point is that a traditionally nonfunctional requirement is made a functional requirement Performance When the answer is produced is part of its correctness Failure to meet deadline constraints means something bad happens Data lost machines damaged people die EECS 448 61 Dr Douglas Niehaus 2009 RealTime Design Often implemented on embedded hardware Not always and increasingly desktop laptop PDA and cellphones all include realtime applications Music video games Often distributed Communication and timing issues are key Concurrency control Communicating components Multiple threads Semaphores deadlock starvation EECS 678 First class design goal is ensuring all timing constraints are met Averagecase vs Worst Case EECS 44B 62 RealTime Design Dr Douglas Niehaus 2009 All parts of conventional computers are designed with respect to optimizing average case performance Most money drives this Realtime computations require guarantees of completion under all possible conditions Even in the worst case Knowing what all possible cases are is required Which is worst case with respect to which criteria Proofs of correctness of desired but difficult to do Proofs of deadlockfree designs Realtime is precise control and predictable behavior Not Fast or AsFastAsPossible EECS 44B 63 Dr Douglas Niehaus 2009 Hardware design technology generally stronger formally than software Convincing HW designers to consider worstcase Ratemonotonic analysis Wide range of scheduling semantics is really hard Hugely different from average case designs in many cases Vastly smaller market than average case Many advances in theory of realtime systems Specialized system SW emphasizing predictability Linux RTpatch components moving into mainline EECS 44B 64 Dr Douglas Niehaus 2009 CASE Tools for Design CASE Tools for Design CASE tools exist to support Design WF as for all Many design CASE tools incorporate screen and others report generators Integration of requirements analysis and design Some incorporate management tools for estimation workflows is particularly attractive and planning Popular tools include Some tools support design within a set of tools AnaystDesigner supporting the entire 00 SW life cycle Software through Pictures Together System Architect Rose Generally built around a data dictionary Software through pictures Many incorporate consistency checkers ArgoUML open source CASE Tool Uses DD determines if every item in DD has been declared in specifications and if every item in specifications is in DD EECS 44B 65 Dr Douglas Niehaus 2009 EECS 44B 66 Dr Douglas Niehaus 2009 Metrics for Design Metrics for Design A variety of metrics can be used to describe various Lower values of M are better aSPeCtS 0f des39Q Huge variance in applications of what the lowest Eg The number of artifacts modules or classes vaue of M might be could be used as a measure of product size Cohesion and coupling can be quantified and are 39 Not a deCisions are binary correlated to quality 0 design Some flavour of using what can be measured Expectations to very rule and every numeric because It can be measured threShOId Strength easy to compute Fault statistics can measure reliability of methods How far the implications of a fault reach is a 39 weakness Data compleX39ty Is Ignored measure of its seriousness For example convert ASCII to char Cyclomatic complexity M of a detailed design 128 way branch using switch M 128 Number of binary decisions Array lookup M 1 Number of branches in a code artifact Equrvalent functionality EECS 44B 67 Dr Douglas Niehaus 2009 EECS 44B 68 Dr Douglas Niehaus 2009 Metrics for Design In classical design data flow among modules used Modules represented by nodes Flows among modules procedure calls represented by arcs Computation Fanin and fanout of modules Number of flows in plus number of global DS usedupdate by module Length size of the module Complexity length fanin fanout2 Experimentally no better than cyclomatic complexity in predicting design quality Usually low for classes ignores data complexity EECS 44B 69 Dr Douglas Niehaus 2009 Challenges of Design WorkFlow Design is hard Least mechanical or systematized aspect of software life cycle Different people do it differently Creativity hard to formalize Often intuitive Experience helps with ability to create arguments for a design after the creative impulse Collecting good questions is an excellent way to collect important design issues Formulating good questions creative and hard Highly productive SW designers are rare and precious also very hard to create EECS 44B 71 Dr Douglas Niehaus 2009 Metrics for Design Number of ancestors for a class Some measure of product complexity as it is correlated to number of classes and complexity of relations among them Dynamic binding more complex than static Some languages support hierarchy flattening FLAT command in Eiffel prints text of a class incorporating all inherited features SWE continue to search for metrics that support meaningful and accurate predictions of SW lifecycle experience and software quality EECS 448 Still an elusive goal 70 Dr Douglas Niehaus 2009 Challenges of Design WorkFlow Two major sources of error in Design WF Doing too much Crossing border into coding Very common when designer will also be coders Doing too little Leaving important design issues to implementation step Not uncommon Rarity of great designers Some are obviously much much better than most Great designer on a team single most important EECS 44B factor in product success Using their great designs is second 72 Dr Douglas Niehaus 2009 Challenges of Design WorkFlow Conclusions Growing great designers is a huge challenge Design is the single most crucial SW lifecycle work Smart organizations flow Identify them early Least easy to do according to procedure Assign a mentor Cruclially depends on creativity and input from Provide with formal education and apprenticeship requ39rements and analys39s work39 ows with great designers Abilit to comparecontrast advantages and Specific career path should be available disa vantages of various proposed designs crucial They should be richly rewarded Verbal skill not normally considered relevant to computer programming But it is OOD current state of the art but dataflow and transaction oriented methods can give insight EECS 44B 73 Dr Douglas Niehaus 2009 EECS 44B 74 Dr Douglas Niehaus 2009
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'