Software Engineering I
Software Engineering I EECS 448
Popular in Course
Popular in Elect Engr & Computer Science
verified elite notetaker
This 33 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 36 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
Object Oriented Analysis Chapter 12 EECS 448 Dr Douglas Niehaus EECS 448 1 Dr Douglas Niehaus 2009 Analysis WorkFlow Analysis WF of the Unified Process has two aims Obtain a deeper understanding of requirements Describe those requirements in a way that makes it easier to create an 00 product design and implementation that is easy to understand and maintain Unified Process is case driven During the analysis WF the use cases of the product are described in terms of product class use and interaction Deepening understanding of requirements and product may suggest additional use cases or adjustments to existing use cases EECS 448 3 Dr Douglas Niehaus 2009 Overview Objectoriented analysis is a semiformal approach to requirements analysis used as part of the Object oriented paradigm Well over 60 techniques have been proposed that are all baSIcally equ1valent Today the Unified Process is almost always the choice of those choosing to do 00 SW production Jacobson Booch Rumbaugh 1999 Major advances were made in CO paradigm between 1990 and 1995 Usually takes 15 years for general acceptance Millenium Bug Y2K concerns accelerated this Needed to revamp SW used current leading edge EECS 448 2 Dr Douglas Niehaus 2009 Analysis WorkFlow Unified Process defines three types of classes Entity models information that is longlive often including persistence across product instances Eg Painting Class in Art Gallery product Boundary models interaction of software product and its actors Actors are humans or other SW products that act independently and interact with product Associated with some form of IO Eg Purchases Report Class Control models decision making parts of product embodying computations and other algorithms Eg Compute Masterpiece Price Class EECS 448 Dr Douglas Niehaus 2009 Analysis WorkFlow Analysis WorkFlow UML defines symbolic notation for these classes During the analysis WF use cases are described in These are stereotypes extensions of UML for terms of the classes defined for the product eXpressIng partlcular concepts Classes are a vocabulary for describing the Additional constructs like these can be created to PFOdPCt componentS being teSted by seeing hOW model a specific system accurater well it permits describing the use cases Difficulty describing a use case means either Figure 121 Perfectly fine symbols and standardization can 39 use case is badly de ned 0r described help but making your own choices would be OK Class decomposition needs refinement Unified process does not specify a method for extracting product classes Some general advice can be helpful but practice that comes with experience is probably the most Entity Class Boundary lass Control iass important component as it develops SWE s intuition EECSME 5 Dr Douglas Nlenans 2009 EECSME 5 Dr Douglas Nlenaiis 2009 Extracting Entity Classes Extracting Entity Classes Functional Modelling Work through specific Word type extraction from a written use case scenarios representing eaCh 0f the use cases Book mentions this but not as extensively as Entity Class Modelling Define entity classes and think is best their attributes Nouns are often class candidates Determine relationships and interactions among Entity Boundary Control entity Classes Adjectives often denote class attributes or Create a Class Diagram showing inheritance subclasses depending on which qualification better relationships senes OO descriptions of use cases Dynamic Modelling List operations performed by Verbs often denote cass methods invoked although each entity and what operations on an entity will be they can also sometimes best be described by used by outside elements actors boundary control mdependent SUbrOUtIneS Statecharts are a popular representation for this 39 Ad g rzsbomendengtftwetmd Palra39T eterf thatl ffleCt me o e aVIor u ey canaso enoemu ipe Iterative process interleaVing modelling types related methods EECSME 7 Dr Douglas Nlenaiis 2009 EECSME a Dr Douglas Nlenaiis 2009 Extracting Entity Classes Quick Elevator related example use case A user pushes an up or down floor button which tells the elevator controller that it should choose an elevator and schedule a stop at that floor Nouns button elevator controller user stop Adjectives Up Down Floor all button modifiers Ve rbs push schedule Adverbs none Entity class Button up down floor elevator ActorBoundary class user Controller class controller EECS 448 9 Elevator Example Scenario is a specific instantiation of a use case Specific set of lowestlevel events Usually a large number of scenarios Dr Douglas Niehaus 2009 How important the differences in event sequence are depends on the product and context Normal scenarios describe a sequence of events when things are working well Exception scenarios describe a sequence of events when something goes wrong Both are constructed by reasoning from first principles about the problem domain and by observing users at their activities EECS 448 Dr Douglas Niehaus 2009 Elevator Example Functional Modelling Collect use cases describing how actors interact with a product Actors are outside the product but are often represented in the product in some way Often a boundary class In this case the most obvious actors are passengers Only two interactions with passengers Press floor button Press and elevator button Building Fire Alarm is a less obvious actor but these often modify elevator behavior EECS 448 10 Dr Douglas Niehaus 2009 Elevator Example Specific scenario specifies details such as floor that may or may not distinguish it from other scenarios Would using 268 vs 379 matter EECS 448 1 bogoLolloor7 2 3 9 5quot Antw n flourl and pressed the elevator button larfloor 9 buuuu at now 1 W A Wishes The Up floor button 15 turned on The Up our button is turns off The elevator doors open The timer stalls User A enters me elevator USErA presses the Elevator button for oor 7 The elevator bullon for oor 7 is turned on The elevator doors close after a tgtmc0uL The elevator travels to our The elevator button for floor 7 is turned off The elevator doors open to allow User A to exit lrom the Elevator The timer starts User A exits from the elevator The elevator doors close after a timeout The elevator proceeds to floor 9 with User B 12 Dr Douglas Niehaus 2009 Elevator Example Elevator Example Entity Class Modelling Create set of entity classes and their attributes No methods yet Two approaches to Entity Class identification Identify them from the use cases nouns Study normal and exceptional cases Identify components playing roles CRC Cards Effective when SWE have domain experience Shortcuts contemplation based on experience Floor buttons Elevator buttons elevators doors timers extracted from scenario EECS 448 13 Dr Douglas Niehaus 2009 Elevator Example Large number of scenarios may initially suggest a large number of classes Refining a candidate vocabulary by applying it to many scenarios and looking for commonality Adding a candidate class is easier than removing one Apparently different classes can sometimes be consolidated by adding an attribute variable to emphasize large set of common semantics and minor set of different semantics Noun extraction Describe product in a paragraph Identify nouns EECS 448 14 Dr Douglas Niehaus 2009 Elevator Example Noun classification Exclude those outside problemproduct boundanes Can be useful to change typeface of candidate noun entity classes in description Floor building door can be ignored Assumes elevator door is controlled locally Elevator door related to timer which may be centrally or locally determined Button and elevator are obvious candidates Floor buttons and elevator buttons could be related in class hierarchy EECS 448 15 Dr Douglas Niehaus 2009 Candidate Hierarchy Abstract Button class inherited from Elevatc and Floor buttons Elevator class and its relations M buttons within each elevator instance illuminated Boolean I i Elevator Button Floor Button communicates N elevators W 1 2m2 floor buttons communicates with Only 1 on bottom and top floors EECS 448 16 Dr Douglas Niehaus 2009 Elevator Example Elevator Example Button Class Inserting controller more realistic All buttons have Illuminated attribute Changes Ciass reiations Other attributes might include entity the button Buttons do not communicate sends messages to directly to the elevator Elevator and Floor subclass relation denoted With C t H b t lines and open triangle on m er 39 e Ween EtevatorCtaSS Controller sends messages to Attribute doors open tracks door state elevator floor ancgle39e fagqr Might also have state variable describing floor bUttlons e evator Cor m 39Cator At least for floor indicator 39 NOt39CPe 139t039many and manYtO1 Might also be in controller class relations between controller and Clearly a controller is needed elevators Coordinating the set of all elevators as well as 39 More complex to mOdel and each individually program ClassResponsibilityCollaboration CRC Cards ClassResponsibilityCollaboration CRC Cards Utilized by some groups to describe product classes CASE tool support exists 39 For eaCh Class General Drawing tools 39 Name Drawing Templates UMLCRC format FunctionDuties in product system Architect List of other classes with which it collaborates Strengths of CRC 39 Those It 39nVOkeS When used by a group it promotes member Those it is invoked by can be left implicit interaction which can highlight missing or incorrect class components or class set members Relationships among classes are tested and refined by discussion Vis a Vis use cases Role playing by group members as classes Good way to train your intuition Extensions Identify class attributes Specific set of methods invoked and by whom PostIt notes moved around on a board Online diagram wold work well too EECS 448 19 Dr Douglas Niehaus 2009 EECS 448 20 Dr Douglas Niehaus 2009 ClassResponsibility Collaboration CRC Cards Dynamic Modelling Weaknesses of CRC Aim of dynamic modelling is to produce a Starts with describing a set of classes and thus represehtatlon Of a sequence 0f 09ml30nent depends on strong experience and intuition of interactions representing a scenario users for 9Xtra0t39ng Classes from use cases Tests correctness of class and method vocabulary Easily combined with Noun extraction as CRC can Can be done a at teast two ways be used to describe a set of classes derived using State Chart noun extraction 8 Ob I D Do not let detailsmechanics of a given approach WWW Ject 39 nteract39on 39agram distract you from meaning StateChart Similar in some ways to a Finite State Extracting meaningful components and their Machme prOdUCt descr39pt39on semantics from use cases Less formal but can be made more preCIse during iterative refinement EEcs us 21 Dr Douglas Nislaus 2009 EEcs us 22 Dr Douglas Nislaus 2009 Dynamic Modelling Test WorkFlow First elevator Test WF applies to the set of functional problem state V n requirements entity classes and dynamic models chart iteration 1 i appear to be complete Specific 439 quot gm For a given set of usecases scenario quot Review the Analysis WF product to date and test how well it can be use to describe each of the current set of use cases Difficulties or gaps suggest improvements CRC card creation and use given another view of the completeness of the Analysis WF product CRC cards for each entity deduced from class diagrams and statecharts Responsibilities correspond to statechart operations EEcs us 23 Dr Douglas Nislaus 2009 EEcs us 24 Dr Douglas Nislaus 2009 specific path Refinement can extend notations on both states and transitions Test WorkFlow CRC collaborations determined by examining class diagrams First iteration of CRC for Elevator Control Class Can highli ht badly placed responsibi ities Turning buttons on and off vs sending signals Classes can be overlooked Elevator Door Iterations change class hierarchy and relations EEcs 448 25 Lum n PPFNP S PP P CLASS Elevator Controller RESPONSIBILITV Turn on elevator button Turn olf elevator button Turn on oor button Turn off lloor button Move elevator up one iloor Move elevator down one floor Open elevator doors and start timer Close elevator doors after timeout Check requests Update requests COLLABORATION Class Elevator Button Class Floor Button Class Elevator Dr Douglas Niehaus 2009 Refined Analysis Products Test WorkFlow Use case diagrams may need adjustment or addition and certainly must be reexamined Statecharts extended to include new classes Scenarios updated to include new entities their use by actors and their interactions with each other Figure 1211 page 391 second iteration of Normal scenario extended to include controller messages to elevator doors and buttons etc Even with the greatest care when you get to the 00 design WF adjustments to the OO analysis WF may be necessary Revision to the set of artifacts EEcs 448 Dr Douglas Niehaus 2009 Refined Analysis Products Elevator Cuntroller RESPONS Send message to Start timer Check requests Update requests 7 9 P 399Equot WNquot IBILITY Send message to Elevator Button 0 mm on button Send message 0 Elevator Button to rum off button Fluor Button to turn on buttun Send message to Floor Button to turn all button Send message to Elevtor to move up one low Send message to Elevator to move down one lluur Send message to Elevator Doors to open Send message to FJevalnr Doors to close after llmEElul C0 Subclass Elevator Button Subclass Floor Button Class Elevator Doors Class ilevator 9WNT LLABORATION Figllre129 EEcs 448 27 Dr Douglas Niehaus 2009 Elevator Buttm m n Illuminaled Boolean rloor Button 2m Z l controls controls 1 1 Elevatvr controller E ruquosLs rcques ypt tontrols doors Dpnn Boolean EEcs 448 Figure 1210 23 levator Dear Dr Douglas Niehaus 2009 Extracting Boundary amp Control Classes Boundary classes are linked to concrete components and tend to be a bit easier to extract Each lO screen printed report GUI component Granularity of the classes intended to maximize clarity of the usecase descriptions GUI components as small as a sin le button or as large as an entIre screen full of WI gets mIght correspond to a Boundary class Set of information and how it related to CO analysis is the determining factor Classes might be used to represent individual users Preferences or state within and interaction scenano EEcs ME 29 Initial Functional Model Osbert Oglesby Art Dealer 5 Seller Proouce a Report Osbert Buyer Figure 1212 EECS ME CH Dr Douglas Nlenans 2009 Dr Douglas Nlenans 2009 Initial Functional Model Functional model of an application concentrates on generating scenarios from the usecases Usecase diagram illustrates interactions among users and components of the product as well as among product components Art Dealer SW product Dealer is the only user Customer is an actor Both buyer and seller roles Buying and Selling use cases Art dealer can use product in 4 ways so there are 4 use cases EEcs ME 10 Dr Douglas Nlenans 2009 Initial Functional Model Scenarios depict component interactions Variations of use cases such as buying a painting Numbering of relevant sentences enhances readability while permitting description of additional information Multiple scenarios can be combined into a single usecase diagram Normal and exception scenarios are both important Can be combined into extended scenarios Scenarios are important to functional modelling and to the dynamic modelling as well EEcs ME 2 Dr Douglas Nlenans 20m Initial Functional Model Use cases subsume several related scenarios Osberl Oglssby wishes to buy a masterpiece I Osbcrl entcn the description of the painting 2 39 39 yam mine sale oi me most slmllar work by the same artist I n r a r rm i L V x 5 commanded nnnlmIIIy for Earth ynar smc39a he aucvrnn nr he most similar wnrk n h n r r ll u is atmpted oy uie seller 4 Osbeit enters sales information name and address of seller purchase pr ce Osbcn Oglcsby wishes lo buy a maslcipiccc Oshcrl Enters llie descriprjm oi the painting The software produ scans the auction records to Iind the price and year ol he sale of Ilie most Sill Ior work by the same artist Nr39 v 85 compuunded annually for each year since the auction of the most similar work Osberl makes an oIIEr below the maximum purchale price The seller turns down Osbell s uilei EEcs 44a 33 Dr Douglas Niehaus 2009 Initial Class Diagram Entity class modelling step Extracts entity classes Determine their relationships Find their attributes Twostage noun extraction process Paragraph description of the art dealer product Relevant nouns are extracted Abstract nouns Effectiveness process information Less likely to be entity classes EEcs 44a 35 Dr Douglas Niehaus 2009 Initial Functional Model Dsbzrt Oglesby wishes 0 buy a masterpieze i Ohberterllen ma deacripLiun ill the painting quot 039 U1 sale of the most similarwork by the same arrisl The sorlware producl reports that here are no similar workx Osbsn does not malls an offer Inrme pairiung L Osbm Oglesby wishes in bsiy a masietpiecs Osberl enters the description oi llie panning The all 39u nmdll I 39 sa e or iris miss similar won by the same arrisl N 35 conpounded Annually for eah ycar since m auction or the mail similar work omen makes an offer below lilo maximum purchase price the oller is accepted by the seller ll mi in 39 ni rV Possible allemalives A The seller turn down Oslx39t39s offer a No similar pulmng by llldl cHLIsI is in lire dllLUulI Me so emu uuus uul make m Ci of cr ror me painllr EEcs 44a 34 Dr Douglas Niehaus 2009 Initial Class Diagram Nouns derived from verbs and verbs Buying selling appraising Likely to be operations of some class Nouns that are shortlived Report Likely to be boundary classes Four candidate entity classes from nouns Painting Masterpiece Masterwork Other Maybe one class and classification is an attribute Painting base class and subclasses Subclass supported by need for different sets of information EEcs 44a 36 Dr Douglas Niehaus 2009 Initial Class Diagram Initial Class Diagram Studying the use cases can lead to additional insight Need to distinguish gallery painting and painting Masterwork has all attributes of masterpiece but aUCtioned WOFIdWide add new Classes needs additional informatlon as well Need to compare gallery paintings to similar paintings auctioned worldwide to determine prices a Auctioned painting is a painting but has nothing to mangoquot do with man as ects of aintin s owned b Ea a a W p g y i i l i Fashionability class A painting of Other Painting class uses aninstance of fashionability for that artist to compute maximum price EECS 448 37 Dr Douglas Niehaus 2009 EECS 448 38 Dr Douglas Niehaus 2009 Initial Class Diagram Initial Class Diagram m Attributes of each class are added Top level global class can contain attributes for the application as a whole mamma Often good for holding invocation options in a Callery Painting lass wrde range of applications Associated with starting execution of product as a whole 39 am omwamngmss rasnmna um 39 Other classes represent types of paintings and associated attributes and operations Version leaving out attributes but using stereotypes aluminium of each IS also a useful vrew EECS 448 39 Dr Douglas Niehaus 2009 EECS 448 40 Dr Douglas Niehaus 2009 Initial Class Diagram um Ugluby AyalaInn o EEos MB Dr Douglas Mlenaus 2009 Initial Dynamic Model Initial Class Diagram lenrl Ogluby Appllcillun lass Falnllng lass l I Q Q GAIIeIy Analogad raluuug clm Palnlhlgs am d A e 2 Marlevplm only fawnnnhlllly Ian Pulrrrlng clm Inn Q Mislurwulk Ins EEcs MB Dr Douglas Mlenaus 2009 Initial Dynamic Model Dynamic modelling is the third step in extracting entity classes Statechart is a compact representation of dynamic behavior over several use case scenarios Statechart Starting solid and Ending states solid circled Arrows depict permitted transitions Start leads to event loop Note correspondence to GUI event loop gtkmain Major states note name and narrative Buying Selling Report Fashionability 41 EEos MB Dr Douglas Mlenaus 2009 qlll eIBLIEJ L Oshen Oglesby Event Loop J u buy sci produce nodalc palmmg painllng rp rt iathinnahlliry mleuud menu naule mleuh I I I r l n 4 r n 1 urn iggEl Huya masterplece sell a maxterplece Lrsuold paintings 39 m quoty masterwork cr masterwork or bought paintings Upcate ashianability mlwr painting 0mm paralan or remix melhtlenl J EEcs MB Dr Douglas Mlenaus 2009 Initial Dynamic Model Boundary Class Extraction One of five events can occur Events cause state transitions Quite leads to final state and exit destroy and delete events associated with gtkmainquit Dynamic model can be made for application as a whole for each class or for combinations Goal is to clearly describe application semantics Initial functional entity class and dynamic modelling being completed All models checked against use cases Considered correct for the moment EECS 448 45 Dr Douglas Niehaus 2009 Boundary Class Extraction Each inputoutput operation represents an interaction with the outside world and thus actors Represent separate interfaces or components of an interface GUI frames or sections of frames are often associated with specific sets of IO data One simple menu GUI for the ART dealer Book illustrates some of these points using an application for a foundation providing mortgages Toplevel GUI with N possible operations common Text based curses interfaces more easily portable and accessible over SSH Five commands Buy sell report fashionability and quit EECS 448 46 Dr Douglas Niehaus 2009 Boundary Class Extraction Click on your choice Buy a painting MAIN MENU OSBERT OCLESBY ART DEALER I Buy a painting 2 Sell a painting 3 Produce a report 4 Update fashionability 5 Quit Type your choice and press ltENTERgt Sell a painting Print a report Update fashionability EECS 448 47 Dr Douglas Niehaus 2009 Three types of reports Purchase Sales Future Trends Separate boundary class modelling each Four Boundary classes result User Interface Purchase Report Sales Report Future Trends Report Boundary Class set is adjusted as IO types change and as interactions with outside world are refined EECS 448 48 Dr Douglas Niehaus 2009 Control Class Extraction Refining the Use Cases Nontrivial computation modelled by control class or As a set of classes is defined it needs to be checked Control class methods grouping sets of related against existing requirements and usecases compilations In some applications Often reveals a need for refinement 39 Might be methOds 0f entity Classesv IMHO Checking the candidate Art Dealer classes against Art Dealer has four computations 39 the proposed classes indicates that Bu In a Masterpiece Price Painting and Producing a Report usecases should Masterwork Price be re ned Other Painting Price Buying a Painting becomes Trends Calculation Buy a Masterpiece Four initial control classes Buy a Masterwork mputer Masterpiece Price Computer I I Buy other Painting gnajtgmqghg39g i g gfgr ggomer Pa39m39ng Pr39cev Each painting type has a different class with different information and so buying each is slightly different gas 9 or Daugizmimzm Ems 5n or Daugizmimzm Reflnln the Use Cases Reflnln the Use Cases Producing a Report use case becomes Third iteration of the mummy Produce a Purchase Report product usecases is more rm39 Produce a Sales Report complex 39 t Produce a Future Trends Report Specification of each use quot v Key point is that the set of use cases should use all case and set of scenarios mm the major product components at least once obviously contains more detail than the diagram 0 r Buying separate painting types does not re u39 Compilers exist that include instrumentation in emitted code to record and re ort the branch Buyer Aim is to give a quantitative measure for how completely the software functions have been separ te menace for eaCh exercised Attribute or sub I Assumes correspondence of functions and code component Of mam conditional branches which is often tenuous pUrChase Cho39ce EEcsue 5i Dr mum Niehzusz g EEcsue 52 Dr mum Niehzusz g cations of refined use cases for other UML Buying a Masterpiece usecase example I grams describing Art Dealer business model Knetocsmpzton Splits the original Buya Paina39ng case into three separat cases each representing a se scena 39 Art Dealer must supplychoose the classification of the painting to permit the SW to choose the correct class associated s are GTK entrycombo box does thi Permits entering a choice as text or selection from a pulldown list Refining the Use Cases Refining the Use Cases lmpli d39a mew y me c xmomcn Oqlmhv m M 5 mmpr Stemwach Dum miu I mm inpu m m im r m m imam We is ain tuiuq L mm mm c u39unm nrk 4 Time are l x n lum on mama omzr ml Hm iira1iil4iire immawmwmwat Splits the Produce a Report case into three as well wwuh l L Maximo ms as m p Krase pm imam would wars p omr39 vamUYP mg m whirh 1ka numimn CNN 4 analxcimvirm m Illwpmmmgunuei conside39st i mate wanequot mmks m ma mm mm n1 0 mm m in me Humane at mewtw mlm ignnrrd uvumgizsmmusomng EEcsus so Refining the Use Cases Use Case Realization Use cases describe interaction among actors and the software product W Utilized at the beginning 39d eounln n is mu m of software life cycle in the requirements workflow mi i m min Details are added as each case is refined and as y w use cases are added L 1 mm L f V t V quot adescrIptIon of the classes mm m used as part of each case as classes are defined 1 ll lhrwlvrar wscrbexlsoffal Dxbt39tsw During analysis and design workfow5 me n mm NH 1 ullm Use cas s guIde desIgn and Implem A1nrnt N rllrr becau MM mi m mm mm 1n39mmmrd 39n m mmin Mmm p win my yew 3 fur mm entation se they must be supported by specific software omponents which implement specified semantics During the implementation workflow mm 53 u may mm om u Dough Nnmusoznng Use Case Realization An interaction diagram depicts how a specific use case scenario can be realized as a set of interactions among actors and class instances Two types sequence and collaboration Two ways to add a narrative of use case scenarlo steps to a class diagram Consider a Buy a Masterpiece scenario and classes involved in its realization User Interface models actorsoftware interaction Computer Masterpiece Price models computation Involves comparing this painting Masterpiece class to masterpieces previously auctioned Auctioned Painting class EEtS ME 57 Dr Douglas Nlohaus m Use Case Realization Artifacts representing a use case Req WF use case and description Analysis WF a number of artifacts including class diagram showing classes used by use case Scenario is a specific realization of a use case Class diagram incomplete unless all classes required to realize scenario are present Working software uses object instances not classes Each Masterpiece is represented by a Masterpiece object Masterpiecequot notation denotes a class instance by prefixing the colon Collaboration diagram adds instances and messages to class diagram EEtS ME 59 Dr Douglas Nlohaus m Use Case Realization Seller does not interact wit the software directly Provides data entered into the product by Dealer Class diagram adds note to Seller Actor The seller provides L data enter d by Osberl Ak Manerplece 0 Class User Interface Compun Ian Mmarplm rice lass Oxhert Audiuned Paln ng lass EEtsua 59 Dr Doughs Nlohausm Use Case Realization Collaboration diagram Shows each object class instance used Shows object interaction method callsmessages Arrow direction shows controlinformation flow Object creation noted by newquot Client must be able to understand elements and terms of a collaboration diagram Client must understand what SW will do to approve specification document Written narrative must accompany a collaboration diagram in a Phase Report or Requirements Specification document EEtsua so Dr Doughs Nlohausm Use Case Realization Use case scenario elements are realized as a set of actions among collaboration diagram obiects r mu m K x ft m around my mm m ensr in a a m r 0quot mi 39 H mm a mmwm P a EECSus 51 Dr mugas limmsm Use Case Realization Sequence diagrams can take more room Use whichever communicates most clearl F y x 5 EECSus 63 Dr mugas limmsm Use Case Realization Sequence diagram represents almost same set of information as the collaboration diagram Developers can choose to use one or both Sequence Diagram Uses vertical lines for timelines of each object Lifeline of an object section of time line from object creation to object deletion Activation box narrow rectangle on lifeline showing when object was active Sequence diagrams are thus capable of showing concurrent execution in multithreaded systems Important in other applications not relevant in 448 project and examples a ms us nr Douglas quotImmsm Use Case Realization Strengths of a sequence diagram Shows the flow of information unambiguously Ordering of messages is clear Shows that every transfer of information in one direction is followed by a transfer in the other Possibly just a method invocation return code Sequence diagram tends to be better at describing the transfer of information Focus for much of the time in the Analysis WF Collaboration diagrams tend to permit concentrating on the classes better correspondence of Class and Collaboration Diagrams is useful ms us nr Douglas quotImmsm Use Case Realization Use Case Realization Buy Other Painting use case Similar in structure to other cases but different classes are used and low level set of events is different in collaboration or sequence diagrams The seller provides IE5 data entered by Osbert O Seller Other I G Painting Class oshert User Interface Compute C Other Painting Q Price lass Fashionabillty lass EECS 448 65 Dr Douglas Niehaus 2009 Use Case Realization Other use cases are quite simple and so their class diagrams and collaborationsequence diagrams re basically trivial too At some point you may elect no to create them Prudent when it saves time Painful when it overlooks important details Judgement is involved and both types of mistake are common Q 05b Userlnterfam Gallery Painting Purchases Report Class Class Class usher User Interlaze Gallery Palntlng lass lass Sales Report lass EECS 448 66 Dr Douglas Niehaus 2009 Incremental Improvement Future Trends Report slightly less trivial Gallery Painting Class r 39 Osbert User Interface Compute Future Trends Class Future Trends Report Class Class EECS 448 67 Dr Douglas Niehaus 2009 Several incremental improvement steps have increased the information content of the class diagram reflecting the set of product classes Entity Boundary and Control class extraction Interrelationships among classes Inheritance Use Information in various class diagrams combined First use case information is included Then class inheritance relations can be added and any additional classes EECS 448 68 Dr Douglas Niehaus 2009 Incremental Improvement am Mm umquot mhu Palling nu m lib 51 LA mmmm Muletv l39 Amlmd Clan Ian naming um mum mmnu a g mmrmmmm MN m m f I gt H r H 1J m Mmum quotmquot uwm am an Irma leynn um EEcs Ma Dr Douglas Nlahaus zone Software Project Management Plan IEEE has a standard SPMP format Appendix F in text is an example SPMP for the Mortgage Foundation application In general this document is an excellent example Contains some information not relevant to all situations Other information may be presented in different forms in different contexts Budget may be in monetary or time units Different units for different items Initial phases of the project may not fill in all sections Sections are refined in subsequent phases Tempting but overkill for 448 semester project EEEAAE 71 D r Douglas Nlahaus 2009 Incremental Improvement 1 I 4 amn Dulull Al llllmumt m um mmm a Z i J h in Q0 mmmmwamw WMMW m quotmm m a m mun n EEcs ME 70 Dr Douglas Nlahaus 2009 Software Project Management Plan Semester project reports will concentrate on requirements analysis design implementation and testing components of planning and execution Schedules for development list of developers their assignments and how development tasks actually turned out will be included AssumptionsAssertions are strongly related to requirements and the SW architecture EEcs ME 72 Dr Douglas Nlahaus 2009 Test WorkFlow Specs Document in Unified Process Anal sis WF of the art dealer product can be Unified process is use case driven Chec ed 39n two ways Use cases and artifacts derived from them contain Classes and the relatIQnS Qan beCheCked by all information appearing in tradition specs doc taking another View of Situation using CRC cards I Genera convey more information more All artifacts of Analysis WI can be inspected accurate y to customer 39 By a grOUp members Indlwdually or tOgether Collection of artifacts for complete product 39 By SQA alone or W39th development constitutes contract between client and developers 39 By Fug0mg Traditional specifications document usually played All checking is still inspection ratherthat execution contractual role because no software exists generally I I I I RP might exist but it addresses limited issues Interaction diagrams reflecting classes that realize Proofofconcept code may exist but it use case scenarios are shown to client demonstrates capabilities and test assumptions Replaces some of RP uses Not product features RP better for GUI diagrams could be used Dr Douglas Niehaus 2009 EECS 44B 73 Dr Douglas Niehaus 2009 EECS 44B 74 Specs Document in Unified Process More on Actors and Use Cases Why 448 will build a RP A use case illustrates interaction among software ProofofConcept for GUI SW related to widget components and aCtOFS use look and fell etc Actors can be humans or SW outside the product boundary outside what you develop Finding actors and use cases can be subtle Consider ever role played by individuals interacting wit the SW Actors extracted from list of roles Sometimes different actors sometimes just slightly different behavior or options by an eXisting actor Mortgage example first apply applicant role and if approved borrow borrower could be 2 actors or two roles for 1 actor depending on SW design Dr Douglas Niehaus 2009 Possible to draw a diagram that is hard to build Screen shot of interface implemented using PyGTK or PyQT can by definition be built Helps professor avoid crashandburn scenario where some group cannot finish because they do not start learning about GUI code early enough EECS 44B 75 Dr Douglas Niehaus 2009 EECS 44B 76 More on Actors and Use Cases More on Actors and Use Cases Unified process terminology uses term worker to refer to a particular role Poor choice but in this case applicant and borrower would be different workers Makes more sense to me as 2 roles for single actor although software may make taking a view as two related actors better In many business cases finding the roles often easy Construct use case business model Roles are all types of interactions with business Find subset of use case diagram that models the software product and its users Actors in this subset are the product actors EECS 44B 77 Dr Douglas Niehaus 2009 Object Oriented Analysis Summary Having identified relevant actors finding use cases fairly easy Each role will involve one or more use cases Start with each actor and enumerate scenarios involving each of their roles Categorize according to application semantics and how you are choosing to explain them to everyone Clients developers users etc Flexibility in defining these things is helpful Too rigid definition of actors roles etc can lead to peculiar results EECS 448 Dr Douglas Niehaus 2009 CASE Tools for 00 Analysis WF lterate Perform Functional Modelling Perform EntityClass Modelling Perform Dynamic Modelling Until a consistent and complete set of entity classes have been extracted Then Extract Boundary and Control Classes Refine use cases in reaction to data of all kinds Additional situations Gaps in ability to explain Changes in classes Perform use case realization EECS 44B 79 Dr Douglas Niehaus 2009 Several CASE tools have been developed to support 00 analysis Essentially a drawing tools for performing modelling steps Simpler to modify online diagrams vs handdrawn Support for graphical aspects of OO analysis Some tools also draw CRC cards Changes to underlying model can be reflected automatically in all related diagrams Some CASE tools support a considerable portion of 00 software lifecycle Currently most tools support UML eg Rose and Together ArgoUML is an OpenSource CASE tool EECS 44B 80 Dr Douglas Niehaus 2009 Challenges of 00 Analysis WF Conclusion Many challenges are shared with classical analysis ObjectOrientation is a powerful perspective for Easy to cross analysisdesign boundary analysis and design PolicyMechanism distinction helps Analysis phase is a vital part of the SW life cycle Analysis emphasizes policies that need to be But then a of them are implemented but usually not the mechanisms M used to implement them odeIIIng target busrness actIVItIes Is Vital to proper understanding of the problem and constructing a Analysis can also generate a set of constraints on software solution to the problem successful designs beyond policy scaung or performance requirements Categories of classes into Entity Boundary Nonfunctiona requirements Compute is helpful in organizing models Transition from 00 Analysis to Design is smooth 39 ClaSS COHabOFa EiQn and sequence diagrams are Actions of use cases in analysis can tempt developer usetUt representations Wltn different purposes and to overstep and specify class methods which should adVantages wait until design stage As with all parts of SW Process Practice EECS 448 81 Dr Douglas Niehaus 2009 EECS 44B 82 Dr Douglas Niehaus 2009 Why Maintenance is Necessary Post De very Maintenance Three reasons for making a change to a product Corrective Maintenance changes required to correct a discovered fault Analysis design coding documentation fault Perfective Maintenance changes to improve a product s effectiveness New features Chapter 15 Adaptive Maintenance changes accommodating a change In the enVIronment New compiler OS or hardware Dr Douglas Niehaus Percentages of time from a study of 69 organizations Corrective 175 Perfective 605 Adaptive 18 Other 4 EECS 448 EECS 448 1 Dr Douglas Niehaus 2009 EECS 448 Dr Douglas Niehaus 2009 Development VS Maintenance PostDelivery Programmer Requirements Most of the same activities Even though on average 67 23 of the total cost FiX faults corrective maintenance of a product can be attributed to postdelivery Extend product capabilities enhancement maintenance Some computer scientists prefer the term evolution Many organizations assign this to beginners and Viewing the entire software lifecycle as an less competent programmers evolutionary process Those with less influence over their work Maintainability should be built into the product from aSSIQnmentS the very beginning of the development process New development is generally more satisfying so Different context postdelivery maintenance be ins everyone gravitates to it if they can after a client accepts the first version of the pro uct Contradiction Maintenance is generally cheaper than re Postdelivery maintenance is the most difficult but implementation is assigned to the lest able Though it can be harder in some ways and less Counterpoint postdelivery maintenance is easiest fun in most ways on best designed products EECS 448 2 Dr Douglas Niehaus 2009 EECS 448 4 Dr Douglas Niehaus 2009 PostDelivery Programmer Requirements PostDelivery Programmer Requirements Postdelivery maintenance PDM incorporates all So PDM is potentially quite educational aspects of other phases lf approached correctly Thus properly managed it is an excellent training f supervised we greued for 39Inexper39ence programmer Provide inexperienced programmers with a Pebulgging skills are requrred to determine where a mentor auties However PDM is often still a thankless job Dealing with dissatisfied customers You do not meet them unless they are unhappy Mandatory tour of product to learn its structure well enough to isolate fault Sometimes requires considerable debugging skills in some way Fixing a fault without introducing others Fixing their problem Cheers them up though Requires considerable study and understanding of problems caused usually by original existing product software architecture developer not the maintainer Excellent training it product is well written EECS 44B 5 Dr Douglas Niehaus 2009 EECS 44B 7 Dr Douglas Niehaus 2009 PostDelivery Programmer Requirements PostDelivery Programmer Requirements Updates to incomplete incorrect or outofdate Further perils documentation also an excellent learning experience Code may be badiy written 39 TeSt39ng I Many developers consider it a lowerstatus job SpeCIfic test cases for corrected fault or extended Being too good at it may get you stuck prOdUCt feature Managers want a quiet life and programmers Regression tests to check for regression faults efficient at fixing problems a major asset 39 Also excellent educat39en 39n prOdUCt PDM most challenging aspect of lifecycle and development if they are done well management can help 39 Dfoggrp entation Of 3 Changes and implications is apn Restrict PDM to programmers with required skills 0 Adaptive and perfective maintenance 39 orlgmal develOpers can x the bUgs Programmer must perform requirements analysis 39 lee PDM hlgher Status and pay design implementation and testing workflows 39 ggiesit as a training ground maSter39apprentice EECS 44B 6 Dr Douglas Niehaus 2009 EECS 44B 8 Dr Douglas Niehaus 2009 Managmenet of PDM Managmenet of PDM Defect Report Data Base Each defect report should be tracked individually Filed by user with enough information to reproduce it Often a really hard problem Assigned to PDM developer Progress tracked ldeally defects should be fixed immediately PDM chronically understaffed Often a cost and not a revenue Often LowerROI even if explicitly paidfor Response time tied to defect criticality EECS 44B 9 Dr Douglas Niehaus 2009 Managmenet of PDM Defect data base should be open to users Users may not see all elements but Some information on open defects is reasonable for all users Can make the PDM organization look bad if some defects remain open for long periods Defects are often not fixed immediately for good reasons however Almost always cheaper to fixed a set of related defects all at once and perform related sets of testing and documentation rather than doing each separately Particularly true if new version of software must be installed on many machines EECS 44B 11 Dr Douglas Niehaus 2009 Authorizing Changes to a Product lf previously reported user can be given known information about fault If new defect maintenance programmer must study the problem and form a theory about how to fix it Perhaps ways to live with or workaround the defect are possible until it is fixed Programmers ideas and conclusions should be added to the set of information associated with the tracking data base defect record Management of PDM should consult set of open defect records regularly Rank criticality Monitor progress EECS 44B 10 Dr Douglas Niehaus 2009 Once the corrective maintenance is approved a maintenance programmer is assigned to the task of determining the fault that has caused the failure and repairing it Code is changed and tested Regression testing of the product as a whole Documentation updated SOA testing before modified product distributed PDM is also fault prone Conducting complete testing is hard Importance of developing solid regression test suite along with the product EECS 44B 12 Dr Douglas Niehaus 2009 Authorizing Changes to a Product Ensuring Maintainability PDM is a significant cost and testing is a significant During PDM the maintainability of product lean 0f PDM expense Ideally should improve It is estimated that the first fix of a PDM fault is optimisticaiiy shouid get no worse itself incorrect 70 of the time Care in conducting PDM and care in oversight is thus important Causal and inadequately tested fixes often cause more problems than the original fault Probability of cascading problems greatly increases if the regression test suite Realistically entropy always wins Major rewrites and revisions are often a result of longterm PDM entropy Fixing individual faults always involves a restricted view of the product Leading to greater entropy of changes Even if a broad view is taken in fixing each fault 39 Does nOt eXlSt changing conditions often mean that some PDM ls not automated work pushes the existing design beyond its limits Ensuring Maintainability Problem of Repeated Maintenance PDM is not a one time effort Moving target problem is one of the biggest Successful products go through many versions difficulties 0f PDM over its lifetime Client Changes reqUIrements Some are PDM Frustratinglfor developers H Can result In poorly structured code 39 some are new developm9nt I Can add to the cost of product Planning for orderly andleffICIent PDM during All these issues only get worse during PDM entire software process is crUCIal The more a completed product changes I Well designed software architecture explicitly 39 The more It deVlateS from Its Ollglnal des39Qn supports extension and modification Documentation becomes less reliable Moving target has a management component Oble orlentafllon helps Wlth mlormatlon hldlng Firm control of client expectations and need to 39 l39llgh COheSIOn and lOW coupling freeze requirements for PDM Variable names comments documentation all 39 Some PDM ShOUld be development of new contribute product version EECS 44B 14 Dr Douglas Niehaus 2009 EECS 44B 16 Dr Douglas Niehaus 2009 ObjectOriented Software Maintenance ObjectOriented Software Maintenance OO paradigm promotes maintainability Consequences of inheritance Well designed objects exhibit high level of Changes are propagated to all descendants conceptual independence Fragile class problemquot is descriptive phrase 39 EncapSUIation high COheSion IOW coupling Inheritance increases scope of the analysis 39 Generally easy to see WhiCh partls Of a IDFOdUC E Inappropriate uses of inheritance tend to make reqUIFQ Changes this much worse 39 GOOd locality usually Inheritance is often an advantage during initial Information hiding increases object independence development but a disadvantage during PDM Reduces undesirable and unnecessary interaction Clarity Clarity Clarity Changes to one object rarely affect another object Simplicity Simplicity Simplicity EECS 44B 17 Dr Douglas Niehaus 2009 EECS 44B 19 Dr Douglas Niehaus 2009 ObjectOriented Software Maintenance PDM vs Development Skills Obstacles to 00 SW maintenance Many basic skills of reasoning and coding are of PDIM programmer must study entire class hierarchy course common to both BUT wn39Cn was Often des39gned by Others Remarkably important set of differences To understand context of a class reqUIring modification Ability to diagnose the cause of a problem Good CASE tool support for browsing Class Starting point and among the most important PDm hierarchies is a big help skills Some tools can provide a flattened view of a class with all inherited features appearing explicitly Inadequate Incomplete or outofdate 39 Pogmorpn39sm and qunamlg binding f documentation is available rogrammer mus consiI eraWI Ier range 0 more I Simple is almost always better d t y g Clever should always have a good reason CO 9 you WI 9 I I I I Strong analysis design implementation and testing EECS 448 18 Dr Douglas Niehaus 2009 EECS 44B 20 Dr Douglas Niehaus 2009 Ability to read code to learn about it especially when PDM vs Development Skills Reverse Engineering Hypothesis formulation and testing Major skill in Systems Programming Constant feature of learning about a large code 39 LinUX Kernel base completely separate from diagnosing and Compuers fixing a specific fault Sewers 39 PDM deSlgn Challenge CASE tools for process Createlmodifications that achieve a given purpose Pretty printers and formatting editors display code while Violating no assumptions of other modules in cearer and standardized ways Clearly requires a detailed understanding of Tools for displaying code structure and data overall software architecture dependence PDM developers must no only be skilled in a broad 39 Compiler plugins range of areas but must be highly skilled In them Lint looks for structural problems and39CoverOty Obviously contradictory to who is assigned PDM and Other analyZIng compilers nellc Wlln tasks most often concurrence Reverse Engineering Reverse Engineering Phrase reverse engineeringquot refers to starting with a Terminology product and recreating design and perhaps Forward engineering usual development process specifications documents that proceeds from analysis through design to Write accurate and complete documents starting 39mplementatlon and teSt39ng only with source code Reengineering reverse engineering followed by Clarity Of COde and deSign commentS Segtibiticigg39eitinrygving the product without Happens frequently during PDM Changing its function Possibly for specific modules rather than whole pretty printing code prOdUCt Refactoring of software architecture is term Far more common for legacy systems used in extreme programming Still in use even though code was written 1520 Two approaches are possible once as products years ago design has been reconstructed by reverse engineering EECS 44B 22 Dr Douglas Niehaus 2009 EECS 44B 24 Dr Douglas Niehaus 2009 Reverse Engineering Reverse Engineering Option 1 Option 1 39 Attempt to reCODStrUCt the Spelcmcaltlons Use disassembler machine codegt assembler Modify the reconstructed speCIfIcatIons Use reverse compiler assembler gt C ReImplement the product In normal forward P bl engineering manner r0 ems BUT BUT BUT Variable names are all lost Reconstruction of specifications is hard Compiler optimization makes deducing I When successful often crucially depends on structure harder and makes understanding extensive experience deduced structure harder Option 2 Loops in assembler have more than one Modify reconstructed design and forward engineer pOSSIble source code progenitor mom Tere H d b t It I If t Option 2 treat existing product as a black box 39 Ore requen y use U I eaves speC39 39Ca 390 One possible use forvirtualization is to provide documents OUt39Of39date specific environment for such products EECS 44B 25 Dr Douglas Niehaus 2009 EECS 44B 27 Dr Douglas Niehaus 2009 Reverse Engineering Reverse Engineering Situation is vastly more difficult if source code is lost Option 3 and the executable version is all that is available Reverse engineering is used to deduce snoud never happen yet does more often specifications from black box behavior than YOU might think Reconstructed specifications are updated to reflect Essentially impossible of source code control tools current enVIronment are used Newversion of product is built from updated Some version of code is always available SpeCIflcatlons Almost as bad however is that the executable 39 Best approaCh being used is not built by the corresponding Make sure it never happens source code All options are painful but there are 3 approaches that can be use EECS 44B 26 Dr Douglas Niehaus 2009 EECS 44B 28 Dr Douglas Niehaus 2009 Case Study SourceExec Mismatch Case Study SourceExec Mismatch 1985 Convergent Technologies is building the first Fourth set of problems deSktOP UNIX bOX for ATampT Executables built from source still don t match UnixPC or 381 testing executables after compare tool ignoring Deliver first product version of entire UNIX release ltlme39StampS 395 bUllt OS compilers DB Editors applications etc 39 Fifth set 0f PrOb39emS 50 514quot oppies How can I possibly tell my boss this incredibly bad news without being shot or otherwise damaged Need more evidence of what is happening and why but I cannot delay for too long either Sixth set of problems Code and compilation analysis for 24 hours Found multiple copies of 45 header files that were different EECS 44B 29 Dr Douglas Niehaus 2009 EECS 44B 31 Dr Douglas Niehaus 2009 Deliver source code and a machine the size of top opening freezer to build it Machine provided the specific version of UNIX software necessary to build release l was given the task to build the release from source Not easy Case Study SourceExec Mismatch Case Study SourceExec Mismatch First set of problems SiXth set of problems Environmental variables and structure of source Telling my bosses code was not all set up correctly Told my boss at 9AM 39 Not too fr39ghtemng Explained evidence and writeup until 945 Second set of problems Not all makefiles called each other well and some makefile variables had to be defined Issue when up 4 levels of management above me 2 PM When can you leave for Californiaquot More serious Seventh set of problems Third set of problems Proving to Convergent there was a problem Executables built did not match executables being Denial vs 250 Million dollar check teSted I m I Seventh set of problems 39 A falled at 4398 bytes eXeCUtable t39mestamp Designing a reliable source code control and 39 Create a too39 to x this software manufacturing method EECS 44B 30 Dr Douglas Niehaus 2009 EECS 44B 32 Dr Douglas Niehaus 2009 Case Study SourceExec Mismatch Testing During PDM Eighth set of problems Test cases and outputs Convert entire UNIX release source to new Machine readable form methOd by myself Automatically executable preferably Prove it build exactly the same set of executables Automatically comparable to current output best as original source Bit for bit Minus timestamps Ninth set of problems Convincecoerce Convergent developers to use new system How it worked discussed in case study segment in tools discussions PDM changes often require expansion of test suite as well as modification of existing tests or results Regression testing absolutely crucial aspect of PDM EECS 44B 33 Dr Douglas Niehaus 2009 EECS 44B 35 Dr Douglas Niehaus 2009 Testing During PDM CASE Tools for PDM Unusual for PDM team to have been involved with PDM workers cannot keep track of version numbers original development for everything manually PDM lower status Tools support obviously required Personnel turnover in SW industry is nigh Source file version control for source code as well Maintainer generallll not already aware of how 3le tests and even documents Is commonly changes to one arti act will affect another Common Tools Ma39or ob39ect of stud J J y sccs Original Unix tool 1980 Time generally too restricted to complete such study of interactions RCS gt CVS gt SVN Open source versions Documentation often lacking Git BZR Hg etc are many other tools especially Comments those Isupporting distributed development without requiring connections to central servers Full record of all test cases and expected outcomes is thus vital EECS44B 34 Dr Douglas Niehaus 2009 EECS 44B 36 Dr Douglas Niehaus 2009 CASE Tools for PDM Metrics for PDM Source code control tools manage versions of Metrics for analysis design implementation testing individual files and perhaps sets of files and documentation a apply to PDM Content Management Systems add DB support for 39 Metrics SpeCifiC t0 PDM inClUde predUCt Version numbers correspondence to Measures related to software defect reports spec39f39c Vers39ons Of a Component 3995 Number classification severity duration 39 Huge number 0f Componelnts Current status metrics and Monthly or Yearly CCC change and configuration control also a term performance statistics used If an organization is not buying a complete CCC tool Then at least as version control CVS and build tool make must be used together Defect tracking DB is also mandatory for PDM EECS 44B 37 Dr Douglas Niehaus 2009 EECS 44B 39 Dr Douglas Niehaus 2009 CASE Tools for PDM Challenges for PDM Other useful tools can produce representations of Toughest aspects of PDM code structure for reverse engineering mm is usuany harder than devebpment 39 Rational Rose Together PDM work is often lower status and avoided by Doxygen those who can Disassemblers reverse compilers PDM is often paid less than other development wor Binutils objdump I Battlemap Teamwork Bachman Reengineering 39 FUtUre 39n uences I Product Set Greater use of formal technio1lues for development Defect tracking would have use implications or PDM Rational CearQuest Intensive code reuse Bugzilla Certainties Trac SWE will still be hard and fun if you like it EECS 44B 38 Dr Douglas Niehaus 2009 EECS 44B 40 Dr Douglas Niehaus 2009 Conclusions PDM is often given far less attention and credit than it deserves PDM very difficult and educational PDM is a common first job for developers Emphasize educational opportunities Prepare for difficulties EECS 448 41 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'