Software Engineering I
Software Engineering I EECS 448
Popular in Course
Popular in Elect Engr & Computer Science
verified elite notetaker
This 19 page Class Notes was uploaded by Melissa Metz on Monday September 7, 2015. The Class Notes belongs to EECS 448 at Kansas taught by Doug Niehaus in Fall. Since its upload, it has received 41 views. For similar materials see /class/186783/eecs-448-kansas in Elect Engr & Computer Science at Kansas.
Reviews for Software Engineering I
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: 09/07/15
Design Chapter 13 EECS 448 Dr Douglas Niehaus EECS 448 1 Dr Douglas Niehaus 2009 Overview 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 modu es 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 39quot ElEEJ W hrmatted claimL ormgL wunL dlsP39rSY uumui war we count mum ltoum Ouuut hum hem II pm tulme input module Lramform module output module 7 rm 39Ile val dated mm marL rm wlidate lienArne coon I l T O t gt me rile n U u U name name 7 quot 697 j 39 Fol39ll Or Poll of highest abstracticn higheit abstracton Point Di Point of U39i Pul d ul highest abstraction highest abstraction of input of output 5525 443 9 Dr Douglas Niehaus 2009 5525 443 10 Dr Douglas Niehaus 2009 Design and Abstraction Design and Abstraction Refactor component pipeline stages into generic Further elaboration of initial refactoring produces inputtransformoutput decomposition subordinate modules perrunu W0 performg word validated fi lein a m e L validated filena me J wicount format anddisplay wordcount I word Count v readand validate filename iormaued word count display 392 A word name count 0 Data 0 Control EECS 448 11 Dr Douglas Niehaus 209 EECS 448 12 Dr Douglas Niehaus 2009 word 7 0 le name status Iag word count formatted r wordcount validate file Detailed Design Design and Abstraction Architectural design lays out the higherlevel logic Design can be largely independent of the I Lower level details await detailed design programming language bUt 3i this ieVei 0f detail Lower level details can be crucially important target iangulag can have a S39gn39f39cant influence Unpleasant surprises relating to data access 39 D39Ctionat39es in Python make organizmg some and use can motivate refactoring designs kinds 0f information Simple Less frequent with experience Similar design targeting C would require library support or Significantly more programming 39 Detalled Des39gn In general whether a target language is known or 39 Determines data StrUCtures and algorithms not pseudocode more officially known as Program 39 Detailed deSign Of eaCh module is largely Description Language PDL is the best way to Independent 0f Others describe a detailed design and algorithms High cohesion and low coupling f target language is known PDL can be comments Likely to be implemented by different connected by control statements in target language programmers Dr Douglas Nrehaus 2009 EECS 448 13 Dr Douglas Niehaus 2009 EECS 44B 14 Detailed Design Detailed Design Advantage of pseudocode is that it is generally clear Weakness of PDLpseudocode is that designers and concise tend to go into too much detail Close enough to an implementation language that Closer to code implementation than PDL design relatively few details can be left out and thus left description ambiguous during implementation After the detailed design is documented and tested it is handed over to the implementation team for coding 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 448 Dr Douglas Niehaus 2009 EECS 448 Dr Douglas Niehaus 2009 Detailed Design Standard specification template for modules often reflected in standard comments for each module Mamie name Return ty 0 input arguments Output arguments hror messang File duoqu Files Changed Modules called lan39ativp EECS 448 readvfile ame Furcrion tiring No we The a39nducr is invoked by tne user by means of the Lumiim39id 3 ing wordAcount ltfileAnamegt Usiwq an ooerating systerr cal this module accesses the writmr the rrmrnand strinq input by ti e L ser extracrs tile7namegtr and returns it as the ya tie at rile duic 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 tyne Returr type lnpu arguments Outpu arguments Error messages Files accessed Cilcs changed Mnriulcs called N lidllVL39 EECS 448 countnumbernliwnrds Funct on integer validatedjileiname 1 string ionc lmiL Nor None None Tl is module detennines Wi L t39iIZY validatedjileiname is a text file that is divided into lines of chararre r If 5171 the module returns the number 07 Words W the text tile otherwise the module vellum 39i 19 Dr Douglas Niehaus 2M9 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 Moduiu name Murlliie type Return type input arguments Output argumcnts Error mcssages i t lies 3LHl P Lhanqed Modules called Narrative EECS 448 validatei ie ame Function Boolean file name string None None None This module makes an upt39raling system call to derermire whether ile file name exists Tim module returns true if the file exists ard 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 argumcnls Output arguments Error message l39iles accessed Files changed MUULIIES called Narrative producenutput Func on void wordicount integer None None NLNIE None formatworduunl arguments wordccunt inte er formatteernrrLtount string displaywordcuunt arguments formattedwordcount string The rr mc uie takes the integer wordicount passed r0 it by iIiL Luiing module and Calls formatwordgmunt u have that integertormahed art ording to thc specitizatiom Then ll La display Wordicount to have the lint printe s 20 Dr Douglas Niehaus 2009 Detailed Design PDL assume Cish target language How different if Python target assumed void performiwordicomto String validate fileiname int wordAcounl if getiinput validatejileiname ix false prim quoterror 1 file does not existquot else i set word count mqu m OlJntinllthLOLWOFdS validatefilename if wordicount ix equal In 4 pl39llll quoterror 2 file is not a text file else produceoutput wordcount l EECS 448 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 getinpu String validate file name i void displaijo39dioul39t Strlrg formatted word ounl Stung iiieiname gt pl39flii mwmrriwnlicmmt hrultu wd file name read llltJ killlt I if validate file Fame fileiname is rue mva dalefllenarremguufm file name return true Stung fomatiwordgcuunr Int wmllt mini return quotFile contains word Counl quotwordsquot e 52 return false EECS 448 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 i OC 01 i2 3 5X osciox xm i 3X O 4 04 O 5 EECS 448 Dr Douglas Niehaus 2009 Transaction Analysis Transaction Analysis Transaction analysis is appropriate for the important How to perform transaction analysis sub class of application that are transaction oriented Design the architecture in terms of two A number of relatedactions are performed on data components as part of a transaction Analyzer Determines transaction type A transaction is usually atomicfrom the user s Dispatcher Performs designated transaction po39nt 0f Y39W For each set of related operations 39 Atom39c a or Oth39rlg Design one basic module embodying common Operations In transaction based systems are components of performing all transactions S39m39lar OUtl39ne bUt d39fferent 39 deta39 Instantiatelnherit from it as many times as Transaction systems necessary to implement each transaction Automatic Teller Machine Ticket purchase kiosk Transactions strongly foster encapsulation and on line purchase at Amazon LL Bean etc decomposition Atomic commitabort support part of this EE AAE 25 Dr Douglas Nlehans2009 EECS ME 26 Dr Douglas Nlehans2w9 Transaction Analysis DataOriented Design Strong parallel structure and encapsulation based on This approach emphasizes the structure of the data transaction type is common in such applications upon which the product operates in determining the structure of the product mi 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 writeiloz audit trail 1 Dr Douglas Nlenaiis 2009 l 9 edit 7 gum update quot quot39 quot mus L mu L5 1 7 EEcsMs 2 Dr Douglas Nlenaiis 2009 EEcs 448 m 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 ata 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 implementationslof I perform detailed design clasksfrlnodule operations specrerd during analysis wor ow 39 completmg Class D39agram Correspond to interactions within interaction Formats of attributes are determined diagrams of various scenarios 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 eaSIest and most efflClent workflow but not necessary and Methods of classes support specified class interactions Thus easier to add attribute format to UML as late 39 some fleXibility in how many methOds are Implemented In which classes to support an as ossible in desi n rocess p g 390 Interaction EECS 44B 33 Dr Douglas Niehaus 2009 EECS 44B 34 Dr Douglas Niehaus 2009 Each iteration would result in changes 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 Private accessible only within an object of a nge lacngur ges esserltjallyrqwrre defInIn specific Class 0 jects or a contexts ava utt at can 0 scure the logic of the product in some cases Egoggcgfgugg essss39ble only mm a spec39flc Constant global goal Is to express product semantics Operations on or using state variables must be as clearly as possible 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 ObjectOriented Design Elevators void SIEMiTlT C Il HLLLlDP voldj ElevatovAppllutlon amen ElevaturlJtllltles l l Illumlnaledz onlenn l lulrlolllsulluu abalrazl lulllOrlBulwn abstuct lurnC Button lumen Butan EIewlorCunlroller nnlmi reuuesu requealTrpe i lurnOffEuum lLlll DnEKIHDquot run rmllmlx Elavatornmm n uoomolleu bouledll closeDcors o penDoors l movenawnom Fluor moveUpOneHnm EECS 448 41 Dr Douglas Niehaus 2009 00 Design Art Dealer Step 1 complete the class diagram whlle TRUE i if 91 Mon in if I39butum M l else if elevate r a nnulllg 39JUWl I wuiln n m raw else if elevator n val7m an l valEH n JibILI39ltg l rub my elevatnl Dnogzx oseDCors 1 ifrfllmr ultm myorBuLl 39 upmtek wquuzls buttgutrn0nl Hrn 1 FV VYHHE lll eleyatormovel else if Ievalor l else if elevator lv ml llig up m Mn and not l t qlll nfl w waterboors Ci05 Doors else if MW M W 1 IV I Iquot n I uBv t HI lzwlm39ls ejmjom thyWM liil39i jEV tnrDQLI SlllH39lLAl wll39 g MIEITIO ELPOHEHXN l else i mp elevatpl i39 l gt 39lLl leA39ijl me m g H mm elevalnrDoorszcenDoors startTlmel39 if 39elevagot unon l 43 glevator uttg mrn01 Blltlrlll upcntchrlucsts l EEcs 448 42 Dr Douglas Niehaus 2009 00 Design Art Dealer 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 dlagrams Designer decides which actions correspond to which methods associated with which classes EECS 448 Dr Douglas Niehaus 2009 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 Dr Douglas Niehaus 2009 00 Design Art Dealer mt Dylany um up n Input uvnpu compm Muleer Munrplxe name onquot Plnung ma Elm Mu mu mm am Put Elnu masterwork muerpm Auctioned Palnllng 39 qu Us Hnung I l mu EECS 448 00 Design Art Dealer float CornputeMaslemleceP39iceigetAlgor demwm rm mmmmm p EECS 448 nat hig 1 float algl ligh float highDate oat Irmp c 17 mhon Dglethy y K Gallery onquot fulllannhllky uu Palnllng quotmung Inn Im a Sale Purchase lulur mm upon nepun leparl 0 Its Clan 45 Dr Douglas Niehaus 2009 EECS 448 itnm Price Calleryl alnl rmA const masterplccc to Unarm 394 m jmn y nlgltDarr Wll m mm 4w My nungm all ulmeuuwiun ojt l for luluml IAu quotIn f nlar wer m ibllo 39339 r u m wig w39 temp rqum m 00 if uu n fur irstName w llastName m m mule m lmiarv39lv in mm return al l Dr Douglas Niehaus 2009 EECS 448 nuI H hlqh v n plr lgHigh ny l 085 00 Design Art Dealer 09m Anlln n a PalMIng a madam 9 ranum n New mm thxmuMmu may mum mm Dr Douglas Niehaus 2009 00 Design Art Dealer If lr39wr r39 u mum ml mrdit m Md 1 u Lem if hym it a mm H on sublect WJ 39l Ir terns 9 gm Hm mm a m nutup my Dy HUI110414 rm hcignL hr ir widt39l my LIlllrLln39icU4l1 1v m n if eITa l grt39umt r l w r mp Wm 111m fin Imme v a umnon xvUUUH A 139CqcYral39 Ht IComputeMasteraiecePrice getAlgc39ithmPrle 48 Dr Douglas Niehaus 2009 00 Design Art Dealer float f 39 quot x I K int century mimrr m wmliiumimg nm39 ummi L r l my mumquot my w39a u My Ivriilili39ng m i i uwx39 n mummm u Imw ohmm mu enlury m IiiIi linr panning um uwuwl milmime ApplyB imm m Ilm Winnu m minquot if century n vqmu m 21 return maSIPrpietePrice 025 else return masterpiecei rice quot 2 7 century22 7 century ComputeMaslerworkPricexgetAIgorilhmPrice EECS us Dr coughs menaus 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 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 w the design workro 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 Dr coughs meihusozooe Design WorkFlow 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 EE Dr coughs meihusozooe 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 Design inspection should reflect transaction orientation of transaction based designs Consider all transaction types Specificationdriven inspections are always essential Goal is to ensure that no statement of specification document has been either overlooked or misinterpreted EECS 44B 57 Dr Douglas Niehaus 2009 Design Method Comparisons Topdown vs BottomUp Dataflow analysis is topdown decompostional Jackson s method is bottomup compositional Combination of both sandwich technique is often stronger Proofofconcept or actual module implementation for components designers are sure will be needed is bottomup DataFlow of OO topdown decompositional approach elaborates components and tries to connect to bottomup components Adaptations obviously required from both sides to create final design EECS 44B 59 Dr Douglas Niehaus 2009 Formal Techniques Formal techniques applied to detailed design can help in 3 ways State of the art in correctness proofs is that they are applicable to modulesized components Generally not yet able to scale up to a whole product 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 58 Dr Douglas Niehaus 2009 Design Method Comparisons Maintenance Jackson s method is not maintenance oriented Dataflow analysis has advantages GOD is strongly recommended for maintainability Reuse Dataflow and OOD have an advantage over Jackson s method Overall GOD is the state of the art with advantages over other approaches Surpise surprise surprise EECS 448 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 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 AnaiystDesigner 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 mig t 9 could be used as a measure of product size Not all decisions are binary Cohesion and couplin can be quantified and are 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 threshold I I I Strength easy to compute Fault statistics can measure reliability of methods Weakness Data complexity is ignored How far the implications of a fault reach IS a measure of seriousness 39 For example convert t0 Char Cyclomatic complexity M of a detailed design 128 way branch using switch M 128 Number of binary decisions Number of branches in a code artifact Array IOOkUp39 M 1 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 8Usually low for classes ignores data EECS 44 complexity 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 448 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 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'