Principals of Object Orientation OO Analysis Modeling with UML UML Views User model view

1. Principals of Object Orientation • OO Analysis • Modeling with UML • UML Views • User model view • Structural view • Behavioral view • Implementation view • Environment view Functional View Static View Dynamic View CS585

2. Principals of Object Orientation CS585

3. What is an Object? • A thing • A Visible Thing • It has: • Identity • Behavior • What the object do and what can be done to it • State – this includes • static properties and dynamic values of these properties • Structure and behavior of similar objects are defined in a common CLASS. CS585

4. What is an Object • Behavior of objects is achieved via its • Operations and • Methods. • The state of an object is realized thought the contents of its data. • Objects can communicate via messaging protocols CS585

5. Object Behavior - Object Life Cycle InitializeObject Wait forRequest HandleRequest TerminateObject CS585

6. Principals of OO - Abstraction • Abstraction • Denotes the essential characteristics of an object that distinguishes it from all kinds of objects. • What does the object do without any implication on how does it do it • A software object is an abstraction • A representation of something in the real word like a student, a book, … CS585

7. Principals of OO - Encapsulation • Encapsulation • The process of Compartmentalizing the elements of an object that constitute its structure and behavior • Data hiding • Localize design decisions • What are the encapsulated elements? • Information that describes the object (the things an object know about itself) • No of pages, cover type, ISBN, and other Book information • State, the object’s current condition (or state) • Behavior • What the object can do (register, drop etc.) • What can be done to it (a pencil object can Write!!) Encapsulation CS585

8. Principals of OO - Encapsulation • Encapsulation • What you need to know to use the object • The interface • What you need to know in order to make the object work properly • Mechanism to respond to the interface,THE IMPLEMENATION FOR EACH INTERFACE • Example • Driving a car! • You need to know the ignition, steering, brake, and gas pedal • No need to know about the mechanics of the engine, spark plugs, etc. CS585

9. Principals of OO • Modularity • OO is different from Structured Paradigm • In Structured Paradigm module and function are the same • In OO Paradigm Classes and objects are the lowest form of Modularity. • A module could have multiple classes CS585

10. Principals of OO • Hierarchy • Ranking of ordering of abstraction • Inheritance (is a) • The relationship between classes • One class share the structure and behavior of one or more classes • Generalization and Specialization CS585

11. Inheritance Class: Furniture Object: Chair Cost Dimensions Weight Color Cost Dimensions Weight Color Chair inherits all attributes and operations of class Furniture Buy Sell Buy Sell CS585

12. Principals of OO • Polymorphism • The same operation may behave differently on different classes. • Example + sign • When an object is substituted with one of its children at run time • (The is-a relationship) • Overloading of operations • Same operation with different signatures CS585

13. Principals of OO • Identifying Classes • External Entities (devices, people) • Things (reports, forms, Features, Estimates) • Occurrences or Events (Moving) • Roles (Mangers, Engineers, Group, Team) • Places (Loading dock, Shipping Floor) • Structures(Computers) CS585

14. OO Analysis CS585

15. OO Modeling • OO has its own Modeling Techniques • UML – Unified Modeling Language • Grady Booch Method • James Rumbaugh Method • Ivar Jacobson Method CS585

16. OO Modeling • Grady Booch Method • Micro Development Process • Defines a set of analysis tasks that are re-applied in the Macro process • Identifies classes, objects, and relationships • Macro development Process • Refine CS585

17. OO Modeling • James Rumbaugh Method • Object Modeling Technique (OMT) for • Analysis, creates: • The object model – objects, classes, and relationships • The dynamic model – objects and system behavior • The Functional Model – DFD like • System level design • Object level design CS585

18. OO Modeling • Ivar Jacobson Method • Object Oriented Software Engineering • Use Cases Oriented method CS585

19. The Unified Modeling Language CS585

20. Why do we model? • Provide structure for problem solving • Experiment to explore multiple solutions • Furnish abstractions to manage complexity • Reduce time-to-market for business problem solutions • Decrease development costs • Manage the risk of mistakes CS585

21. The Challenge Tijuana “shantytown”: http://www.macalester.edu/~jschatz/residential.html CS585

22. The Vision Fallingwater: http://www.adelaide.net.au/~jpolias/FLW/Images/FallingWater.jpeg CS585

23. Why do we model graphically? • Graphics reveal data. • 1 bitmap = 1 megaword. • Anonymous visual modeler CS585

24. What is UML • The UML is a graphical language for • Specifying, can be used to communicate "what" is required of a system, and "how" a system may be realized. • Visualizing, it can be used to visually depict a system before it is realized • Constructing, can be used to guide the realization of a system similar to a "blueprint". • Documenting, can be used for capturing knowledge about a system throughout its life-cycle the artifacts of software systems CS585

25. What is UML • Added to the list of OMG adopted technologies in November 1997 as UML 1.1 • Most recent minor revision is UML 2.0, • MDA CS585

26. OMG UML Evolution CS585

27. OMG UML Contributors AonixColorado State University Computer Associates Concept Five Data Access EDS Enea Data Hewlett-Packard IBM I-LogixInLine Software Intellicorp Kabira TechnologiesKlasse Objecten Lockheed Martin Microsoft ObjecTimeOraclePtech OAO Technology SolutionsRational SoftwareReich SAP Softeam Sterling Software Sun Taskon TelelogicUnisys… CS585

28. OMG UML Specification • UML Summary • UML Semantics • UML Notation Guide • UML Standard Profiles • Software Development Processes • Business Modeling • UML CORBAfacility Interface Definition • UML XML Metadata Interchange DTD • Object Constraint Language CS585

29. the Language • language = syntax + semantics • syntax = how the symbols should look and how are they combined (i.e words in natural language) • semantics = rules that tells us the meanings of each symbol. • UML Notation Guide – defines UML’s graphic syntax • UML Semantics – defines UML’s semantics CS585

30. UML Analysis Modeling UML Design Modeling UML Views • User model view • The system from the user’s perspective. • Use-cases • Structural model view • Static structure • Classes, objects, and relationships • Behavioral model view • Dynamic aspect of the system including collaborations between elements identified in the user-model and the structural model views. • Implementation model view • Describes the structural and behavioral aspects of the implementation. • Environment model view • Shows the actual hardware that is required to implement the solution. CS585

31. Inter object behavior UML Diagrams Diagram UML decomposition dimension Use case diagram Functional Class diagram Static Collaboration diagram Dynamic Sequence diagram Dynamic Intra object behavior Statecharts Dynamic CS585

32. UML Views Static ViewClass DiagramObject Diagram Dynamic ViewSequence DiagramCollaboration Diagram State Chart Diagram Functional ViewUse Case DiagramActivity Diagram CS585

33. Structural model view or Static View UML Views • Structural model view • Class Diagram • User model view • Behavioral model view • Implementation model view • Environment model view CS585

34. Structural model view or Static View What is structural modeling? • Structural model: a view of a system that emphasizes the structure of the objects, including their classes, relationships, attributes and operations. • Used to model the static structure and relationships among the classes of an OO software system • A class diagram is made of: • Nodes (Classes and Interfaces) • Links (Relationships) CS585

35. UML Class Diagram • Source for code generation • It represents classes, their members, and relationships. It includes: • Attributes • Operations • Stereotypes • Associations • Inheritance • Properties • It shows static view • Blueprint for building • Does not show behavior CS585

36. UML Class Diagram - Modeling Attributes • An Attribute describes a piece of information • Show type of attribute • Primitive (Language supplied data type, int, boolean) • User defined class (String) • Show visibility • - private • + public • # protected • ~ package • Show default value • Show Constraints – Integrity rules • Show static values by underlining the attribute • Example Visibility / attribute Name: Data Type = default value {constraint} CS585

37. UML Class Diagram - Modeling Operations • An operation denotes behavior • Things an object can do and • Things can be done to an object • Show Name • Show arguments – use attribute notation • Show return type – use attribute notation • Visibility (-,+,#,~) • Example + totalOrderAmount (order: Order): Dollar {total >0} CS585

38. Structural model view or Static View Point ~x:int~y:int +move(dx:int, dy:int) Class Representation in UML • class Point { int x,y; public void move (int dx, int dy) { x += dx; y += dy; } • } CS585

39. Structural model view or Static View P1:Point P1:Point x =0y=0 x =20y=15 Object Representation in UML • Point p1 = new Point (); • p1.x = 0; p2.y=0; • p1.move (20,15); After sending the move message to p1 object CS585

40. Modeling Relationships With UML Association CS585

41. Structural model view or Static View Relationships in UML • Association • To permit the exchange of messages • Associations are the mean for objects to communicate • Default is bi-directional (support messages in either way) • When an object uses the services of another object but does not own it. • Client server CS585

42. Structural model view or Static View enroll Student Course * Advisee * * teach 1 Adviser Faculty 1 Class Diagram: Association • General Binary Relationship CS585

43. owns rents drives Car Car Car Person Person Person Association Elements - Association Name • Association Name • Expresses the purpose of the association (verb) that describes how objects of one type (class) relate to objects of another type (class) • A Person owns a Car • A Person drives a Car • A Person rents a Car • You can show the direction to read the association name CS585

44. drives Car Person Association Elements - Multiplicity • Association Multiplicity • Defines rules on how objects in each class are related • A value can be assigned to each participant in the association • Min..Max • * denotes zero or more • 1..* no upper limit 0..* 1..1 CS585

45. participate manager participate Project Employee programmer UI Designer participate Association Elements - Roles • Association Roles • Generates code CS585

46. drives Car Person Association Elements - Constraints • Association Constraints Must have valid driver license CS585

47. Product Customer order 0..* 0..* Order • orderQuantity: int = 0 • orderDate: Date = today • orderTerms: Terms=NULL Association Elements - Class • Association Class • Encapsulate the association in a class to include information about the association CS585

48. Employee 0..* supervisor 0..* subordinates Association Elements - Reflexive • Reflexive Association • Objects in the same class can be associated and related to one another • Common for modeling Hierarchies CS585

49. Customer places orderNo: int 1..1 1..1 Order • orderQuantity: int = 0 • orderDate: Date = today • orderTerms: Terms=NULL Association Elements - Qualified • Qualified Association • Indexes • The customer uses the order number to lookup the order • Used to reduce multiplicity just like indexes are used to reduce time to search a table CS585

50. Job 1..* * Company Person employer employee Job boss salary 0..1 worker * Manages Associations CS585