OO Requirements to OO design

1. Csaba Veres Alan M. Davis (1995), Colorado OO Requirements to OO design

2. Alan Davis • “Guru” • Academic and professional • www.omni-vista.com • Controversial article on research into requirements engineering Requirements Researchers: Do We Practice What We Preach? Requirements Eng (2002) 7:107–111

3. Do we practice what we preach? • 31% of systems built today are never delivered • another 15% had less than half of the customers needs satisfied • but are requirements engineers really to blame? • criticizes standard academic practice • suggests some alternative problem scenarios

5. Introduction to OO • Object orientation proposed in 1960s as a programming technique • an object is a data abstraction • encapsulation of protected data, procedures, processes to manipulate the data • classes • generic set of objects or other classes • inheritance

6. intro ... • OOP (OO Programming) languages developed by late 1980s • OOD (Design) techniques developed by the mid 1980s. • Close connection between OOD and specific OOP languages • Booch: ADA, Meyer: Eiffel • OOR (Requirements) also developed in the late 1980s. • OOA (Analysis) is a sub set of OOR

7. OOR • Software requirements aims to understand and document the needs of the user • problem analysis • understanding • requirements specification • documenting (SRS: Software Requirements Specification) • “Expected external behavior” • description of all inputs, outputs, possible mapping relationships between them • OOR is good at describing the problem domain • used to model objects from the SRS • external behavior ?

8. OOD • purpose of design is to transform requirements into an optimal configuration (architecture) for implementation • OO optimizes • maintainability • reusability • enhanceability • reliability • encapsulation ensures • less errors • easier to find errors • less risk of errors after changes

9. OOR vs. OOD • OOD optimizes reusability, etc. • OOR optimizes understandability • So, is an object the same in OOD and OOR? • OOR captures • real world entities • attributes and states of that entity • the services provided by that entity • inherited attributes and services

10. OOR vs. OOD ... • OOD captures • an encapsulation of attributes and states of an entity • an encapsulation of services and operations • inheritance of attributes and operations • Real world (OOR) vs. software design (OOD) • understandability and accuracy vs. optimal design for performance and maintainability

11. Four origins of OOR (as it stood in 1995) • OOD • main difference is level of detail • Database design • adaptation of ER • problem with function definitions • Requirements analysis • already had some methods for looking at “domain entities” • Structured analysis • change to and call it OO

12. Transition from OOR to OOD • Many different opinions by leaders in the field • Jacobson and Embley • analysis and design objects are identical • “object oriented construction means that the analysis model is designed and implemented in source code ..” • Coad, Yourdon, Booch, Rumbaugh • design follows “simply” from requirements • “moving from analysis to design is a progressive expansion of the model” • add detail to existing objects, as well as new objects

13. Transition from OOR to OOD • Cherry, Lorenz, Wirfs-Brock .... & Davis • it is good to seperate requirements from design • allows us to worry about external behaviour without efficiency, reuse, etc. • OOR provides a draft document that can be changed at design time

14. OOR vs. OOD • OOD is the selection of the optimal solution to a required set of external behaviors • not easy • differneces introduced in the transition • Different objects. • OOR: is the object important for understanding the problem? • OOD: is the inclusion of the object important for software quality? • e.g. elevator requirements: passenger, design: floor requests

15. Aggregation • OOR records aggregation to understand the objects. • e.g., elevator control panel shall include floor select button, emergency button, open/close button ... • OOD has aggregation to optimize software packaging • e.g. ControlPanel will always include button, subtype .... • Instantiation • OOR does not worry about instance creation/destruction, or states (to some extent) • e.g. passengers just appear • OOD has to worry about instantiation and attribute modification • Different emphasis on services • OOR does not require a complete specification of the services, algorithms of all objects • OOD clearly does

16. Genericity of services and Dynamic Binding • OOR wants to avoid ambiguity, so services should be uniquely labeled • OOD makes use of polymorphism and dynamic binding to achieve runtime behavior • Verification and Validation • Verifying OOR for clarity and accuracy • Verifying OOD for correctly satisfying the requirement

17. Transitioning advice • So it is not THAT easy to transition from OOR to OOD • e.g. many changes have to be made • Techniques for easing the transition: • Recognize that SRS is necessary • OOR is not very good at describing external system behavior (e.g. push button A  green light comes on) • supplement each OOR object with its contribution to external system behavior

18. Don't underestimate the difficulty • Use a system development process appropriate for the application • e.g., for complex systems, do system requirements, partition into subsystems, subsystem software requirements, etc. • Use OOR objects as a starting point • difficulty is in deciding which ones will make good design • Add other objects from SRS • external interfaces might have been missed in OOR, and can add objects to the design • Use accepted design principles to complete the design • reusable objects, libraries, etc.

19. Csaba Veres Ontology and other things

20. Conceptual Modeling

21. Reality? • Milton (2002) • “Data modelling languages are used to create models of real world information systems..” • “... assess its capacity to “capture our reality” ...” • “... capturing reality is subjective ...” • “... models should be consistent enough with our perceptions of reality ...”

22. Why reality? • Wand, Storey & Weber (1999) • “... users of conceptual modeling methodologies are frequently confused about whether to show an association as a relationship, entity, or attribute” • The correct application of the constructs is not clear • Milton (2002) • “... ontology can be viewed as an intellectual “lense” through which to view reality ...”

23. Example: construct overloadis “Assignment” an entity? Worker City Assignment Project

24. The “real world” and “the model” The world Thing Thing Entity Entity Entity The model

25. Perception and “Reality” • So, our “... perception of reality” can not be trusted • Ontology tells us what the real world is really like • Many different ontologies exist • Bunge • things • intrinsic property, mutual property • attribute • dynamics of things: state change • interaction of things • composition: emergent properties • classification: specialisation

26. Prescriptive ontology • An ontology can tell us how we SHOULD model certain things • e.g. never model mutual properties as entities • ENROLLMENT University Student enrolled University Student Enrollment