Bouwkundige Informatiesystemen ADMS 2006 UML part 2

1. Bouwkundige InformatiesystemenADMS 2006UML part 2 Jan Dijkstra - 30 oktober 2006

2. Subjects • Objects & Classes 16 okt. • UML : Class Diagram 23 okt. • UML : Object Diagram 23 okt. • UML : Class Diagrams Exercises 23 okt. • Exercise Class Diagram MKW 23 okt. • Discussion Exercise Class Diagram MKW 30 okt. • UML : Class Diagrams - Advanced Concepts30 okt. • Task UML-part 2 30 okt.

3. Exercise 30 October Ga uit van de MKW beschrijving van oefening van UML1 • Identificeer enkele klassen • Geef zo mogelijk relaties tussen klassen aan

4. Objects • An object is a thing that can be tangible or intangible. • Examples • tangible : bike, car, house • intangible : order, account • An object has properties. • Example • a Customer has a • name and address Customer Name Address

5. (Multiple) Objects Property of object = attribute + value Adacs: Customer Name = Adacs Address = Enschede Primo: Customer Name = Primo Address = Grave Multiple objects  unique identity 1247: Customer Custno = 1247 Name = Adacs Address = Enschede 9378: Customer Custno = 9378 Name = Primo Address = Grave

6. Connection between Objects Link = connection between objects 1247: Customer Custno = 1247 Name = Adacs Address = Enschede 345T7: Order Orderno = 345T7 dateReceived = 10/10/05 Price = 1987 902U2: Order Orderno = 902U2 dateReceived = 07/04/05 Price = 3789

7. Class • Class • class is abstract concept • each object is instance of a class • classes classify objects • attribute has no values Customer Custno Name Address Order Orderno dateReceived Price Object analysis  than values to attributes

8. Class Diagram • Attribute has no values • Association is relation between classes Customer Custno Name Address Order Orderno dateReceived Price 1 * Link is instance of association

9. Advanced Class Features

10. Advanced Class Concepts : Visibility • Visibility – class members (attributes, operations) may be specified as: {we have feature f, an attribute or operation that is defined on an object O of class C } • + : public {f is public  f is visible to any object and f is inherited by the subclasses of C.} • # : protected {f is protected  f is visible only to objects of class C and to objects of C’s subclasses and f is inherited by the subclasses of C.} - : private {f is private  f is visible only to O and f is not inherited by the subclasses of C.} • Restricting visibility is the same as restricting accessibility.

11. Advanced Class Concepts : Scope • Individual member data (= attributes) may have: • Class scope : a single copy of an attribute is shared by all instances of a class. • Instance scope : each instance of a class would have its own copy of the attribute.

12. Advanced Class Concepts : Abstract • An operation is abstract if it has no implementation. • A abstract class cannot have any direct instances. • Abstract classes only occur in the context of an inheritance hierarchy. • Abstract operations and classes are specified by writing its name in italics.

13. Advanced Class Concepts : Abstract

14. Window as Abstract Class

15. Characteristics of Object Oriented Design (OOD) • Data and operations (functions) are combined  object • Objects arte abstractions of real-world or system entities and manage themselves. • Objects are independent and encapsulate state and represent information. • System functionality is expressed in terms of object services. • Objects communicate by message passing.

16. Objects are abstractions of real-world entities. Objects encapsulate state and represent information. Object’s state is protected. Objects have responsibility. Objects interact byinterfaces.

17. Conceptions • Encapsulation • Information hiding • Responsibility

18. Encapsulation • Encapsulation is the grouping of related ideas into one unit, which can thereafter be referred to by a single name. • Object-oriented encapsulation is the packaging of operations and attributes representing state into an object type so that state is accessible or modifiable via the interface provided by the encapsulation.

19. Information hiding • Information hiding is the use of an encapsulation to restrict from external visibility certain information decisions that are internal to the encapsulation structure.

20. Responsibility • Object oriented design is a responsibility driven design approach. • Objects have responsibilities that they prove oneself. • Therefore, collaboration with other objects is needed.

21. Classes and Objects • Objects looks like modules in some ways Object = Identity + State + Behaviour • Objects provide encapsulation of data • An object is described by a class. A class may define a number of objects with identical properties

22. About an Object • An object has a public interface defining the operations (methods) it will support • An object has private data called attributes, which only its own operations can access • An object can have private operations for its own use • An object may know about other objects by means of links

23. Structural modeling essentials

24. An operation is the implementation of a service that can be requested from any object of the class in order to affect behaviour. Operations are used to manipulate the attributes or to perform other actions. Operations are normally called functions, but they are inside a class and can be applied only to objects of that class. An operation is described with a return-type, a name and zero or more parameters. Together, the return-type, name, and parameters are called the signature of the operation. The signature describes everything needed to use the operation. Look back: Class - operations

26. Aggregation and Composition • Aggregation is a special form of association that specifies a whole-part relationship between the aggregate (the whole) and a component (the part); aggregation is the part-of relationship. { it is a special form of association in which a collection of objects, each having an independent existence, is associated with an single object} {unfilled diamond} • Composition is a form of aggregation with strong ownership and coincident lifetime of the parts by the whole; the part object may belong to only one whole – the parts are usually expected to live and die with the whole. {usually, any deletion of the whole is considered to cascade to the parts} {filled diamond}

27. Aggregation and Composition: Example

28. Derived Associations and Attributes • Derived associations and attributes can be calculated from other associations and attributes, respectively, on a class diagram. • For example, an age attribute of a Person can be derived if you know that Person’s date of birth.

29. Relations and Constraints

30. UML for Database Design • Database • A database is a collection of data. • Databases can be stored in one or more files, or can be managed by a software system called Database Management System (DBMS) • What makes a database • Add Data • Delete Data • Change Data • Lookup or search for data • Organize Data

31. Key Terminology • Table • Column • Record • Field • Primary Key • Foreign Key

32. Database Diagram Elements • Table • Column • Primary key • Foreign key • Identifying relationship • Non-identifying relationship

33. Database Diagram Elements (2) Table (stereotype <<table>>) Not used Not used Primary key (stereotype <<pk>>) Foreign key (stereotype <<fk>>) Primary/Foreign key (stereotype <<pk/fk>>) Non-identifying relationship Identifying relationship

34. Example 1

35. Mapping Logical Design To Database Design • Synchronization • Classes > Tables • Attributes > Columns • Associations > Relations • Normalization • There are more ways to do it

36. Mapping Classes To Tables • Map persisted classes to tables • Many to many associations must be broken down to one to many associations using an association table.

37. Mapping Subtype Classes to Tables • One table per class • One table per concrete class • One table per hierarchy

38. Mapping Attributes to Columns • Map persistent attributes • Don’t map calculated attributes • Can use Generic Types first, later use database specific types. Generic Types: Boolean, Currency, Date, Double, Integer, Long, Single, String

39. Example 2

40. Example Projecten

41. Database Example

42. Normaliseren • Het verfijnen van een informatiebehoefte en het verder detailleren van een gegevensmodel wordt normaliseren genoemd. • Normaliseren gebeurt in een aantal stappen die leiden tot zogenaamde normaalvormen. Met een denkproces kan men tot hetzelfde komen zonder dat men de specifieke normaalvormen hanteert. • Uitgangspunt is een ongenormaliseerde groep, dwz alle gegevens elementen worden geidentificeerd.

43. Voorbeeld Het lenen van boeken bij de bibliotheek; er kunnen meerdere exemplaren van een boek zijn. Gegevens: ISBN titel omschrijving boekidentificatie aantal leendatum lener lenernaw

44. Normaliseren 1 • Allereerst worden procesgegevens verwijderd en wordt een repeterende groep afgesplitst. De oorspronkelijke sleutel wordt overgenomen; deze zorgt voor de koppeling (relatie, associatie) tussen de groepen. Deze sleutel is niet voldoende samen met een ander gegeven vormt het een samengestelde sleutel. (1eNV) boekid isbn titel omschr aantal lenerid leendatum lenernaw boekid isbn titel omschr aantal boekid lenerid leendatum lenernaw

45. Normaliseren 2 • Daarna geldt dat attributen functioneel afhankelijk moeten zijn van de gehele sleutel. Dat betekent dat de attributen die slechts van een gedeelte van de sleutel afhankelijk zin, in een aparte groep worden opgenomen. (2eNV) boekid isbn titel omschr aantal boekid isbn titel omschr aantal boekid lenerid leendatum lenernaw boekid lenerid leendatum lenerid leennaw

46. Normaliseren 3 • Daarna worden ook attributen die ook functioneel afhankelijk zijn van andere niet-sleutelattributen in aparte groepen genomen. (3eNV) boekid isbn aantal boekid isbn titel omschr aantal boekid lenerid leendatum boekid lenerid leendatum isbn titel omschr lenerid leennaw lenerid leennaw

47. Resultaat BIBBOEKboekid isbn aantal BOEKLENER boekid lenerid leendatum BOEK isbn titel omschr LENER lenerid leennaw

48. Database Desktop Example

49. Questionnaire A market research company develops written questionnaires for customers, carries out the market research and presents the results to the customer. The company would like to develop an information system to help them in their work. The information system is based on the following description.  A questionnaire consists of a number of questions. Each question can appear in one or more questionnaires. A question always has one or more possible answers and each possible answer can be associated with one or more questions (for example, an answer "Yes" can be given to a large number of questions in the questionnaire). The chosen answer results in a number of points. The number of points depends on the combination of the question for which the answer was given and the questionnaire in which the question was asked. The answers given for a filled-in questionnaire are registered per question. The person filling in a questionnaire can also give a comment with some questions. He or she can also give a comment on the questionnaire as a whole. These comments are all registered in the information system. Comments with questions or on the questionnaire as a whole are not mandatory.   Make a class diagram showing the most important object types. State any assumptions that you have made. Only functional relationships are allowed in the class diagram.

50. Questionnaire A101 CustomA QuestionsAnswersPoints Question_A answer_1 points0 answer_3 points1 answer_4 points7 Comment Question_B answer_2 points9 answer_3 points2 Comment  ------- ------ ------ Comment questionnaire Questionnaire B341 CustomC QuestionsAnswersPoints Question_A answer_1 points4 answer_4 points1 answer_7 points2 Comment Question_D answer_4 points9 answer_3 points2 Comment  ------- ------ ------ Comment questionnaire Questionnaire 1