1 / 213

Object Oriented Programming

Object Oriented Programming. Marc L. Smith mlsmith@cs.ucf.edu http://www.cs.ucf.edu/~mlsmith School of EECS University of Central Florida. Week#1. Basic Information. Who and Where?. Instructor: Marc L. Smith Meeting Times and Place: W 19:00 to 21:45 in CL1 104 Office Hours:

lotus
Download Presentation

Object Oriented Programming

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

E N D

Presentation Transcript

  1. Object Oriented Programming Marc L. Smith mlsmith@cs.ucf.edu http://www.cs.ucf.edu/~mlsmith School of EECS University of Central Florida © UCF SEECS 2001

  2. Week#1 © UCF SEECS 2001

  3. Basic Information © UCF SEECS 2001

  4. Who and Where? • Instructor: Marc L. Smith • Meeting Times and Place: W 19:00 to 21:45 in CL1 104 • Office Hours: W 17:30 to 18:30; R 19:00 to 21:00; CSB 207 • Text: Object-Oriented Software Development Using JavaXiaoping Jia, Addison-Wesley, 2000. • Web Page: http://www.cs.ucf.edu/courses/cop3930-OOP/Smith/ © UCF SEECS 2001

  5. Other Java Learning Resources • The Java Programming Language, Third EditionK. Arnold, J. Gosling, D. Holmes, Addison-Wesley, 2000 • Thinking in Java, 2nd EditionBruce Eckel, Prentice Hall, 2000 also on-line at http://www.eckelobjects.com/ • The Java Tutorial Second Edition: Object-Oriented Programming for the Internet Mary Campione, Kathy Walrath, Addison-Wesley, 1998 also on-line at http://java.sun.com/docs/books/tutorial/index.html • Design Patterns: Elements of Reusable Object-Oriented SoftwareGamma, Helm, Johnson & Vlissides, Addison-Wesley, 1995 © UCF SEECS 2001

  6. Software Development • Java IDE: JBuilder Foundation 4 http://www.borland.com/jbuilder/foundation/Need support for Java 2 -- jdk1.3 or later, preferably jdk1.3. JBuilder is packaged with jdk1.3. © UCF SEECS 2001

  7. Prerequisites • Knowledge of core syntax of C as presented in COP 3223 – this can also be satisfied by a programming course in Java or C++. • Programming experience as would be required to successfully complete assignments in COP 3223. © UCF SEECS 2001

  8. What you Hopefully will Learn • Object Oriented Principles • The Java Programming Language and Culture – to the level of being proficient at designing and implementing small to medium size programs • Enough about C++ to know how it addresses the OO paradigm relative to how Java does this. © UCF SEECS 2001

  9. Why JBuilder 4? • It’s Free • It has a GUI designer that does not trash your program; no magical comments • It has one of the best help systems around; you can peruse the Java class files with great ease • It includes a very slick interface for running both applets and applications • It can be configured for any JDK, even the pared-down class hierarchy used to create software for pda’s – Note: The free JBuilder can only manage one JDK at a time. The Pro version manages multiple JDK’s on a per-project basis. © UCF SEECS 2001

  10. Evaluation • Exams: Midterm and Final for about 50% of grade • Programming Assignments: Four of five for about 30% of grade; Adhere to Deadlines • Quizzes: Two for about 20% of grade © UCF SEECS 2001

  11. Some Guiding PrinciplesMotherhood and Apple Pie Included at No Extra Cost © UCF SEECS 2001

  12. Programming in the Small • Code is developed by one programmer • Maybe a small close-knit group • One person can understand the entire system • To them the system is self-documenting • The creator is the maintainer • Designed to solve a particular (singular) problem • System does not have a long life cycle • The biggest problem is getting it done on time © UCF SEECS 2001

  13. Programming in the Large • Developed by a large team of programmers with a lot of input from management • Nobody really knows what is really going on inside all parts of the system • Everybody has their own little piece • The system is designed to solve a “systems” level problem • Ideally, the system will be around for a long time • Communication (developers to customers & developers to developers) is the biggest problem © UCF SEECS 2001

  14. Desirable System Qualities • Useful – meets needs • Timely – shipped when expected • Reliable – within tolerable limits • Easy to use – by intended audience • Efficient – including good algorithms • Maintainable – flexible, simple, readable • Over 40% of maintenance is change in user requirements • Reusable – by you and others • These are the two primary issues for this course, and the ones most effectively addressed by the OO Paradigms © UCF SEECS 2001

  15. Maintainability Factors • Flexibility • Easily changeable; limited impact from changes • Simplicity • All complex systems have errors; dividing a system into simpler components reduces or at least manages complexity • Readability • Clarity is a great aid to maintainability; simple, consistent style aids understandability © UCF SEECS 2001

  16. Software Phases • Conceptualization • Requirements – informal description of what is needed; often includes prototype to help resolve issues • Specifications – formal requirements; can be legal document; often includes walkthrough with client, moderated by QA staff • Analysis and Modeling – identifying the software components • Design – designing the components and their relationships • Implementation – making it real • Integration – putting the parts together with each other and existing components • Maintenance – fixing, improving, adapting © UCF SEECS 2001

  17. Focus of Course • We will focus on • Analysis and Modeling • Design • Implementation • This is an iterative part of the process. Design often uncovers missing components. Of course, any of these phases can drive us all the ways back to requirements, but we will focus on the tighter loop above. © UCF SEECS 2001

  18. Basic Vocabulary • Abstraction • Selective examination of certain aspects of a problem • The goal is to isolate those aspects that are important for some purpose and suppress those that are unimportant • Many different abstractions of the same thing are possible, depending on the purposes for which they are made • Model • An abstraction used to understand or reason about some real object • Omits nonessential details and is at granularity appropriate for its purposes • Methodology (in software engineering) • A process for the organized production of software using a collection of predefined techniques and notional conventions © UCF SEECS 2001

  19. Modeling • Designing a system is about modeling the problem space (real world) • Issues include • What are the components of the real world? • How do they behave? • How do they interact? • What can we ignore? © UCF SEECS 2001

  20. The Java Environment © UCF SEECS 2001

  21. Java Attributes • Run on many platforms • Unix, Windows, Mac • Develop on multiple platforms • The usual suspects • Reuse at many levels • Components • Classes (families of components) • Frameworks (collaborating components) © UCF SEECS 2001

  22. Features • Browser friendly • Network aware • Implements new paradigms • User interface framework • Distributed computing framework(s) • Multimedia framework • 3D framework • … © UCF SEECS 2001

  23. Protecting Your Investment • Reuse, don’t reinvent • Use components and frameworks • Across many products • Component assembly via beans • Plug in look and feel • Maintain same across all platforms • Or adapt to local preferences © UCF SEECS 2001

  24. More on Your Investment • Develop for international market • Java characters are Unicode • Meet accessibility needs of clientele • Visual or hearing impaired • Deliver early prototypes • Open/closed principle of good OO • Upgrade incrementally • Replace parts of system through jars © UCF SEECS 2001

  25. How is Java Portable? • Java source code (.java) is compiled for a JVM • JVM = Java virtual machine • Byte code files (.class) run on the JVM via • Machine emulation on local host • Just-in-time compilation from byte to native codes • An actual silicon implementation of the JVM © UCF SEECS 2001

  26. JVM • RISC architecture • Registers used to maintain stack • Top of stack, Local variables, Frame (current context) • Primitive data and object handles are on stack • Objects are allocated from a garbage collected heap • JVM also does • Exception handling and thread synchronization © UCF SEECS 2001

  27. The Development Environment • There are lots of IDEs. • Our choice of Borland JBuilder4 was its lack of placing tags in your source to synchronize the Visual Design component with your code. It also has a great help facility and instant access to base class code. • JBuilder4 uses the JVM for its compiler and run time, but does incremental parsing to keep your source synched with design. © UCF SEECS 2001

  28. Applications versus Applets • Java applications run like any other program, with all the rights and privileges thereto appertaining • Applets run in a sandbox, Internet browser or applet viewer • The sand box provides services, but limits what applet can do • No reading or writing files on local machine (just from host) • No network connections, except back to host • No inter-applet communication except to others from same host • JVM enforces byte-code verification, security management • Java language does not allow pointer manipulation © UCF SEECS 2001

  29. Hello Examples © UCF SEECS 2001

  30. Hello Java Application • class Hello { • /** A Java app prints "Hello!" */ • public static void main (String args[]) { • System.out.println("Hello!"); • /* System.out refers to the standard output */ • } • } © UCF SEECS 2001

  31. Vocabulary • public • accessible by clients of class • static • belongs to the class; non-static belong to instances • void • returns nothing • main • must be public; called by you execute application • String • immutable strings (StringBuffer used if must change characters) • String args[] • array of Strings from command line (does not include class name) • System • base class containing system items like console handles • System.out • console output stream © UCF SEECS 2001

  32. A Swing Java Application • import javax.swing.*; • import java.awt.*; • import java.awt.event.*; • public class HelloApp extends JFrame { • public HelloApp() { • super("An Application"); • Container contentPane = getContentPane(); • Icon icon = new ImageIcon("swing.gif", "Duke on a swing"); • JLabel label = new JLabel("Welcome!", icon, SwingConstants.CENTER); • contentPane.add(label, BorderLayout.CENTER); • } • public static void main(String args[]) { • final JFrame f = new HelloApp(); • f.setBounds(100,100,300,250); • f.setVisible(true); • f.setDefaultCloseOperation(DISPOSE_ON_CLOSE); • f.addWindowListener(new WindowAdapter() { • public void windowClosed(WindowEvent e) {System.exit(0);} • }); • } • } © UCF SEECS 2001

  33. Vocabulary • import • opens up a library so we can use its classes • javax.swing.*; java.awt.*; java.awt.event.* • all classes defined in directories <classpath>/javax/swing/, etc. • swing is new model/view framework • JFrame • a heavyweight container • getContentPane • called to get the Container into which “lightweight” Swing components are placed • ImageIcon • class each of whose instances holds a named small image • JLabel • swing label that includes text and a graphical component; awt labels contain only text • final • write once variable • addWindowListener • listeners gets notified of events in which they are interested • new WindowAdapter() { overriden methods } • anonymous object to capture window events; here exit on close of window © UCF SEECS 2001

  34. Hello Java Applet import java.awt.*; import java.applet.Applet; public class HelloApplet extends Applet { public void paint(Graphics g) { Dimension d = getSize(); g.setColor(Color.black); g.fillRect(0,0,d.width,d.height); g.setFont(new Font("Helvetica", Font.BOLD, 24)); g.setColor(new Color(255, 215, 0)); // gold color g.drawString("Welcome!", 40, 25); g.drawImage(getImage(getCodeBase(), "swing.gif"), 20, 60, this); } } © UCF SEECS 2001

  35. Vocabulary • java.applet.Applet • Applet class defined in the directory <classpath>/java/applet/ • extends • adds or overrides services from a parent class (super type) • Applet • the class defining standard applet services and parts • paint • called when Component image is originally drawn or must be repaired (uses clipping) • Graphics • the class associated with graphical contexts • Dimension • class of two-dimensional objects • getSize( ) • returns dimension of Applet • getImage(getCodeBase(), "swing.gif") • Applets can acquire images; code base is directory of Applet © UCF SEECS 2001

  36. Hello Java Applet HTML <title>Test</title> <hr> <applet code=“HelloApplet.class" width=300 height=150> </applet> <hr> © UCF SEECS 2001

  37. Hello Java JApplet • import javax.swing.*; • import java.awt.*; • public class HelloJApplet extends JApplet { • public void init() { • Container contentPane = getContentPane(); • Icon icon = new ImageIcon("swing.gif", “Swinging Duke"); • JLabel label = new JLabel("Welcome!", icon, • SwingConstants.CENTER); • contentPane.add(label, BorderLayout.CENTER); • } • } © UCF SEECS 2001

  38. Vocabulary • JApplet • the class defining standard applet services and parts in the swing framework • getContentPane • called to get the Container into which “lightweight” Swing components are placed • ImageIcon • class each of whose instances holds a named small image • SwingConstants • interface holding standard Swing constants • BorderLayout • interface holding standard BorderLayout constants © UCF SEECS 2001

  39. Hello Java JApplet HTML <title>Test</title> <hr> <applet code=“HelloJApplet.class" width=300 height=150> </applet> <hr> © UCF SEECS 2001

  40. Applets versus JApplets • Applets run in all JVMs • JApplets only run in JVM for Java 2 – JDK1.2 and later. • Communicator 6 is needed to view JApplets in a standard browser. • Jbuilder 4 supports viewing both Applets and JApplets © UCF SEECS 2001

  41. Jars • To transport images and multiple class files, put them in a jar – can use deployment wizard in JBuilder4 <APPLET CODE = “HelloJApplet.class" ARCHIVE = "HelloJApplet.jar" WIDTH = 300 HEIGHT = 150 > </APPLET> © UCF SEECS 2001

  42. Get Some Experience • Alter the trivial HelloJApplet applet to make it personal. Put in any image you like and any text. • For those with experience, help your colleagues get started. © UCF SEECS 2001

  43. Principles and Concepts © UCF SEECS 2001

  44. Modularity • A system is a collection of highly cohesive, but loosely coupled modules • Cohesiveness is a measure of intra-module relatedness • Coupling is a measure of module interdependency • In process-oriented programming, modules are procedures • In object-oriented programming, modules are classes and packages © UCF SEECS 2001

  45. Modularity Questions • Decomposable – how to divide? • Composable – how to make it possible to put pieces together easily? • Understandable – how to make it easy to follow? • Continuity – how to guarantee that small specification changes lead to isolated code changes? • Isolation/Protection – how to prevent changes from propagating far; supports continuity © UCF SEECS 2001

  46. Process versus Object • Processes • Data structures are designed to fit processes • Processes and data structures conceived in solution space • Objects • Objects are from the problem space • They survive changes in functionality © UCF SEECS 2001

  47. Proverb (Bertrand Meyer) Ask not what the system does; Ask what it does it to! © UCF SEECS 2001

  48. Insights #1 (Grady Booch) We cannot hope to reduce the complexity of our problems. Abstraction and Information Hiding are software engineering's best hopes to date for managing the complexity of our solutions to problems. © UCF SEECS 2001

  49. Insights #2 (Bertrand Meyer) In the evolution of a system, the functions tend to be the most volatile parts. A successful system will soon be asked to perform new tasks. © UCF SEECS 2001

  50. Insights #3 (Sapir / Whorf) We see and hear and otherwise experience very largely as we do because the language habits of our community predispose certain choices of interpretation. © UCF SEECS 2001

More Related