Wikipedia

Benutzer:Centic/Komponentenbasierte Programmierung

< Benutzer:Centic

Generell

Bearbeiten

/Ausarbeitung /LaTex /Kritik /Notizen Andere Artikel

Thema: Komponenten und die objektorientierte Programmierung

Bearbeiten

Hier soll der Zusammenhang von objektorientierter Programmierung mit bzw. deren Eignung für die komponentenbasierte Programmierung untersucht werden. Was findet man in der objektorientierten Programmierung vor, das man verwenden könnte, was fehlt hingegen?

  • Eigenschaften von Objektorientierter Programmierung
  • Eigenschaften von Komponentorientierter Programmierung

Gliederung

Bearbeiten

Grundsätzlich:

Inhaltlich sollen die Texte das jeweilige Thema verständlich aufarbeiten und, nach einer Einführung in die Problemstellung und der Präsentation der Lösung(sansätze) mit einer eigenen Einschätzung des Potentials der vorgestellten Techniken oder Verfahren versehen werden.

Einführung/Motivation der Problemstellung

Bearbeiten

siehe /Ausarbeitung#Einführung/Motivation der Problemstellung

Vorstellung des Objektorientierten Paradigmas

Bearbeiten

siehe /Ausarbeitung#Vorstellung des Objektorientierten Paradigmas

[Szy02], Kap. 4.1.2:

The notions of instantiation, identity, and encapsulation lead to the notion of objects. In contrast to the properties characterizing components, the charactristic properties of an object are that it:

  • is a unit of instantiation, it has a unique identity;
  • may have state and this can be externally observable;
  • encapsulates its state and behavior.

Vorstellung der Komponentenbasierten Programmierung

Bearbeiten

/Ausarbeitung#Vorstellung der Komponentenbasierten Programmierung

[Szy02] (Kap. 4.4.1) Einleitung:

The characteristic properties of a component are that it:

  • is a unit of independent deployment;
  • a unit of third-party conmposition;
  • has no (externally) observable state.
Granularität
Bearbeiten

Granularität beschreibt, nach welchen Kriterien die Funktionalität in Komponenten unterteilt wird. [Griffel98] definiert die folgenden drei Granularitätsmaße:

  1. den "Anteil" einer Komponente an Anwendungssemantik
  2. den Umfang der Komponentenschnittstelle
  3. die Größe des (einsatzfähigen) Codes einer Komponente
Schnittstellenbegriff
Bearbeiten

Laut [Griffel98] (Kap. 3.1.2):

Die Schnittstellen stellt aber gewissermaßen den "Vertrag" bereit, den ein außenstehender Benutzer (eine andere Komponente) zur Nutzung der Funktionalität einer Komponente eingehen kann.

Schnittstellen umfassen vor allem:

  • Eigenschaften (Attribute)
  • Ereignisse
  • Methoden
Semantik des Verhaltens
Bearbeiten
Zustand
Über die Definition des Zustandes einer Komponente (oder auch eines Objektes) finden sich in der Literatur unterschiedliche Ansätze. Vor allem stellt sich die Frage, ob der Zustand von "außen" ebenso sichtbar ist wie das Verhalten, oder ob er durch die Eigenschaft der Kapselung verborgen bleibt und sein Einfluß sich lediglich im Verhalten widerspiegelt. [...] Ein sauberer Ansatz besteht deshalb darin, nur von Methoden zu sprechen und die Komponenteneigenschaften - wie in der OO üblich - durch Zugriffsmethoden zugänglich zu machen (operationale Sicht), so dass dann nur noch von einer bestimmten zulässigen Abfolge (Protokoll) von Methodenaufrufen ausgegangen werden kann (die ein Verhalten darstellt)
Dokumentation
Bearbeiten

Wichtig für die Wiederverwendung.

Distribution
Bearbeiten

Vergleich der beiden Konzepte

Bearbeiten

Ohne vorgreifen zu wollen, hab ich einige Ansätze, die aber ausgearbeitet und dargelegt werden müssen:

  • Ein wichtiger Punkt scheint mir zu sein, dass die OO per se keine Contracts hat. Es wird nur das statische Interface und die Funktionalitaet beschrieben, aber nicht das dauerhafte Verhalten.
  • Komponenten sind nach aussen hin zustandslos, Objekte nicht zwingend. Das muss durch die Schnittstelle sichergestellt werden.
  • Aliasing (insb. bei Containern)

Fazit

Bearbeiten

Eignung der OOP für Komponentenorientierte Programmierung, Zusammenfassung Vorteile, Nachteile.

Weitere Textstellen

Bearbeiten

Fundamental concepts

Bearbeiten

Object-oriented programming emphasizes the following concepts:

  • Objects - packaging data and functionality together into units within a running en:computer program; objects are the basis of modularity and en:structure in an object-oriented computer program. Objects are self contained and should be easily identifiable. This en:modularity should allow the program parts to correspond to en:aspects of the en:problem.
  • Abstraction - the ability for a program to ignore some aspects of the information that it is manipulating, i.e. the ability to focus on the essential. Each object in the system serves as a model of an abstract "actor" that can perform work, report on and change its state, and "communicate" with other objects in the system, without revealing how these features are implemented. Processes, functions or methods may also be so abstracted, and when they are, a variety of techniques are required to extend an abstraction.
  • Encapsulation - ensuring that users of an object cannot change the internal state of the object in unexpected ways; only the object's own internal methods are allowed to access its state. Each object exposes an interface that specifies how other objects may interact with it. Other objects will rely exclusively on the object's external interface to interact with it.
  • Polymorphism via message sending. Instead of subroutine calls, object-oriented languages can make message sends; the specific en:method which responds to a en:message send depends on what specific object the message is sent to. For example, if a bird receives the message "move fast", it will flap its wings and fly. If a lion receives the same message, it will move its legs and run. Both answer the same request, but in ways appropriate to each creature. This gains polymorphism, because a single variable in the program text can hold different kinds of objects as the program runs, and thus the same program text can invoke different methods at different times in the same execution. To contrast, en:functional languages gain polymorphism through the use of first-class functions.
  • Inheritance - organizing and facilitates polymorphism and encapsulation by permitting objects to be defined and created that are specialized types of already-existing objects - these can share and extend their behavior without reimplementing that behavior. (en:Object-based languages do not always have inheritance.)



Differences from object-oriented programming

Bearbeiten

The idea in object-oriented programming (OOP) is that software should be written according to a mental model of the actual or imagined objects it represents. OOP and the related disciplines of object-oriented design and object-oriented analysis focus on modelling real-world interactions and attempting to create 'verbs' and 'nouns' which can be used in intuitive ways, ideally by end users as well as by programmers coding for those end users.

Software componentry, by contrast, makes no such assumptions, and instead states that software should be developed by gluing prefabricated components together much like in the field of electronics or mechanics. It accepts that the definitions of useful components, unlike objects, can be counter-intuitive. In general it discourages anthropomorphism and naming, and is far more pessimistic about the potential for end user programming. Some peers will even talk of software components in terms of a new programming paradigm: component-oriented programming.

Some argue that this distinction was made by earlier computer scientists, with Donald Knuth's theory of "literate programming" optimistically assuming there was convergence between intuitive and formal models, and Edsger Dijkstra's theory in the article The Cruelty of Really Teaching Computer Science, which stated that programming was simply, and only, a branch of mathematics.

In both forms, this notion has led to many academic debates about the pros and cons of the two approaches and possible strategies for uniting the two. Some consider them not really competitors, but only descriptions of the same problem from two different points of view.

It takes significant effort and awareness to write a software component that is effectively reusable. The component needs: 

   * to be fully documented;
   * more thorough testing;
   * robust input validity checking;
   * to pass back useful error messages as appropriate;
   * to be built with an awareness that it will be put to unforeseen uses
   * a mechanism for compensating developers who invest the (substantial) effort implied above.


Bearbeiten

CBSE

Bearbeiten

OOP

Bearbeiten
  • Object-Oriented Analysis and Design von John Deacon Addison Wesley ISBN 0321263170
  • Coad, Peter : Object-oriented design <dt.> OOD  : objektorientiertes Design / Peter Coad und Edward Yourdon . - 1. Aufl. . - München ; New York [u.a.]  : Prentice Hall , 1994 . - 231 S. . - ISBN 3-930436-09-4
  • Jacobson, Ivar : Object-oriented software engineering  : a use case driven approach / Ivar Jacobson . - 1. print. . - Wokingham [u.a.]  : Addison-Wesley , 1992 . - XX, 524 S. . - ISBN 0-201-54435-0
  • Neumann, Horst A. : Objektorientierte Entwicklung von Software-Systemen  : Konzepte, Notationen, Einführung in die praktische Anwendung / Horst A. Neumann . - 1. Aufl. . - Bonn [u.a.]  : Addison-Wesley , 1995 . - XVI, 605 S. . - ISBN 3-89319-452-5
  • Oestereich, Bernd : Objektorientierte Softwareentwicklung  : Analyse und Design mit der UML 2.0 / von Bernd Oestereich . - 6., völlig überarb. Aufl. . - München ; Wien  : Oldenbourg , 2004 . - 377 S. . - ISBN 3-486-27266-7 geb. : EUR 44,80 (D)
  • Bernd Oestereich: Objektorientierte Programmierung mit der Unified Modeling Language. Oldenbourg, ISBN 3-486-24319-5
  • Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns: Elements of Reusable Object Oriented Software, Addison-Wesley, ISBN 0201633612
  • Harold Abelson, Gerald Jay Sussman, Julie Sussman: Structure and Interpretation of Computer Programs. The MIT Press, ISBN 0262011530
  • Peter Eeles, Oliver Sims: Building Business Objects. John Wiley & Sons, ISBN 0-471-19176-0
  • Paul Harmon, William Morrissey: The Object Technology Casebook. Lessons from Award-Winning Business Applications. John Wiley & Sons, ISBN 0-471-14717-6
  • Bertrand Meyer: Object-Oriented Software Construction. Prentice Hall, ISBN 0136291554
  • David A. Taylor: Object-Oriented Information Systems. Planning and Implementation. John Wiley & Sons, ISBN 0-471-54364-0
  • Martin Abadi, Luca Cardelli: A Theory of Objects, Springer-Verlag, ISBN 0-387-94775-2
  • Peter Eeles, Oliver Sims: Building Business Objects, John Wiley & Sons, ISBN 0-471-19176-0

Seminararbeit

Bearbeiten

ANNOTATED BIBLIOGRAPHY

Bearbeiten
  • Berard 93
   Edward V. Berard. Essays on Object-Oriented Software Engineering. Prentice Hall.

   Many topics on OOSE, includes coverage of OO domain and requirements analysis.
  • Blair 89
   "Genericity vs Inheritance vs Delegation vs Conformance vs ..." Gordon Blair, John Gallagher and Javad Malik, Journal of Object Oriented Programming, Sept/Oct 1989, pp11-17.

   Recommended by a reader, but the Author has yet to review this article.
  • Chambers 93
   Craig Chambers. Predicate Classes. Proceedings ECOOP '93 O. Nierstrasz, LNCS 707. Springer-Verlag, Kaiserslautern, Germany July 1993 pp 268-296

   "... an object is automatically an instance of a predicate class whenever it satisfies a predicate expression associated with the predicate class. The predicate expression can test the value or state of the object, thus supporting a form of implicit property-based classification that augments the explicit type-based classification provided by normal classes. By associating methods with predicate classes, method lookup can depend not only on the dynamic class of an argument but also on its dynamic value or state. * ... A version of predicate classes has been designed and implemented in the context of the Cecil language.
  • de Champeaux 93
   Dennis de Champeaux, Doug Lea, Penelope Faure. Object-Oriented System Development. Addison-Wesley, ISBN 0-201-56355-X.

   Covers an integrated treatment of OOA and OOD. Takes serious the computational model of one thread per object. Gives more than usual attention to the OOA&D micro process. Presents a unique OOD language.
  • Coleman 94
   Derek Coleman, et. al. Object-Oriented Development - The Fusion Method. Prentice-Hall Object-Oriented Series. ISBN 0-13-338823-9

   Fusion is considered to be a second generation OOAD method in that it builds on successful components of a number of first generation methods (OMT, Booch, CRC, Objectory, etc). However, this has been done with the requirements of industrial software developers in mind. And so issues of traceability, management etc. have been taken into consideration and the Method provides full coverage from requirements through to code.
  • Colbert 89
   E. Colbert. The Object-Oriented Software Development Method: a practical approach to object-oriented development. Tri-Ada Proc., New York.

   Presents the Object-Oriented Software development method. Has emphasis on objects.
  • Cox 86,91
   Cox, Brad J. Object-Oriented Programming, An Evolutionary Approach. Addison Wesley.

   The original book on Objective-C. Coverage on object-oriented design and programming. Also covers Objective-C implementation, even into object code.

   Objective-C... '91 AW by Pinson and Wiener provide another good text.
  • Embley 92
   D.W. Embley, B.D. Kurtz, S.N. Woodfield. Object-Oriented Systems Analysis, A Model-Driven Approach. Yourdon Press/Prentice Hall, Englewood Cliffs, NJ.

   Presents the Embley and Kurtz OO methodology.
  • Gunter 94
   Carl A. Gunter and John C. Mitchell. Theoretical Aspects of Object- Oriented Programming. MIT Press. ISBN 0-262-07155-X.

   Highly mathematical, formal coverage of object-oriented programming; primarily on typing.
  • Harmon 93
   Paul Harmon. Objects In Action: Commercial Applications Of Object- Oriented Technologies. Jan, 1993. A-W ISBN 0-201-63336-1.

   Sponsored by the OMG to summarize the use of OO technology in industry and business, contains a brief history and summary of OO and many case studies.
  • Hudak 90
   P. Hudak. Principles of Programming Languages. ACM Press, pp 125 -135.

   Contains several articles, including * Cook 90.
  • IBM 90,91
   Various Documents from the IBM International Technical Centers: GG24-3647-00, GG24-3641-00, GG24-3566-00, GG24-3580-00.

   Present IBM's OOSE methodology.
  • ISO
   ISO Standards Compendium - ISO 9000 Quality Management, 5th edition. Switzerland. ISBN 92-67-10206-0.

   The complete standard. 9000-3 discusses software and 9004 is a quality management standard.
  • Jurik 92
   John A. Jurik, Roger S. Schemenaur, "Experiences in Object Oriented Development," ACM 0-89791-529-1/92/0011-0189.

   Presents the EVB OOSE methodology. Also: Barbara McAllister, Business Development, EVB Software Engineering, Inc., (301)695-6960, barb@evb.com.
  • Kim 89
   Won Kim and Frederick Lochovsky Editors. Object-Oriented Concepts, Applications, and Databases.

   Collection of articles on advanced OO and research systems.
  • Kleppe 03
   Anneke Kleppe, Jos Warmer, Wim Bast. MDA Explained The Model Driven Architecture: Practice and Promise. Addison Wesley. ISBN 0-321-19442-X

   MDA and UML action language. PIM (platform independent language) to PSM (platofrm specific language). EJB, Web Models, RUP, Agile.
  • Martin 92
   James Martin and James J. Odell. Object-Oriented Analysis and Design, Prentice-Hall, Englewood Cliffs, NJ.

   Its primary purpose is to indicate how information engineering (IE) can be evolved to accommodate OO. The analysis portion (starting at Chapter 15) attempts to go back to 'first principles' and is based on a formal foundation. Therefore, the IE aspect is not required. Emphasis is more on analysis than design.
  • Meyer 88
   Bertrand Meyer. Object-Oriented Software Construction. Prentice Hall. * Is there a new edition out?

   The original book on Eiffel. Coverage on object-oriented design and programming. Also:
  • Meyer 94
   Bertrand Meyer. Reusable Software: The Base Object-Oriented Components Libraries.

   The new Eiffel class Libraries.
  • Nerson 92
   Jean-Marc Nerson. Applying Object-Oriented Analysis and Design. CACM, 9/92.

   Demonstrates the basics of the BON method/notation. Nerson: marc@eiffel.fr
  • Paepcke 93
   Andreas Paepcke. Object-Oriented Programming: The CLOS Perspective. MIT Press. ISBN 0-262-16136-2.

   CLOS, readable introduction to its metaobject protocol, comparisons with other languages, uses and methodology, and implementation. Develops a persistent object metaclass example.
  • Reenskaug 91
   T. Reenskaug, et al. OORASS: seamless support for the creation and maintenance of object-oriented systems. Journal of Object-Oriented Programming, 5(6).

   Presents the Object-Oriented Role Analysis, synthesis, and Structuring OOSE methodology.
  • Reenskaug 95
   T. Reenskaug, et al. WORKING WITH OBJECTS: The OOram Software Engineering Method Manning ISBN: 1-884777-10-4, PH ISBN: 0-13-452930-8.

 Accolades:
 "...the authors take you on a journey through object techniques filled with
 examples. You will come away from this book enriched, with a sound
 understanding of OT-based abstractions for modeling programs."
                               Richard Mark Soley, OMG
 "The first method that deals realistically with reuse, and one of the few
that comes close to describing what I do when I design."
                               Ralph Johnson, University of Illinois
"...the first complete account of role-based methods that have proven to be
 a step forward in OO design and development."
  • Rout 95
   T.T. Rout. Ed. Software Process Assessment: Theory and Practice. Proceedings, 2nd International SPICE Symposium. Australian Software Quality Research Institute, Brisbane, Australia., June 1 - 2, 1995. ISBN 0 86857 676 X.

   Excellent coverage of the new SPICE standard: history, present details, goals. * Royce 70

       W. W. Royce. Managing the Development of Large Software Systems. Proceedings of IEEE WESCON, August 1970.

       Introduces the Waterfall Process Model.
  • Selic 94
       Bran Selic, Garth Gullekson, and Paul T. Ward. Real-Time Object-Oriented Modeling. Published by John Wiley & Sons. ISBN 0-471-59917-4

       OO method addresses complete lifecycle needs of real-time systems. Emphasizes executable models for early validation of requirements, architecture, and design combined with techniques for automatic generation of implementations. Specifically real-time with iterative and incremental development process. Single consistent graphical modeling concepts apply uniformly to OOA/D/I.
  • Shlaer 88
       Sally Shlaer and Stephen J. Mellor. Object-Oriented Systems Analysis: Modeling the World in Data.

       Credited as the first book proposing an OOA method.
  • Shlaer 92
       Sally Shlaer and Stephen J. Mellor. Object Lifecycles: Modeling the World in States.

       An addition to * Shlaer 88, provides dynamic modeling with a state- transition driven approach.
  • Strachey 67
       C. Strachey. Fundamental Concepts in programming languages. Lecture Notes for International Summer School in Computer Programming, Copenhagen, Aug.

       Contains original, classical definition of polymorphism.
  • Wasserman 90
       A.I. Wasserman et al. The Object-Oriented Software Design Notation for Software Design Representation. IEEE Computer, 23(3).

       Presents the Object-Oriented Structured Design (OOSD) OOSE methodology. Traditional structured techniques to OO, hybrid containing structured design and Booch.
  • Wegner 87
       Peter Wegner. "Dimensions of Object-Based Language Design", Proceedings of OOPSLA '87, October 4-8 1987, SIGPLAN Notices (Special Issue), V22, No 12, pp168-182, 1987.
  • Wilkie 93
       George Wilkie. Object-Oriented Software Engineering - The Professional Developer's Guide. Addison Wesley.

       Covers OOSE, 11 popular analysis and design methodologies with examples, comparisons, and analysis, information systems (OODB), and case studies.
  • Wirfs-Brock 90
       Rebecca Wirfs-Brock, Brian Wilkerson, Lauren Wiener. Designing Object Oriented Software, Englewood Cliffs, NJ. Prentice Hall.

       Presents a "Responsibility Driven Design" (RDD) with "Class, Responsibility, Collaboration" (CRC) technique, a modern and new OOA/OOD methodology.
Bearbeiten

Wichtig

Bearbeiten

Sonst

Bearbeiten
  • Newsgroup: comp.sw.components
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Benutzer:Centic/Komponentenbasierte_Programmierung&oldid=75125291“