Diskussion:Cross-Cutting Concern

Hi, Vorschlag Einleitung:

Die kostengünstige und termingerechte Entwicklung und Wartung qualitativ hochwertiger Software ist das Primärziel des Software Engineering. Um dieses Ziel zu erreichen, ist eine möglichst modularisierte Software mit einer möglichst geringer Komplexität notwendig.

In einem konventionellen System, wobei hier auch die objektorientierten Ansätze hinzugehören, können Kernfunktionalitäten, sprich englisch core concerns für sich allein betrachtet nach den Regeln der Kunst sauber in Module getrennt werden. Es gibt jedoch concerns (Anliegen, Belange) wie Fehlerbehandlung, Performance und Sicherheit in jedem System, dass die Kernfunktionalitäten quer schneiden (eng. croscutt) und sich deshalb nicht eindeutig einem Software Modul zuordnen lassen. Dies führt dazu, dass Fragmente solcher croscutting concerns (quer schneidende Kernfunktionalitäten - fehlende Kohäsion) nicht zugeordnet und ungekapselt im ganzen Code verstreut sind. Diese quer schneidenden Kernfunktionalitäten verhindern in konventionellen Software Systemen eine saubere Modularisierung und beeinträchtigen Pflege, Verständlichkeit, Wiederverwendbarkeit und (Rück)-Verfolgbarkeit. Verantwortlich hierfür ist bei konventionellen Programmiersprachen die Systemdekomposition, die nur eine Dimension zulassen. Man spricht in diesem Zusammenhang auch von dominanter Dekomposition. Mit anderen Worten: ein natürlicherweise mehrdimensionales Problem muss eindimensional gelösst werden.

Pierre gronau 04:28, 26. Jul 2005 (CEST)

Hallo Pierre, ja, so ist das doch einfach viel verständlicher. Danke für Deine Mühe. Nimm den Löschantrag bitte raus, wenns Du fertig bist. Klasse! ((ó)) Käffchen?!? 08:05, 27. Jul 2005 (CEST)

Hallo, das solltest lieber du machen ... Pierre gronau 21:00, 27. Jul 2005 (CEST)

Nicht schlecht. Ist sehr gut geworden! Ist doch gut, dass der Artikel gerettet wrude. Aber ich halte das erzwingen der Verbesserung mit der Brechstange nach wie vor fuer falsch! -- sparti 21:20, 27. Jul 2005 (CEST)

Hallo, ich stimme dem zu ! Pierre gronau 21:31, 27. Jul 2005 (CEST)

Hi, ich würde gerne den Absatz Anforderung löschen. Was haltet ihr davon ? Pierre gronau 00:03, 2. Aug 2005 (CEST)

Warum willst du den denn löschen? Ich finde den eigentlich ganz sinnvoll. --jpp ?! 11:27, 2. Aug 2005 (CEST)

Hi, weil inzwischen dadurch doppelte Informationen entstanden sind ... Pierre gronau 12:05, 2. Aug 2005 (CEST)

Meiner Ansicht nach fehlt nochimmer eine Pregante Definition des Lemmas. Waere der Absatz nicht als Defintion von CCC geeignet? -- sparti 12:20, 2. Aug 2005 (CEST)

Hi, naja damit habe ich auch bißchen Bauchweh. Aber die Definitionen versuchte/versuche ich unter dem Abschnitt Concerns zu treffen ... Pierre gronau 13:12, 2. Aug 2005 (CEST)

Literaturliste

Ausserdem moechte ich Pierre zu dem neuen Artikel gratulieren, er ist hoch interessant und eine echte Bereicherung! Einziges Makel ist die Literaturliste, die ist doch ein bisschen sehr lang. Das hier ist doch eine Encylopaedie und kein Wissenschaftsmagazin. Waere es nicht sinnvoll, die Liste auf die top 5 (und keines Falles mahr) Papiere zu kuerzen? Denn wenn ich jetzt etwas Allgemeines zum Thema nachlesen moechte, dann moechte ich nicht in 20 Artikeln suchen, bis ich einen guten gefunden habe. -- sparti 12:20, 2. Aug 2005 (CEST)

Hi, ich werde da mal eine Empfehlung versuchen ... und ich möchte noch mehr schreiben ... Pierre gronau 13:08, 2. Aug 2005 (CEST)

Was sollen eigentlich die ganzen Links in den Jahreszahlen der Literaturliste? Ist irgendein Leser dieses Artikels daran interressiert, was z.B. im Jahr 2001 alles so passierte? Dann könnte man doch jeden B uchstaben oder jedes Wort verlinken!

--84.142.222.98 14:23, 6. Mär 2006 (CET)

Da hast du recht, so ist das unsinnig. Eigentlich gibt's ja als Konvention Wikipedia:Literatur. Ich werd's mal umformatieren... --jpp ?! 14:53, 6. Mär 2006 (CET)

Lob und zuviel AOP

Hallo Pierre, sparti und jpp, vielen Dank erstmal, dass ihr den Artikel gerettet habt. Großes Lob für die erfolgreiche Überarbeitung. Allerdings habe ich folgende Anmerkungen:

• Den Abschnitt Was ist AOP würde ich in dem Artikel Aspektorientierte Programmierung belassen und darauf verweisen. Erstens sind die Informationen redundant und zweitens ist mir der AOP Anteil in diesem Artikel hier etwas zu hoch. AOP ist zwar eine Möglichkeit mit CCCs umzugehen, allerdings nicht die einzige. Insbesondere sollte die Definition und Beschreibung von CCCs relativ unabhängig von AOP sein. (Zuerst gabs CCCs und erst später AOP)

• Dem Vorschlag die Literturliste zu kürzen schließe ich mich an.

--Gudi 15:23, 12. Sep 2005 (CEST)

Hallo, ich bin auch dafür, den Abschnitt Was ist AOP hier zu streichen, da er nicht wirklich erklärt, was AOP ist, sondern hauptsächlich auf andere Paradigmen eingeht. Wer tut es nun letztendlich?

--Andybey 13:54, 09. Aug 2006 (CEST)

Literaturverweise nicht vollständig

Hi,

Nach Durchsicht dieses Wikipedia-Artikels ist mir aufgefallen, dass ein grosser Teil des Inhalts einfach aus einer (sehr guten) Master-Thesis der Universtät Zürich kopiert wurden. Leider wird diese aber nicht referenziert. Es wäre ausserordentlich nett, wenn diese Arbeit referenziert würde und wäre nichts weiter als eine faire Würdingung der originalen Arbeit. Die Arbeit findet sich unter http://www.ifi.uzh.ch/archive/mastertheses/abstracts_2004/Bonomo.html. (nicht signierter Beitrag von 83.78.184.79 (Diskussion) )

Hi Unbekannter, bitte signiere deine Diskussionsbeiträge immer mit „--~~~~“ (das wird dann zu IP und Zeitstempel expandiert).

Zum Thema: Ich habe jetzt leider keine Zeit, die Master Thesis zu lesen, um herauszufinden, welche Abschnitte des Artikels sich auf welche Abschnitte der Arbeit beziehen. Du kannst aber gerne die Arbeit wieder unter Literatur eintragen. Eventuell ließen sich auch einzelne Abschnitte konkret belegen. Wie das geht, erfährst du aus Wikipedia:Einzelnachweise. --j ?! 17:33, 3. Jan. 2009 (CET)

Aussagen im Text direkt mit Referenzen versehen

Hallo,

erstmal vielen Dank für den ausführlichen Artikel. Was ich mir noch wünschen würde, wenn hier und da ein Hinweis zu finden wäre, aus welchem Paper oder Buch eine Aussage stimmt bzw. wo man etwas nachlesen kann. Die ganze Literaturliste durchzuarbeiten ist doch wahrscheinlich bisschen viel verlangt. Besonders geht es mir um den Abschnitt

"Solcherart modular implementierte Core Concerns (Kernfunktionalitäten) werden Komponenten genannt; modular implementierte Crosscutting Concerns werden als Aspekte bezeichnet."

Hier gibt es doch bestimmt ein Paper, das die Bezeichnung mal eingeführt hat, oder zumindest ein Buch, das diese Bezeichnungen so definiert hat. Wäre für Hinweise sehr dankbar. Gruß Nickflos -- Nickflos 16:59, 6. Dez. 2011 (CET)

Separation of concerns

Völlig fehlgeleiteter Redirect, läßt sich auch daran erkennen, daß en:Separation of concerns auf keine deutsche Seite zeigt. --193.254.155.48 16:35, 9. Feb. 2012 (CET)

Ich spreche mich dafür aus, einen eigenständigen Artikel zu Separation of concerns zu erstellen. --Fretdf (Diskussion) 09:29, 4. Feb. 2015 (CET)

Einleitung schief

Mir fällt spontan keine bessere Formulierung ein, aber irgendwie finde ich den Artikel, insbesondere in der Einleitung, schief.
Man sollte zunächst die Begriffe übersetzen oder definieren. Etwa: Der Begriff "Crosscutting Concern" steht für ein Konzept, das Querschnittsbelage näher betrachtet. Es wird das Problem der steigenden Komplexität betrachtet, wenn sich diverse fachliche oder technische Concerns beliebig in der Software verteilen. Lösungsansäzte sind Modularisierung, SOC und auch AO-Programmierung, ...

• Beispiel fachliche Concerns: Währungskursermittlung bei einem Zahlungsverkehrssystem.
• Beispiel für technische Concerns: Logging, Persistenz,...

"Teile und Herrsche" sollte man nicht gleich in dem ersten Satz erwähnen, da es zudem eher zu SOC gehört. Hier sollte man "Teile und Herrsche" als ein Lösungsweg, eine Devise bzw Verfahren beschreiben.
Ich vermisse den Begriff "Dependencies Injection" - sollte hier auch als Lösungsansatz eingeordnet werden.


Vielleicht noch ein Wort zur Gliederung.
Der Begriff CCC steht ja im Wesentlichen für das Problem der Verteilung von Sofwarefragmenten. Das Anliegen "Concern" besteht also in der Vereinfachung und Modularisierung mit diversen Mitteln, so dass die verstreute Verteilung unterbunden wird "cross cutting". Damit muss man dann natürlich auch auf diese Punkte eingehen. Etwa:

• Probleme die mit der Verteilung von Softwarefragmenten verbunden sind. (Steht in der Einleitung, wirkt auf mich etwas unvermittelt)
• Identifikation der Concerns (wurde bereits im Artikel gemacht, ist allerdings sehr vage beschrieben.)
• Separations-Methoden (siehe Artikel, z.B. Modularisierung, Methoden der AO-Programmierung)
• Integration (siehe Artikel)
• Lösungsansätze, deren Ergebnisse und Techniken.

Zum "Ziel" im Artikel:
"Ziel der Aspektorientierung ist es, die Integration im Entwicklungsprozess möglichst lange hinauszuzögern." Das kann man so nicht stehen lassen! Spotan fragt man sich "weil manden Chef ärgern will oder warum"!?. Hier wird mit Ziel ja die Aspektorientierung betrachtet, nicht etwa z.B. die Modularisierung. Das Ziel ist aber einfach, nämlich die Lösung der genannten Probleme. (nicht signierter Beitrag von 92.205.21.99 (Diskussion) 15:33, 11. Dez. 2012 (CET)) -- Uhennig (Diskussion) 14:13, 11. Dez. 2012 (CET)

Nachtrag zu einigen Sätzen in diesem Artikel

• Zitat: Die kostengünstige und termingerechte Entwicklung und Wartung qualitativ hochwertiger Software ist das Primärziel der Softwaretechnik.

Das gilt nicht für jedes Projekt. Software für ein Handelssystem der Bank wird wohl eher Wert auf Qualität legen. Die Kosten spielen kaum eine Rolle, da bei einem Ausfall der Syteme die Kosten explodieren. Zudem wird diese Software stets angepasst, überarbeitet und verbessert. Der Satz kling wie eine Parole eines Managers.

• Zitat: Teile-und-Herrsche-Prinzips

Das Prinzip gehört eher in die Kategorie Projektmanagement. Softwarekomponenten in Teile zu zerlegen und diese wie ein Herrscher zusammen zu halten, nenne ich Modularisierung. Ansonsten habe ich zuvor schon etwas dazu gesagt.

• Zitat: .. für sich allein betrachtet nach den Regeln der Kunst sauber in Module getrennt werden

Was sind denn hier die "Regeln der Kunst"?

• Zitat: Anforderungen verhindern in konventionellen Software-Systemen eine saubere Modularisierung und beeinträchtigen Pflege, Verständlichkeit, Wiederverwendbarkeit und (Rück)-Verfolgbarkeit

Anforderungen sind da und müssen in Software gegossen werden. Ich kann nicht erkennen warum diese generell eine Modularisierung verhindern. Das klingt nach "Hacker"-Bullshit!

• Zitat: Identifikation, Separation und Integration, Jeder Entwicklungsprozess mit Aspektorientierung.

CCC ist nicht eine Einleitung für AOP! Warum wechselt man das Thema zu AOP. Es gibt andere Möglichkeiten! Alle folgenden Kapitel scheinen sich nur noch mit AOP zu beschäftigen!

• Zitat: Beispiele für Cross-Cutting Concerns sind Fehlerbehandlung, Logging, Tracing und Sicherheitsanforderungen

Was ist denn mit den fachlichen Concerns?

• Zitat: Ziel der AOP

Da hab' ich ja oben schon etwas gesagt. Ansonsten sind die Formulierungen ein "No-Go"! in diesem Kapitel.

• Anforderungen: .. mit größerer Mitarbeiterzahl konzentrieren sich die Entwickler primär auf die Kernfunktionalität,..

Das sollte immer so sein unabhängig von Mitarbeiterzahlen!?

• ... Cross-Cutting Concerns einen hohen Anpassungs- und Koordinierungsaufwand.

Das ist quatsch! Das klingt als würde man mit AOP eine Gerneralierung anstreben und daher Koordinierung benötigt. (nicht signierter Beitrag von 92.205.122.233 (Diskussion) 07:27, 19. Jan. 2013 (CET))

Defekter Weblink

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Der folgende Weblink wurde von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieses Fehlers finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://www.research.ibm.com/hyperspace/
  • Vielleicht ist eine archivierte Version geeignet: archive.orghttp://giftbot.dwl.invalid/http://www.research.ibm.com/hyperspace/

– GiftBot (Diskussion) 02:06, 20. Dez. 2015 (CET)