1 / 28

A few words from the field

A few words from the field. Programming in Java. Source file. Source file. Source file. Application. Java Compiler. Application Bytecode. Core Libraries. Java VM implementation. Native Platform. Java and platform independence. What it does

reina
Télécharger la présentation

A few words from the field

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. A few words from the field

  2. Programming in Java Source file Source file Source file Application Java Compiler Application Bytecode Core Libraries Java VM implementation NativePlatform

  3. Java and platform independence • What it does • VM and Core Libraries hide partially underlying hardware/OS • Compiled bytecode can be used with different VM implementations • Guarantee bytecode level backward compatibiity • Gives us pretty productive language • ... and does not • Give us fully standardized networking/persistent storage IO • Stable user interface management • Remove the problems caused by poor development process or tools

  4. Java Platforms • Java Enterprise Edition • EJB, CORBA, Servlets/JSP, JMS • Java Standard Edition • Commonly used as client counterpart of J2EE backend • Java Personal Edition • AWT basis, lightweight Virtual Machine • Aimed to small devices • Java Micro Edition • Device configuration specifications (CLDC/MIDP) • KiloByte Virtual Machine

  5. ... are specifications that • do evolve -> different versions of VMs and extension libraries • contain both mandatory and (common) optional features • are implemented by dozens vendors that have different capabilities of • fullfilling specified requirements • documenting and maintaining the implementation • supporting actual development

  6. ... running on devices, with • varying support for colors, fonts etc. • different screen sizes • different pointing devices and keyboards • own layout / look-and-feel standards and recommendations • memory and performance limitations • varying support for character encodings • varying support for networking • etc.

  7. ... and on the top of all • Core and extension libraries are huge, and each developer interprets the documentation differently • Libraries contain overlapping functionality • Developers have different cababilities of solving development/desing problems => Each problem can be solved / each requirement can be fullfilled by dozens of different ways

  8. Example of problem solving package hello; public class SecondHello { static { System.err.println("Hello World!"); System.exit(0); } } package hello; public class FirstHello { public static void main(String[] args) { System.out.println("Hello World!"); } }

  9. Write once, run anywhere? • Run anywhere • Increasing applications portability increases applications complexity • Try to please everyone == please no-one • ... Or Run where you need it • Maximize component re-use between selected platforms • Make configurable components based on real needs, not ideas • Keep your focus on correct issues => solve customers problems

  10. What do we need? • Somebody who can find out what customer really needs, and can interpret these needs to clear requirements • Somebody who picks technologies that should be used • Somebody who decides how this new application should be constructed • Somebody who states guidelines and patterns that should be used in development • Somebody who designs and developes the application • Somebody who checks that application does what it is supposed to do • Somebody who manages the time and money spent during development process

  11. ... so, what do we need? • Software development process with • Requirement design • UI and usability design • Architecture design • Implementation level design, development and Unit Testing • Application level testing • Tight and working project management • Backend systems to support the process, ease management and keep track of deliverables

  12. Requirements design • Conducts work shops with the team and customers to establish a common view of the system • Does customer interviews • Identifies business processes • Defines Use Cases and ER –diagrams • Controls Changes to the requirements

  13. UI and usability design • Analyzes the user’s tasks by looking at the requirements and use case scenarios • Defines iteratively the overall functionality of the user interface • Creates an UI demonstration • Conducts usability tests

  14. Architecture design • Designing the structure of the software as a component architecture • Feature package production with Project Manager • Selecting platforms for production, testing and delivery • Finding reusable parts and pre-existing components that can be used in project • Designing initial components and the interaction between them • Setting up the deployment order • Stating guidelines and patterns for design development • Verify that desing and development follow these guidelines/patterns

  15. Design, development and Unit Test • Modeling and structuring interfaces and classes and their relationships • Planning a unit tests • Designing operations, selecting algorithms etc. • Implementing and testing the component

  16. Testing • Plans and schedules the testing process • Designs automatic and manual tests with testing team • Executes and administers tests alongside testing team • Informs results of testing • Verifies delivery of software • Co-operates with development team

  17. Project Management • Roadmap management • Goals • WBS and workload allocation • Resource assignments • Scheduling • Budgeting • Risk Management • Reporting

  18. Designing Platform Independent Software

  19. Approach • Isolate parts that are changing between platforms • Define main layers of application (based on isolation decisions) • Divide application into manageable components (keep the layering in mind) • Put components into layers • Define component interfaces and interactions • Define design patterns that should be used on component development (keep isolation in mind) • Assign appropriate pattern for each component • Check components that are within same layer and/or share same pattern • Decide design and development order

  20. Isolation of changing parts Device depedent rendering components Configurable rendering components Graphics/UI Configuration styles, mechanisms and posting styles Configuration Logic and state Network IO File/other persistence IO Supported protocols and access styles

  21. Main layers of application Data visualization Client Logic Protocol encapsulation Business Logic System Integration Persistence storage access Persistent Storages

  22. Application Components Human Resources Main Resouce List View Logon Resource View Resouce Browse Resource Management Access Rights LDAP Storage Human Resources Database

  23. Resource List in application layers Data visualization Client Logic Resource List Protocol encapsulation Business Logic Persistence storage access Persistent Storages

  24. Resource List interactions Application Resource List Resource List <init> Set Privileges Set Configuration Refresh List Selection Changed Get Selection Load Resource Info

  25. Resource List interface • IN: • setAccessPrivileges(ApplicationUser) • setConfigurationProvider(ConfigurationProvider):void • refreshList():void • getSelection():Resource • OUT: • selectionChanged(Notification):void

  26. Pattern for Resource List View RListView Controller RListControl Model RListModel BL Access BrowseAccess PATTERN IMPLEMENTATION

  27. A few common patterns • Factory • Singleton • Proxy • Observer • Command • Facade • Model-View-Controller => Do not re-invent the wheel

  28. Sources for information • Main Sources for Java: • http://java.sun.com • http://developer.java.sun.com/developer/ • Books: • Framing software Reuse. Lessons from the real world: Paul G. Basset • Implementing application frameworks: Mohamed E. Fayad, Douglas C. Schmidt, Ralph E. Johnson • Domain specific application frameworks: Mohamed E. Fayad, Ralph E. Johnson • Software Project Management. A unified framework: Walker Royce • The craft of software testing: Brian Marick • Java Design Patterns:James W. Cooper

More Related