1 / 92

Object-Oriented Software Engineering

Object-Oriented Software Engineering. Anton Eliëns Vrije Universiteit, Amsterdam http://www.cs.vu.nl/~eliens/online/courses/oo. Topics:. Basic OO technology Application Framework(s) Universal Modeling Language Design Patterns Project Management Current developments and trends.

Download Presentation

Object-Oriented Software Engineering

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 Software Engineering Anton Eliëns Vrije Universiteit, Amsterdam http://www.cs.vu.nl/~eliens/online/courses/oo

  2. Topics: • Basic OO technology • Application Framework(s) • Universal Modeling Language • Design Patterns • Project Management • Current developments and trends

  3. Introduction If OO is the Answer, What is the Question?

  4. Keywords and phrases • the OO lifecycle -- modelling • encapsulation, inheritance, delegation, polymorphism • specification and implementation inheritance • design by contract • interfaces, components and frameworks • idioms, patterns, software architecture

  5. Themes and Variations • abstraction -- the object metaphor • modeling -- understanding structure and behavior • software architecture -- mastering complexity • frameworks -- patterns for problem solving • components -- scalable software

  6. Object Terminology • objects -- packet containing data and procedures • methods -- deliver service • message -- request to execute a method • class -- template for creating objects • instance -- an object that belongs to a class • encapsulation -- information hiding by objects • inheritance -- allowing the reuse of class spec.s class • hierarchy -- tree structure inheritance relations • polymorphism -- to hide different implementations

  7. Features of OOP • information hiding: state, autonomous behavior • data abstraction: emphasis on what rather than how • dynamic binding: binding at runtime, polymorphism , virtual functions • inheritance: incremental changes (specialization), reusability

  8. Benefits of OOP • OO = encapsulation + inheritance • modularity -- autonomous entities, cooperation through exchanges of messages • deferred commitment -- the internal workings of an object can be redefined without changing other parts of the system • reusability -- refining classes through inheritance • naturalness -- object-oriented analysis/design, modeling

  9. The San Francisco Framework How useful is an OO framework?

  10. Example - San Francisco Framework

  11. A framework is ... • a collection of components • a generic solution for a class of problems • a frame of mind for solving problems • a set of architectural constraints

  12. The San Francisco Framework • is meant to develop business applications • is based on Java technology • may solve 70% of your problem • leaves 30% (minimum) to solve for you • may set a standard • or may fail to do so ...

  13. San Francisco - motivation • The project was started when several software vendors asked IBM to help modernizing their application products • However, there were several barriers preventing them from being able to update their applications

  14. Barriers to modernizing • (1) The problem of how to retrain their development staff to effectively use OO technology. • (2) The risk involved in moving to a new technology. • (3) moving -> the cost of the change • The software developers realized they needed some basic infrastructure. • Many companies could not develop this infrastructure themselves.

  15. San Francisco - the press • The San Francisco project helps to solve these problems by offering developers Business Process Components, • designed as frameworks that provides an object oriented infrastructure, • a consistent application programming model, and • some default business logic • The frameworks make it easier to move to OO technology because developers use well-tested services instead of building their own.

  16. San Francisco Framework - layers • Core Business Process Layer - the highest • Common Business Objects Layer - middle • Foundation Layer - lowest

  17. Core Business Processes • The objective for this layer is to create a sound architecture and highly extensible OO implementation for the basic structure and behavior which any application provider delivering a solution in the application doamin would require: • Accounts Receivable/Payable Ledger • General Ledger Framework • Sales Order Management Framework • Purchase Order Management

  18. Common Business Objects • Business Objects common to multiple domains • Common Application level Services • CBO: • Business Partner • Address • Number - decimal structure • Currency - how many euros in a dollar?

  19. Foundation Layer • Foundation Object Model Classes • Utilities • in other words: it provides the infrastructure • comment: reinventing the wheel is not a big problem, because the wheel is a terrific invention

  20. Foundation Object Model Classes • Command • Entity • Dependent • Collection/Iterator • Factory • you need to study Design Patterns to appreciate these ...

  21. Using the San Francisco Framework • … The San Francisco Frameworks are designed to make many types of extensions easy for application developers: • overriding the default business logic in supplied methods • adding additional attributes to existing classes • adding additional methods to existing classes • from the report: Complete documentation will be provided …

  22. Example • Two classes: Receipt and Purchase order Line • default attributes, methods • default business logic: inspect Quality on receipt • Extension: enhance this logic • subclass Receipt • override inspection method • change logic to include checks against supplier tables, and hazardous or high value products

  23. San Francisco - issues • Standards: OMG/CORBA Business Issues • Technology Integration: • Compound Documents: Lotus Notes, JavaBeans, Active X • Business process Modeling and Control: workflow engines may be used as glue … • Internet/Intranet and Java: applications may be designed …. • Conclusions: … a bit premature ...

  24. Beyond Object-Orientation?

  25. Trends -- modeling patterns -- examples of design UML -- Unified Modeling Language Technologies -- components Web -- global infrastructure CORBA/DCOM - the software bus Java -- the platform? Challenges Applications -> Frameworks <- Patterns

  26. Challenges in O-O • vertical framework development -- finance, medical care, insurance • separation of 'logic' from 'control' -- business rules • distributed object technology -- heterogeneous systems • visualisation -- structure and processes • knowledge intensive applications -- declarative • heterogeneous systems - fragmented applications

  27. Universal Modeling Language • … why you need models? • Models are necessary to communicate, • to stabilize abstractions • as a reference for the implementation • and maintenance • and you need an agreement on the notation and formalisms in which you express your models

  28. Unified Modeling Language Introduction Class diagrams Use cases Interaction diagrams Package and deployment diagrams State and activity diagrams Discussion

  29. The Unified Modeling Language (UML) resulted from a joint effort of leading experts in object-oriented analysis and design, Grady Booch, Jim Rumbaugh and Ivar Jacobson, also known as the three amigos, all currently employees of Rational.

  30. Unified Modeling Language UML • class diagrams -- conceptual structure • use cases -- functional requirements • interaction diagrams -- operational characteristics • package and deployment diagrams -- implementation • state and activity diagrams -- dynamic behavior See http://www.rational.com/uml and UML Distilled, [Fowler97].

  31. Class diagrams

  32. Use cases

  33. Interaction diagrams

  34. Package and component diagrams

  35. State and activity diagrams

  36. Event annotations event(arguments)[conditions]/action

  37. Discussion

  38. The UML toolbox is very rich. It allows you to model every conceivable aspect of the system. Nevertheless, to my mind, graphical models are not always appropriate. But, on the other hand, most people like them and they often make a good impression, suggesting clarity ...

  39. Examples - interactive drawing tool - the reactor pattern (events) - business process modeling - the observer pattern

  40. Interactive drawing tool

  41. Reactor (event-handling) pattern

  42. Reactor - Interaction diagram (events)

  43. Business process modeling

  44. (simulation) event state transition diagram

  45. Observer Pattern

  46. Basic OO Technology Technology determines the effectiveness of the approach

  47. Concepts • Encapsulation • Data hiding • Inheritance • Polymorphism

More Related