![Class attributes (=
fields)
• attributes (fields, instance variables)
– visibility name : type [count] =
default_value
–
visi
bility:
+ public
# protected
- private
~ package
(default)
/ derived
– underline static attributes
– derived attribute: not stored, but
can
be computed from other attribute
values
• “specification fields “ from CSE 331
– attribute example:
- balance : double = 0.00](https://image.slidesharecdn.com/1-210927051103/85/1-introduction-to-uml-13-320.jpg)
![Class diagram example:
student
StudentBod
y
+ main (args :
String[])
1 100
Student
- firstName : String
- lastName : String
- homeAddress : Address
- schoolAddress : Address
+ toString() : String
Address
- streetAddress : String
- city : String
- state : String
- zipCode : long
+ toString() : String](https://image.slidesharecdn.com/1-210927051103/85/1-introduction-to-uml-26-320.jpg)
More Related Content
Similar to 1. introduction to uml (20)
1. introduction to uml
- 2. Design phase • design: specifying the structure of how a software system will be written and function, without actually writing the complete implementation • a transition from "what" the system must do, to "how" the system will do it – What classes will we need to implement a system that meets our requirements? – What fields and methods will each class have? – How will the classes interact with each other?
- 3. What is UML? • Unified Modeling Language • OMG Standard, Object Management Group • Based on work from Booch, Rumbaugh, Jacobson • UML is a modeling language to express and design documents, software • Particularly useful for OO design • Not a process, but some have been proposed using UML • Independent of implementation language
- 4. Why use UML • Open Standard, Graphical notation for • Specifying, visualizing, constructing, and documenting software systems • Language can be used from general initial design to very specific detailed design across the entire software development lifecycle • Increase understanding/communication of product to customers and developers • Support for diverse application areas • Support for UML in many software packages today (e.g. Rational, plugins for popular IDE’s like NetBeans, Eclipse) • Based upon experience and needs of the user community
- 5. Why use UML • as a sketch: to communicate aspects of system – forward design: doing UML before coding – backward design: doing UML after coding as documentation – often done on whiteboard or paper – used to get rough selective ideas • as a blueprint: a complete design to be implemented – sometimes done with CASE (Computer-Aided Software Engineering) tools • as a programming language: with the right tools, code can be auto-generated and executed from UML – only good if this is faster than coding in a "real" language
- 6. Brief History • Inundated with methodologies in early 90’s • Booch, Jacobson, Yourden, Rumbaugh • Booch, Jacobson merged methods 1994 • Rumbaugh joined 1995 • 1997 UML 1.1 from OMG includes input from others, e.g. Yourden • UML v2.0 current version
- 7. 7 • The basic building blocks of UML are: • model elements (classes, interfaces, components, use cases, etc.) • relationships (associations, generalization, dependencies, etc.) • diagrams (class diagrams, use case diagrams, interaction diagrams, etc.) • Simple building blocks are used to create large, complex structures • cf. elements, bonds and molecules in chemistry • cf. components, connectors and circuit boards in hardware Building Blocks
- 8. UML – Unified Modeling Language • Union of all Modeling Languages – Use case diagrams – Class diagrams – Object diagrams – Sequence diagrams – Collaboration diagrams – Statechart diagrams – Activity diagrams – Component diagrams – Deployment diagrams – …. • Very big, but a nice standard that has been embraced by the industry.
- 10. 10 What is a Class Diagram? • A class diagram is a view of the static structure of a system – Models contain many class diagrams • Class diagrams contain: – Packages, classes, interfaces, and relationships • Notation: Package Name Class Name Interface Name <<Interface>>
- 11. UML class diagrams • UML class diagram: a picture of – the classes in an OO system – their fields and methods – connections between the classes • that interact or inherit from each other • Not represented in a UML class diagram: – details of how the classes interact with each other – algorithmic details; how a particular behavior is implemented
- 12. Diagram of one class • class name in top of box – write <<interface>> on top of interfaces' names – use italics for an abstract class name • attributes (optional) – should include all fields of the object • operations / methods (optional) – may omit trivial (get/set) methods • but don't omit any methods from an interface! – should not include inherited methods
- 13. Class attributes (= fields) • attributes (fields, instance variables) – visibility name : type [count] = default_value – visi bility: + public # protected - private ~ package (default) / derived – underline static attributes – derived attribute: not stored, but can be computed from other attribute values • “specification fields “ from CSE 331 – attribute example: - balance : double = 0.00
- 14. Class operations / methods • operations / methods – visibility name (parameters) : return_type – visi bility: + public # protected - private ~ package (default) – underline static methods – parameter types listed as (name: type) – omit return_type on constructors and when return type is void – method example: + distance(p1: Point, p2: Point): double
- 15. Employee object class (UML) Object attributes Services to other objects
- 16. Commen ts • represented as a folded note, attached to the appropriate class/method/etc by a dashed line
- 17. 17 Relationships • Class diagrams may contain the following relationships: – Association, aggregation, dependency, realize, and inheritance • Notation: Association Aggregation Dependency Inheritance Realize
- 18. UML Class Notation • Lines or arrows between classes indicate relationships • Association • A relationship between instances of two classes, where one class must know about the other to do its work, e.g. client communicates to server • indicated by a straight line or arrow • Aggregation • An association where one class belongs to a collection, e.g. instructor part of Faculty • Indicated by an empty diamond on the side of the collection • Composition • Strong form of Aggregation • Lifetime control; components cannot exist without the aggregate • Indicated by a solid diamond on the side of the collection • Inheritance • An inheritance link indicating one class a superclass relationship, e.g. bird is part of mammal • Indicated by triangle pointing to superclass
- 20. Generalization (inheritance) relationships • hierarchies drawn top-down • arrows point upward to parent • line/arrow styles indicate whether parent is a(n): – class: solid line, black arrow – abstract class: solid line, white arrow – interface: dashed line, white arrow • often omit trivial / obvious generalization relationships, such as drawing the Object class as a parent
- 21. Associational relationships • associational (usage) relationships 1. multiplicity (how many are used) • * ⇒ 0, 1, or more • 1 ⇒ 1 exactly • 2..4 ⇒ between 2 and 4, inclusive • 3..* ⇒ 3 or more (also written as “3..”) (what relationship the objects have) 2.name 3.navigabilit y (direction )
- 22. ■ one-to-one ■ each student must carry exactly one ID card ■ one-to-many ■ one rectangle list can contain many rectangles Multiplicity of associations
- 23. Association types • aggregation: “is part of” – symbolized by a clear white diamond • composition: “is entirely made of” – stronger version of aggregation – the parts live and die with the whole – symbolized by a black diamond • dependency: “uses temporarily” – symbolized by dotted line – often is an implementation detail, not an intrinsic part of that object's state 1 1 Car aggregation Engine Lottery Ticket Random dependenc y Page Book composition 1 *
- 24. Composition/aggregation example If the movie theater goes away so does the box office => composition but movies may still exist => aggregation
- 25. UML example: people Let’s add the visibility attributes
- 26. Class diagram example: student StudentBod y + main (args : String[]) 1 100 Student - firstName : String - lastName : String - homeAddress : Address - schoolAddress : Address + toString() : String Address - streetAddress : String - city : String - state : String - zipCode : long + toString() : String
- 27. Class diagram pros/cons • Class diagrams are great for: – discovering related data and attributes – getting a quick picture of the important entities in a system – seeing whether you have too few/many classes – seeing whether the relationships between objects are too complex, too many in number, simple enough, etc. – spotting dependencies between one class/object and another • Not so great for: – discovering algorithmic (not data-driven) behavior – finding the flow of steps for objects to solve a given problem – understanding the app's overall control flow (event- driven? web-based? sequential? etc.)
- 28. Object Diagrams • Shows instances of Class Diagrams and links among them • An object diagram is a snapshot of the objects in a system • At a point in time • With a selected focus • Interactions – Sequence diagram • Message passing – Collaboration diagram • Operation – Deployment diagram
- 29. Object Diagrams • Format is • Instance name : Class name • Attributes and Values • Example:
- 30. 30 UML diagrams: use cases • A use case encodes a typical user interaction with the system. In particular, it: • captures some user-visible function. • achieves some concrete goal for the user. • A complete set of use cases largely defines the requirements for your system: everything the user can see, and would like to do. • The granularity of your use cases determines the number of them (for you system). A clear design depends on showing the right level of detail. • A use case maps actors to functions. The actors need not be people.
- 31. 31 Use case examples, 1 (High-level use case for powerpoint.)
- 32. 32 About the last example... • Although this is a valid use case for powerpoint, and it completely captures user interaction with powerpoint, it’s too vague to be useful.
- 33. 33 Use case examples, 2 (Finer-grained use cases for powerpoint.)
- 34. 34 About the last example... • The last example gives a more useful view of powerpoint (or any similar application). • The cases are vague, but they focus your attention the key features, and would help in developing a more detailed requirements specification. • It still doesn’t give enough information to characterize powerpoint, which could be specified with tens or hundreds of use cases (though doing so might not be very useful either).
- 35. 35 Use case examples, 3 (Relationships in a news web site.)
- 36. 36 About the last example... • The last is more complicated and realistic use case diagram. It captures several key use cases for the system. • Note the multiple actors. In particular, ‘AP wire’ is an actor, with an important interaction with the system, but is not a person (or even a computer system, necessarily). • The notes between << >> marks are stereotypes: identifiers added to make the diagram more informative. Here they differentiate between different roles (ie, different meanings of an arrow in this diagram).