1. T. E. Potok - University of Tennessee Software Engineering Dr. Thomas E. Potok Adjunct Professor UT Research Staff Member ORNL

2. T. E. Potok - University of Tennessee Object-Oriented Analysis and Design

3. 3 Software Engineering CS 594T. E. Potok - University of Tennessee OO Analysis  A way of representing the design of a system in real world object  Provides a way of analyzing the system for design flaws  No single way to represent information  Analysis is effected by experience and knowledge

4. 4 Software Engineering CS 594T. E. Potok - University of Tennessee OO Design  This is typically a refinement of the OOA model  The real world objects are augmented by design level object  Complex objects may be prototyped to ensure a valid design

5. 5 Software Engineering CS 594T. E. Potok - University of Tennessee Responsibility Driven Design  Responsibility driven design created by Wirfs-Brock and others – What actions is this object responsible for? – What information does this object share?  Encapsulation is compromised with the structural details of an object become part of the interface to that object  Designing classes without knowledge of their structure encourages the design of the inheritance hierarchy to follow a type hierarchy.

6. 6 Software Engineering CS 594T. E. Potok - University of Tennessee More on Responsibility Driven Design  Focus on high-level design. It has two phases, – exploratory - focuses on identifying and defining classes themselves, the responsibilities of classes, and the collaborations among classes. – Analysis - focuses on constructing hierarchies, identifying subsystems (and collaborations between subsystems), and defining class protocols and written design specifications for classes and subsystems. – sets out 26 detailed steps to create a design.

7. 7 Software Engineering CS 594T. E. Potok - University of Tennessee Other Methods  Many, many other approaches some of the more popular: – Jacobson - Invented use-cases – Cox - Evolutionary Approach – Meyer - OO Software Construction

8. 8 Software Engineering CS 594T. E. Potok - University of Tennessee Implementation  Keep methods small and single purpose  Avoid “global variables,” keep variables in small scopes, helps isolate changes  Need discipline to enforce key principles – Encapsulation – Modularity

9. 9 Software Engineering CS 594T. E. Potok - University of Tennessee Layers  There may be value in keeping separate layers within an application – Data – Logic or business rules – GUI or View

10. 10 Software Engineering CS 594T. E. Potok - University of Tennessee Layering Example Folder Job Resume Is the system complete?

11. 11 Software Engineering CS 594T. E. Potok - University of Tennessee Layering Example Folder Job Resume Database GUI

12. 12 Software Engineering CS 594T. E. Potok - University of Tennessee Layering Example Folder Job Resume Database GUI Is this the way to build the system?

13. 13 Software Engineering CS 594T. E. Potok - University of Tennessee Layering Example Folder Job Resume Database GUI Data Broker Visualization Layer

14. 14 Software Engineering CS 594T. E. Potok - University of Tennessee Brokers  Brokers provide yet another layer of encapsulation within the system  A data broker hides the complexity of the database from the domain objects – All the domain object sees is the call to the broker – The broker interfaces with the database and understand SQL and the DB structure

15. 15 Software Engineering CS 594T. E. Potok - University of Tennessee View Layers or Controllers  How should views be represented in an OO model?  The view has certain characteristics that are unique to the view – Size, shape, position, …  Yet the view without data is nothing  The view characteristics should not impact domain object, and changes to domain objects should not effect the view

16. 16 Software Engineering CS 594T. E. Potok - University of Tennessee Reuse  General notion that reuse increase programmer productivity – A section of code works, has been tested, and can be snapped into new code – The programmers don’t have to write the code!! – However, there are several key problems

17. 17 Software Engineering CS 594T. E. Potok - University of Tennessee Problems with Reuse  Berlin notes 5 main problems – How are argument validated? Declaratively, interactively, or implicitly – Who handle errors? The object or the system? – How are composite object handled? Top-down or bottoms-up – How is Control and Communication handled? Who is in charge, and when? – How are group and compound operations handled? What is the right level of interface

18. 18 Software Engineering CS 594T. E. Potok - University of Tennessee Reuse Problems  When designing for reuse, these 5 issues need to be clearly addressed  Other problems – How do you find reusable components? – Who should write them? Programmers, or a separate group – What components should be reusable?

19. 19 Software Engineering CS 594T. E. Potok - University of Tennessee Is it smart to reuse code?  There are costs – Designing, coding, and testing for reuse takes more time and costs more – Maintaining a reuse library can be expensive – Providing search tools can be expensive – What if components are not being reused

20. 20 Software Engineering CS 594T. E. Potok - University of Tennessee Economic Models  Models to estimate the benefit of reuse – Schimsky, based on very optimistic assumptions, reports the break-even point for reuse is 5 years out, and not economically justifiable – Schimsky’s model assumes that only one project will contribute and receive benefit from a reuse library – Henderson-Sellers shows a positive ROI over time. Even in the pessimistic case where only 10% of the classes are reused, while 50% of new classes were developed to be reused – Henderson-Seller’s does not include the cost to establish and maintain a reuse library.

21. 21 Software Engineering CS 594T. E. Potok - University of Tennessee Reuse in Practice  Few companies reuse code  Reuse on a project tends to be small  White box reuse - having to modify the component, may actually take longer than starting from scratch

22. 22 Software Engineering CS 594T. E. Potok - University of Tennessee Patterns  In the development of software, certain designs occur over and over  These patterns can be captured in models, such as ER models, or object models  These models are known as meta- models, or models of models

23. 23 Software Engineering CS 594T. E. Potok - University of Tennessee Pattern Example StudentTeacher Exam teaches grades takes EmployeeManager Work manages evaluates performs Person Output produces leads Measures Pattern

24. 24 Software Engineering CS 594T. E. Potok - University of Tennessee Factory Person Output produces leads Measures ChildFather Lawn trains evaluates mows

25. 25 Software Engineering CS 594T. E. Potok - University of Tennessee Patterns Summary  Can provide a means of reusing design and code  Complicated, and difficult to follow  Used in database design  Hard to draw the line on how general the pattern gets Object Relates to

26. 26 Software Engineering CS 594T. E. Potok - University of Tennessee Productivity Analysis  Lewis et al. performed an experiment with undergraduate software engineering students to study the effect of reuse. The study consisted of two parts, – one where a group of students created reusable components, – the other where a different group of students develop the target system, possibly using components developed in the first part.

27. 27 Software Engineering CS 594T. E. Potok - University of Tennessee More on Lewis  Lewis concludes that: – 1) the object-oriented paradigm substantially improves productivity through reuse; – 2) software reuse improves productivity; – 3) language differences are “far more important” with reuse, and – 4) the object-oriented paradigm is well suited for reuse.  There are some concerns about this study, for example, it is not clear how differences in the number of runs made, and the number of edits performed relates to productivity. The other metrics are related to software defects, not productivity.

28. 28 Software Engineering CS 594T. E. Potok - University of Tennessee OO Design  Boehm-Davis et al. report on a comparison of Jackson program design, object-oriented design, and functional decomposition design  Three groups of professional programmers, who were familiar with the various methodologies, volunteered to develop designs for three experimental problems.  Some of the insights they report from the data are that  Jackson’s method, and object-oriented methodologies produce – more complete solutions, regardless of the time spent on the solution, – required less time to design and code a problem, and – produced less complex designs than designs developed using functional decomposition.  The conclusion to the study is that different methodologies produce different solutions to the same problems.

29. 29 Software Engineering CS 594T. E. Potok - University of Tennessee Layering and Encapsulation  Zweben et al. in an experiment with graduate and undergraduate students examined the effects of layering and encapsulation on effort and quality  Three experiments were performed. – The first created a simple enhancement in functionality to an existing unbounded queue component; – the second created a more complex enhancement; and – the third modified the functionality of the original component.

30. 30 Software Engineering CS 594T. E. Potok - University of Tennessee More on Zweben  From this analysis they concluded that the use of layering and encapsulation requires less effort than a direct approach, and that layering and encapsulation does not hinder the quality of the software produced.  More recent studies show little or no difference in OO productivity

31. 31 Software Engineering CS 594T. E. Potok - University of Tennessee Summary  There is a big question whether you can translate student programming results to professional programmers working on real applications  There are also many factors that may contribute the productivity gains that were not analyzed