Object-Oriented Software Engineering

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.

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

18. 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

20. 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?

21. 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

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

23. 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 …

24. 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

26. 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 ...

27. Beyond Object-Orientation?

28. 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

29. 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

30. 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

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

32. 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.

33. 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].

34. Class diagrams

35. Use cases

36. Interaction diagrams

37. Package and component diagrams

38. State and activity diagrams

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

40. Discussion

41. 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 ...

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

43. Interactive drawing tool

44. Reactor (event-handling) pattern

45. Reactor - Interaction diagram (events)

46. Business process modeling

47. (simulation) event state transition diagram

48. Observer Pattern

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

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