DRE-PlugIns For Together Control Center User Manual
Contents
1. DIR B DRE Ftugns E ORE Toot 3 ORE Toot ORE UML E ORE UML El Esrly Access AECE AECE E vos con EN crea Parentis abstract no behavior sequence Concret descandant O Sample 3 El system ays must supply behavior VES Order Product Y ee YEAR AAA E A ES ACERA C Sorted by Wernings C Use Case Warnings 0 a C ucClass Wernings 0 E E Class Weenings 1 E Component Warnings S E Sorted by Bemerts Cuse Cases 0 Classes 1 CI components 5 Ci ore ey Figure 8 DRE Warnings Affected Elements Description Refactoring Guideline Warnings el miL ji y ls The Warnings Pane is organized in the following way On the left side you see a tree with all warnings Basically there are two trees one sorted by Warning type and one sorted by Elements You can use the first one if you want to track down warnings of a specific kind The second one should be used to track down warnings for a certain Use Case Class or Component After selecting a warning the boxes on the right side show more information about it 2 Affected Elements Shows a list of all elements that are affected by this warning If you click on one of those the corresponding diagram will be shown automatically with the element selected this works only if the diagram is already open 2 Description Provides a description2. and Component Interfaces we need to define that Definition 6 Each Component Interfaces gets assigned a set of Class Interfaces which are the Class Interfaces Abstract Classes that the Component Interface represents As Components are supposed to be easily replaceable and plug able it makes no real sense to assign generalities to Components because the definition of a Component itself makes it general in any case Based on the Definitions shown above we get the following properties Property 11 A component is related to a set of Classes Cc Classes in Cc have relations between them The relations between the classes form one or more graphs As we want a component to be cohesive there should only be one relation graph RGS amp To refactor property 1 the software engineer should either establish relations between the graphs or split the component into several components which don t violate Property 1 any more Property 12 A class Cc in Cc is related or coupled to a class Co of another component If Co is not a Fagade Class or a Class Interface of the Interface that the other component implements there has to be a refactoring RG9Y The software engineer either has to remove the relation coupling form Cc to Co or make the Co a Facade Class or Class Interface of an implemented Interface Property 13 A class Cc in Cc is related or coupled to a Fagade Class or a Class Interface of another component but there is no dependen
3. of the warning 22 Refactoring Guideline Provides one or more refactoring guidelines for the currently selected warning fer oy Sorted ny warnings use Case Wernings 0 LJ uc Class Wernings 0 E class Werninas 1 A Component Warnings 5 E E Cohesion Pt R68 1 D Component E CI Gass relation violation P12 RGS 4 E Sorted by Bemerts EJ use cases 0 WA tc ibi Affected Elements Component CLClass3 CLClass4 Description The used classes form 2 cohesive parts Cohesive are lt lt Class3 gt gt lt lt Class4 gt gt Refactoring Guideline Enher related the classes so that they form one cohesive part or spit the component Figure 9 DRE Warnings 13 As you can see in the figure the nodes in the tree provide a link to the properties and refactoring guidelines of the underlying theory e g P11 RG8 This additional information may help you improve the reuse potential of your design The DRE UML runs it s warning based on the following properties 2 Use Case Diagrams o Generalities o Dependencies to other Use Cases include extend generalize o Related Classes 2 Class Diagrams O Generalities o Dependencies to other Classes association dependency generalization O Related Classes 22 Sequence Collaboration Diagrams O Method invocations 2 Component Diagrams O O O O Related Classes Facade Classes Implemented Inte
4. B Guc a Property 6 UCA generalizes UCg is a relation of a specialized UCs to a more general UCa meaning that UCs is at most as general UCA or Guc a Guc The refactoring guidelines RG1 RG2 To enforce Property 4 or Property 5 the refactoring rule is If Guc gt Guc a then refactor by making UCg more general so that Guc Guc a or UCA more specific so that Guc a Guc a or by removing the extend include RG3 To enforce Property 6 the refactoring rule is If Guc a gt Guc a then refactor by making UCA more general so that Guc a Guc or UCz more specific so that Guc a Guc z or by removing the generality 2 2 Dependencies between Use Cases and Classes Both Use Cases and Classes have generality levels G Use Cases are related to a set of classes Ca that realize the Use Case Also Classes are related to other classes We get the following properties and refactoring guidelines Property 7 Suppose that UCA is related to a set of classes C4 C C2 Cy for some n Then the generality of UC must be as specific as the most specific class in Ca and may be more specific i e Guc a max generality C Ca RG4 To enforce Property 7 the refactoring rule is generality change of UCA or one or more G Ca until Guc a max generality C Ca or the removal of all classes in Ca that cause the Guc a max generality C Ca to be violated Property 8 Suppose that UC is related to C4 and UC is relat
5. DRE Plugins For Together Control Center User Manual 1 2 3 4 Table of Contents IntrodUchON sesini a sidad ida ei 3 A O ET 3 2 1 Dependencies between Use Cassi ia 3 2 2 Dependencies between Use Cases and Classes ccssccccccceeeeeeeennceeeeeeeeeeeeees 4 2 3 Dependencies between Classes sssnsesssssssseesreesssssseerreersssssserereessssssseerreeesss 5 ZA ACOMIPONEIS eii 6 Installation iii anida aio 8 DRE Pl s Mns USAGE soii coi 9 4 1 Generality Evelio 9 AD Use Lasuna oi 9 4 3 A Rae Re PRO ee SEN BESS Cre ee eee Tee eee eee 10 JA MOT POITE TIS 55h Syriac aie Sasa vedat Gala acoso etnias belo 11 AS R n DREUM ie OR 12 46 RUN RE OO ose tae acs Maas ca cc eae acces dt dd le E 15 1 Introduction The DRE PlugIns for TCC help assessing reuse potential during the design and coding phase of software development We provide two PlugIns for TCC namely DRE UML and DRE Tool DRE UML enables the user to set generalities for Use Cases and Classes define relations between Use Cases and Classes define relations between Classes define relations between Components and Classes and finally run a measurement on the design to assess reuse potential and provide refactoring guidelines DRE Tool crafts a bridge between TCC and the standalone DRE It ships over project information generalities and relations between classes Using these one can use the standalone DRE to run reusability metrics in code This user manual is or
6. T it Help 07 15 02 17 32 1 423 59 All Files y doc 05 07 02 20 45 177 23 A1 Files help 07 15 02 17 28 801 51 qd 07 15 02 17 23 786 50 I Overwrite Existing Files TO 2 07 15 02 17 28 801 51 oy i a son 3 07 15 02 17 29 786 50 ish 07 15 02 17 28 8626 52 4 lt gt New Folder slected 0 files 0 bytes T Total 40 files 112KB 00 Figure 1 Make sure to use Folder Names After doing that the DRE UML PlugIn should run without problems To get the DRE Tool PlugIn running you have to modify a configuration file to match your installation path of the standalone DRE Open Together modules com togethersoft modules dretool Manifest mf in an arbitrary editor What you ll see should look like this Name DRE Tool Time User Main Class com togethersoft modules dretool newDR Class Path TGH com togethersoft modules dretool c DR Folder DRE PlugIns You have to change Class Path so that TCC can find the standalone DRE In this case it is installed in c DRE El 4 DRE Plugins Usage This section shows you how to use the DRE PlugIns in TCC According to the underlying theory you have to set several DRE properties for Use Cases and Classes 4 1 Generality Levels The DRE PlugIns support different numbers of generality levels for each project The default number is four If you need more or less generality levels for your project you can change this value Open the Project opti
7. cy link to the other component or the interface it implements RG1O Either remove the relation coupling or introduce a dependency link to the other component or one of its interfaces 3 Installation As a prerequisite for the DRE PlugIns you need an installed TCC 5 5 or higher www togethersoft com If you want to use DRE Tool PlugIn you also need an installed DRE which is available at our website The installation of the DRE PlugIns is pretty simple If not done yet download the DRE PlugIn ZIP form our webpage http www engr uconn edu steve DRE tcc html Unzip DRE_TCC_Plugin zip into your TCC installation folder Make sure to use the folder information of the ZIP so that the files get into the right directories For example You installed TCC to C Program Files Together Unzip DRE_TCC_Plugin zip to C Program Files Together as Els se Ewe View CheckOut Wizard Date Time Size Ratio Packed Path 07 15 02 17 32 604 44 339 modules com togethersoft modules dreextension A 07 15 02 17 28 5 327 60 2 137 modulesicomitogethersoftimodulestinspectoridre_class extension 07 15 02 17 23 5 036 60 2 0 07 15 02 17 32 8 021 57 34 07 15 02 17 36 541 65 a 07 15 02 17 32 1540 44 9 al dosis 07 15 02 17 32 431 28 C Program Files T ogeth y gt E Together a ae relass 07 15 02 17 32 1 381 60 Files aie __ Caneel 07 15 02 17 32 16 589 57 c 3 07 15 02 17 32 1 440 53 FA
8. ed to Cg If UCA is related to UCg extend include or generalize see Section 3 1 then there has to be at least one transitive relation chain from one C Ca to one Cj Cp RG5 To enforce Property 8 the refactoring rule is add one or more dependencies between class es C Ca and class es Cj Cp Property 9 Suppose that UC is related to C4 and UC is related to Cg and that UCA is not related to UCz that is there is not an extend include or generalize relation Then if at least one C Ca is related directly meaning not by transitive relation chain to at least one C Cp there must be a refactoring to correct the problem RG6 To enforce Property 9 the refactoring rule is make UC related to UCz or remove all dependencies between all C Ca and all Cj Cp Property 10 Suppose that UC is related to C4 Then for all C Ca if there is a transitive relation chain from C to some C Ca then UC must also be related to C in some manner UC can be either related directly to C or it can be related to some UCz to which C is related RG7 To enforce Property 10 the refactoring rule is C Ca related to some Cj Ca include Cj in C4 Ca Cy C or relate UC to some UCg where C Cp or unrelate UC to C ss Ca C 2 3 Dependencies between Classes Again classes get assigned a level of generality Also we want to relate classes to other classes meaning that these classes are intended to work togeth
9. er On the other hand we get couplings between classes by UML associations and dependencies attributes method signatures method invocations and later on in the source code We define the following properties Property 1 In an inheritance hierarchy the parent class is equally general or more general than its children meaning that children have at least the reusability level of the parent plus optional specific less general method s For example Walmartltem 1s less general than its ancestor Item Property 2 The generality level of a class is equal to the generality level of the least reusable coupled class Given two classes C and C with generality levels G and G there are two cases C is more specific than C G gt Gg in which case C is the least reusable class and C is more general than C Gp lt G If there is a coupling from C to C Cp may be dependent on specific features of C that will condition the reusability of C to situations when C is reusable i e the generality level of C must be equal to or greater than the reusability level of C Property 3 Couplings between unrelated classes are undesirable and hinder reuse since unrelated classes are not intended to be reused together in future applications If there are dependencies among unrelated classes the coupled classes must be brought along to the reusing application in order for the system to function properly which contradicts the intent of not r
10. eusing the components together We also the following coupling types where G means General and S means Specific if we have more than two levels we only compare two generalities so they can be seen as just general and specific Type 1 G G among related classes is an asset to reuse the two classes are to be reused together and the objective is to increase these couplings Type 2 G G among unrelated classes is undesirable since the source and destination are not expected to be reused together Refactor by moving both the source and destination to Specific descendant classes or making classes related Type 3 G S among related classes is undesirable since the General class to be reused depends on a class which is not expected to be reused Refactor by moving the source to a Specific descendant or destination to a General ancestor Type 4 G S among unrelated classes is undesirable since the source is expected to be reused while the destination is not Refactor by moving the source to a Specific descendant class Type 5 S G among related classes does not hinder reuse since the source of the coupling is not expected to be reused Refactor to improve reuse by moving the source to a General ancestor Type 6 S G among unrelated classes does not hinder reuse since the source of the coupling is not expected to be reused There is no need to refactor in this case Type 7 S S among related classes does not hinder reuse since
11. ganized in the following way section two gives a short introduction to the underlying theory section three contains installation instructions and section four finally shows how to use the DRE PlugIns 2 Theory This chapter is only supposed to give a quick and short overview of the underlying theory For more detailed information check out the following paper on our website F Eickhoff J Ellis S Demurjian D Needham A Reuse Definition Assessment and Analysis Framework for UML To assess the reuse potential of a design we take measurements on four different levels 2 Dependencies between Use Cases 22 Dependencies between Use Cases and Classes 2 Dependencies between Classes 22 Dependencies between Components and Classes For all dependencies we defined a set of properties and according refactoring guidelines The properties listed in the remainder of this section are borrowed from our paper 2 1 Dependencies between Use Cases Each Use Case gets assigned a level of generality G Dependencies between Use Case are established by lt include gt lt extend gt lt generalize gt Therefore we get the following properties Property 4 UCA extends UCg is a relation in which UCA adds behavior to UCp meaning that UCA is at most as general as UCs or Guc s Guc a Property 5 UCA includes UCs is a relation of the behavior sequence of the supplier UCs into the interaction sequence UCA meaning that UC is at most as general as UC or Guc
12. lated classes and the Use Cases that use this class 10 Properties of Class1 Level of Generality Related to classes Utilized by Use Cases Related To Supply Customer Data Pace Order Order Product Arrange Payment Cash Payment Credit Payment el Press Ctrl Figure 5 Class Inspector and Setting relations to Use Cases 4 4 Components To set the DRE properties for Components you also have to use the Inspector dialog s DRE Page There you can set the Classes that are used by the component and its fa ade classes Setting the properties for the Component Interfaces works the same way Open the Inspector for the Component Interface and select the DRE Page There you can set the implemented interfaces 11 Properties of Component Related To Class1 Class2 Figure 6 Component Inspector and relating Used Classes 4 5 Run DRE UML Once you have set all necessary DRE properties for Use Cases Classes and Components you can run the reuse assessment by selecting the TCC Modules Tab open the DREPuglns folder right click DRE UML and select run Together 5 5 UML and Reuse File Edit ec Search View Options Tc alee NTE E 3 All Modules E El DRE Plugins E DRE Too E Sample El System Figure 7 Run the DRE UML The results are shown in the DRE Warnings pane 12 IS Together 5 5 Fle Edt obec untitled8 Search View Options Tools Hep
13. ons dialog of TCC Menu Options Project Options The following dialog will show up Project options General Diagram Hi Levels of Generality EA DRE View Management Source Code GA Print Text Editor Generate HTML Run Debug 3P P P 3P P 3P SP 3P aP Description Number of different generality levels Figure 2 Set number of generality levels Select the DRE Folder and enter the desired value 4 2 Use Cases For each Use Case you have to set the level of generality To do that open the Inspector Dialog for the Use Case and select the DRE Page Using the Drop down Box you can set the generality Properties of Supply Customer Data _ G2 Level of Generality Related to classes el Press Ctrl Enter to finish editing and close Inspector Figure 3 Setting the generality for a Use Case Also you have to relate Classes to any Use Cases that they will realize To do that open the Inspector Dialog of the Use Case and select the DRE Page Press the button right of the Related to Classes edit field to relate classes to this Use Case Related to classes Source Related To Order_Container__G4 Payment__GO Figure 4 Relate a Use Case to Classes 4 3 Classes Setting the DRE properties for Classes works basically the same way as for Use Cases Open the Inspector Dialog for a Class and select the DRE Page There you can set the generality the re
14. rfaces Dependencies between Components and Interfaces 14 4 6 Run DRE Tool In order to run the DRE Tool you have to have generalities of classes and relations between classes set As the DRE Tool works on source code you should have at least some code It is not necessary to mark the Use Cases if you only want to use the DRE Tool To run the DRE Tool select the TCC Modules Tab open the DREPugIns folder right click DRE Tool and select run The standalone DRE Tool shows up and you can run measurements on your code Changes of generalities or relationships between classes are shipped back to TCC as soon as you close the DRE Tool IA 2e A Be E ES ERE PVF wl LE Ol a a S pe S eed 3 ES Bona A Power orf 2 new oz o jeej Ersan ao a E E El Eady AcOSSS A pe er O tE BE Kast asa E Senge zi i gt 4 LATA gt l System gt A SDRF v2 05 tallers 63 Project Option Hep Olea gt E Project a Cors__02 8 Cooh_Poynet_Gt Ss Caida e SS Conputers_G3 MS Crot Paynet _ E ea Customer G1 208_A00883_02 Hen_0B_62 H aw ane WA a Ha LLEI MERA Figure 10 DRE Tool started from TCC 15
15. the source of coupling is not expected to be reused Refactor to improve reuse if both the source and destination are moved to their General ancestors Type 8 S S among unrelated classes represents the desired situation for couplings between unrelated classes they need to be among the Specific classes 2 4 Components Component Diagrams offer another opportunity to assess reuse potential Using UML Component diagrams the developer can model components the interfaces they implement and the dependencies between components In general UML components don t have to contain classes or code They can just represent physical units of a system But for our approach we consider components as a collaboration of classes which together provide a coherent functionality Definition 4 A Component is related to a set of Classes Cc which implement the Components functionality and behavior As components are self contained physical units it should be easy to replace a component with another To achieve that we need low couplings between components Therefore components should only be accessed through the interfaces they implement or through classes that act as facades for the component Definition 5 Each Component gets assigned a set of Classes which act as facades for the component and hide the implementation details of the component As the UML does not define relations between Class interfaces meaning Interfaces Abstract Classes in code
Download Pdf Manuals
Related Search