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

Alan Davis ● “Guru” ● Academic and professional – ● Controversial article on research into requirements engineering Requirements Researchers: Do We Practice What We Preach? Requirements Eng (2002) 7:107–111

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

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

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

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 ?

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

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

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

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

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

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

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 1 Different objects. i. OOR: is the object important for understanding the problem? ii. OOD: is the inclusion of the object important for software quality? iii. e.g. elevator requirements: passenger, design: floor requests

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

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

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: 1 Recognize that SRS is necessary i. OOR is not very good at describing external system behavior (e.g. push button A  green light comes on) ii. supplement each OOR object with its contribution to external system behavior

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

Ontology and other things Csaba Veres

Conceptual Modeling

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

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

Example: construct overload is “Assignment” an entity? City Worker Project Assignment

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

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

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