Limitations in Mapping from UML to Java Shakeel Sadiq Computer Science (2002/2003)

Transcription

1 Limitations in Mapping from UML to Java Shakeel Sadiq Computer Science (2002/2003) The candidate confirms that the work submitted is their own and the appropriate credit has been given where reference has been made to the work of others. I understand that failure to attribute material which is obtained from another source may be considered as plagiarism. (Signature of student)

2 SUMMARY Planning is an essential activity in any task to be undertaken. So much so, that without it a task can quite quickly become an utter disarray. Likewise, design is crucial, and a prerequisite, if one is to produce efficient code. It is also easier and cheaper to modify a design model than to make rectifications once implementation is well under way. This report summarises a research based Final Year Undergraduate Project which set out to investigate why it is often the case that the design aspect of software or a system and its actual implementation do not represent the same concepts. The approach taken was to attempt to implement in Java a set of class diagrams created using the UML. The purpose of attempting such mappings was to highlight which constructs were mapped to Java with ease and clarity and which provided problems. The project then analysed these constructs and looked to provide solutions so that the logical gap between the diagram and the code could be diminished. I

3 ACKNOWLEDGEMENTS First and foremost I would like to say that all praise is due to Allah who makes all things happen. I thank him for everything in my life. My parents have helped me through everything and have been there for me through all situations. I respect and appreciated their presence and cannot thank them enough. I would like to thank Eric Atwell and John Davy for his helpful hints at a vital stage of the project. II

4 TABLE OF CONTENTS SUMMARY ACKNOWLEDGEMENTS I II 1. INTRODUCTION 1.1 STATEMENT OF THE PROBLEM 1.2 PROJECT PURPOSE AIM MINIMUM REQUIREMENTS POSSIBLE ENHANCEMENTS SCOPE 1.3 METHODOLOGY BACKGROUND 2.1 RELEVANCE TO DEGREE PROGRAM 2.2 PREVIOUS ATTEMPTS AT THIS OR SIMILAR PROBLEMS 2.3 MOTIVATION 2.4 LITERATURE SEARCH AN INSIGHT INTO UML 3.1 INTRODUCTION 3.2 CLASS DIAGRAMS USES UML CONSTRUCTS AVAILABLE FOR CLASS DIAGRAMS Attributes and Operations Visibility Association Multiplicities Generalization Aggregation and Composition Qualified Associations Derived Associations Association Classes III

5 Interfaces Abstract Classes Constraints Parameterised classes Components and packages Summary EQUIVALENCE IN JAVA 4.1 INTRODUCTION 4.2 CLEARLY CORRESPONDING CODE FOR CONSTRUCTS Classes Packages Interfaces Associations Composition Association Stereotypes Association Qualifiers Inheritance Constraints Summary 4.3 CODE FOR WHICH THERE IS NO CONSTRUCTS 4.4 CONSTRUCTS FOR WHICH CODE IS NOT APPARENT Multiplicity Templates Aggregation Multiple Inheritance Summary ANALYSIS OF UNCLEAR MAPPINGS 5.1 INTRODUCTION 5.2 CLOSER LOOK AT THESE CONSTRUCTS Parameterized classes Multiple inheritance Aggregation IV

6 5.2.4 Multiplicity Summary 5.3 POSSIBLE IMPROVEMENTS TO UML Multiple inheritance Aggregation Summary 5.4 POSSIBLE IMPROVEMENTS TO JAVA Parameterized classes Multiplicity Summary CONCLUSIONS AND FURTHER WORK EVALUATION 7.1 INTRODUCTION 7.2 ROLE OF THE UML 7.3 ROLE OF INDIVIDUALS 7.4 PROJECT MANAGEMENT Initial Plan of Work Amendments to Schedule Summary 7.5 EVALUATION CRITERIA APPENDIX A Dealing with third parties Reflection APPENDIX B 73 APPENDIX C 75 BIBLIOGRAPHY 76 V

7 LIST OF FIGURES Section Description Page Class Model General Association Multiplicities Generalization Multiple Generalization Aggregation Composition Qualified Association Derived Association Association Class Interface Interface Interface with dependency and stereotypes Abstract Class Constraint Parameterized Class Package Class diagram with corresponding Java Code Bi-directional Association Class displaying naming convention A package with an Interface and its corresponding Java implementation An Interface with its Java implementation Unidirectional Link with Java implementation Association Class Implementation of Association shown in Figure Implementation of a Singleton Object Composition and its Java implementation Composition Common Stereotypes An Association Qualifier and its Java Implementation Single Generalization and its implementation Multiplicity and its implementation Aggregation in action Multiplicity in action State changes in deletion and addition of links Multiple Inheritance Converted from Multiple Inheritance 55 VI

8 1 INTRODUCTION 1.1 STATEMENT OF THE PROBLEM There is often a lack of consistency between design and code. In specific, the design as represented by the Unified Modelling Language (UML) and the code as constructed in the Java programming language. This issue can no doubt have negative consequences when one is undertaking the development of a piece of software of any magnitude. Hence, this project shall attempt to diminish this gap between the conceptual design and the implemented code by analysing the process of mapping from a UML class diagram to Java source code. 1.2 PROJECT PURPOSE AIM The aim of the project will be to highlight and analyse what a UML class diagram may contain which could cause potential problems when being mapped to Java. It is essentially attempting to identify the limitations that exist when converting UML constructs or concepts to Java source code. Having identified and analysed these constructs, the aim is to provide solutions to clarify the mapping for those constructs which currently have an unclear mapping to Java MINIMUM REQUIREMENTS To identify primitive constructs in UML To gather a corpus of UML diagrams and corresponding Java implementation For each primitive construct in UML, seek some representative example and some corresponding Java code in my corpus An analysis of the above results POSSIBLE ENHANCEMENTS A possible enhancement could be to produce software that attempts to overcome the issues raised. This would attempt to take the theoretical work a step further and implement a tool which maps UML to Java code in a more accurate fashion than is already done. 1

9 A further enhancement could be to cover other areas of the UML that have not initially planned to deal with in this project, such as Building Web applications with the UML SCOPE The project deals with class diagrams only as opposed to any other diagrams as defined by the UML. Also, not all the available constructs will be considered. The constructs shall be limited to those that are relevant to the discussion at hand and it shall be clearly stated what these constructs are. Furthermore the mapping stage shall be limited to the manual mapping of a construct from the UML to Java. In other words no software, i.e. CASE tool, will be used to perform the mapping and hence the project shall be limited to a paper-based study. 1.3 METHODOLOGY The project utilises a methodology based on a collection of UML class diagrams and corresponding Java code. Such a methodology shall aid in easing the process as well as ensuring efficiency and accuracy of work from start to conclusion. Also, a methodology of this type is ideal for a project of this nature due to it involving the analysis of the collection of diagrams and code obtained. In other words, a diagram representing a certain construct is chosen from the collection and then an attempt is made to find the equivalent piece of code, again from the collection. Therefore, the flow of work is decided by whether or not a clear correspondence is established between the code and the UML; for an unclear correspondence there is a requirement to analyse why this is the case. This also allows for conclusions to be consolidated with real examples. The justification of such an approach is that examples are essential in such a project. It is a lot more efficient and concise to explain the clarity, or lack of clarity, between a UML construct and Java code, if it can be seen both graphically and explained with theoretical explanations. It also allows the reader to relate to the project as they may have come across similar examples. The background reading showed there to be some existing documentation of graphical and theoretical examples of UML constructs and their mapping to Java. Therefore, such information only motivated the use of this methodology further. 2

10 Another possible methodology involves the use of a tool in order to carry out code generation. It begins with a construct, as done in the chosen methodology, and results in Java code, again as done in the chosen methodology. However, this approach was refused as it was felt that many limitations in the mapping would have been clouded by the limitations in the tool itself as opposed to the languages themselves. Previous knowledge on the capabilities of a tool that produces source code led to the belief that such a methodology would not have allowed a progression in the project to the depth desired. 3

11 2 BACKGROUND 2.1 RELEVANCE TO DEGREE PROGRAM This project is relevant to my degree program, i.e. Computer Science, due to its content of the Unified Modelling Language and Java. Java is a language that I have studied previously in SO21: Object-Orientated Programming but have a preference to look more closely at some of its concepts and content. Therefore this is an opportunity for me to go over, and more importantly expand, on what has already been taught. Furthermore, The UML is again a language that has been done in SO21: Object-Orientated Programming, though not to the extent that I wished it to be taught. Hence, again this is a chance to expand on existing knowledge in an area of interest covered in my degree program. 2.2 PREVIOUS ATTEMPTS AT THIS OR SIMILAR PROBLEMS This section discusses existing work done in the proposed area of research of this project. This allows for the distinction of how this project extended or differed from work done previously. It also displays the completeness of the existing work, based on what this project wishes to achieve. Hence the sources considered here tackled, in some form or another, the question of mapping from UML to Java. [10] documents a proposed methodology of a tool mapping from UML diagrams to Java. It does not provide any background to the UML nor are there any examples or discussion of the general mapping from UML to Java as this is assumed knowledge. However it was seen as one possible solution to the problem being tackled within this report. This is because it does highlight and concentrate on specific areas in Java where a UML mapping could cause problems or where certain issues could arise. Therefore in the proposed implementation of the tool it has considered and brought up areas that were expand on within this project. Although this paper has been created by employees of IBM and may have a flavour of advertising within it, it is never the less very useful. Chapter 3 of [14] discusses what should be considered when developing a design for Java implementation. It also looks at correspondence between what is in the UML and how it can be implemented in Java. It therefore provided a good platform for the discussion to be pursued in 4

12 this report. It does however lack detail as graphical and theoretical examples are not always provided. Furthermore it does not take the issues further by providing solutions to the limitations it has raised. In any case, as stated, it was a solid base on which the development of this project took place [26] provides graphical examples of UML and the corresponding Java code, hence was no doubt valuable for use in this project. It also provides a brief explanation with each of these mappings, however, as stated; this is only brief and not concise. Also, it fails to take the process further by providing an insight into the unclear mappings. [11] declares that There are several well-known problem areas in the UML (Version 1.3). [11] This sets the tone of the article. However it is not simply a paper stating what problems were identified at the conference, but is more interested in providing constructive criticism. Along with the problem areas identified recommendations are provided in order to improve future versions of the OMG s modelling language [11]. This article was not seen to directly aid in identifying problems in mapping from UML to Java, however it gave weight to the case that problems or issues may be in the definitions or usage of the UML and are magnified when a mapping to a language such as Java takes place. Therefore, it is a piece of work done in a relevant, though only captured one end of the argument. [9] is again a paper which deals with the ambiguities in the UML, however only concentrates on associations. Even though it again captures only one side of the argument, its input is vital as it looks at possible problems in the latest release of UML, UML 1.4, and provides a concise explanation with possible solutions. The above discussion highlights that even though many of the areas proposed to be researched in this project may have been covered separately; they were incomplete in accordance with the aims of this project. They did not cover the complete line of work that was desired, i.e. beginning from a background section, on UML, working through mapping to Java and continuing through to possible solutions in unclear mapping of constructs. Hence, this report intended to collate existing work; however more importantly to expand on areas that were not covered by these existing pieces of work. 5

13 2.3 MOTIVATION An obvious background area, amongst those discussed in section 2.2 would have been the theoretical approach creators of CASE tools take before implementing the tools. Such work should state what aspects of mapping from UML to Java are considered, and so again would have been relevant with respect to the aims of this report. However, it was found that such information either did not exist or was not very well documented. The lack of access to such information only motivated this project further as one single report was to be compiled which contained the bare essential of background knowledge required, as well as graphical and textual examples of mapping from UML to Java. Also, guidelines and solutions were to be provided, depending on whether correspondence between the UML and Java was clear or unclear. Further motivation arose from personal reading and experience, especially a 12 month placement as a software engineer. Such personal experience provided an insight into how it often occurs that there is a gap or discrepancies between design and code. In other words the UML diagrams and the Java code are out of sync. This obviously could be for several reasons, though the research for this project aimed to reduce this element of difference between the languages. Furthermore, as mentioned earlier, the expanding of knowledge on UML and Java was a motivation in itself. By undertaking this project, there was a requirement to dwell into the various constructs and concepts in UML as well as the coding concepts of Java. In order to make the comparisons there was a need to gather and analyse UML class diagrams which represented many aspects of UML. Hand in hand with this was a need to analyse the corresponding Java code. Therefore, several opportunities existed to deepen existing knowledge and interest in these areas. 2.4 LITERATURE SEARCH In order to complete the project, a systematic form of literature gathering was essential. Initial steps were to simply look at the UML. The aim was to gather enough sources dedicated to the UML itself and also that the sources provided both graphical and theoretical explanations. The result was the gathering of information from textbooks, articles and forums. Many examples in the background to UML were taken from [33], with [24] also being used. The reason for extracting examples from text books was that as they exist and are well documented, it was 6

14 pointless to create more. [29], [31] are websites of well recognised companies related to the UML, in one form or the other, and so provided valuable and relevant information. The next stage was to collect information on Java. A sensible starting point was [18] which provided information on the background to the creation of Java; aims and justifications. Also, the reason for researching Java was that when attempting to map a construct from the UML, the Java equivalence must be understood clearly in order to verify whether or not the mapping was successful. Therefore [3] was instrumental in the phase of assembling information on the Java as it deals with not only the syntax of Java, with use of an extensive case study, but also looks at object modelling featuring UML. Also, as modifications to Java were a possibility, [17], [20] were identified in order to keep up to date with such proceedings as modifications or additions to Java. The next logical phase of information gathering was to look at the actual mapping of UML to Java; however this was dealt with in section 2.2. The following steps were to analyse results and to provide possible solutions, which inevitably required the analysis of the UML constructs causing unclear mappings to Java. To undertake these steps, forums were of great importance as they embody the ideas and debates of experienced and knowledgeable individuals. Therefore, [24], [21] were used to gather ideas and views on UML constructs, concepts and limitations. Likewise, [19], [2] were used for the same reason however for Java. Also, in order to provide solutions, [30], [11], [22] played a part. Again, they were read, analysed and only included in the project when agreed with. Furthermore, alternative perspectives were fuelled with sources such as [13], [27], [4]. These were required in order to add depth to the project as solutions were never going be to be as clear as black and white. In other words, conclusions and solutions to the project needed to include a combination of improvements to UML, to Java as well as alternative approaches. Therefore such sections provided the backbone to follow this path of study. This approach to the work allowed for a blend of background knowledge with an in-depth analysis of both languages. 7

15 3 AN INSIGHT INTO UML 3.1 INTRODUCTION "The UML is made of a number of models that together describe the system being designed. Each model comprises one or more diagrams with supporting documentation and descriptions". [14] The relationships between components of a system are easier to understand when some form of graphical representation is used. This has appeared in the form of modelling languages, such as the UML, which not only visualises the artefacts of an object-orientated system under development but also documents the various aspects within it. In terms of a language for communicating decisions The Unified Modeling Language (UML) provides a very robust notation, which grows from analysis into design.[9] The justification of its use is further strengthened by the widespread opinion that it is the industry-standard for the tasks it represents in the development of software systems. Section discusses the part played by class diagrams in the modelling and capturing of the details of a system. Section then looks in detail at the various constructs available for class diagrams, however not all possible construct will be discussed here. The discussion in section will be limited to those constructs that are essential to the study at hand. 3.2 CLASS DIAGRAMS USES The class diagram is just one of nine types of diagrams that comprise the UML however it is the core of the UML notation and of an object-orientated design. The nine diagrams that are defined are class (package), object, use case, sequence, collaboration, statechart, activity, component, and deployment. However, just to reiterate, the focus of this study shall solely be on the class diagram only. The role of the class diagram is that of presenting the static structure of the system, including the properties and methods of each class. Furthermore, the various relationships that can exist between classes, such as an inheritance relationship are also represented. This form of 8

16 diagram is seen to be the most widely used diagrams from the UML specification. One reason for this popularity is the fact that many CASE tools, such as Rational XDE, will auto-generate code in a variety of languages, including Java and C++ from these models. Such tools can provide the synchronization between the models and code and, to some extent, reduce an individual s workload. Furthermore, these tools can also generate class diagrams from the object-oriented code, itself. However, this project shall not be using such tools or be utilising the facilities provided by such tools UML CONSTRUCTS AVAILABLE FOR CLASS DIAGRAMS This section considers those constructs which are available for class diagrams and hence which are within the scope and purpose of this study. For each of these constructs there is a brief explanation and a graphical representation however for further knowledge on the uses and explanations of these constructs, as well as UML and associated diagrams, [33], [14], [24], [29], [31], [1] should be referenced. The corresponding sections in section 4 that discusses the mapping of the construct to Java have also been stated below Attributes and Operations The attributes of a class can be seen as the simple data found within them and their instances. An operation is a representation of the functions that the class and its instances perform. Figure 1 shows a simple class model, with attributes and operations. The attributes can be seen listed in the second, or middle, compartment of the class representation icon and the operations listed in the bottom, or third, compartment. title : String Book copiesonshelf() : Integer borrow(c:copy) Figure 1 pg64 [33] Class Model The discussion of the mapping of classes to Java will be discussed in section

17 Visibility It is often the case that a class has operations or attributes that are not available to every client of the class. The UML uses the + sign to show it is public, the # sign to show it is protected and the sign to distinguish it from being private. The discussion of the mapping of visibility to Java will be discussed in section Association An association is a concept that shows there is a meaningful relationship between objects. As classes correspond to nouns, associations correspond to verbs. Two classes, class A and class B can be said to be associated if: "an object of class A sends a message to an object of class B an object of class A creates an object of class B an object of class A has an attribute whose values are objects of class B or collections of objects of class B an object of class A receives a message with an object of class B as an argument" [33] The UML for a general association is shown in Figure 2. Copy is a copy of Book Figure 2 pg62 [33] General Association As stated this is a general association, as associations may have direction, name, and should show multiplicities. The discussion of the mapping of the association relationship to Java will be discussed in section

18 Multiplicities Multiplicities show how many, if any, of a class is associated with another class. There are various possibilities that can be represented. It could be an exact number, or it could be a range of numbers or it could be an unspecified number. The UML to represent these cases is as follows: Employee * worksfor Company Secretary * 1..* supervisor Manager Company BoardOfDirecto Office allocatedto * 0..1 Employee Person 0,3..8 * boardmember BoardOfDirecto Figure 3 pg 157 [24] Multiplicities Figure 3 shows how to label an association, the varying types of multiplicities and also how to represent direction in order to make the reading of the association clearer. The discussion of the mapping of multiplicities to Java will be discussed in section

19 Generalization Generalization can be seen as another important relationship which may exist between classes. It can be seen to represent the "is a" conceptual relationship. For example, a LibraryMember is a generalization of MemberOfStaff as conceptually every MemberOfStaff is a LibraryMember. The UML for a generalization is shown in Figure 4. LibraryMember MemberOfStaff Figure 4 pg 67 [33] Generalization UML allows this to be taken further whereby you can have multiple subclasses. Figure 5 illustrates a possible use of multiple generalization. In the example, the Animal class is called a superclass, and the classes Cat, Dog and Raccoon are referred to as subclasses of the Animal class. Animal Cat Dog Racoon Figure 5 Multiple Generalization The discussion of the mapping of generalization to Java will be discussed in section and the discussion of the mapping of multiple generalization will be discussed in

20 Aggregation and Composition These are being discussed together as they are both kinds of association however show greater detail of what kind of association exists between classes. Essentially, they both are stating that an object of one class "is part of" and object of another class. An aggregation is the representation of a "part-whole" relationship where the whole side of the relationship is often called the assembly or the aggregate. Often there is a source of confusion in when in to use aggregation. However, as a rule, aggregation should be used when: "You can state that the parts 'are part of' the aggregate, or the aggregate 'is composed of' the parts. When something owns or controls the aggregate, then they also own or control the parts." [24] Figure 6 illustrates aggregation with the diamond at the end of the whole part: HonoursCourse 1..* 6..* Module Figure 6 pg 75 [33] Aggregation The discussion of the mapping of aggregation to Java will be discussed in section Composition is seen as a stronger form of aggregation as it imposes further restrictions. If the aggregate is destroyed then the individual parts are destroyed as well hence the whole strongly owns it parts. In terms of use, the multiplicity at the whole end of the composition must be either 1 or 0..1, as a part cannot be part of more than whole by composition. Figure 7 illustrates composition from which it can be seen that the notation is similar to aggregation however the diamond is filled in: Board Square Figure 7 pg 75 [33] Composition The discussion of the mapping of composition to Java will be discussed in section

21 Qualified Associations When a designer wishes to give finer details about an association there is the possibility of utilizing a qualified association. This allows for placing extra information that will make the association clearer and allow for a more accurate implementation. Figure 8 shows a qualified association. This particular example allows the designer to state that the nine squares on a board are realised by providing the nine pairs of values to the two attributes row and column. Board Row:{1,2,3} Column: {1,2,3} 1 1 Square Figure 8 pg 79 [33] Qualified Association The discussion of the mapping of qualified associations to Java will be discussed in section Derived Associations This is a form of association where a designer implements two associations and a third one will exist automatically. Hence, the designer need not worry about the implementation of this association as ultimately the existence of this third association can be deduced from the existence of the other two. Figure 9 shows a derived association, which is represented by a slash in front of its name. The association between Lecturer and Student, named teaches student, can be seen as the derived association as logically if a student is taking module X and lecturer Y teaches module X, then lecture Y will be teaching that student. 14

22 Student Module /teaches student teaches course Lecturer Figure 9 pg 80 [33] Derived Association The discussion of the mapping of derived associations to Java will be discussed in section Association classes Associations have been discussed however often, the way in which two objects are associated is just as important as the objects themselves [33] Figure 10 will clarify this brief definition: Student 1..* is taking 6 Module is taking mark : int Figure 10 pg 84 [33] Association Class In this scenario there is an association between student and module, as discussed earlier. However the question is where one would store a record of student s marks on this course. This is why and where an association class is utilised. Each instance of this class can now connect a student with a module and record the results as required. There would also be operations to retrieve and set these results accordingly. The discussion of the mapping of association classes to Java will be discussed in section

23 Interfaces An interface is a collection of operations that specifies a particular service of a model element, i.e. a class or a component. It need not specify all the operations that the element supports, therefore the same element could match several different interfaces. For instance lists, stacks and trees an interface in the form of an iterator which allows other classes to identify what elements are contained with them. Figures 11 and 12 show both ways to specify interfaces in UML: Person <<interface>> Cashier withdraw deposit Machine Employee ATM Figure 11 pg 172 [24] Interface Person Machine Cashier Cashier Employee ATM Figure 12 pg 172 [24] Interface In Figure 11 the interface is represented via a class rectangle using the expression <<interface>> and also, as an option, a list of operations supported by the interface. Though the notation is similar to generalisation there is a key difference in meaning and that being that the relationship between the implementing class and the interface is one of can-be-seen-as, as opposed to is a. Therefore it is a weak form of inheritance as the classes realising or supporting the interface must provide their own implementation. Also note that there is no attribute compartment for the reason that interfaces cannot have attributes. 16

24 Figure 13 clarifies a few more important points. The diagram again shows an interface and its use; however here the focus is on dependency and stereotypes. <<interface>> Stringifiable Module Stringify() : String <<uses>> prints stringify() : String Stringifiable Printer Figure 13 pg 87 [33] Interface with dependency and stereotypes In this example the class Printer depends on the interface Stringifiable only, as shown by the dependency arrow from Printer to the circle representing the interface Stringifiable. This is an extra piece of useful information in this example as it states that as long as a class provides the method stringify, Printer does not care about other features. Therefore, following on from this, any changes made in the Module class that do not affect the stringify method can be made without any changes having to be made to Printer. The other point to be made is the use of a stereotype, namely <<uses>>. A stereotype is UML s way of attaching extra classification to model items; its one of the ways that UML is made extensible. [33] In this example it is simply stating that Printer depends on the interface Stringifiable. The discussion of the mapping of interfaces to Java will be discussed in section The discussion of mapping a stereotype to Java shall be undertaken in section

25 Abstract classes A related idea to the previous one of interfaces is abstract classes. This form of class may have implementations defined for some of its operations however it is abstract in the sense that at least on of these operations will not have an implementation defined Again, UML uses a stereotype for representing an abstract class, this time it is <<abstract>>, as shown in Figure 14. <<abstract>> Shape Draw() Erase() Circle Square Figure 14 Abstract Class The discussion of the mapping of abstract classes to Java will be discussed in section Constraints The issue of constraints can be discussed in two sections, one being the facilities provided by UML itself and the other being those facilities provided by a language such as the Object constrain Language (OCL) used in conjunction with UML. However, the aim of both is to add additional information to a UML diagram. The constraint can be seen as a condition that must be fulfilled by an implementation that is to be deemed correct according to the design. 18

26 Figure 15 is an example of a constraint provided by UML itself: Copy 1..* 0..1 is a copy of Book 1..* (or) 0..1 Journal Figure 15 pg 81 [33] Constraint The discussion of the mapping of Constraints to Java will be discussed in section Parameterised classes Though the name may suggest, these are not actually classes. They can be more accurately thought of as functions that take classes an return classes, as opposed to the norm of taking a value and returning a value. Such classes are also known as templates or generic classes. Figure 16 is an example displaying a parameterized class and its uses. In this scenario we have a list of students and a list of games, which though are different, will also have a lot in common. For example, adding and deleting elements from the list. Therefore, as the parameterized class will take a class and in return will describe the objects of the class, it can be defined once and used twice. Hence time shall be saved in development and maintenance of the lists. 19

27 List add(t:t, pos:int) get(i:int) : T T List<Game> <<bind>>(student) StudentList Figure 16 pg 90 [33] Parameterized Class In Figure 16 only one dependency is shown however not the other, i.e. the dependency of List<Game> on List<T>. The reason is simply that this is obvious from the name. The discussion of the mapping of Parameterized classes to Java will be discussed in section Components and packages A relationship mentioned earlier is dependency. This is most commonly used in UML between packages. A package can be seen as a collection of related model elements, such as classes and their relationships, which then defines a namespace for these elements. There are several reasons for wanting to use packages and the recommended books will provide this knowledge. Also, visibility and hierarchies of packages are key issues, however again these will not be explained in the context of this project. Figure 17 gives the UML graphically view of the notation, with a package represented as a rectangle with a tab on its edge: 20

28 P R C B A foo:?? Figure 17 pg 162 [33] Package The discussion of the mapping of packages to Java will be discussed in section Summary Within this section definitions have been given, using graphical examples where appropriate, of relevant constructs used in conjunction with class diagrams. This background knowledge shall be useful as section 4 will consider whether these constructs can or can not be mapped to Java. As stated earlier, in accordance with the scope of the project, only certain constructs have been discussed here. These, and also the constructs not mentioned here, are well documented elsewhere. References for these have been provided. 21

29 4 EQUIVALENCE IN JAVA 4.1 INTRODUCTION It is within this section that a search for a correspondence in Java for the UML constructs identified in section shall be undertaken. Three categories have been identified. The first section is section 4.2 and those constructs that provide a direct equivalence in Java shall be considered. Certain guidelines may also be provided with this section in order to avoid potential issues. Then a brief subsection shall be dedicated to certain aspects of an implementation language that are not represented by the UML. This aspect is discussed further in section 4.3. Finally, though probably of greatest importance, are the UML constructs that provide problems when being mapped to Java. Each of these, in some form or another, will require analysis and proposed solutions, which shall be dealt with later. Within section 4.4 these constructs are identified. 4.2 CLEARLY CORRESPONDING CODE FOR CONSTRUCTS This section shall discuss those constructs in UML for which the equivalent code in Java exists. For further information on the UML constructs section 3 should be referenced and the relevant sections under each sub-section has been provided below. Here the theory shall be combined with practical examples in order to provide further evidence of the usage of the constructs within Java. There may, however, be instances where the corresponding Java code is evident but care must be taken when performing the actual implementation; this shall be expanded on if and when required Classes The definition of classes, including attributes, operations and visibility, was given in section Here the mapping shall be discussed. The mapping of classes is a straightforward process and can be seen as a one-to-one relationship. Figure 18 shows a class in UML, with instance variables and operations, and a corresponding implementation in Java: 22

30 Figure 18 [26] Class Diagram with corresponding Java code In this example it is evident that the class name, its attributes and its operations have been mapped to the java source code. Furthermore, the types and visibility of both attributes and operations and parameters and return types of the operation have also been implemented though there are several issues that may hinder this clear mapping. From a design perspective, it is important to note that the UML offers four levels of visibility; public, protected, private and package. The last of these visibilities was introduced in version 1.4 of the standard and so brings the UML closer to the Java implementation as the Java programming language supports these four visibilities. [8] discusses, however, that the definition of this new package visibility in the UML seems to contain an element of ambiguity. This is because an association could be declared between classifiers from two different packages. Therefore it could be questioned, to which package does the association declaration actually belong to? An immediate solution is provided which is a modification to the UML explanation of the package visibility. This being the inclusion of the following sentence to the existing explanation, The association end is declared in the same package as the opposite source class(that is, the class that owns the association end) [9] [9] also discusses the possible issues with visibility as a whole. It agrees that the mapping of the visibility of an association is clear, however only for unidirectional associations. It goes on to state that when bidirectional associations are considered this mapping is faced with several problems. The problems discussed seem logical and realistic and so shall an example shall be provided here in order to clarify the point being made by [9]. Figure 19 displays a bidirectional association, namely Lecturer-Subject, with both public and private visibility. 23

31 Figure 19 Bi-directional Association The potential problem revolves around the idea of lecturer being public, hence usable by any other class and also able to have indirect access to the private association end, and subject being private, which means it has direct access to itself. Thus far the explanation is simply based on definitions however it is these very definitions that can cause an issue. This is because the association end with the private rolename subject is only known to lecturer hence this means that the Subject class realises it is associated with the Lecturer class. However it does not know that the Lecturer class is associated with it also. This raises the question of whether this really is a bidirectional association. [9] states that such a scenario can occur as Visibility in UML is not specified for associations but for association ends and that the solution is that We need in UML a definition of visibility that fits better with the concept of bidirectional association. Further, as a general rule of thumb for visibility, it is usually better to be as restrictive as possible when setting the visibility of a method. In other words, if a method does not have to be public, then make it protected. If it does not have to be protected, then make it private. Also, use default visibility only when it is meant and document the reasoning for applying that visibility in the method header documentation if it is not clear why it has been applied. With respect to using types, the UML will allow the use of, almost, any type. However, only valid Java types should be used. This is the case for the attributes as well as for the operations, which are implemented as Java methods. In the case of the operations, it is the parameter list as well as the return type usage in the UML that must be concentrated on. In Java the difference between the static methods and attributes and non-static, or instance methods and attributes is significant. However, when representing them in UML, it may be possible to lose their significance when carrying out an implementation. This is because on a class diagram a static method or attribute is represented only by a small symbol, i.e. it is underlined, and an instance method or attribute is left non-underlined. This minor criticism does not demand a change in the notation of the UML however has been pointed out just as form guideline which if not followed could be the cause of several problems. 24

32 Furthermore, Design Class Diagrams should reflect language naming conventions. Design class models define the structure of the object source code, and therefore should reflect the naming conventions for the implementation language being used. For example, in Figure 20 the design version of the Order class uses names that conform to common Java programming conventions such as placementdate and calculatetaxes(). Figure 20 pg 29 [1] Class displaying naming conventions A final point is that the UML does not explicitly distinguish between operations and constructors. To make it more explicit which are the constructors, an approach is to use the convention of the language being used to implement the design model. In the case of Java the new operator is used to invoke the method, i.e. the constructor, and so operations in the model that are named new shall be distinguished as constructors Packages The definition of packages was given in section Here the mapping shall be discussed. Though there is a direct mapping from UML packages to Java packages, there are some issues in what they represent in either language. A Java package can be seen as a collection of classes and interfaces stored in the same area or directory and maintained using scoping rules. By acting as namespaces, they allow situations such as classes having the same name, as long as they reside in different packages. The UML, however, takes this definition further and packages in the UML are hence somewhat more than this. The first issue is concerned with the fact that the UML packages have similarities to 25

33 aggregation whereas Java packages do not. [14] discusses this difference in meaning of packages, If a package owns it s content it is composed aggregation, but if it refers to its contents (i.e. imports elements from other packages) it is shared aggregation. Don t be confused here with Java imports, which merely make classes or interfaces in other packages visible to the current package there is no aggregation happening with Java Further issues are that UML packages may have visibility, whereas this concept does not hold in Java. Also, inheritance of packages exists in UML however Java does not entertain this idea and its use only complicates the process of translating designs into Java further. Though there is no direct concept of a Package Interfaces in Java, it is usually a good idea to make use of it. Figure 21, taken from [14], is both the UML for a package with an interface and a possible implementation in Java. package vehicles; public interface Drives { public boolean drives (String dest); } vehicles public class VehicleFactory { public static Drives getvehicle( ) { return new car ( ) ; } } drives public class Car implements Drives { public Boolean drive(string dest) { } } Figure 21 [14] A Package with an Interface and its corresponding Java implementation Interfaces The definition of interfaces was given in section Here the mapping shall be discussed. There is a direct mapping from UML interfaces to Java interfaces. Figure 22 shows such a mapping with the UML diagram and the corresponding Java code. 26

34 Figure 22 [26] An Interface with its Java implementation However, when mapping to Java a method specification and public static final constant must also be provided. The reasoning is that, as Java provides no direct support for multiple inheritance one can implement functionality similar to multiple inheritance by using interfaces in Java. Therefore, Java interfaces provide object method descriptions but contain no implementations Associations The relevant sections for definitions related to this section are sections , and Here the mappings of such relationships shall be discussed. There are many possibilities when it comes to mapping associations from UML to Java. Each shall be discussed here, along with its pros and cons. The simplest approach is simply to use an instance variable in one object to reference another object. This, however, leads to several limitations and can be seen as too simplistic in terms of what relationship it is attempting to represent. The main problem lies in the notion that it is usually almost impossible to use this technique to represent anything other than a single unidirectional link. However, in most cases we are interested in either a bi-directional link or multiple objects referenced by the link, and you may even require a key to determine which link to follow. [14] Furthermore, it may be the case that associations have their own attributes, which would again decrease the use of this approach as a single variable reference could not provide such flexibility. Figure 23 is an example of a representation using this approach. Evidently, Phone holds a reference to Button and this can be coded in Java as shown to the right of the UML representation. However, as discussed, one can be limited to a single unidirectional link. 27

35 Figure 23 [14] Unidirectional Link with Java implementation Another option is to use a separate class that represents the association itself. This class will reside in between the two classes that are being associated. Figure 24 shows two classes being associated, Developer and Project, and an association class, namely Link and figure 25 is one possible implementation of the association. Developer Link Project Figure 24 [14] Association Class This approach overcomes the limitations encountered before in that the link may be unidirectional or bi-directional. Also, due to the fact that the link object now represents the association, and not a reference as before, the association can have attributes and operations like any other object does. Hence, again, increases its flexibility and behaviour capabilities. Another issue is that of singleton objects. These objects exist when there will only ever be one instance of a class within the system. It should be possible for this object to be referenced by other objects and so an easy implementation of such associations must exist. With regards to the implementation of singletons, [14] discusses the use of both class-side attributes and operations and instance-side attributes and operations. The issue with the class-side approach is that, though it is easier to access the class, information on the class-side is never inherited in Java. This would cause certain limitations in the future development of the system as there would be no possibility of subclassing the class to create a different type of singleton object. 28

36 public class Developer { private Link link; public void addlink(link 1) { link = 1; } } public class Project { private Link link; public void addlink(link 1) { link = 1; } } public class Link { private Project project; private Developer developer; public Link(Project project, Developer developer) { addtolink(project, developer); } addtolink(project project, Developer developer) { this.project = project; project.addlink(this); this.developer = developer; developer.addlink(this); } } Figure 25 [14] Implementation of Association shown in figure 24 The alternative approach overcomes the issue of inheritance however it creates further potential obstacles. The main concern is how other objects will access the instance. A possibility is to create a reference to the instance and then pass it to other objects; however this can soon lead to cluttered coding if several objects wish to reference the singleton. The other option is to create an instance of the object as soon as the class is loaded. This instance can then be maintained within a class-side public final attribute. This attribute can then be accessed wherever the class is imported, but it is an instance that is then obtained. [14] A coded example of the latter approach can be seen in Figure