1 / 92

based on the presentation at http ://technion.ac.il/~erant

Hoang Huu Hanh, Hue University hanh-at-hueuni.edu.vn. Modeling Class Architecture with UML Class Diagrams. based on the presentation at http ://www.technion.ac.il/~erant. Outline. Introduction Classes, attributes and operations Relations Generalization

casta
Download Presentation

based on the presentation at http ://technion.ac.il/~erant

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Hoang Huu Hanh, Hue University • hanh-at-hueuni.edu.vn Modeling Class Architecture with UML Class Diagrams based on the presentation at http://www.technion.ac.il/~erant

  2. Outline • Introduction • Classes, attributes and operations • Relations • Generalization • Guidelines for effective class modeling

  3. System Development Process Intro | Classes | Relations | Generalization | Guidelines

  4. Elements of Modelling Language • Symbols: Standard set of symbols • Syntax: Acceptable ways of combining symbols • Semantics: Meaning given to language expressions C C C C2 C1 C1 sends a message to C2 Intro | Classes | Relations | Generalization | Guidelines

  5. Advanced Properties • Expressiveness: What the language can say • Methodology: Procedures to be followed • Guidelines: Suggestions on how to build effective models OK: C1 sends messages to C2 Not OK: C1 sends messages to C2, after all messages of C2 were recieved • Model all classes • Model all relations • Model all inheritance Try to model classes with a balanced number of associations Intro | Classes | Relations | Generalization | Guidelines

  6. Modeling Approaches Modeling approaches differ from each other according to their view of the world Intro | Classes | Relations | Generalization | Guidelines

  7. Design Process System requirements legend Use Case Model Class Diagram Structural Behavioral Activity/Sequence Diagram State Chart Component Diagram Deployment Diagram Intro | Classes | Relations | Generalization | Guidelines

  8. From Requirements to Structure Requirements Document • Administrator enters course name, code and description • System validates course code • System adds the course to the data base and shows a confirmation message Structure (what’s the constant things of the system) Course description Course code (validation) Data base Course name Intro | Classes | Relations | Generalization | Guidelines

  9. What is Structural Modeling? A structural design defines the artifact unchanging characteristics, which do not change over time. Intro | Classes | Relations | Generalization | Guidelines

  10. Structural Modeling in Information Systems • Static structure of the model • the entities that exist (e.g., classes, interfaces, components, nodes) • relationship between entities • internal structure • Do not show • temporal information • Behavior • Runtime constraints Intro | Classes | Relations | Generalization | Guidelines

  11. Outline • Introduction • Classes, attributes and operations • Relations • Generalization • Guidelines for effective class modeling

  12. Reality Domain Model Domain bus models vehicle car models cup models Object-Oriented Approach • Objects are abstractions of real-world or system entities Intro | Classes | Relations | Generalization | Guidelines

  13. Classes • A class is a template for actual, in-memory, instances Class Name Attributes Operations Intro | Classes| Relations | Generalization | Guidelines

  14. Attributes - Signature [visibility] name [[multiplicity]] [: type] [=initial value] [{property}] • visibility: the access rights to the attribute • multiplicity: how many instances of the attribute are they: • middleName [0..1] : String, phoneNumber [1..*] • Type: the type of the attribute (integer, String, Person, Course) • initial value: a default value of the attribute • salary : Real = 10000, position : Point = (0,0) • property: predefined properties of the attribute • Changeable, readOnly, addOnly, frozen (C++: const, Java: final) Intro | Classes| Relations | Generalization | Guidelines

  15. Attributes - Examples + isLightOn : boolean = false - numOfPeople : int mySport + passengers : Customer[0..10] - id : long {readOnly} Intro | Classes| Relations | Generalization | Guidelines

  16. Operations - Signature [visibility] name [(parameter-list)] [: return-type] [{property}] • An operation can have zero or more parameters, each has the syntax: • [direction] name : type [=default-value] • Direction can be: in (input paremter - can’t be modified), out (output parameter - may be modified), inout (both, may be modified) • Property: • {leaf} – concrete operation • {abstract} – cannot be called directly • {isQuery} – operation leaves the state of the operation unchanged • … Intro | Classes| Relations | Generalization | Objects | Guidelines

  17. Operations - Examples + isLightOn() : boolean + addColor(newColor : Color) + addColor(newColor : Color) : void # convertToPoint(x : int, y : int) : Point - changeItem([in] key : string, [out] newItem : Item) : int What’s the difference? Intro | Classes| Relations | Generalization | Guidelines

  18. Visibility • public (+) – external objects can access the member • private (-) – only internal methods can access the member • protected (#) – only internal methods, or methods of specialized objects can access the member We will try to keep the visibility as minimal as possible Intro | Classes| Relations | Generalization | Guidelines

  19. Full Blown Class <<abstract>> Window Constraints Stereotype {transient status=tested} +size:Area = (100,100) #visibility:Boolean = invisible +default-size:Rectangle #maximum-size:Rectangle -xptr: XWindow +display () +hide () +create () -attachXWindow(xwin:Xwindow*) Intro | Classes| Relations | Generalization | Guidelines

  20. Object Diagram • In an Object Diagram, class instances can be modeled In runtime Class Diagram Object Diagram Intro | Classes| Relations | Generalization | Guidelines

  21. Outline • Introduction • Classes, attributes and operations • Relations • Generalization • Guidelines for effective class modeling

  22. Intro | Classes | Relations | Generalization | Guidelines

  23. Relations • A relation is a template for a connection between two instances. • Relations are organized in a Hierarchy: • Dependency: dynamic relations • Associations: consistent relations • Composition: whole-partrelations Dependency Association Composition Intro | Classes | Relations | Generalization | Guidelines

  24. Associations • Objects on both sides of the association can find each other • The relation is consistent in time (unless removed) • Multiplicity • Indicates cardinality • – 1:1default • 3 – exactly 3 object • * (or n) - unbounded • 1..* - 1 to eternity • 3..9 – 3 to 9 Intro | Classes | Relations | Generalization | Guidelines

  25. Navigation • If an association is directed, messages can pass only on that direction • If the association does not have directions, then it’s a bidirectional association • By default, all relations should be directed, unless the requirements dictate a bidirectional relation Folder File Given a folder, we want to know the files of each folder. However, we do not have a requirement for knowing the folder of each file. Intro | Classes | Relations | Generalization | Guidelines

  26. Association Classes Denoted as a class attached to the association, and specify properties of the association According to the requirements, each product can appear is several orders, and each order may include several products An association class is a “normal” class, and may include relations, inheritance etc. Intro | Classes | Relations | Generalization | Guidelines

  27. Association Class - Objects Links should be verified, according to the association multiplicity For each link, an association class instance should be declared Intro | Classes | Relations | Generalization | Guidelines

  28. Class Normalization • Classes should be normalized, if: • Attributes are selected from large or infinite sets • Relations with attributes are in n:n form • Groups of attributes are related 1 2 3 Before After Intro | Classes | Relations | Generalization | Guidelines

  29. Relations & Attributes • Relations are denoted with associations, not attributes. • Implementation (pointers, arrays, vectors, ids etc) is left to the detailed design phase. What is the problem? Intro | Classes | Relations | Generalization | Guidelines

  30. *..1 * * Company Person Worker employee employer 1..0 Manages Manager Role Names • Names may be added at each end of the association • Provide better understanding of the association meaning • Especially helpful in self-associated classes Intro | Classes | Relations | Generalization | Guidelines

  31. Ternary Associations Intro | Classes | Relations | Generalization | Guidelines

  32. Qualifiers • A qualifier is an attribute or list of attributes whose values serve to partition the set of objects associated with an object across an association Chessboard College rank : int file : int Student ID Qualifier 1..* 1 1 1 Square Student • The qualifier limits the multiplicity of the target object according to the qualifier attribute. Thus, even though a Bank has many persons, it has one or zero person with a particular account # Intro | Classes | Relations | Generalization | Guidelines

  33. Constraints • Constrains are simple properties of associations, classes and many other things in UML • Specify limitations that implementers need to satisfy Window length width Property Constraints {0.8 £length/width£1.5} Denotes explicit order of instance {ordered} Dictionary 1 Word Language * Intro | Classes | Relations | Generalization | Guidelines

  34. Constraints - cont’d A full order on associated objects Project {ordered} Outsource * * Committee Task {xor} memberOf * {subset} chairOf * boss Employee salary Only one of the associations can exist for a given instance (what is the meaning of “or”?) 0..1 * {salary < boss.salary} Intro | Classes | Relations | Generalization | Guidelines

  35. Constraints • Constraints can be applied to almost every element in UML diagrams, using: • natural language • mathematical notation • OCL (Object Constraint Language) • Expressing: • Invariants: interest > 3% • Preconditions: before loan() takes place, salary > 5,000$ • Postconditions: after loan() takes place, dayCollect = 1 or 10 See http://www.klasse.nl/ocl/index.html Intro | Classes | Relations | Generalization | Guidelines

  36. Dependency • Notated by a dotted line • The most general relation between classes • Indicates that an object affects another object AccountingSystemcreates a Receipt object Intro | Classes | Relations | Generalization | Guidelines

  37. Dependency – cont’d • Dependencies are the most abstract type of relations. • Properties: • Dependencies are always directed (If a given class depends on another, it does not mean the other way around). • Dependencies do not have cardinality. • If instances of two classes send messages to each other, but are not tied to each other, then dependency is appropriated. • Types: • «call» • «create» Intro | Classes | Relations | Generalization | Guidelines

  38. Aggregation • “Whole-part” relationship between classes • Assemble a class from other classes • Combined with “many” - assemble a class from a couple of instances of that class Intro | Classes | Relations | Generalization | Objects | Guidelines

  39. Composition • Composition is a stronger form of aggregation • Contained objects that live and die with the container • Container creates and destroys the contained objects Intro | Classes | Relations | Generalization | Objects | Guidelines

  40. * * document Frame category Window Composition vs. Aggregation 0..4 Intro | Classes | Relations | Generalization | Objects | Guidelines

  41. Outline • Introduction • Classes, attributes and operations • Relations • Generalization • Guidelines for effective class modeling

  42. Generalization – Definitions • Super Class(Base class) • Provides common functionality and data members • Subclass(Derived class) • Inherits public and protected members from the super class • Can extend or change behavior of super class by overriding methods • Overriding • Subclass may override the behavior of its super class Super Class … Subclass Intro | Classes | Relations | Generalization | Guidelines

  43. Intro | Classes | Relations | Generalization | Guidelines

  44. Generalization – advantages • Modularity: • Eliminate the details • Find common characteristics among classes • Define hierarchies • Reuse: • Allow state and behavior to be specialized Overriding Multiple Inheritance Intro | Classes | Relations | Generalization | Guidelines

  45. Generalization Guidelines • Look carefully for similar properties between objects, sometimes they are not so obvious What’s the problem here? Intro | Classes | Relations | Generalization | Guidelines

  46. Generalization – cont’d IDand name are common to all classes Association is the same as any other attribute Intro | Classes | Relations | Generalization | Guidelines

  47. Abstract Class • A class that has no direct instances Content Denoted by an Italics name Picture <<abstract>> Article Or by the stereotype “abstract” 1..* has picture MagazineArticle News Article 1..* Intro | Classes | Relations | Generalization | Guidelines

  48. Models and Sets Intro | Classes | Relations | Generalization | Guidelines

  49. Generalization and Sets Instances GraphicComponent Image Button ImageButton Class Set Representation Class Representation Intro | Classes | Relations | Generalization | Guidelines

  50. What Relations are Missing? • Union • We cannot define a class such as:allPeopleInTheTechnion = students  Staff • Complementary • We cannot create classes which take some of the super-class properties but omit some of them:MultiMedia = Content \ Textual Staff Students Content Textual Multimedia Intro | Classes | Relations | Generalization | Guidelines

More Related