1 / 28

CS288 Object-Oriented Software Engineering Motivation and Introduction

This course provides an overview of object-oriented software engineering, covering topics such as UML modeling, Java programming, and the business design process.

ddeardorff
Download Presentation

CS288 Object-Oriented Software Engineering Motivation and Introduction

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. CS288Object-Oriented Software EngineeringMotivation and Introduction Bill Mitchell

  2. Overview • Outline of course • Introduction to business development process • Motivation for Object Oriented Programming

  3. Outline of Course • UML modelling concepts • Use Case Diagrams • Class Diagrams • Interfaces • Collaboration • Interaction diagrams • Statechart diagrams • Component • Deployment

  4. Outline of Course • Java OO topics • Classes and inheritance • Class members and methods • Creating and destroying objects • Class inheritance and hierarchy • Java GUI with Swing • Java Event Model • Refactoring (modifying the model) • Threads of control (parallel programming)

  5. Introduction to business design process • Purpose • Introduction to complexity of real world methods • Understand some of the social aspects of real software engineering • Realize the need for good methodology in global enterprise environments

  6. Enterprise Development Process Groups Feature System Customers Technical Marketing Requirements System Requirements Technical Marketing Feature Teams High Level Designs Component Requirements Box Teams Functional Requirements Architecture Requirements Integration Teams Detailed Designs Testing Teams Standards

  7. Telecoms Example (of dynamic behaviour) Network Infrastructure User InterfaceJava Game Menu Java GameRepository • Network provider deploying 3G. • Placing order for handsets. • One of the many features included will be access to network Java game repository.

  8. Initial Customer Requirements Handset Network User Menu Key Options Select Fetch Resource Java Game Confirmation

  9. Technical Requirements Signal Battery Abstract representation of screen elements Context dependant public methods(on screen menus) UI (Screen) Specific interface methods(buttons) Usage Scenariosdetermine functional elementswithin the interface. 06:00:12 Jed Sneed Ph. Bk Menu Hold Power Java Ack B1 B2 B3 B4 B5 B6

  10. Technical Marketing Scenarios Signal Signal Battery Battery Java Games • Doom 8 • Quake 9 • etc...... Back Menu Select Each eventmodifies functionality and UI configuration Power Java Ack Java Key Press B1 B2 B3 B4 B5 B6 Customer Scenariobroken down intosequence of atomicevents, which changeinterface functionality. Default ScreenDisplay Ph. Bk Menu Hold Power Java Ack B1 B2 B3 B4 B5 B6

  11. Technical Marketing Scenarios • Normative scenarios are very focused on isolated behaviour of feature in these requirements: • What if voice call received during download? • Are there other applications that should be able to override the download? • What if during the download the network service provider tries to update the phone configuration via the air interface for enhanced game play?

  12. Technical Marketing Scenarios Network User System UI Marketing Requirements Functional Requirements These omissions arise because the role of technical marketing is to focus on customer requirements, rather than functional requirements. Customers are focussed on generating revenue from each feature, and rarely worry about the system as a whole.

  13. Functional Requirements Network System UI Functional Requirements • Functional requirements refine technical marketing requirements to logical entities defined in terms of their functionality. • They are defined independently from any architecture requirements that will constrain implementations.

  14. Functional Requirements Scenarios • The purpose of functional requirements is to be precise enough for detailed specifications to be written for any particular architecture that can then be implemented. • They do not define every single aspect of the features behaviour. • They define comprehensive behaviour of the feature so that it performs well for any common eventuality, and can fail gracefully in exceptional circumstance. • Made up of functional scenarios and partially defined state based models. State Based Model

  15. Sequence Diagram Example Message with parameters Process timeline User Start UI Phone_OS System State Idle Display Default View key_press java_game_menu (java_game_menu) display (menu, java_games) Display Java Game View Java Game View Finish A single user action in marketing scenario is decomposed into multiple events between concurrent system components.

  16. Quick Quiz, C++ Revision • Write a complete C++ program that: • adds up the squares of the first 20 integers:1 + 2*2 + 3*3 + .......... + 20*20 • The program must use a for loop to achievethis task. • The program must implement this algorithm: • Let sum be an integer with initial value 0 • For each integer i between 0 and 20 add i*i to sum • Output the final value of sum to standard out. Time: 5 mins NOT assessed To be marked by person next to you in class

  17. Quick Quiz, C++ Model Solution #include <iostream.h> main() { int n = 20, sum = 0; for (int i = 0, i <= n, i++) { sum += i*i; } cout << "Sum of squares is " << sum; } (3 marks: including IO library) (3 marks: defining main and { } enclosing body) (3 marks: variable declarations) (5 marks: ‘for’ loop syntax) (3 marks: loop body) (3 marks: output syntax)

  18. Software Engineering Methodology • Modular(Can split tasks into self contained units that canbe worked on by different groups) • Reusable(So can be incorporated into future releases of new products) • Flexible(When requirements are in constant flux it is easier to modify system) • Reliable(Less likely to introduce errors and easier to find errors)

  19. Object Data Object Methods Objects Oriented Programming • Language for describing process, ‘things’ and ‘how’ they behave, change, can be used or can be adapted. • Think of cookery recipe. An Apple Pie recipe tells you what you need, and how to put things together. Neither on there own makes much sense.

  20. Objects - Packaging data and functionality together • Example: CGI character in TV drama, Emperor Dalek • Data: • 3d coordinates of geometry • texture properties • Methods: • Mapping 3d coords to pixels • Audio rendering ofvoice • Physical movementof components

  21. Example – Tea the drink • Object: Tea Drinking • Data: • types of tea • kind of tea (bag or leaf) • amount of tea for pot of tea for N people • additional ingredients, milk, sugar, lemon • Methods: • Top level method of ‘Making Tea’ breaks down into many sub methods: • fill kettle with water • boil kettle • WHAT NEXT?

  22. There were five primary goals in the creation of the Java language: • It should use the object-oriented programming methodology. • It should allow the same program to be executed on multiple computer platforms. • It should contain built-in support for using computer networks. • It should be designed to execute code from remote sources securely. • It should be easy to use and borrow the good parts of older Object Oriented languages like C++.

  23. Java Example: Azureus BitTorrent Client

  24. Java Example: Web Servers

  25. Java Example: Open Office, Open Source Microsoft Office Replacement. • As built in Java is portableto: • All Linux • All Unix • All Windows • Macs • Currently gaining market incash strapped local governments

  26. NetBeans, IDE for Java.

  27. CS288 Exam Marks 2004 Course Average : 60% (Weight 40%) Assignment average: 68% (Weight 60%) Exam average: 55% Distribution of Marks

  28. Summary • Course outline and structure • Introduction to global enterprise engineering methods • Realization of complexity of system design • Next time • UML class diagrams and language constructs

More Related