Myth and Reality of OOA the lack of
- Slides: 33
Myth and Reality of OOA: the lack of domain knowledge in the representation Matti Sadeh Roi Gelbard Dov Te’eni Myth and Reality of OOA
informatics Computer Science IS ACM – IEEE MIS Quarterly ISR Management Science )HCI (International Journal of Human computer studies 2 Myth and Reality of OOA
1. Facts about practice of OOA • Object-Orientation is the most widely discussed Systems Development approach. • Books, Researches, Papers, Interest groups… • What happens in practice? 2. Speculation In practice, no inclusion of relevant theories 3 Myth and Reality of OOA
The OO Promise Many see the OO approach as a panacea to software problems: “It is a major premise of this book that the object-oriented approach to systems development helps to avoid many of the problems and pitfalls described in earlier chapters" [of the structured or functional analysis] (Bennett, Mc. Robb and Farmer, 2002) However, little empirical evidence exist to support such premise, and most of them are lab results. 4 Myth and Reality of OOA
The Current Research • The current research tests empirically the application of the OO approach, with special emphasis on analysis. 5 Myth and Reality of OOA
The promise of OOA The OO approach holds the promise to cope with the traditional waterfall life cycle pitfalls: • Real world projects don’t follow a simple sequential life-cycle. • Inadequacies in the requirements analysis will arise in the late stages of the project • A long time may elapse between the initial system requirements stage and final installation. • The traditional life-cycle tends to be unresponsive to changes in client requirements or technology. • The transition between stages is not smooth - in OO smooth. • OO designs are more suited to real world problems • The OO software will be easier to understand • Better support for software reuse 6 Myth and Reality of OOA
OOA Principles Since the late ’ 80 many OO methodologies where suggested, but one can treat the work of the OMG (2001) as a conclusive work. The essentials of OO are: • Seeing the system as a collection of object that interact. • Classification of the objects into classes • Generalizations of classes to super-classes • Inheritance • Encapsulation • Polymorphism • Use of visual language (diagrams) • Continuance evolving approach to system life-cycle 7 Myth and Reality of OOA
Sample characteristics Company Type Total Develop Total Main focus System Type Total Defense Industry 2 Product 12 R/T Communication and Multimedia 2 Governmental 2 One-Time-System 12 Embedded 3 Hitech 11 Operating System and Communication 1 Security and communication 5 Services 1 Combined Command Control 3 Software House 4 UI Information System 8 start-up 4 Internet Commerce Site 2 Project Size (MY) Total Up to One year 6 Up to 3 5 Up to 10 9 Up to 50 1 Above 50 3 8 #of professionals Total Up to 3 9 Up to 10 12 More than 50 3 Myth and Reality of OOA
Research method - Interviews • Diversity between projects suggested interviews best. – Project differ by: LC models, language, deliverables and more. • To manage risks (researcher bias, social desire) of such research few steps where adopted: – Structured interviews – skeletons, questions phrased up-front – Assuring the interviewees confidentiality – Gradual questions from ‘what’ through ‘How’ to ‘Why’ – postponing judgment questions to the end – Clear translation map from interview to quantitative measures 9 Myth and Reality of OOA
The generic life-cycle Although much is discussed about the iterative LC and its benefits the practice follows a more structured LC Customer Requirements RFP, SOW, MRD, or other. Software Requirements Might be divided into Sys. Req and SRS Software Analysis Software Design 10 Myth and Reality of OOA May be divided HLD & LLD
Findings – Activities in stages Customer Software Analysis Req. Design User Requirements Technical description of requirements UC descriptions UI S/W Architecture API between components Classes (structure and operation) Class collaboration Conceptual DB schema Classes (structure and methods) Logical and physical DB structure Analysis and design activities are pushed down the LC 11 Myth and Reality of OOA Code
Findings – Requirements specification • Requirements state the functionality needed from the system (not the objects that it will handle( • Requirements are broken-down by their functionality. 12 Myth and Reality of OOA
Findings – Analysis • In small projects and in some cases of information system development - might be neglected, jumping straight to implementation (overhead? ) • In most cases – functions allocated to components. • Most times – not yet dealing with objects • When classes identified, almost never use the OO power of inheritance. • Declair interfaces within the system (between components) and with external systems. • Most times – UI design (specifically) 13 Myth and Reality of OOA
Findings – Design • Hardly ever full specification of system – the gap between the specification and the S/W system relate to – – the complexity of the system, knowledge and experience of the programmer, usage of CASE tools customer demands • Not all the classes are designed or even identified • Complex methods tend to be more specified Might suggest cost-effectiveness of design not fully proven. 14 Myth and Reality of OOA
Findings – Design • In most cases the design model is not kept updated. – implies about the usefulness of the model for maintenance 15 Myth and Reality of OOA
Findings - Graphical Language Diagram Usage Notes UC Very few Doesn’t express much Activity Very often Class Frequent Sometimes drawn as Entities-Relations Sequence Very often In many cases present interaction between large components of the system – not in classes resolutions. State-chart Very few Package Sometimes Collaboration Very few Instance Never observed 16 Sometimes will look like block diagram Myth and Reality of OOA
Findings - Graphical Language • The graphical language is not fully adopted • Usually, text complements diagrams • Nevertheless, diagrams deliver quickly the overall picture • Two exceptions: – one very large project – design is completely graphical. Text is not feasible in such huge system. – Another, medium-scale project – completely textual descriptions of process (diagrams are overhead) 17 Myth and Reality of OOA
Story II (a little speculative): we do not in practice, include theory 18 Myth and Reality of OOA
(Systems modeling, 2000) 19 Myth and Reality of OOA
Type of information – theory implications? 20 Myth and Reality of OOA
Myth and Reality of OOA
22 Myth and Reality of OOA
23 Myth and Reality of OOA
An example of theory A cognitive-affective model of organizational communication: theory informs design MIS Quarterly, 2001 24 Myth and Reality of OOA
25 Myth and Reality of OOA
26 Myth and Reality of OOA
Design Principles of Communication support systems (forthcoming Communications ACM) • Principle 1: Design must simultaneously consider enhancing mutual understanding and promoting relationships between communicators • Principle 2: Design should support adaptive behavior, including the contingent use of alternative communication strategies, alternative message forms and alternative media. • Principle 3: Design should control complexity. • 27 Myth and Reality of OOA
Design Principles of Communication support systems (Cont. ) • Principle 4: Design should support multiple levels of communication and easy travel between levels. • Principle 5: Memory should consist of speech act components, situations, norms and values. • Principle 6: Memory should consist of associative information, accessible through multiple media, and represented in multiple forms, allowing for indeterminate and emergent views too 28 Myth and Reality of OOA
Original message 29 IEEE Trans. Myth and Reality of OOA Intelligent systems 2000 w Schwartz
Contextualized message 30 Myth and Reality of OOA
31 Myth and Reality of OOA
32 Myth and Reality of OOA
33 Myth and Reality of OOA
- Zoos connect us to the natural world claim
- Hilda tresz
- What encapsulates both data and data manipulation functions
- Ood/oop
- Ooad uml
- Ooa
- Ooa process
- Softwareprodukt
- Generic components of ooa model
- Apa itu ooa
- Lack of communication between parents and teenager
- Prqrt method
- Psalm 23 john piper
- Modal verbs prohibition
- Voluntary consent meaning
- Lack of dopamine
- Lack of diversification
- Roxanne bartolome
- Over consumption of fat
- Causes of teenage pregnancy
- Lack of unity example
- Lack of cohesion of methods
- Your child's success or lack of success
- Lack of knowledge in teenage pregnancy
- Your child's success or lack of success
- Used so often as to lack freshness or originality
- User support examples
- Lack of social context cues theory
- Users over lack support
- Frictional force formula
- Criminal thinking patterns
- Which one is a barrier to speaking
- Used so often as to lack freshness or originality
- Lack of commitment