Lecture 1 uml with java implementation

5,004 views

Published on

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

No Downloads
Views
Total views
5,004
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
126
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Lecture 1 uml with java implementation

  1. 1. COSC 1320<br />Please find your perfect seat first 3 rows,you will sit there this June!<br />Please find your perfect seat first 3 rows,you will sit there this June!<br />Please find your perfect seat first 3 rows,you will sit there this June!<br /> tlc2 / Ewe2010!<br />www.uh.edu/webct<br />psid/ mmddyya!<br />
  2. 2. Introduction to Computer Science II<br />COSC 1320/6305<br />Lecture 1: Software Engineering and Classes<br /> UML, OOA/OOD/JAVA Implementation <br />A TOP DOWN EXAMPLE <br />(Chapter 12)<br />
  3. 3. Copyright © 2011 Dept of Computer Science - University of Houston. All rights reserved.<br />7-3<br />
  4. 4. Class Participation NetBeans Projects<br />
  5. 5. Software Engineering<br />Software Engineering is the study of the techniques and theory that support the development of high-quality software<br />The focus is on controlling the development process to achieve consistently good results<br />We want to:<br />satisfy the client – the person or organization who sponsors the development<br />meet the needs of the user – the people using the software for its intended purpose<br />
  6. 6. Goals of Software Engineering<br />Solve the right problem<br />more difficult than it might seem<br />client interaction is key<br />Deliver a solution on time and under budget<br />there are always trade-offs<br />Deliver a high-quality solution<br />beauty is in the eye of the beholder<br />we must consider the needs of various stakeholders<br />
  7. 7. Aspects of software quality<br />
  8. 8. Development Models<br />A development life cycle defines a process to be followed during product development<br />Many software development models have been introduced<br />All of them address the following fundamental issues in one way or another:<br />problem analysis (What?)<br />design (How?)<br />implementation<br />evaluation<br />maintenance<br />
  9. 9. Problem Analysis - What<br />We must specify the requirements of the software system<br />
  10. 10. Problem Analysis - What<br />We must specify the requirements of the software system<br />Must be based on accurate information<br />Various techniques:<br />discussions and negotiations with the client<br />modeling the problem structure and data flow<br />observation of client activities<br />analysis of existing solutions and systems<br />
  11. 11. Design - How<br />We must specify the solution<br />You would not consider building a bridge without a design<br />Design involves determining:<br />the overall software structure (architecture)<br />the key objects, classes, and their relationships<br />Alternatives should be considered<br />
  12. 12. Implementation<br />We must turn the design into functional software<br />Too many people consider this the primary act of software development<br />May involve the reuse of existing software components<br />
  13. 13. Evaluation<br />We must verify that the system conforms to the requirements<br />This includes, but goes way beyond, testing code with test cases<br />It is possible to build a system that has no bugs and yet is completely wrong<br />
  14. 14. Maintenance<br />After a system is initially developed, it must be maintained<br />This includes:<br />fixing errors<br />making enhancements to meet the changing needs of users<br />The better the development effort, the easier the maintenance tasks will be<br />
  15. 15. The Waterfall Model<br />One of the earliest development models<br />Each stage flows into the next<br />Driven by documentation<br />Advantages:<br />Lays out clear milestones and deliverables<br />Has high visibility – managers and clients can see the status<br />Disadvantages:<br />late evaluation<br />not realistic in many situations<br />
  16. 16. The Spiral Model<br />Developed by Barry Boehm in the mid '80s<br />Embraces an iterative process, where activities are performed over and over again for different aspects of the system<br />Designed to reduce the risks involved<br />Continually refines the requirements<br />Each loop through the spiral is a complete phase of development<br />
  17. 17. The Evolutionary Model***<br />Like the spiral model, an evolutionary approach embraces continual refinement<br />Intermediate versions of the system are created for evaluation by both the developers and the client<br />May be more difficult to maintain depending on the attention given to the iterations<br />
  18. 18. The Unified Modeling Language<br />The Unified Modeling Language (UML) has become a standard notation for software analysis (OOA) & design (OOD)<br />It is language independent<br />It includes various types of diagrams (models) which use specific icons and notations<br />However, it is flexible – the details you include in a given diagram depend on what you are trying to capture and communicate<br />
  19. 19. UML Class Diagrams<br />UML class diagrams may include:<br />The classes used in the system<br />The static relationships among classes<br />The attributesand operations of each class<br />The constraints on the connections among objects<br />An attributeis class level data, including variables and constants<br />An operation is essentially equivalent to a method<br />May include visibility details<br />+ public<br /><ul><li> private</li></ul># protected<br />
  20. 20. UML class diagram showing inheritance relationships<br />
  21. 21. UML class diagram showing an association<br />
  22. 22. One class shown as an aggregate of other classes<br />
  23. 23. UML diagram showing a class implementing an interface<br />
  24. 24. One class indicating its use of another<br />
  25. 25. Objectives<br />Advise on the class<br />Software Engineering<br />Problem solving<br />Memory<br />Classes<br />
  26. 26. Life Cycle<br />“Read a sequence of marks from the user, ending with the word ‘done’ and then print the average of the marks.”<br />
  27. 27. Specify — Design — Code — Test<br /> Edit—Compile—Run cycle: <br />Problem Solving<br />InitialDesign<br />Edit:<br />typing in the Java code <br />Specification<br />Compile:<br />Translating to executable <br />instructions <br />Run:<br />Testing the program to <br />see that it works <br />
  28. 28. Life Cycle<br />Problem<br />⇒Specification<br />⇒ Design of Solution<br />⇒ Computer program<br />⇒ Test and debug!<br />“Find the average mark in an exam”<br />“Read a sequence of marks from the user, ending with the word ‘done’ and then print the average of the marks.”<br />
  29. 29. Life Cycle<br />Problem<br />⇒ Problem description<br />⇒Design of Solution<br />⇒ Computer program<br />⇒ Test and debug<br />“Initialise count and sum<br /> loop:<br /> Prompt user for next number<br /> if user enters a non-number, then exit loop<br /> read the number, and add to the sum<br /> increment the count<br /> end loop<br /> print out the value of sum/count”<br />pseudocode<br />
  30. 30. Life Cycle<br />⇒ Problem description<br />⇒ Design of Solution <br />⇒Computer program<br />⇒ Test and debug<br />import java.util.*;<br />public class ExamAverage <br />{<br />public void findAverage () <br />{<br />int count = 0;<br />double sum = 0;<br />Scanner input = newScanner(System.in); <br />while (true)<br />{<br />System.out.print("Enter next mark: ");<br />if ( ! input.hasNextDouble() ) break;<br />sum = sum + input.nextDouble();<br />count = count + 1;<br />}<br />System.out.printf(“average mark = %4.2fn", sum/count);<br />}<br />}<br />
  31. 31. Life Cycle<br />⇒ Problem description<br />⇒ Design of Solution <br />⇒ Computer program<br />⇒Test and debug:<br /> Run the program on a range of possible inputs and check that it is correct. <br />Enter next mark: 70<br />Enter next mark: 85<br />Enter next mark: 65<br />Enter next mark: done<br />average mark = 73.33<br />Enter next mark: done<br />Error: divide by zero<br />
  32. 32. Objectives<br />Advise on the class<br />Software Engineering<br />Problem solving<br />Memory<br />Classes<br />
  33. 33. Machine Languages, Assembly Languages, and High-level Languages<br />Three types of programming languages<br />Machine languages<br />Strings of numbers giving machine specific instructions<br />Example:<br />+1300042774<br />+1400593419<br />+1200274027<br />Assembly languages<br />English-like abbreviations representing elementary computer operations (translated via assemblers)<br />Example:<br />LOAD BASEPAY<br />ADD OVERPAY<br />STORE GROSSPAY<br />High-level languages<br />Codes similar to everyday English<br />Use mathematical notations (translated via compilers)<br />Example:<br />grossPay = basePay + overTimePay<br />
  34. 34. History of C<br />C<br />Evolved by Ritchie from two previous programming languages, BCPL and B<br />Used to develop UNIX<br />Used to write modern operating systems<br />Hardware independent (portable)<br />By late 1970's C had evolved to "Traditional C“<br />Standardization<br />Many slight variations of C existed, and were incompatible<br />Committee formed to create a "unambiguous, machine-independent" definition<br />Standard created in 1989, updated in 1999<br />
  35. 35. The C Standard Library<br />C programs consist of pieces/modules called functions<br />A programmer can create his own functions<br />Advantage: the programmer knows exactly how it works<br />Disadvantage: time consuming<br />Programmers will often use the C library functions<br />Use these as building blocks<br />Avoid re-inventing the wheel!<br />If a premade function exists, generally best to use it rather than rewrite <br />Library functions carefully written, efficient, and portable<br />
  36. 36. The Key Software Trend: Object Technology<br />Objects <br />Reusable software componentsthat model items in the real world<br />Meaningful software units<br />Date objects, timeobjects, paycheckobjects, invoiceobjects, audio objects, videoobjects, file objects, recordobjects, etc.<br />Any noun can be represented as an object!<br />More understandable, better organized, and easier to maintain than procedural programming<br />Favor modularity<br />
  37. 37. C++<br />C++<br />Superset of C developed by BjarneStroustrup at Bell Labs<br />"Spruces up" C, and provides object-oriented capabilities<br />Object-oriented very powerful<br />10 to 100 fold increase in productivity<br />Dominant language in industry and academia<br />
  38. 38. Java<br />Java is used to <br />Create Web pages with dynamic and interactive content <br />Develop large-scale enterprise applications<br />Enhance the functionality of Web servers<br />Provide applications for consumer devices (such as cell phones, pagers and personal digital assistants)<br />
  39. 39. Other High-level Languages<br />Other high-level languages<br />FORTRAN<br />Used for scientific and engineering applications<br />COBOL<br />Used to manipulate large amounts of data<br />Pascal <br />Intended for academic use<br />
  40. 40. Basics of a Typical C Program Development Environment<br />Preprocessor program<br />processes the code.<br />Compiler creates object code and storesit on disk.<br />Compiler<br />Linker links the object<br />code with the libraries<br />Primary Memory<br />Loader<br />Loader puts program in memory.<br />Primary Memory<br />CPU takes each<br />instruction and executes it, possibly storing new data values as the program executes.<br /> <br />CPU<br />Preprocessor<br />Linker<br />Editor<br />Disk<br />Disk<br />Disk<br />Disk<br />Disk<br />.<br />.<br />.<br />.<br />.<br />.<br /> <br />.<br />.<br />.<br />.<br />.<br />.<br />Phases of C++ Programs:<br />Edit<br />Preprocess<br />Compile<br />Link<br />Load<br />Execute<br />Program is created in<br />the editor and stored<br />on disk.<br />
  41. 41. Memory Concepts<br />Variable names<br />Correspond to actual locations in computer's memory<br />Every variable has name, type, size and value<br />When new value placed into variable, overwrites previous value<br />Reading variables from memory nondestructive<br />
  42. 42. Memory Concepts<br />45<br />45<br />72<br />45<br />72<br />integer1<br />integer1<br />integer2<br />integer1<br />integer2<br />117<br />sum<br />std::cin >> integer1;<br />Assume user entered 45<br />std::cin >> integer2;<br />Assume user entered 72<br />sum = integer1 + integer2;<br />
  43. 43. Memory<br />9278<br />9279<br />9280<br />9281<br />9282<br />9283<br />9284<br />9285<br />9286<br />Main memory is divided into many memory locations (or cells)<br />Each memory cell has a numeric address, which uniquely identifies it<br />
  44. 44. Storing Information<br />Each memory cell stores a set number of bits (usually 8 bits, or one byte)<br />Large values are<br />stored in consecutive<br />memory locations<br />9278<br />9279<br />9280<br />9281<br />9282<br />9283<br />9284<br />9285<br />9286<br />10011010<br />
  45. 45. References<br />38<br />num1<br />"Steve Jobs"<br />name1<br />Note that a primitive variable contains the value itself, but an object variable contains the address of the object<br />An object reference can be thought of as a pointer to the location of the object<br />Rather than dealing with arbitrary addresses, we often depict a reference graphically<br />
  46. 46. Assignment Revisited<br />38<br />num1<br />Before:<br />96<br />num2<br />38<br />num1<br />After:<br />38<br />num2<br />The act of assignment =takes a copy of a value and stores it in a variable<br />For primitive types:<br />num2 = num1;<br />
  47. 47. Reference Assignment<br />"Steve Jobs"<br />name1<br />Before:<br />"Steve Wozniak"<br />name2<br />"Steve Jobs"<br />name1<br />After:<br />name2<br />For object references, assignment copies the address:<br />name2 = name1;<br />
  48. 48. Numeric Primitive Data<br />Type<br />byte<br />short<br />int<br />long<br />float<br />double<br />Storage<br />8 bits<br />16 bits<br />32 bits<br />64 bits<br />32 bits<br />64 bits<br />Min Value<br />-128<br />-32,768<br />-2,147,483,648<br />< -9 x 1018<br />+/- 3.4 x 1038<br />+/- 1.7 x 10308<br />Max Value<br />127<br />32,767<br />2,147,483,647<br />> 9 x 1018<br />The difference between the various numeric primitive types is their size, and therefore the values they can store:<br />9278<br />9279<br />9280<br />9281<br />9282<br />9283<br />9284<br />9285<br />9286<br />
  49. 49. C/C++ Program<br />1<br />2<br />3<br />4<br />5<br />6<br />7<br />8<br />
  50. 50. Another Picture<br />
  51. 51. Assembly & Machine Language<br />
  52. 52. An Assembler<br />
  53. 53. Compiler<br />
  54. 54. Software: User Programs<br />Programs that are neither OS programs nor applications are called user programs.<br />User programs are what you’ll be writing in this course.<br />
  55. 55. Putting it all together<br />Disk<br />RAM<br />CPU<br />Cache<br />OS<br />App<br />Bus<br />Programs and applications that are not running are stored on disk.<br />
  56. 56. Putting it all together<br />Disk<br />RAM<br />CPU<br />Cache<br />OS<br />App<br />App<br />OS<br />Bus<br /> When you launch a program, the OS controls the CPU and loads the program from disk to RAM.<br />
  57. 57. Putting it all together<br />Disk<br />RAM<br />CPU<br />Cache<br />OS<br />App<br />App<br />App<br />Bus<br />The OS then relinquishes the CPU to the program, which begins to run.<br />
  58. 58. The Fetch-Execute Cycle<br />As the program runs, it repeatedly <br /> fetches the next instruction (from memory/cache), <br />executes it, and <br />stores any results back to memory.<br />Disk<br />RAM<br />CPU<br />Cache<br />OS<br />App<br />App<br />App<br />Bus<br />That’s all a computer does: fetch-execute-store, millions of times each second!<br />
  59. 59. Object Oriented Paradigm<br />
  60. 60. Overview<br />Understand Classesand Objects.<br />Understand some of the key concepts/features in the Object Oriented paradigm.<br />Benefits of Object Oriented paradigm.<br />
  61. 61. OOP: Model, map, Reuse, extend<br />Model the real world problem to user’s perceive<br />Use similar metaphor in computational env.<br />Construct Reusable components<br />Create new components from existing ones.<br />
  62. 62. Examples of Objects<br />
  63. 63. Classes :Objectswith the same attributes and behavior<br />
  64. 64. Object Oriented Paradigm: Features<br />Encapsulation<br />Data Abstraction<br />Single Inheritance<br />OOP Paradigm<br />Polymorphism<br />Persistence<br />Delegation<br />Genericity<br />Multiple Inheritance<br />
  65. 65. Java’s OO Features<br />Encapsulation<br />Data Abstraction<br />Single Inheritance<br />Java<br />OOP Paradigm<br />Polymorphism<br />Persistence<br />Delegation<br />Genericity<br />Multiple Inheritance<br />
  66. 66. Encapsulation<br />Associates the Code & the Datait manipulates into a single unit; and keeps them safe from external interference and misuse.<br />Encapsulation<br />Data Abstraction<br />Single Inheritance<br />OOP Paradigm<br />Polymorphism<br />Persistence<br />Delegation<br />Data<br />Genericity<br />Code<br />Multiple Inheritance<br />
  67. 67. Data Abstraction<br />The technique of creating new data types that are well suited to an application. <br />It allows the creation of user defined data types, having the properties of built data types and a set of permitted operators.<br />In Java, partial support.<br />In C++, fully supported (e.g., operator overloading).<br />Encapsulation<br />Data Abstraction<br />Single Inheritance<br />OOP Paradigm<br />Polymorphism<br />Persistence<br />Delegation<br />Genericity<br />Multiple Inheritance<br />
  68. 68. Abstract Data Type (ADT)<br />A structure that contains both dataand the actions to be performed on that data.<br />Classis an implementation of an Abstract Data Type.<br />
  69. 69. ClassDefinition Syntax<br />69<br />
  70. 70. Class - Example<br />class Account <br />{ <br />private StringaccountName;<br />privatedoubleaccountBalance;<br />publicwithdraw();<br />publicdeposit();<br />public determineBalance();<br />} // Class Account<br />
  71. 71. Class<br />Class is a set of attributesand operations that are performed on the attributes.<br />Student<br />Circle<br />Account<br />accountName<br />accountBalance<br />name<br />age<br />studentId<br />centre<br />radius<br />withdraw()<br />deposit()<br />determineBalance()<br />area()<br />circumference()<br />getName()<br />getId()<br />
  72. 72. Objects<br />An Object Oriented system is a collection of interacting Objects.<br />Objectis an instance of a class.<br />
  73. 73. Classes /Objects<br />John and Jill are <br />objects of class<br />Student<br />:John<br />Student<br />:Jill<br />:circleA<br />circleA and circleB are <br />objects of class<br />Circle<br />Circle<br />:circleB<br />
  74. 74. Class<br />A class represents a template for several objects that have common properties. <br />A class defines all the properties common to the object - attributes and methods.<br />A class is sometimes called the object’s type.<br />
  75. 75. Object<br />Objects have state and classes don’t.<br />Johnis an object (instance) of class Student. <br />name = “John”, age = 20, studentId = 1236<br />Jill is an object (instance) of class Student. <br />name = “Jill”, age = 22, studentId = 2345<br />circleAis an object (instance) of class Circle. <br />centre = (20,10), radius = 25<br />circleB is an object (instance) of class Circle. <br />centre = (0,0), radius = 10<br />
  76. 76. Encapsulation<br />All information (attributes and methods) in an object oriented system are stored within the object/class.<br />Information can be manipulated through operations performed on the object/class– interface to the class. Implementation is hidden from the user.<br />Objectsupport Information Hiding – some attributes and methods can be hidden from the user.<br />
  77. 77. Encapsulation - Example<br />message<br />withdraw<br />deposit<br />account<br />Balance<br />message<br />determine Balance<br />message<br />class Account { <br />privatedoubleaccountBalance;<br />public withdraw();<br />public deposit();<br />public determineBalance();<br />} // Class Account<br />
  78. 78. Data Abstraction<br />The technique of creating new data types that are well suited to an application. <br />It allows the creation of user defined data types, having the properties of built in data types and more.<br />
  79. 79. Abstraction - Example<br />class Account { <br /> private String accountName;<br /> private double accountBalance;<br /> public withdraw();<br /> public deposit();<br /> public determineBalance();<br />} // Class Account<br /> Creates a data<br /> type Account<br />AccountacctX;<br />
  80. 80. Inheritance<br />Parent<br />Child<br />New data types (classes) can be defined as extensions to previously defined types.<br />Parent Class (Super Class) – Child Class (Sub Class)<br />Subclass inherits properties from the parent class.<br />Inheritedcapability<br />
  81. 81. Inheritance - Example<br />Examples<br />Define Person to be a class<br />A Person has attributes, such as age, height, gender<br />Assign values to attributes when describing object<br />Define student to be a subclass of Person <br />A studenthas all attributes of Person, plus attributes of his/her own ( student no, course_enrolled)<br />A studenthas all attributes of Person, plus attributes of his/her own (student no, course_enrolled)<br />A studentinherits all attributes of Person<br />Define lecturer to be a subclass of Person<br />lecturer has all attributes of Person, plus attributes of his/her own (staff_id, subjectID1, subjectID2)<br />
  82. 82. Inheritance - Example<br />Circle Class can bea subclass (inheritedfrom) of a parent class - Shape<br />Shape<br />Circle<br />Rectangle<br />
  83. 83. Inheritance - Example<br />Inheritance can also have multiple levels.<br />Shape<br />Circle<br />Rectangle<br />GraphicCircle<br />
  84. 84. Uses of Inheritance - Reuse<br />If multiple classes have common attributes/methods, these methods can be moved to a common class - parent class. <br />This allows reuse since the implementation is not repeated.<br /> Example : Rectangle and Circle method have a common method move(), which requires changing the center coordinate. <br />
  85. 85. Uses of Inheritance - Reuse<br />Circle<br />centre<br />radius<br />area()<br />circumference()<br />move(newCentre)<br />move(newCentre)<br />{<br />centre = newCentre;<br />}<br />Rectangle<br />centre<br />height<br />width<br />area()<br />circumference()<br />move(newCentre)<br />move(newCentre){<br /> centre = newCentre;<br />}<br />move(newCentre)<br />{<br />centre = newCentre;<br />}<br />
  86. 86. 86<br />Uses of Inheritance - Reuse<br />Shape<br />centre<br />move(newCentre)<br />{<br />centre = newCentre<br />}<br />area()<br />circumference()<br />move(newCentre)<br />Rectangle<br />Circle<br />height<br />width<br />radius<br />area()<br />circumference()<br />area()<br />circumference()<br />
  87. 87. Uses of Inheritance - Specialization<br />Specialized behavior can be added to the child class.<br />In this case the behaviour will be implemented in the child class.<br />e.g. the implementation of area() method in the Circle class is different from the area() method in the Rectangle class. <br />area() method in the child classes override the method in parent classes(). <br />
  88. 88. 88<br />Circle<br />centre<br />radius<br />area()<br />circumference()<br />move(newCentre)<br />area()<br />{<br /> return pi*r^2;<br />}<br />Uses of Inheritance - Specialization<br />Rectangle<br />centre<br />height<br />width<br />area()<br />circumference()<br />move(newCentre)<br />area()<br />{<br /> return height*width;<br />}<br />
  89. 89. 89<br />Uses of Inheritance - Specialization<br />area()<br />{<br /> return pi*r^2;<br />}<br />Shape<br />centre<br />area(); - not implemented <br />and left for the child classes<br />to implement<br />area()<br />circumference()<br />move(newCentre)<br />Rectangle<br />Circle<br />height<br />width<br />radius<br />area()<br />circumference()<br />area()<br />{<br /> return height*width;<br />}<br />area()<br />circumference()<br />
  90. 90. Uses of Inheritance – Common Interface<br />All the operations that are supported for Rectangle and Circle are the same. <br />Some methods have common implementation and others don’t.<br />move() operation is common to classes and can be implemented in parent.<br />circumference(), area() operations are significantly different and have to be implemented in the respective classes. <br />The Shape class provides a common interface where all 3 operations move(), circumference() andarea().<br />
  91. 91. Uses of Inheritance - Extension<br />Extend functionality of a class.<br />Child class adds new operations to the parent class but does not change the inherited behavior.<br />e.g. Rectangle class might have a special operation that may not be meaningful to the Circle class - rotate90degrees()<br />
  92. 92. Uses of Inheritance - Extension<br />Shape<br />centre<br />area()<br />circumference()<br />move(newCentre)<br />Rectangle<br />Circle<br />height<br />width<br />radius<br />area()<br />circumference()<br />rotate90degrees()<br />area()<br />circumference()<br />
  93. 93. Uses of Inheritance – Multiple Inheritance<br />Inherit properties from more than one class. <br />This is called Multiple Inheritance.<br />Shape<br />Graphics<br />Circle<br />
  94. 94. Uses of Multiple Inheritance<br />This is required when a class has to inherit behavior from multiple classes.<br />In the example Circle class can inherit move() operation from the Shape class and the paint() operation from the Graphics class.<br />Multiple inheritance is not supported in JAVA but is supported in C++. <br />
  95. 95. Uses of Inheritance – Multiple Inheritance<br />Shape<br />centre<br />area()<br />circumference()<br />move(newCentre)<br />Circle<br />radius<br />area()<br />circumference()<br />GraphicCircle<br />color<br />paint()<br />
  96. 96. Polymorphism<br />Polymorphic which means “many forms” has Greek roots.<br />Poly – many<br />Morphos - forms.<br />In OO paradigm polymorphism has many forms.<br />Allow a single object, method, operator associated with different meaning depending on the type of data passed to it.<br />
  97. 97. Polymorphism <br />An object of type Circle or Rectangle can be assigned to a Shapeobject. The behavior of the object will depend on the object passed.<br />circleA = new Circle(); Create a new circle object <br />Shape shape = circleA;<br />shape.area(); area() method for circle class will beexecuted<br />rectangleA = new Rectangle(); Create a new rectangle object<br />shape= rectangleA;<br />shape.area()area() method for rectangle will be executed.<br />
  98. 98. Polymorphism – Method Overloading<br />Multiple methods can be defined with the same name, different input arguments.<br />Method 1 - initialize(int a)<br />Method 2 - initialize(int a, int b)<br />Appropriate method will be called based on the input arguments.<br />initialize(2) Method 1 will be called.<br />initialize(2,4) Method 2 will be called.<br />
  99. 99. 99<br />Polymorphism – Operator Overloading<br />Allows regular operators such as +, -, *, / to have different meanings based on the type.<br />e.g. + operator for Circle can re-defined<br />Circle c = c + 2;<br />Not supported in JAVA. C++ supports it.<br />
  100. 100. 100<br />Persistence<br />The phenomenon where the object outlives the program execution.<br />Databases support this feature.<br />In Java, this can be supported if users explicitly build object persistency using IO streams.<br />
  101. 101. 101<br />Why OOP? <br />Greater Reliability<br />Break complex software projects into small, self-contained, and modular objects<br />Maintainability<br />Modular objects make locating bugs easier, with less impact on the overall project<br />Greater Productivity through Reuse!<br />Faster Design and Modelling<br />
  102. 102. Benefits of OOP..<br />Inheritance: Elimination of Redundant Code and extend the use of existing classes.<br />Build programs from existing working modules, rather than having to start from scratch.  save development time and get higher productivity.<br />Encapsulation: Helps in building secure programs.<br />
  103. 103. Benefits of OOP..<br />Multiple objects to coexist without any interference.<br />Easy to mapobjects in problem domain to those objects in the program.<br />It is easy to partition the work in a project based on objects.<br />
  104. 104. Benefits of OOP..<br />Object Oriented Systems can be easily upgraded from small to large systems.<br />Message-Passing technique for communication between objects make the interface descriptions with external systems much simpler.<br />Software complexity can be easily managed.<br />
  105. 105. Summary<br />Object Oriented Analysis, Design, and Programming is a Powerful paradigm<br />Enables Easy Mapping of Real world Objects to Objects in the Program<br />This is enabled by OO features:<br />Encapsulation<br />Data Abstraction<br />Inheritance<br />Polymorphism<br />Persistence<br />Standard OO Analysis and Design (UML) and Programming Languages (C++/Java) are readily accessible.<br />
  106. 106. What We Will Learn?<br />How to solve a problem.<br />Using Java<br />Java is a good language to start doing object oriented (OO) in because it attempts to stay true to all the different OO paradigms.<br />Copyright © 2011 Dept of Computer Science - University of Houston. All rights reserved.<br />
  107. 107. Differences Between Procedural Programming (PP) and Object Oriented Programming (OOP)<br />The focus of procedural programming is to break down a programming task into a collection of variables, functionsand modules, <br />whereas in object oriented programming it is to break down a programming task into objectswith each "object" encapsulating its own data (variables) and methods (functions). <br />We will sometimes use predefined classes and sometimes write our own classes.<br />OOP<br />PP<br />Variables<br />Data<br />Functions<br />Methods<br />Class<br />
  108. 108. Example program<br />Design and Implement a program to calculate perimeter of a circle.<br />PP<br />C<br />OOP<br />Java<br />Copyright © 2011 Dept of Computer Science - University of Houston. All rights reserved.<br />7-108<br />CLASS Participation A!<br />
  109. 109. Example program, PP in C<br />Design and Implement<br />PP<br />Variables<br />Functions<br />Driver.c<br />#include <iostream><br />const double PI=3.14;<br />void main()<br />{<br />doublecircleRadius = 10;<br />double circlePerimeter = 2*PI*circleRadius;<br />printf("Circle Perimiter%fn",circlePerimeter);<br />system("pause");<br />}<br />CLASS Participation B!<br />
  110. 110. Copyright © 2011 Dept of Computer Science - University of Houston. All rights reserved.<br />7-110<br />CLASS Participation B!<br />
  111. 111. Example program, OOP in Java<br />7-111<br />The core of OOP: “Put related things together.”<br />Design <br />Implement <br />Circle.java<br />public class Circle<br />{<br />private double radius;<br />static double PI = 3.14;<br />publicCircle(double r)<br /> {<br /> radius = r;<br /> }<br /> double getPerimeter()<br /> {<br /> return 2 * PI * radius;<br /> }<br />}<br />CLASS Participation B!<br />Main.java<br />public classMain {<br />public static void main(String[] args) <br /> {<br /> Circle circle = new Circle(10);<br />System.out.println("Circle Perimeter " + circle.getPerimeter());<br />}<br />}<br />Data<br />OOP<br />Methods<br />
  112. 112. Copyright © 2011 Dept of Computer Science - University of Houston. All rights reserved.<br />7-112<br />
  113. 113. Example program, PP in C<br />Design and Implement<br />PP<br />Variables<br />Functions<br />Driver.c<br />#include <iostream><br />const double PI=3.14;<br />void main()<br />{<br />doublecircleRadius = 10;<br />double circlePerimeter = 2*PI*circleRadius;<br />printf("Circle Perimiter%fn",circlePerimeter);<br />system("pause");<br />}<br />CLASS Participation B!<br />
  114. 114. Copyright © 2011 Dept of Computer Science - University of Houston. All rights reserved.<br />7-114<br />CLASS Participation B!<br />
  115. 115. Start with OOA&OOD or Coding?<br />The heart of object-oriented problem solving is the construction of a model.<br />Architects design buildings. Builders use the designs to create buildings. Blueprintsare the standard graphical language that both architects and builders must learn as part of their trade.<br />Writing software is not unlike constructing a building. <br />Writing software begins with the construction of a model. A model is an abstraction of the underlying problem. <br />Unified Modeling Language (UML) is a pictorial language used to makesoftware blueprints.<br />“A picture is worth a thousand words”<br />
  116. 116. OOAnalysis & Design: UML<br />Unified Modeling Language (UML) is a standardized general purpose modeling language in the field of software engineering.<br />UML includes a set of graphical notation techniques to create visual models of software intensive systems.<br />UML is not a programming language but tools can be used to generate code in various languages using UML diagrams. <br />UML has a direct relation with object oriented analysis and design.<br />The most important purpose of object oriented (OO) analysis is to identify objects of a system to be designed.<br />After identifying the objects their relationships are identified and finally the design is produced.<br />
  117. 117. Unified Modeling Language<br />UMLprovides structure for problem solving.<br />A method for modeling object oriented programs.<br />A means for visualizing, constructing and documenting software projects.<br />Promotes component reusability. <br />You will not understand what your algorithm does two weeks after you wrote it. But if you have the model, you will catch up fast and easily.<br />Teamwork for parallel development of large systems.<br />UMLincludes 13 diagrams.<br />
  118. 118. 1. UML Use Case Diagrams<br />The use case diagram is the first model when starting a project. <br />A use case is a set of scenarios that describing an interaction between a user and a system. The emphasis is on what a system does rather than how.<br />Use Case Diagram displays the relationship among actors (users) and use cases (scenarios ).<br />Use cases are used during the analysis phase of a project to identify and <br />to partition system functionality. The two main components of a use case diagram are use cases and actors.<br />An actor is represents a user or another system that will interact with the system you are modeling.<br />Use cases describe the behavior of the system when one of these actors perform a task.<br />
  119. 119. 1. UML Use Case Diagrams<br />We first write use cases, and then we draw them.<br />For example, here is a typical use case for a point of sale system. <br /> Here is just ONE USE CASE from this system<br />1. Cashier swipes product over scanner, scanner reads UPC code.<br />2. Price and description of item, as well as current subtotal appear on the display facing the customer. The price and description also appear on the cashier’s screen.<br />3. Price and description are printed on receipt.<br />4. System emits an audible “acknowledgement” tone to tell the cashier that the UPC code was correctly read.<br />Clearly a point of sale system has many more use cases than this.<br />Use Case 1: Check Out Item<br />
  120. 120. 1. Use Case Diagrams<br />Drawing Use Case Diagrams<br />1. Cashier swipes product over scanner, scanner reads UPC code.<br />2. Price and description of item, as well as current subtotal appear on the display facing the customer. The price and description also appear on the cashier’s screen.<br />3. Price and description are printed on receipt.<br />4. System emits an audible “acknowledgement” tone to tell the cashier that the UPC code was correctly read.<br />Inside the boundary rectangle we see the use cases. These are the ovals with names inside. The lines connect the actors to the use cases that they stimulate. <br />Use Case 1: Check Out Item<br />Use Case 1<br />Use Case 2<br />Use Case 3<br />Use Case 4<br />
  121. 121. 2. UMLClass Diagrams<br />The purpose of a class diagram is to depict the classes within a model.<br />A class diagram gives an overview of a system by showing its classes and the relationships among them. <br />In an object oriented application, classes have attributes(member variables), operations (member methods/functions) and relationships with other classes.<br />The fundamental element of the class diagram is an icon the represents a class. A class icon is simply a rectangle divided into 3 compartments. <br />The topmost compartment contains the name of the class. The middle compartment contains a list of attributes (member variables), and the bottom compartment contains a list of operations(member methods/functions). <br />In many diagrams, the bottom two compartments are omitted. Even when they are present, they typically do not show every attributeand operations. The goal is to show only those attributesandoperations that are useful for the particular diagram.<br />The central class is the Order. Associated with it are the Customer making the purchase and the Payment. A Payment is one of three kinds: Cash, Check, or Credit. The order contains OrderDetails (line items), each with its associated Item.<br />
  122. 122. 2. UML Class Diagrams<br />Notice that each member variable is followed by a colon and by the type of the variable.<br />Notice also that the return values follow the member methods/functions in a similar fashion.<br />Finally, notice that the member function arguments are just types.<br />Again, these can be omitted if they are redundant...<br />
  123. 123. 2. UML Class Diagrams<br />Class diagrams also display relationships among classes . <br />Each instance of type Circle seems to contain an <br /> instance of type Point.<br />This is a relationship known as composition.<br />It can be depicted in UML using a class relationship.<br />The black diamond represents composition. <br />It is placed on the Circle class because it is the Circle that is composed of a Point.<br />The arrowhead on the other end of the relationship denotes that the relationship is navigable in only one direction. That is, Point does not know about Circle. But, Circle knows about Point. The arrow lets you know who "owns" the association's implementation.<br />At the code level, this implies a NOimport Circle.java within Point.java <br />BUT, this also implies a import Point.java within Circle.java<br />In UMLrelationships are presumed to be bidirectional unless the arrowhead is present to restrict them.<br />
  124. 124. 2. UML Class Diagrams<br />Composition relationships (black diamond) are a strong form of aggregation.<br />Aggregation is a whole/part relationship. In this case, Circle is the whole, and Point is part of Circle .<br />Composition also indicates that the lifetime of Point is dependent upon Circle. This means that if Circle is destroyed, Point will be destroyed with it.<br />In this case we have represented the composition relationship as a member variable.<br />
  125. 125. 2. UML Class Diagrams<br />The weak form of aggregation is denoted with an open diamond.<br />This relationship denotes that the aggregate class (the class with the white diamond touching it) is in some way the “whole”, and the other class in the relationship is somehow “part” of that whole.<br />Window class containsmany Shape instances.<br />In UML the ends of a relationship are referred to as its “roles”.<br />Notice that the role at the Shape end of the aggregation is marked with a “*” (multiplicity). Multiplicity denotes the number of objects that can participate in the relationship. <br />Notice also that the role has been named. This is the name of the instance variable within Window that holds all the Shapes.<br />
  126. 126. 2. UML Class Diagrams<br />Another common relationship in class diagrams is a generalization. A generalization is used when two classes are similar, but have some differences. In other words, it shows the inheritance relationship .<br />The inheritance relationship (generalization) in UML is depicted by a peculiar triangular arrowhead. <br />In this diagram we see that Circle and Square (derived classes) both derive from Shape (base class/super class).<br />Circle and Square(derived classes) have some similarities, but each class has some of its own attributes and operations.<br />
  127. 127. Candy Machine Case Study<br />Requirements<br />Textual Analysis<br />UML Modeling<br />
  128. 128. UMLClass Diagram<br />Simplified methodology<br />1. Write down detailed description of problem<br />2. Identify all (relevant) nouns and verbs<br />3. From list of nouns, select objects<br />4. Identify data components of each object<br />5. From list of verbs, select operations<br />
  129. 129. UMLClass Diagram<br />A place to buy candy is from a candy machine. The candy machine has four dispensers to hold and release items sold by the candy machine as well as a cash register. The machine sells four products— candies, chips, gum, and cookies— each stored in a separate dispenser. <br /> The program should do the following:<br />Showthe customer the different productssold by the candy machine<br />Let the customermakethe selection<br />Showthe customerthe cost of the item selected<br />Acceptmoney from the customer<br />Return change<br />Release the item; that is, makethe sale<br />textual analysis<br />
  130. 130. UMLClass DiagramTextual Analysis<br />Place, candy, candy machine, cafeteria, dispenser, items, cash register, chips, gum, cookies, customer, products, cost ( of the item), money, and change.<br />In this description of the problem, products stand for items such as candy, chips, gum, and cookies. In fact, the actual product in the machine is not that important. What is important is to note that there are four dispensers, each capable of dispensing one product. Further, there is one cash register. Thus, the candy machine consists of four dispensers and one cash register. Graphically, this can be represented as in Figure 6-14.<br />
  131. 131. UMLClass Diagram<br />
  132. 132. UMLClass DiagramTextual Analysis<br />You can see that the program you are about to write is supposed to deal with dispensers and cash registers. That is, the main objects are four dispensers and a cash register. <br />Because all the dispensers are of the same type, you need to create a class, say, Dispenser, to create the dispensers. <br />Similarly, you need to create a class, say, CashRegister, to create a cash register. <br />We will create the classCandyMachine containing the four dispensers, a cash register, and the application program.<br />
  133. 133. UMLClass DiagramTextual Analysis<br />Dispenser To make the sale, at least one item must be in the dispenser and the customer must know the cost of the product. Therefore, the data members of a dispenser are: <br /> Product cost <br /> Number of items in the dispenser <br />Cash Register The cash register accepts money and returns change. Therefore, the cash register has only one data member, which we call <br /> cashOnHand<br />Candy Machine The classCandyMachine has four dispensers and a cash register. You can name the four dispensers by the items they store. Therefore, the candy machine has five data members— four dispensers and a cash register.<br />
  134. 134. UMLClass Diagram<br />Dispenser To make the sale, at least one item must be in the dispenser and the customer must know the cost of the product. Therefore, the data members of a dispenser are: <br /> Product cost <br /> Number of items in the dispenser <br />
  135. 135. UMLClass Diagram<br />Cash Register The cash register accepts money and returns change. Therefore, the cash register has only one data member, which we call <br /> cashOnHand<br />
  136. 136. UMLClass Diagram<br />Candy Machine The classCandyMachine has four dispensers and a cash register. You can name the four dispensers by the items they store. Therefore, the candy machine has five data members— <br /> four dispensers <br /> candy, <br /> chips, <br /> gum, <br /> cookies and a<br /> cash register.<br />
  137. 137. UMLClass Diagram<br />The relevant verbs are show ( selection), make ( selection), show ( cost), accept ( money), return ( change), and make ( sale). <br />The verbs show ( selection) and make ( selection) relate to the candy machine. <br />The verbs show ( cost) and make ( sale) relate to the dispenser. <br />Similarly, the verbs accept ( money) and return ( change) relate to the cash register.<br />
  138. 138. UMLClass Diagram<br />The verbs show ( selection) and make ( selection) relate to the candy machine. <br />Thus, the two possible operations are: <br />  showSelection: Show the number of products sold by the candy machine. <br />  makeSelection: Allow the customer to select the product.<br />
  139. 139. UMLClass Diagram<br />The verbs show ( cost) and make ( sale) relate to the dispenser. <br />The verb show ( cost) applies to either printing or retrieving the value of the data member cost. The verb make ( sale) applies to reducing the number of items in the dispenser by 1. <br />Of course, the dispenser has to be nonempty. <br />You must also provide an operation to set the cost and the number of items in the dispenser. <br />Thus, the operations for a dispenser object are: <br /> getCount: Retrieve the number of items in the dispenser. <br /> getProductCost: Retrieve the cost of the item.<br /> makeSale: Reduce the number of items in the dispenser by 1. <br /> setProductCost: Set the cost of the product. <br /> setNumberOfItems: Set the number of items in the dispenser<br />
  140. 140. UMLClass Diagram<br />Similarly, the verbs accept ( money) and return ( change) relate to the cash register.<br />The verb accept ( money) applies to updating the money in the cash register by adding the money deposited by the customer. Similarly, the verb return ( change) applies to reducing the money in the cash register by returning the overpaid amount ( by the customer) to the customer. <br />You also need to ( initially) set the money in the cash register and retrieve the money from the cash register. <br />Thus, the possible operations on a cash register are: <br /> acceptAmount: Update the amount in the cash register. <br /> returnChange: Return the change. <br /> getCashOnHand: Retrieve the amount in the cash register. <br /> setCashOnHand: Set the amount in the cash register.<br />
  141. 141. UMLClass Diagram<br />
  142. 142. UMLClass Diagram<br />Detailed Design Pseudocode for showSelectionmethod<br />Show the selection to the customer<br />Get selection<br />If selection is valid and the dispenser corresponding to the selection is not empty, sell the product<br />
  143. 143. UMLClass Diagram<br />Detailed Design Pseudocode for makeSalemethod<br />If the dispenser is nonempty:<br />Prompt customer to enter the item cost<br />Get the amount entered by the customer<br />If the amount entered by the customer is less than the cost of the product<br />Prompt customer to enter additional amount<br />Calculate total amount entered by the customer<br />If amount entered by the customer is at least the cost of the product<br />Update the amount in the cash register<br />Sell the product; that is, decrement the number of items in the dispenser by 1<br />Display an appropriate message<br />If amount entered is less than cost of item<br />Return the amount<br />If the dispenser is empty<br />Tell the customer that this product is sold out<br />
  144. 144. UMLClass Diagram<br />Detailed Design Pseudocode for main method<br />Declare a variable of type cashRegister<br />Declare and initialize four objects dispenserType<br />For example: <br />The statement <br />dispenserType chips(100, 65); <br /> creates a dispenser object, chips, to hold chips; the number of items in the dispenser is 100 and the cost of an item is 65 cents<br />
  145. 145. UMLClass Diagram<br />Detailed Design Pseudocode for main method<br />Declare additional variables as necessary<br />Show menu<br />Get the selection<br />While not done (9 exits)<br />Sell product (sellProduct)<br />Show selection (showSelection)<br />Get selection<br />
  146. 146. Case Study: Candy Machine <br />Implementation - JAVA<br />CLASS Participation C! <br />
  147. 147. Case Study: Candy Machine <br />Implementation- JAVA<br />
  148. 148. Case Study: Candy Machine <br />Implementation- JAVA<br />
  149. 149. JAVA<br />
  150. 150. Video Store Case Study<br />Requirements<br />Textual Analysis<br />UML Modeling<br />Copyright © 2011 Dept of Computer Science - University of Houston. All rights reserved.<br />7-150<br />
  151. 151. OO Analysis & OO Design and Implement in JAVA<br />Requirements<br />A video store intends to offer rentals (and sales) of video tapes and disks to the public. The store management is determined to launch its operations with the support of a computer system. The management has already sourced a number of small-business software packages but has decided to develop its own system. <br />The video store will keep a stock of video tapes, CDs and DVDs. The inventory has already been ordered from one supplier, but more suppliers will be approached in future orders. <br />All video tapes and disks will be bar-coded so that a scanning machine integrated with the system can support the rentals and returns. The customer membership cards will also be bar-coded. <br />Existing customers will be able to place reservations on videos to be collected at a specific date. The system must have a flexible search engine to answer customer enquiries, including enquiries about movies that the video store does not stock (but may order them on request).<br />The central class is the Order. Associated with it are the Customer making the purchase and the Payment. A Payment is one of three kinds: Cash, Check, or Credit. The order contains OrderDetails (line items), each with its associated Item.<br />
  152. 152. UMLUse Case Diagram – Textual Analysis<br />Actor: Whoever or whatever (person, machine etc.) that interacts with a use case.<br />Use case: It represents a complete unit of functionality of value to an actor.<br />Use Case Diagram: It is a visual representation of actors and use cases together with any additional definitions and specifications.<br />USE CASES<br />Before a video can be rented out, the system confirms customer’s identity by swiping over scanner his/her Video Store membership card. <br />Actors : ???<br />Use Case 1 : ???<br />
  153. 153. UMLUse Case Diagram – Textual Analysis<br />Actor: Whoever or whatever (person, machine etc.) that interacts with a use case.<br />Use case: It represents a complete unit of functionality of value to an actor.<br />Use Case Diagram: It is a visual representation of actors and use cases together with any additional definitions and specifications.<br />USE CASES<br />Before a video can be rented out, the system confirms customer’s identity by swiping over scanner his/her Video Store membership card. <br />Actors : Customer and Employee<br />Use Case 1 : Scan Membership Card<br />
  154. 154. UMLUse Case Diagram – Textual Analysis<br />Actor: Whoever or whatever (person, machine etc.) that interacts with a use case.<br />Use case: It represents a complete unit of functionality of value to an actor.<br />Use Case Diagram: It is a visual representation of actors and use cases together with any additional definitions and specifications.<br />USE CASES<br />Before a video can be rented out, the system confirms customer’s identity by swiping over scanner his/her Video Store membership card. <br />Actors : Customer and Employee<br />Use Case 1 : Scan Membership Card<br />A video tape or disk can be swiped over scanner to obtain its description and price (fee) as part of customer’s enquiry or rental request.<br />Actors : ???<br />Use Case 2 : ???<br />
  155. 155. UMLUse Case Diagram – Textual Analysis<br />Actor: Whoever or whatever (person, machine etc.) that interacts with a use case.<br />Use case: It represents a complete unit of functionality of value to an actor.<br />Use Case Diagram: It is a visual representation of actors and use cases together with any additional definitions and specifications.<br />USE CASES<br />Before a video can be rented out, the system confirms customer’s identity by swiping over scanner his/her Video Store membership card. <br />Actors : Customer and Employee<br />Use Case 1: Scan Membership Card<br />A video tape or disk can be swiped over scanner to obtain its description and price (fee) as part of customer’s enquiry or rental request.<br />Actors : Customer and Employee<br />Use Case 2 : Scan Video Medium<br />
  156. 156. UMLUse Case Diagram – Textual Analysis<br />Actor: Whoever or whatever (person, machine etc.) that interacts with a use case.<br />Use case: It represents a complete unit of functionality of value to an actor.<br />Use Case Diagram: It is a visual representation of actors and use cases together with any additional definitions and specifications.<br />USE CASES<br />Before a video can be rented out, the system confirms customer’s identity by swiping over scanner his/her Video Store membership card. <br />Actors : Customer and Employee<br />Use Case 1 : Scan Membership Card<br />A video tape or disk can be swiped over scanner to obtain its description and price (fee) as part of customer’s enquiry or rental request.<br />Actors : Customer and Employee<br />Use Case 2 : Scan Video Medium<br />Customer pays the nominal fee before the video can be rented out. The payment may be with cash or debit/credit card. <br />Actors : ???<br />Use Case 3 : ???<br />
  157. 157. UMLUse Case Diagram – Textual Analysis<br />Actor: Whoever or whatever (person, machine etc.) that interacts with a use case.<br />Use case: It represents a complete unit of functionality of value to an actor.<br />Use Case Diagram: It is a visual representation of actors and use cases together with any additional definitions and specifications.<br />USE CASES<br />Before a video can be rented out, the system confirms customer’s identity by swiping over scanner his/her Video Store membership card. <br />Actors : Customer and Employee<br />Use Case 1 : Scan Membership Card<br />A video tape or disk can be swiped over scanner to obtain its description and price (fee) as part of customer’s enquiry or rental request.<br />Actors : Customer and Employee<br />Use Case 2 : Scan Video Medium<br />Customer pays the nominal fee before the video can be rented out. The payment may be with cash or debit/credit card. <br />Actors : Customer and Employee<br />Use Case 3, 4 : Accept Payment and Charge Payment to Card<br />
  158. 158. UMLUse Case Diagram – Textual Analysis<br />USE CASES<br />Before a video can be rented out, the system confirms customer’s identity by swiping over scanner his/her Video Store membership card. <br />Actors : Customer and Employee<br />Use Case 1 : Scan Membership Card<br />A video tape or disk can be swiped over scanner to obtain its description and price (fee) as part of customer’s enquiry or rental request.<br />Actors : Customer and Employee<br />Use Case 2 : Scan Video Medium<br />Customer pays the nominal fee before the video can be rented out. The payment may be with cash or debit/credit card. <br />Actors : Customer and Employee<br />Use Case 3, 4 : Accept Payment and Charge Payment to Card<br />The system verifies all conditions for renting out the video, acknowledges that the transaction can go ahead, and can print the receipt for the customer. <br />Actors : ???<br />Use Case 5 : ???<br />
  159. 159. UMLUse Case Diagram – Textual Analysis<br />USE CASES<br />Before a video can be rented out, the system confirms customer’s identity by swiping over scanner his/her Video Store membership card. <br />Actors : Customer and Employee<br />Use Case 1 : Scan Membership Card<br />A video tape or disk can be swiped over scanner to obtain its description and price (fee) as part of customer’s enquiry or rental request.<br />Actors : Customer and Employee<br />Use Case 2 : Scan Video Medium<br />Customer pays the nominal fee before the video can be rented out. The payment may be with cash or debit/credit card. <br />Actors : Customer and Employee<br />Use Case 3, 4 : Accept Payment and Charge Payment to Card<br />The system verifies all conditions for renting out the video, acknowledges that the transaction can go ahead, and can print the receipt for the customer. <br />Actors : Customer and Employee<br />Use Case 5 : Print Receipt<br />
  160. 160. An Example: UML Use Case Diagram<br />
  161. 161.
  162. 162. UC3: Accept Payment<br />
  163. 163. An Example: What is next?<br />Use Case View<br />Use Case Diagram<br />Structural View<br />Class Diagram<br />Object Diagram<br />Composite Structure Diagram<br />Behavioral View<br />Sequence Diagram<br />Communication Diagram<br />State Diagram<br />Activity Diagram<br />Interaction Overview Diagram<br />Timing Diagram<br />Implementation View<br />Component Diagram<br />Composite Structure Diagram<br />Environment View<br />Diagram<br />
  164. 164. UML Activity Diagram – Textual Analysis<br />Activity Diagram represents a behavior that is composed of individual elements.<br />The behavior may be a specification of a use case.<br />Activity Diagram can graphically represent the flow of events of a use case<br />Shows the steps of computation<br />We need to find actions (steps) in use case flows.<br />
  165. 165. Finding actions in use case – Textual Analysis<br />1. The Employee requests the system to display the rental charge together with basic customer and video details.<br />2. If the Customer offers cash payment, the Employee handles the cash, confirms to the system that the payment has been received and asks the system to record the payment as made.<br />3. If the Customer offers debit/credit card payment, the Employee swipes the card and then requests the Customer to type the card’s PIN number, select debit or credit account, and transmit the payment. Once the payment has been confirmed electronically by the card provider, the system records the payment as made .<br />Action 1: Display transaction details<br />Action 2: Key in cash amount<br />Action 3: Confirm transaction<br />Action 4: Swipe the card<br />Action 5: Accept card number<br />Action 6: Select card account<br />Action 3: Confirm transaction<br />
  166. 166. Finding actions in use case – Textual Analysis<br />4. The Customer’s card does not swipe properly through the scanner. After three unsuccessful attempts, the Employee enters the card number manually.<br />5. The Customer does not have sufficient cash and does not offer card payment. The Employee asks the system to verify the Customer’s rating (which accounts for the Customer’s history of payments). Depending on the decision, the Employee cancels the transaction (and the use case terminates) or proceeds with partial payment (and the use case continues).<br />Action 7: Enter card number manually<br />Action 8: Verify Customer rating;<br />Action 9: Refuse transaction;<br />Action 10: Allow rent with no payment;<br />Action 11: Allow rent with partial payment<br />
  167. 167. UML Activity Diagram – Textual Analysis<br />Activity diagram shows transitions between actions.<br />Transitions can branch and merge<br />Action 1: Display transaction details<br />Action 4: Swipe the card<br />Action 5: Accept card number<br />Action 6: Select card account<br />Action 3: Confirm transaction<br />Action 2: Key in cash amount<br />Action 3: Confirm transaction<br />Action 7: Enter card number manually<br />Action 8: Verify Customer rating;<br />Action 9: Refuse transaction;<br />Action 10: Allow rent with no payment;<br />Action 11: Allow rent with partial payment<br />
  168. 168. UML Activity Diagram<br />A5:<br />A1:<br />A4:<br />A6:<br />A2:<br />A7:<br />A8:<br />A11:<br />A10:<br />A3:<br />A9:<br />
  169. 169. An Example: Activity Diagram<br />
  170. 170. An Example: What is next?<br />Use Case View<br />Use Case Diagram<br />Structural View<br />Class Diagram<br />Object Diagram<br />Composite Structure Diagram<br />Behavioral View<br />Sequence Diagram<br />Communication Diagram<br />State Diagram<br />Activity Diagram<br />Interaction Overview Diagram<br />Timing Diagram<br />Implementation View<br />Component Diagram<br />Composite Structure Diagram<br />Environment View<br />Diagram<br />
  171. 171. UML Class Diagram – Textual Analysis<br />Class modeling captures the static view of the system although it also identifies operations that act on data. <br />Class modeling elements<br />Classes themselves<br />Attributes (data)and operations (methods) of classes<br />Relationships - associations, aggregation and composition, and generalization.<br />Class diagram is a combined visual representation for class modeling elements.<br />Assignment of use cases to classes<br />FINDING CLASSES is an iterative task as the initial list of candidate classes is likely to change.<br />Answering a few questions may help to determine whether a CONCEPT in a USE CASEis a candidate CLASS or not. The questions are following:<br />Is the concept a container for data?<br />Does it have separate attributes that will take on different values?<br />Would it have many instance objects?<br />
  172. 172. UML Class Diagram – Textual Analysis<br />Before a video can be rented out, the system confirms customer’s identity by swiping over scanner his/her Video Store membership card.<br />Classes?<br />
  173. 173. UML Class Diagram – Textual Analysis<br />Before a video can be rented out, the system confirms customer’s identity by swiping over scanner his/her Video Store membership card.<br />Classes?<br />Video,<br />Customer,<br />MembershipCard<br />
  174. 174. UML Class Diagram – Textual Analysis<br />Before a video can be rented out, the system confirms customer’s identity by swiping over scanner his/her Video Store membership card.<br />Classes?<br />Classes?<br />Video,<br />Customer,<br />MembershipCard<br />A video tape or disk can be swiped over scanner to obtain its description and price (fee) as part of customer’s enquiry or rental request.<br />
  175. 175. UML Class Diagram – Textual Analysis<br />Before a video can be rented out, the system confirms customer’s identity by swiping over scanner his/her Video Store membership card.<br />Classes?<br />Classes?<br />Video,<br />Customer,<br />MembershipCard<br />A video tape or disk can be swiped over scanner to obtain its description and price (fee) as part of customer’s enquiry or rental request.<br />VideoTape<br />VideoDisk,<br />Customer,<br />Rental<br />
  176. 176. UML Class Diagram – Textual Analysis<br />Before a video can be rented out, the system confirms customer’s identity by swiping over scanner his/her Video Store membership card.<br />Classes?<br />Classes?<br />Classes?<br />Video,<br />Customer,<br />MembershipCard<br />A video tape or disk can be swiped over scanner to obtain its description and price (fee) as part of customer’s enquiry or rental request.<br />VideoTape<br />VideoDisk,<br />Customer,<br />Rental<br />Customer pays the nominal fee before the video can be rented out. The payment may be with cash or debit/credit card. <br />
  177. 177. UML Class Diagram – Textual Analysis<br />Classes?<br />Classes?<br />Classes?<br />Before a video can be rented out, the system confirms customer’s identity by swiping over scanner his/her Video Store membership card.<br />Video,<br />Customer,<br />MembershipCard<br />A video tape or disk can be swiped over scanner to obtain its description and price (fee) as part of customer’s enquiry or rental request.<br />VideoTape<br />VideoDisk,<br />Customer,<br />Rental<br />Customer pays the nominal fee before the video can be rented out. The payment may be with cash or debit/credit card. <br />Customer,<br />Video,<br />Rental,<br />Payment<br />
  178. 178. UML Class Diagram – Textual Analysis<br />Classes?<br />Classes?<br />Classes?<br />Classes?<br />Before a video can be rented out, the system confirms customer’s identity by swiping over scanner his/her Video Store membership card.<br />Video,<br />Customer,<br />MembershipCard<br />A video tape or disk can be swiped over scanner to obtain its description and price (fee) as part of customer’s enquiry or rental request.<br />VideoTape<br />VideoDisk,<br />Customer,<br />Rental<br />Customer pays the nominal fee before the video can be rented out. The payment may be with cash or debit/credit card. <br />Customer,<br />Video,<br />Rental,<br />Payment<br />The system verifies all conditions for renting out the video, acknowledges that the transaction can go ahead, and can print the receipt for the customer. <br />
  179. 179. UML Class Diagram – Textual Analysis<br />Classes?<br />Classes?<br />Classes?<br />Classes?<br />Video,<br />Customer,<br />MembershipCard<br />VideoTape<br />VideoDisk,<br />Customer,<br />Rental<br />Customer,<br />Video,<br />Rental,<br />Payment<br />Rental,<br />Receipt<br />
  180. 180. UML Class Diagram – Textual Analysis<br />
  181. 181. UML Class Diagram<br />
  182. 182. UML Class Diagram– Attributes– Textual Analysis<br />Identifying attributesfor each class<br />Attributes are discovered form user requirements and domain knowledge.<br />One or more attributes in a class will have unique values across all the instances (objects) of the class. Such attributes are called keys. <br />
  183. 183. C2<br />C3<br />
  184. 184.
  185. 185. UML Class Diagram<br />
  186. 186. References<br />http://edn.embarcadero.com/article/31863<br />http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/<br />http://www.objectmentor.com/resources/articles/umlClassDiagrams.pdf<br />http://www.objectmentor.com/resources/publishedArticles.html<br />http://www.objectmentor.com/resources/articles/usecases.pdf<br />http://www.objectmentor.com/resources/articles/Use_Cases_UFJP.pdf<br />http://www.tutorialspoint.com/uml/uml_overview.htm<br />

×