How To Understand The Purpose Of A Class Diagram In Java.Io (Java)

Transcription

1 Software Engineering I (02161) Week 3: Class diagrams part 1 Hubert Baumeister Informatics and Mathematical Modelling Technical University of Denmark Spring 2009 c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

2 Contents 1 Class Diagrams 2 Domain Model 3 Design and Implementation 4 Implementing Class Diagrams 5 Example 6 Summary Next Week: Generalisation / Inheritance / Subclass, Qualified Associations / Use of tables / Map datatype c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

3 Class Diagrams Class Diagrams Purpose to model concepts to identify important objects their state and interface to give an overview over the domain as part of the requirements analysis to give an overview over the systems as part of the design of the system to give an overview over the sytems implementation c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

4 Example Class Diagrams Example of a class diagram used for implementation c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

5 Example 2 Class Diagrams The same information as in the class diagram presented as Java source code public class Assembly extends Component { public double cost() { } public void add(component c) {} private Collection<Component> components; } public class CatalogueEntry { private String name = ""; public String getname() {} private long number; public long getnumber() {} private double cost; public double getcost() {} } public abstract class Component { public abstract double cost(); } public class Part extends Component { private CatalogueEntry entry; public CatalogueEntry getentry() {} public double cost(){} public Part(CatalogueEntry entry){} c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

6 Contents Domain Model 1 Class Diagrams 2 Domain Model Introduction Glossary Domain Model 3 Design and Implementation 4 Implementing Class Diagrams 5 Example 6 Summary c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

7 Domain model Domain Model Introduction Purpose: capture the customer s knowledge of the domain so that the system builders have the same knowledge Helps customer and system builders to speak the same language Necessary to define the terminology used Glossary Relationships between terms are shown in a class diagram Related to the concept of an ontology c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

8 Glossary Domain Model Glossary glossary (plural glossaries) 1. (lexicography) A list of terms in a particular domain of knowledge with the definitions for those terms. (Wikitionary) List of terms with explanations Terms can be nouns (e.g. those mentioned in a problem description) but also verbs or adjectives e.t.c. A glossary is prerequisit for defining an ontology c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

9 Example Domain Model Glossary Part of a glossary for a library application Book Copy... A book is a is a conceptual entity in a library. A book is defined by its title, the name of his authors, the publisher and the edition. A library can have several copies of the same book. A copy is a physical copy of a particular book. For example, the library has three copies of the book Using UML by Perdiate Stevens.... Warning Capture only knowledge relevant for the application Don t try to capture all possible knowledge c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

10 Domain Model Domain Model Domain model (concepts and their relations) Class diagrams can be used for showing terms and their relations Generalization Associations Name of the association Multiplicities Class Attributes Reading direction Classes Represent concepts of the domain Associations Represent relationships between concepts Generalizations is-a relationship between concepts c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

11 Contents Design and Implementation 1 Class Diagrams 2 Domain Model 3 Design and Implementation Introduction Classes Unidirectional Associations Bi-directional associations Aggregation 4 Implementing Class Diagrams 5 Example c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

12 Design and Implementation Introduction Class Diagram in Design and Implementations A class describes a collection of objects that a common characteristics regarding state (attributes) behaviour (operations) relations to other classes (associations and generalisations) c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

13 Design and Implementation The purpose of a class Introduction The interface of a class has to purposes to describe the functionality that is provided to the environment (programs using that class) to describe the functionality that needs to be implemented Private attributes encapsulate data Private operations are helper functions for other operations Level of detail of a class description depends on the purpose of the class diagram Domain Modelling : typically low level of detail Implementation. : typically high level of detail c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

14 Class Description Design and Implementation Classes - : private + : public # : protected KlasseNavn +navn1: String = "abc" -navn2: int #navn3: boolean -f1(a1:int,a2:string []): float +f2(x1:string,x2:boolean): void #f3(a:double): String Klassens navn Attributter Operationer navn3 og f1 er statiske størrelser private : only visible in the same class protected : visible also in subclasses public : visible also in other classes package : ( ) visible for other classes in the same package Attributes and operations that are underlined are static Attributes can be accessed without that an instance of that class exists Operations can be called without that an instance of that class exists c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

15 Design and Implementation Associations between classes Unidirectional Associations A association between classes means, that the objects belonging to the tow classes have knowledge of each other Associations can be navigable in one direction or two directions (a.k.a. bidirectional association) this means that knowledge can be only on one side or on two sides c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

16 Design and Implementation Unidirectional Associations Navigable associations in one direction I Example: Persons and their employers: * 0..1 Person Firma every person is associated to an employer (company/firma) every company has 0, 1, or more ( * ) employees (persons) The arrow means that a company has knowledge about all employees (persons) a company object has a reference to all the objects representing employees Conversely, a person object does not need to have a reference to the company object A at an arrow denotes that it should not be possible to navigate in this direction Navigability in the direction of the arrow 0 and are called multiplicities or cardinality c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

17 Design and Implementation Unidirectional Associations Navigable associations in one direction II Example: Persons and their employers: * 0..1 Person ansatte Firma a role (here employee) describes objects (here persons) at the end of an association, seen from the objects belonging to the classes at the opposite end of the (here company) in an implementation a role name is typically a variable. For example: public class Firma {... private Collection<Person> ansatte;... } c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

18 Design and Implementation Attributes and Associations Unidirectional Associations There is in principle no distinction between attributes and associations Associations can be drawn as attributes and vice versa c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

19 Design and Implementation Attributes versus Associations Unidirectional Associations When to use attributes and when to use associations? Associations When the target class of an association is shown in the diagram The target class of an association is a major class of the model e.g. Part, Assembly, Component,... Attributes When the target class of an associations is not shown in the diagram With datatypes / Value objects Datatypes consists of a set of values and set of operations on the values In contrast to classes are datatypes stateless e.g. int, boolean, String... Library classes However final choice depends on what one wants to express with the diagram E.g. Is it important to show a relationship to another class? c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

20 Multiplicities Design and Implementation Unidirectional Associations At the end of associations (or at other places) one often denotes how often an object can appear. E.g. how many employees a company can have These denotations are called multiplicities or cardinalities. Typical values used as cardinalities: values meaning m..n integer interval m to n (m and n inclusive) * 0, 1, 2,... m..* m, m + 1, m + 2, m + 3,... c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

21 Design and Implementation Bi-directional associations Bi-directional associations forældre 2 Person barn * ansatte * 0..1 * * kunde Firma when associations don t have any arrows, can this be understood as bi-directional, i..e. navigable in both directions, where on has decided not to show navigability, e.g. every person object has a reference to his employer every company object has a reference to his employee or as an under specification of navigability The example shows also two different associations between person and companies and a self-association c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

22 Design and Implementation Composite Aggregation (I) Aggregation A special relation between part-of between objects Sammensat Del Example: An consists of a header, a content and a collection of attachments 1 1 * 1 Hoved 1 Inhold * Attachment c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

23 Design and Implementation Composite Aggregation (II) Aggregation The basic two properties of a composite aggregation are: A part can only be part of one object The of the part object is tied to the life of the containing object This results in requirements to the implementation c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

24 Design and Implementation Composite Aggregation (III) Aggregation A part can only be part of one object Allowed c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

25 Design and Implementation Composite Aggregation (IV) Aggregation The life of the part object is tied to the life of the containing object If the containing object dies, so does the part object c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

26 Design and Implementation Composite Aggregation (V) Aggregation But: A part can be removed before the composite object is destroyed c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

27 Design and Implementation Aggregation Composite Aggregation (VI): Styklister A complex component (assembly) cannot have itself as a component Styklister can therefore be modelled using aggregation Component * Part 0..1 Assembly c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

28 Design and Implementation Shared Aggregation Aggregation Shared Aggregation General part of relationship Notation: empty diamond Precise semantics of shared aggregation varies by application area and modeller. (from the UML 2.0 standard) c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

29 Contents Implementing Class Diagrams 1 Class Diagrams 2 Domain Model 3 Design and Implementation 4 Implementing Class Diagrams Implementing classes Implemnting Associations Implementing bi-directional associations 5 Example 6 Summary c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

30 Implementing Class Diagrams Implementing classes Class descriptions and program skeleton (I) When classes are used to describe implementations, they correspond to program skeletons, e.g. public class ClaslName { public String name1 = "abc" private int name2 protected static boolean name3 } private static float f1(int a1, String[] a2) {... public void f2(string x1, boolean x2) {... } protected String f3(double a) {... } Development tools use this connection Diagram Program skeleton Program Diagram software development reverse engineering c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

31 Implementing Class Diagrams Implementing classes Class descriptions and program skeleton (II): Implementing public attributes Attributes are implemented as fields A +int a public class A { public int a; } In Java one uses setter and getter methods to access public fields instead of directly accessing the field This corresponds to the following class diagram public class A { private int a; } public void seta(int a) {this.a = a;} public int geta() { return a; } A -int a +seta(int a) +geta() However, a lot of tools support the generation of above Java code from the original diagram c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

32 Implementing Class Diagrams Implemnting Associations Implementing Associations: Cardinality 0..1 A 0..1 B public class A { private B b; } public B getb() { return b; } public void setb(b b) { this.b = b; } c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

33 Implementing Class Diagrams Implemnting Associations Implementing Associations: Cardinality * A * B public class A { private Collection<B> bs = new java.util.arraylist<b>(); } public Collection<B> getb() { return bs;} public void setb(collection<b> bs) { this.bs = bs; } If the multiplicity is >1, one adds a plural s to the role name: b bs Access to the implementation of the association using setb and getb poses encapsulation problems A client of A can change the association without A knowing it! c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

34 Implementing Class Diagrams Interface Collection<E> Implemnting Associations Operation boolean add(e e) boolean remove(e e) boolean contains(e e) Iterator<E> iterator() int size() Description returns false if e is in the collection returns true if e is in the collection returns true if e is in the collection allows to iterate over the collection number of elements Example of iterating over a collection Collection<String> names = new HashSet<String>() ; names.add("hans");... for (String name : names) { // Do something with name, e.g. System.out.println(name); } Collection cannot be instantiated directly One needs to use concrete implementation classes like HashSet or ArrayList c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

35 Implementing Class Diagrams Implemnting Associations Implementing Associations: Cardinality * (II) A * B public class A { private Collection<B> bs = new java.util.arraylist<b>(); } public void addb(b b) { bs.add(b);} public void contains(b b) { return bs.contains(b); } public void removeb(b b) { bs.remove(b); } addb, removeb,... control the access to the association The methods should have more intention revealing names, like registerstudent for addstudent c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

36 Implementing Class Diagrams Encapsulation problem Implemnting Associations University * Student University dtu = new University("DTU");.. Student hans = new Student("Hans"); Collection<Student> students = dtu.getstudents(); students.add(hans); students.remove(ole);... Students can be added and removed, without the university knowing about it! c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

37 Implementing Class Diagrams Implementing bi-directional associations Implementing bi-directional associations Example: Note: Person -navn: String +setfirma(firma:firma) * 0..1 ansatte arbejdsgiver Firma -navn: String +addansat(ansat:person,) +sletansat(ansat:person) Changes of a person objects employer gives rise to changes in up to two company objects list of employees Changes in the company s objects list of employees gives rise to a change in the person objects employer referential integrity Person private String navn; private Firma arbejdsgiver; public Person(String nv){navn = nv;} public void setfirma(firma f){... } Firma private String navn; private ArrayList<Person> ansatte =... public Firma(String nv){navn = nv; } public void addansat(person p} {... } public void sletansat(person p) {... } c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

38 Implementing Class Diagrams Implementing bi-directional associations Implementing bidirectional associations (II) Bidirectional associations are implemented as two unidirectional associations Person: Firma arbejdsgiver = null; Firma: Collection<Person>ansatte = new ArrayList<Person>(); consistency problem public void testaddansatte() { Firma firma = new Firma(); Person hans = new Person(); firma.addansatte(hans); // hans.setarbejdgiver(firma) needs to be tested too! } asserttrue(firma.containsansatte(hans)); assertequals(firma,hans.getarbejdsgiver()); sletansatte and setarbejdsgiver(null) have similar problems c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

39 Implementing Class Diagrams Consistency via helper functions Implementing bi-directional associations Three extra operations are used to ensure consistency Person: Implementation of role arbejdsgiver in Person Firma arbejdsgiver = null; protected void setf(firma f){arbejdsgiver = f;} public void setfirma(firma f){ if (arbejdsgiver!= null) arbejdsgiver.sletp(this); if (f!= null) f.addp(this); arbejdsgiver = f;} Firma: Implementation of role ansatte in Firma Collection<Person>ansatte = new ArrayList<Person>(); public void addansat(person p) {if (!ansatte.contains(p)) {ansatte.add(p); p.setf(this);} } public void sletansat(person p) {if (ansatte.contains(p)) {ansatte.remove(i); p.setf(null);}} protected void addp(person p){if (!ansatte.contains(p)) ansatte.add(p);} protected void sletp(person p) {if (ansatte.contains(p) ansatte.remove(p);} c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

40 Exercise Implementing Class Diagrams Implementing bi-directional associations Is the implementation correct? What happens if a compnay adds an emplyee that works already for another company? c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

41 Contents Example 1 Class Diagrams 2 Domain Model 3 Design and Implementation 4 Implementing Class Diagrams 5 Example 6 Summary c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

42 Example Eksempel: Svømmere og klubber Problem description En svømmer kan være medlem af en klub, men behøver det ikke hvis hun f.eks. svømmer på et elitecenter. En svømmer kan højst stille op til stævner for en klub. En svømmer beskrives ved navn, bedste tider, osv. En klub har en række medlemmer, og beskrives ved et navn. Man skal kunne oprette svømmere og klubber Man skal kunne tilføje, slette og ændre medlemskab How does one address this problem? What is the user relevant functionality of the system? What are possible use scenarios? For each scenario identify the important concepts create / enhance the domain model (glossary and domain class diagram) Write a test for the scenario Design and implement c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

43 Example Step 1: Identify functionality Functionality #1: Add a swimmer to a club Create a club with name Holte Create a swimmer with name Ole Add swimmer Ole to club Holte Add swimmer Ole to club Holte Check that Ole is member of Holte Check that Ole is member of Holte Functionality #2: Remove a swimmer from a club Create a club with name Virum Create a swimmer with name Per Add swimmer Per to club Virum Check that Per is member of Virum Remove swimmer Per from club Virum Check that Per is not member of Virum anymore c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

44 Example Step 2: Identify relevant notions Problem Description En svømmer kan være medlem af en klub, men behøver det ikke hvis hun f.eks. svømmer på et elitecenter. En svømmer kan højst stille op til stævner for en klub. En svømmer beskrives ved navn, bedste tider, osv. En klub har en række medlemmer, og beskrives ved et navn Add swimmer scenario Create a club with name Holte Create a swimmer with name Ole Add swimmer Ole to club Holte Check that Ole is member of Holte Nouns Classes Relationship between nouns Attributes and Associations Actions Methods c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

45 Example Step 3: Glossary and Domain modelling Glossary Swimmer (Svømmer) Klub A swimmer has a name and is member of at most one swim club. Swimmers are organized in clubs. A club has a name and can have several swimmers as members. c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

46 Example Step 4: Write a test case for the scenario public void testaddsvoemmer1() { Klub holte = new Klub("Holte"); Svoemmer ole = new Svoemmer("Ole"); assertfalse(holte.containssvoemmer(ole)); holte.addsvoemmer(ole); } asserttrue(holte.containssvoemmer(ole)); assertsame(holte,ole.getklub()); public void testaddsvoemmer2() { Klub holte = new Klub("Holte"); Svoemmer ole = new Svoemmer("Ole"); assertfalse(holte.containssvoemmer(ole)); ole.setklub(holte); } assertsame(holte,ole.getklub()); asserttrue(holte.containssvoemmer(ole)); c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

47 Example Step 5a: Design Svoemmer Svoemmer +navn: String +Svoemmer() * +medlemmer +klub 0..1 Klub +navn: String +Klub() +addsvoemmer() +containssvoemmer() c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

48 Example Step 5b: Implement Svoemmer package imm.swe1.svoemmer; public class Svoemmer { private String navn; private Klub klub; public Svoemmer(String navn) { this.navn = navn; } public String getnavn() { return navn; } public Klub getklub() { return klub; } public void setklub(klub klub) { if (this.klub == klub) return; this.klub = klub; klub.addsvoemmer(this); } } protected void setk(klub klub) { this.klub = klub; } c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

49 Example Step 6: Implement Klub public class Klub { private String navn ; private Collection<Svoemmer> medlemmer = new java.util.arraylist<svoemmer>() public Klub(String navn) { this.navn = navn; } public String getnavn() { return navn; } public void addsvoemmer(svoemmer svoemmer) { if (containssvoemmer(svoemmer)) return; medlemmer.add(svoemmer); svoemmer.setk(this); } } public boolean containssvoemmer(svoemmer svoemmer) { return medlemmer.contains(svoemmer); } c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

50 Example Step 2: Identify relevant notions Problem description En svømmer kan være medlem af en klub, men behøver det ikke hvis hun f.eks. svømmer på et elitecenter. En svømmer kan højst stille op til stævner for en klub. En svømmer beskrives ved navn, bedste tider, osv. En klub har en række medlemmer, og beskrives ved et navn. Remove svimmer scenario Create a club with name Virum Create a swimmer with name Per Add swimmer Per to club Virum Check that Per is member of Virum Remove swimmer Per from club Virum Check that Per is not member of Virum anymore Nouns Classes Relationship between nouns Attributes and Associations Actions Methods c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

51 Example Step 3: Domain Class modelling No changes to the domain model and the glossary Glossary Swimmer (Svømmer) Klub A swimmer has a name and is member of at most one swim club. Swimmers are organized in clubs. A club has a name and can have several swimmers as members. c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

52 Example Step 4: Write a test case for the scenario public void testsletsvoemmer1() { Klub virum = new Klub("Virum"); Svoemmer per = new Svoemmer("Per"); virum.addsvoemmer(per); } asserttrue(virum.containssvoemmer(per)); virum.sletsvoemmer(per); assertfalse(virum.containssvoemmer(per)); assertnull(per.getklub()); public void testsletsvoemmer2() { Klub virum = new Klub("Virum"); Svoemmer per = new Svoemmer("Per"); virum.addsvoemmer(per); asserttrue(virum.containssvoemmer(per)); per.setklub(null); } assertnull(per.getklub()); assertfalse(virum.containssvoemmer(per)); c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

53 Example Step 5a: Extend the Svoemmer Design Svoemmer +navn: String +Svoemmer() * +medlemmer +klub 0..1 Klub +navn: String +Klub() +addsvoemmer() +containssvoemmer() +sletsvoemmer() Added operation sletsvoemmer c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

54 Example Step 5: Extend the Svoemmer Implementation Additions to class Svoemmer public void setklub(klub klub) { if (this.klub == klub) return; Klub oldklub = this.klub; this.klub = klub; if (oldklub!= null) { oldklub.slets(this); } if (this.klub!= null) { this.klub.addsvoemmer(this); } } c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

55 Example Step 5: Implement Klub Additions to class Klub public void sletsvoemmer(svoemmer svoemmer) { if (!medlemmer.contains(svoemmer)) return; medlemmer.remove(svoemmer); svoemmer.setk(null); } protected void slets(svoemmer svoemmer) { medlemmer.remove(svoemmer); } c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58

56 Summary Summary Introduction to Class Diagrams Domain Modelling Class Diagrams for Design and Implementation Implementing Class Diagrams c 2009 H. Baumeister (IMM) Software Engineering I (02161) Spring / 58