Class Note for EECS 448 with Professor Niehaus at KU 2
Class Note for EECS 448 with Professor Niehaus at KU 2
Popular in Course
Popular in Department
This 21 page Class Notes was uploaded by an elite notetaker on Friday February 6, 2015. The Class Notes belongs to a course at Kansas taught by a professor in Fall. Since its upload, it has received 22 views.
Reviews for Class Note for EECS 448 with Professor Niehaus at KU 2
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 02/06/15
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 4 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 eXPFeSSInQ ParthUlar concepts Classes are a vocabulary for describing the Additional constructs like these can be created to PFOdPCt componentS 3999an teSted by 399mg hOW model a specific system accurater well it permits describing the use cases Figure 121 Difficulty describing a use case means either 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 iass Control iass important component as it develops SWE s intuition EECSAAE 5 Dr Douglas Nlenans 2009 EECSAAE 5 Dr Douglas Nlehans 2009 Extracting Entity Classes Extracting Entity Classes Functional Modelling Work through specific Word type extraction from a written use case scenarios representing each of 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 ent39ty 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 Modening List operations performed by Verbs often denote cass methods invoked although each entity and what operations on an entity will be they can also sometlmes best be descrlbed by used by outside elements actors boundary control Independent SUbrOUtIneS n Statecharts are a popuar representation for 39 Adverbs Often denote method parameters affect method behavior but they can also denote multiple Iterative process interleaVing modelling types related methods EECSME 7 Dr Douglas Nlenaiis 2000 EECSME a Dr Douglas Nlenaiis 2000 Extracting Entity Classes Elevator Example Quick Elevator related example use case Functional Modelling A user pushes an up or down floor button which Collect use cases describing how actors interact tells the elevator controller that it should choose With a product an elevator and schedule a stop at that floor Actors are ogtside the product but are often Nouns button elevator controller user stop represented In the product In some way Adjectives Up Down Floor all button modifiers 39Oiien a boundary CiaSS Verbs push schedue In this case the most obvious actors are passengers Adverbs none Only two interactions with passengers Entity Ciass Press floor button Button up down floor elevator 39 Press and eieVaiOi bUiion ActorBoundary Ciass user uildinfg Fire glarml is atlesbs bvious actor but Controller class controller ese 0 en mo 39 y e eva or e av39or EECS 448 9 Dr Douglas Niehaus 2009 EECS 448 10 Dr Douglas Niehaus 2009 Elevator Example Elevator Example Scenario is a specific instantiation of a use case Specific scenario specifies details such as floor that Speci c set of iowesteve events may or may not distinguish it from other scenarios Usually a large number of scenarios 39 WOUid USing 268 Vs 379 matter HOW important the differences in event sequence 1 DbSZrOALgrle iershe Up floor button atlluorSlu iequestan elevator UserAwtshES are depends on the product and context i g3d r rf 32553B curl an rasse eeeva or u on or oor9 Normal scenarios describe a sequence of events 4 iieupnwimfn39istimeion when things are working well 3 11fi 35 3 f 395 9quot Exception scenarios describe a sequence 0i events 332Ef f is iif lii bumMamz when something goes wrong a Tlieelevalorbullonlorfloor7islurrtedon I I 9 The elevator doors close aflera tmcout Both are constructed by reasoning from first 10 Theeimrtmvelm wr7 1 The cievamrbullonim aar7islurned off prinCIples about the problem domain and by 12 ThetimimdompmmiowUSNmum imam obserVIng users at their actIVIties quot 32 gtigg fr memw 14 The elevator doors close after a timeout 15 The elevator piocccds to floor 9 with User B EECS 448 11 Dr Douglas Niehaus 2009 EECS 448 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 ml Izmez communicates communicates N elevators m Wquotquot 2m2 floor buttons 1 1 nJ Only 1 on bottom and top floors Button illuminated Boolean f Elevator Button Floor Button Elevator doors open Boolean EECS 448 16 Dr Douglas Niehaus 2009 Elevator Example Elevator Example Button Class Inserting controller more realistic All buttons have Illuminated attribute Changes Ciass teiations 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 EtevatotCtaSS Controller sends messages to Attribute doors open tracks door state Elevator floor ancgle39e fagqr 39 1 1 Might also have state variable describing floor Unions 6 evator Cor m 39Cator At least for floor indicator 39 NOt39CEG 139t039many and manYtO1 Might also be in controller class relat39ons between conther 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 least two ways be used to describe a set of classes derived using State Chart noun extraction Do not let detailsmechanics of a given approach 39 sequeme Object 39InteraCtlon D39agram distract you from meaning State Chart 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 Nietaus 2009 EEcs us 22 Dr Douglas Nietaus 2009 Dynamic Modelling Test WorkFlow First elevator Test WF applies to the set of functional problem state requirements entity classes and dynamic models Ekvllur Emu um chart iteration 312 1131 appear to be complete Specific WW For a given set of usecases scenario 9 quot i i 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 Nietaus 2009 EEcs us 24 Dr Douglas Nietaus 2009 traces a 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 cxoocwmy hwy LuN I EEcs 448 25 CLASS Elevator Controller RESPONSIBILITV Turn on elevator button Turn olf elevator button Turn on 007 button Turn off oor button Move elevator up one floor 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 Hevatur Dr Douglas Niehaus 2009 Refined Analysis Products CLASS Elevator Cnnlroller RESPONSIBILITY Send message m Elevator Doors to Start Iimcr Send message lo FJevatnr Doors to Check requests Update requests T P P 399 EquotPWN Send message to Elevath Button to tum on button Send message to Elevator Button to mm off button Send message to Flnor Button to turn on human Send message to Floor Button to turn of button Send message to Elevator to move up one lloor Send inenage to Elevator to move down one lluui open close after llmanul COLLABORATION Subclass Elevator Button Subclass Floor Button Class Elevator Doors Class Elevator soer Figure 129 EEcs 448 27 Dr Douglas Niehaus 2009 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 26 Dr Douglas Niehaus 2009 Refined Analysis Products Button riluminaieu Boolean 7 li Elevatov Button Floor Button mnl 2miZ controls control l 1 Elevator controller Elevator Donn requests mques ypt toriVols n doors Dpnn Boolean l i ccnlrols l n EIEVBIDI Figure 1210 EEcs 448 23 Dr Douglas Niehaus 2009 Extracting Boundary amp Control Classes Initial Functional Model Boundary classes are linked to concrete components Functional model of an application concentrates on and tend to be a bit easier to extract generating scenarios from the usecases Each O screen primed repen GU component Usecase diagram illustrates interactions among Granularity of the classes intended to maximize users and components 0f the prOdUCt as we as clarity of the usecase descriptions among PrOdUCt components GUI components as small as a sin le button or as 39 A Dealer SW prOdUCt large as an entire screen full of wi gets might Dealer IS the only user correspond to a Boundary class Customer is an actor Set of information and how it related to CO Both buyer and sener rOIes analysis is the determining factor Buying and Selling use cases Classes mIght be used to represent IndIVIdual users Art dealer can use product in 4 ways so there are Preferences or state within and interaction 4 use cases scena o Initial Functional Model Initial Functional Model when Oglest Scenarios depict component interactions Art Dealer Variations of use cases such as buying a painting Numbering of relevant sentences enhances Seller 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 Produce a Report Buyer UpdaLe d Fashionability Coef F i clent Figure 1212 EECS ME CH Dr Douglas Nlenans 2009 EECS ME 12 Dr Donghs Nlenans 2W Initial Functional Model Initial Functional Model Use cases subsume several related scenarios Oshert Oglesby wishes to buy a masterpiece L Osburt enters the description of the painting 2 The MWHE pronttn vans the ilurlinn retards to find the prire and year or the sale of ME most slmllar work by the same artist 3 the soltwere product computes the maxmum purchase price by adding 3 5 compounded annually for each year slnEE L Ir auEDnn or he most similar wnrk Oshert makes an offer below the maximum purchase przceAhE otter is ntcepled 3y the seller 4 Ostrert enters sales information name and address at seller purchase prrce Osbcn Oglcsby wishes to buy a masterpiece 1 Oshert enters the descripLiDrt oi the painting 2 The software pmdut scans the auction records to find the price and year ol the sale Di he most imllar work by the same artist 3 The software produn computes the maxImLm punhase price by adding 85 compounded annually lot ealt year SIVKE the auction of the must similar work Osberl makes an olier below the Tlaxilnum purchase price The seller turns down Osbell s ullel EEcs 44a 33 Dr Douglas Niehaus 2009 Initial Class Diagram Osbzrt Oglesby wishes to buy a masterpieze 1 csuerterrters the description at the paintlug 2 The software product scans the auction remrds te itrto the prrrc and year or the sale or the must similarwerk by the same artist 3 The serrwrre produn reports that there are he similar workx Osbert does not make an utter terthe painting Osharr Oglesby wishes to buy a masterpiece l Oshert enters the description ol the painting 2 The mflwan product scans me auction rcceas to line the price and your oi the 53 s of the most similar won by the same artist 3 The software product computes the maximum pulmasc price by adding 85 canpounded nnnunlly for cah year since the auction or the most similar work Owen mates an utter below the maximum purchase price the otter is accepted by the seller 4 Osbcrt enters sates information name and address of seller purchase p ice Possible alternatives A The seller furm down Oslx39t s 01121 a No allllilar pallltillg b llldl drllol is in the auction ltle 0 Other titres llul mutt m ol er for the painlirg EEcs 44a 34 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 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 Studying the use cases can lead to additional insight Masterwork has all attributes of masterpiece but needs additional information as well Fainting lass l I Masterpiaaz cum Masterwork In other Pnlntlng In EECS 448 37 Painting Class gt i Al l Maiterplece Class Other Palntlng Class r Masterwork Class Initial Class Diagram EECS 448 Gallery Painting Class r f Masterpiece Gas Palmlng Class other Pallltlllg Class Dr Douglas Niehaus 2009 Auctioned Painting Class Fashionability lass USES D t V Masterwork Class 39 Dr Douglas Niehaus 2009 Initial Class Diagram Need to distinguish gallery painting and painting auctioned worldwide add new classes Need to compare gallery paintings to similar paintings auctioned worldwide to determine prices Auctioned painting is a painting but has nothing to do with many aspects of paintings owned by gallery Fashionability class A painting of Other Painting class uses aninstance of fashionability for that artist to compute maximum price EECS 448 Initial Class Diagram Attributes of each class are added 38 Dr Douglas Niehaus 2009 Top level global class can contain attributes for the application as a whole Often good for holding invocation options in a wide range of applications Associated with starting execution of product as a whole Other classes represent types of paintings and associated attributes and operations Version leaving out attributes but using stereotypes of each is also a useful view EECS 448 40 Dr Douglas Niehaus 2009 Initial Class Diagram Initial Class Diagram um onus Awlmlxun a 7 QQ Dsberl Ogluhy Fainting Aupncallan lass class I I 20 unlit Analmad hulllung am Filnlhlgi am H Q 3 Muralum onquot sz nunblllly clan Pallung clm Inn I rummm Mislurwurk Ins EEcs 448 Al Dr Douglas Mlenaus 2009 EEcs MB Dr Douglas Mlenaus 2009 Initial Dynamic Model Initial Dynamic Model Dynamic modelling is the third step in extracting entity classes 0 Statechart is a compact representationof dynamic Walt behaVIor over several use case scenarios Statechart L Oshen Oglesby Event LDcp J Starting solid and Ending states solid circled buy sell mm mm pamrmg paintlng rppnrl imhinnahlliry rrows e IC erml e ranSI Ions selected suleueu Muted wleuml A d p t p tt dt t Start leads to event loop Duylngarainung I I SellingaFnintillg l urnuuclngaucponl Note correspondence to GUI event loop Updating Buyamasterplece I sell a maxtelplece Lrsuold palntlngs Fa hquotquot quotquoty mamawalls cr masterwarlf or bought paintings Upcarc ashionability gtkmaino oliwrpalnllllg ohm palnllllq or 1mm nelllclpnl Major states note name and narrative r Buying Selling Report Fashionability EEEAAE 41 Dr Douglas Mlenaus 2009 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 Control class methods grouping sets of related computations in some applications Might be methods of entity classes IMHO Art Dealer has four computations Masterpiece Price Masterwork Price Other Painting Price Trends Calculation Four initial control classes Computer Masterpiece Price Computer Masterwork Price Computer Other Painting Price and Computer Future Trends EEcsue w Dr mum Niehzusz g Refining the Use Cases As a set of classes is defined it needs to be checked against existing requirements and usecases Often reveals a need for refinement Checking the candidate Art Dealer classes against the proposed classes indicates that Buying a Painting and Producing a Report usecases should be refined Buying a Painting becomes Buy a Masterpiece Buy a Masterwork Buy Other Painting Each painting type has a different class with different information and so buying each is slightly different EEcsue 5n Dr mum Niehzusz g Refining the Use Cases Producing a Report use case becomes Produce a Purchase Report Produce a Sales Report Produce a Future Trends Report Key point is that the set of use cases should use all the major product components at least once Compilers exist that include instrumentation in emitted code to record and report the branch coverage of a set of software test cases Aim is to give a quantitative measure for how completely the software functions have been exercised Assumes correspondence of functions and code conditional branches which is often tenuous EEcsue 5i Dr mum Niehzusz g Third iteration of the product usecases is more complex Specification of each use case and set of scenarios obviously contains more detail than the diagram Buying separate painting L types does not require a separate interface for each Attribute or sub component of main purchase choice omen 991m An Dealer EEcsue 52 Dr mum Niehzusz g Refining the Use Cases Implications of refined use cases for other UML diagrams describing Art Dealer business model Splits the original Buya Paina39ng case into three separate use cases each representing a set of scenarios Art Dealer must supplychoose the classification of the painting to permit the SW to choose the correct class and associated software GTK entrycombo box does this Permits entering a choice as text or selection from a pulldown list Splits the Produce a Report case into three as well ms us 53 w my mm om Refining the Use Cases h m ed um m r m Wu n ikp Jdclxn c 039 mm t mlk you my mmummm mun mi 39lll v lll lulllIlvu minimif nridmwhwhr mm m in m 1 mmun mm m m mum m vri an v 50 wzr arodurlrd e um mamncwmrrnr fnznzerc b t m l u Llle lu 9 ul mull u no me pan u m or m y mm yr n Luwuui imiii llmm mm r orinmwar n rms39 imilmw1rk m n mpmrded m39um ix M 39l 1222 1 ll lhe wlFr mum hEll S we Dxbn 5m my n pmrnm MW I um Ntmur m tuw Max mi m pur wo nurt 1r3939mlnrd h hmilgirnlhm mi Al rurmw pm nrgsl yew 3 mp ms us 55 w my mm om Refining the Use Cases Buying a Masterpiece usecase example Knef Description mew Va m we hlvsc wmoulmbvm aquiVmsterpiEcE Slevrbyrsu Dummiun u Ushertmpu llwlvlnl uillvmimlrwieu39miswmi uiiiq L firstmma zmn mi meaning 0 Tlch m Height in t dlunv on wateicolcf my mad mvl s n mum mu life 1mm th may 2 chwmcp39oductmwoncis maximum pmrasepmmnmwmm limoredsmll theAcllmr p oaur39cnmpuw wnnim nivmm mwcen cam pmmg m mm mm K an nimmn rnmnl mu m mle We considc39stion 39crpurLl39zse Quexuon mmk m me am nrl ndme 1 0 mm of in me liU or dale m rh W m m n Wm EEES a so u mugs mmom Use Case Realization Use cases describe interaction among actors and the software product Utilized at the beginning of software life cycle in the requirements workflow Details are added as each case is refined and as new use cases are added Refinement includes a description of the classes used as part of each case as classes are defined During analysis and design workflows Use cases guide design and implementation because they must be supported by specific software components which implement specified semantics During the implementation workflow EEES us 55 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 scenario 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 teller prowdes dam entered by Osberl Seller Manerpieze i 0 an omen User Interface Compulg Q in Masterpiece Audioned Price lass Painting lax 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 Realization Use case scenario elements are realized as a set of Sequence diagram represents almost same set of actions among collaboration diagram obiects information as the collaboration diagram 7 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 om m K Kit a monk my mm m ensr J om r r imiuu updnz m 5221 quot showing when object was active H Wan Sequence diagrams are thus capable of showing concurrent execution in multithreaded systems Important in other applications not relevant in 448 project and examples mm s D We mm was a u wismmm Use Case Realization Use Case Realization Sequence diagrams can take more room Strengths of a sequence diagram 39 Use WhiCheVer communicates 1051 Clearly Shows the flow of information unambiguously O Q Ordering of messages is clear Shows that every transfer of information in one BMquot direction is followed by a transfer in the other i Mama 5 i Possibly just a method invocation return code i Sequence diagram tends to be better at describing a m Wm 11 the transfer of information ETZ LKVDW 3 Focus for much of the time in the Analysis WF ragga i i i Collaboration diagrams tend to permit j concentrating on the classes better Lawv ifl wwq 1 correspondence of Class and Collaboration WW t Diagrams is useful Ezcsus 63 Dr mugas limmsm ms us 64 hr Douglas quotImmsm Use Case Realization Use Case Realization Buy Other Painting use case Other use cases are quite simple and so their class Similar in structure to other cases but different diagrams and collaborationsequence diagrams re classes are used and low level set of events is basically trivial too different in collaboration or sequence diagrams At some point you may elect no to create them dafyggfe39lrgrdpggvggse Prudent when it saves time Q Painful when it overlooks important details Judgement is involved and both types of Selle Q mistake are common O Other I Painting class I Q Q Q bm User Interface Gallery Painting Purchases Report Class Class Class osber t User Interface ompule Class Other Painting Price lass Fashionagi39 ty osherquot User lrltalsesrlaze Galler la lmtlng Salealallport lass EECS 448 65 Dr Douglas Niehaus 2009 EECS 448 66 Dr Douglas Niehaus 2009 Use Case Realization Incremental Improvement Future Trends Report slightly less trivial Several incremental improvement steps have increased the information content of the class Q diagram reflecting the set of product classes 7 Entity Boundary and Control class extraction Gallery Painting cum Interrelationships among classes Inheritance Use Information in various class diagrams combined i First use case information is included Then class inheritance relations can be added and Osbert User Interface Compute Future Trends any additional classes Class Future Trends Report Class Class EECS 448 67 Dr Douglas Niehaus 2009 EECS 448 68 Dr Douglas Niehaus 2009 Incremental Improvement Manama Mmemlm Clan Inn EEcs Ma Dr Douglas Mlahaus 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 EEcs Ma 71 Dr Douglas Mlahaus zone Incremental Improvement Id 1 an auau j plasma EEcs ME 70 Dr Douglas Mlahaus 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 Mlahaus 2009 Test WorkFlow Specs Document in Unified Process Anal sis WF of the art dealer product can be chec ed in two ways Classes and their relations can be checked by taking another view of situation using CRC cards All artifacts of Analysis WF can be inspected By all group members individually or together By SQA alone or with development By customer All checking is still inspection ratherthat execution because no software eXIsts generally RP might exist but it addresses limited issues Proofofconcept code may exist but it I demonstrates capabilities and test assumptions Not product features EECS 44B 73 Dr Douglas Niehaus 2009 Specs Document in Unified Process Unified process is use case driven Use cases and artifacts derived from them contain all information appearing in tradition specs doc Generall convey more information more accurate y to customer Collection of artifacts for complete product constitutes contract between client and developers Traditional specifications document usually played contractual role Interaction diagrams reflecting classes that realize use case scenarios are shown to client Replaces some of RP uses RP better for GUI diagrams could be used EECS 44B 74 Dr Douglas Niehaus 2009 More on Actors and Use Cases Why 448 will build a RP ProofofConcept for GUI SW related to widget use look and fell etc 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 A use case illustrates interaction among software components and actors 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 EECS 44B 76 Dr Douglas Niehaus 2009 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 44B 78 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
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'