OO & UML

676 views

Published on

Published in: Engineering, Technology, Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
676
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
11
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

OO & UML

  1. 1. OO & UML Chen Bin
  2. 2. UML unified model language model / design / documentation / understand legacy code communication
  3. 3. Table 1.1. Official Diagram Types of the UML Book 文本文本 [3] UML diagram category
  4. 4. our topic class diagram sequence diagram activity diagram oo/design pattern
  5. 5. class diagram describe the classes and their relationship within the system
  6. 6. class diagram class itself class relationship inheritance dependency
  7. 7. class (itself) pictures are captured from [apply UML & pattern] class type method return/params static/abstract attribution visibility
  8. 8. class type(map java/c++) interface abstract class {concrete} class class with all pure virtual methods class with some virtual methods classwith no virtual methods C++JavaUML interface abstract class {concrete} class
  9. 9. class relationship UML interface implementation composition association generalization
  10. 10. class relationship generalization =~ subtype -> extends : interface implementation -> implements : UML Java C++
  11. 11. ! ! 2 type of inheritance interface inheritance IC extends IA ,IB CA implements IA CD extends CA CD extends CA implements CB implementation inheritance Item 16, [5]
  12. 12. The ArrayList itself is a subclass of the AbstractList class. AbstractList provides some, but not all, the implementation of the List behavior. In particular, the get method is abstract. As a result, ArrayList implements get but also overrides some of the other operations on AbstractList. In this case, it overrides add but is happy to inherit the implementation of equals. Example extends extends implements
  13. 13. dependency dependency -local, parameters,static method association - attribution aggregation - whole-part relationship composition - non-shared aggregation A dependency exists between two elements if changes to the definition of one element (the supplier) may cause changes to the other (the client). stronger weaker
  14. 14. example 65/118 Aggregation and Composition One of the most frequent sources of confusion in the UML is aggregation and composition. It's to explain glibly: Aggregation is the part-of relationship. It's like saying that a car has an eng and wheels as its parts. This sounds good, but the difficult thing is considering what the differe between aggregation and association. In the pre-UML days, people were usually rather vague on what was aggregation and what wa association. Whether vague or not, they were always inconsistent with everyone else. As a res many modelers think that aggregation is important, although for different reasons. So the UML included aggregation (Figure 5.3) but with hardly any semantics. As Jim Rumbaugh says, "Thin as a modeling placebo" [Rumbaugh, UML Reference]. Figure 5.3. Aggregation As well as aggregation, the UML has the more defined property of composition. In Figure instance of Point may be part of a polygon or may be the center of a circle, but it cannot b The general rule is that, although a class may be a component of many other classes, any must be a component of only one owner. The class diagram may show multiple classes of owners, but any instance has only a single object as its owner. Figure 5.4. Composition You'll note that I don't show the reverse multiplicities in Figure 5.4. In most cases, as here Its only other possible value is 1, for cases in which the component class is designed so th have only one other class as its owner. The "no sharing" rule is the key to composition. Another assumption is that if you delete th polygon, it should automatically ensure that any owned Points also are deleted. Composition is a good way of showing properties that own by value, properties to value ob (page 73), or properties that have a strong and somewhat exclusive ownership of particula components. Aggregation is strictly meaningless; as a result, I recommend that you ignore own diagrams. If you see it in other people's diagrams, you'll need to dig deeper to find ou they mean by it. Different authors and teams use it for very different purposes. Derived Properties 37/118 discuss other visibilities on page 83. • The name of the attribute—how the class refers to the attribute—roughly corresponds to the name of a field in a programming language. • The type of the attribute indicates a restriction on what kind of object may be placed in the attribute. You can think of this as the type of a field in a programming language. • I'll explain multiplicity on page 38. • The default value is the value for a newly created object if the attribute isn't specified during creation. • The {property-string} allows you to indicate additional properties for the attribute. In the example, I used {readOnly} to indicate that clients may not modify the property. If this is missing, you can usually assume that the attribute is modifiable. I'll describe other property strings as we go. Associations The other way to notate a property is as an association. Much of the same information that you can show on an attribute appears on an association. Figures 3.2 and 3.3 show the same properties represented in the two different notations. Figure 3.2. Showing properties of an order as attributes Figure 3.3. Showing properties of an order as associations An association is a solid line between two classes, directed from the source class to the target class. The name of the property goes at the target end of the association, together with its multiplicity. The target end of the association links to the class that is the type of the property. association [3]
  15. 15. aggregation or composition?
  16. 16. don’t bother use aggregation, use composition when appropriate. [1][4] use association for normal attribution, use aggregation for collection of attribution
  17. 17. FYI[3] 65/118 Static Operations and Attributes The UML refers to an operation or an attribute that applies to a class rather than to an instance as static. This is equivalent to static members in C-based languages. Static features are underlined on a class diagram (see Figure 5.2). Figure 5.2. Static notation Aggregation and Composition One of the most frequent sources of confusion in the UML is aggregation and composition. It's easy to explain glibly: Aggregation is the part-of relationship. It's like saying that a car has an engine and wheels as its parts. This sounds good, but the difficult thing is considering what the difference is between aggregation and association. In the pre-UML days, people were usually rather vague on what was aggregation and what was association. Whether vague or not, they were always inconsistent with everyone else. As a result, many modelers think that aggregation is important, although for different reasons. So the UML included aggregation (Figure 5.3) but with hardly any semantics. As Jim Rumbaugh says, "Think of it as a modeling placebo" [Rumbaugh, UML Reference]. Figure 5.3. Aggregation As well as aggregation, the UML has the more defined property of composition. In Figure 5.4, an instance of Point may be part of a polygon or may be the center of a circle, but it cannot be both. The general rule is that, although a class may be a component of many other classes, any instance must be a component of only one owner. The class diagram may show multiple classes of potential owners, but any instance has only a single object as its owner. Figure 5.4. Composition You'll note that I don't show the reverse multiplicities in Figure 5.4. In most cases, as here, it's 0..1. Its only other possible value is 1, for cases in which the component class is designed so that it can have only one other class as its owner. The "no sharing" rule is the key to composition. Another assumption is that if you delete the polygon, it should automatically ensure that any owned Points also are deleted. Composition is a good way of showing properties that own by value, properties to value objects (page 73), or properties that have a strong and somewhat exclusive ownership of particular other components. Aggregation is strictly meaningless; as a result, I recommend that you ignore it in your own diagrams. If you see it in other people's diagrams, you'll need to dig deeper to find out what they mean by it. Different authors and teams use it for very different purposes. Derived Properties As well as aggregation, the UML has the more defined property of composition. In Figure 5.4, an instance of Point may be part of a polygon or may be the center of a circle, but it cannot be both. The general rule is that, although a class may be a component of many other classes, any instance must be a component of only one owner. The class diagram may show multiple classes of potential owners, but any instance has only a single object as its owner. Figure 5.4. Composition You'll note that I don't show the reverse multiplicities in Figure 5.4. In most cases, as here, it's 0..1. Its only other possible value is 1, for cases in which the component class is designed so that it can have only one other class as its owner. The "no sharing" rule is the key to composition. Another assumption is that if you delete the polygon, it should automatically ensure that any owned Points also are deleted. Composition is a good way of showing properties that own by value, properties to value objects (page 73), or properties that have a strong and somewhat exclusive ownership of particular other components. Aggregation is strictly meaningless; as a result, I recommend that you ignore it in your own diagrams. If you see it in other people's diagrams, you'll need to dig deeper to find out what they mean by it. Different authors and teams use it for very different purposes. Derived Properties Derived properties can be calculated based on other values. When we think about a date range (Figure 5.5), we can think of three properties: the start date, the end date, and the number of days in the period. These values are linked, so we can think of the length as being derived from the other two values. Figure 5.5. Derived attribute in a time period
  18. 18. wrap up example A class diagram describes the types of objects in the system and the various kinds of static relationships that exist among them. Class diagrams also show the properties and operations of a class and the constraints that apply to the way objects are connected. The UML uses the term feature as a general term that covers properties and operations of a class. Figure 3.1 shows a simple class model that would not surprise anyone who has worked with order processing. The boxes in the diagram are classes, which are divided into three compartments: the name of the class (in bold), its attributes, and its operations. Figure 3.1 also shows two kinds of relationships between classes: associations and generalizations. Figure 3.1. A simple class diagram Properties Properties represent structural features of a class. As a first approximation, you can think of properties as corresponding to fields in a class. The reality is rather involved, as we shall see, but that's a reasonable place to start.
  19. 19. advice class diagram is the backbone of UML, so familiar yourself with it focus on big picture use it with sequence diagram
  20. 20. sequence diagram describe object interaction in specific user case
  21. 21. sample pic taken from [1] sync call async call obj:Type activation box
  22. 22. Activity Diagram OO equivalent of flowchart in structured dev. With addition support for concurrency Use it describe business logic or complex algorithm
  23. 23. Example [7]
  24. 24. OOD, Patterns & UML UML express your OOD Good OOD follow OOD principle Design Pattern = proven OOD solution
  25. 25. OOD principle: SOLID [6][4]
  26. 26. DIP dependency inversion principle
  27. 27. DIP [8] List list = new ArrayList();
  28. 28. DIP - strategy pattern programming to interface not implementation
  29. 29. Template Method Hollywood principle : don’t call me , I will call you.
  30. 30. reference 1.apply UML & pattern , Craig Larman 2.design pattern, GOF 3.UML distilled ,Martin Fowler 4. Agile software development, Bob Martin 5. Effective Java , Joshua Bloch 6.http://en.wikipedia.org/wiki/Solid_(object-oriented_design) 7.http://www.visual-paradigm.com/VPGallery/diagrams/Activity.html 8.http://www.objectmentor.com/resources/articles/dip.pdf 9.http://exciton.cs.rice.edu/javaresources/DesignPatterns/

×