Behavioral relationships in object-oriented analysis:
Abstract: "The object-modeling phase of common object-oriented analysis approaches often focuses on representing architectural (or structural) relationships among classes separately from the classes themselves. For example an employs relationship from class employer to class employee would not...
Gespeichert in:
| Hauptverfasser: | , |
|---|---|
| Format: | Buch |
| Sprache: | English |
| Veröffentlicht: |
Seattle, Wash.
1991
|
| Schriftenreihe: | University of Washington <Seattle, Wash.> / Department of Computer Science: Technical report
91,9,3 |
| Schlagworte: | |
| Zusammenfassung: | Abstract: "The object-modeling phase of common object-oriented analysis approaches often focuses on representing architectural (or structural) relationships among classes separately from the classes themselves. For example an employs relationship from class employer to class employee would not be represented in the attributes of the employer or employee classes, but by an arc drawn between these classes. Architectural relationships are externalized to increase the intellectual tractability, semantic clarity, reusability, and ease of evolution of the resulting model. In dynamic modeling, in contrast, object-oriented analysis generally fails to externalize representations of behavioral relationships, instead casting them in terms of direct communications among the related classes This produces exactly the intertwining of definitions that externalizing architectural relationships was intended to avoid, largely defeating the benefits of the previous phase. We informally and formally show that it is not possible to externalize behavioral relationships in a formalism supporting only direct method invocation-like communication. We show that implicit invocation is the dual of explicit method invocation and that adding an implicit invocation mechanism makes it possible to externalize behavioral relationships. We analyze common approaches and show that, even when implicit invocation is available, these approaches fail to externalize behavioral relationships. Finally, we provide rules of thumb for how to produce a model based on behavioral relationships. |
| Beschreibung: | 17 S. |
Internformat
MARC
| LEADER | 00000nam a2200000 cb4500 | ||
|---|---|---|---|
| 001 | BV009015554 | ||
| 003 | DE-604 | ||
| 005 | 00000000000000.0 | ||
| 007 | t | ||
| 008 | 940206s1991 |||| 00||| eng d | ||
| 035 | |a (OCoLC)28390623 | ||
| 035 | |a (DE-599)BVBBV009015554 | ||
| 040 | |a DE-604 |b ger |e rakddb | ||
| 041 | 0 | |a eng | |
| 049 | |a DE-29T | ||
| 100 | 1 | |a Sullivan, Kevin J. |e Verfasser |4 aut | |
| 245 | 1 | 0 | |a Behavioral relationships in object-oriented analysis |c Kevin J. Sullivan and David Notkin |
| 264 | 1 | |a Seattle, Wash. |c 1991 | |
| 300 | |a 17 S. | ||
| 336 | |b txt |2 rdacontent | ||
| 337 | |b n |2 rdamedia | ||
| 338 | |b nc |2 rdacarrier | ||
| 490 | 1 | |a University of Washington <Seattle, Wash.> / Department of Computer Science: Technical report |v 91,9,3 | |
| 520 | 3 | |a Abstract: "The object-modeling phase of common object-oriented analysis approaches often focuses on representing architectural (or structural) relationships among classes separately from the classes themselves. For example an employs relationship from class employer to class employee would not be represented in the attributes of the employer or employee classes, but by an arc drawn between these classes. Architectural relationships are externalized to increase the intellectual tractability, semantic clarity, reusability, and ease of evolution of the resulting model. In dynamic modeling, in contrast, object-oriented analysis generally fails to externalize representations of behavioral relationships, instead casting them in terms of direct communications among the related classes | |
| 520 | 3 | |a This produces exactly the intertwining of definitions that externalizing architectural relationships was intended to avoid, largely defeating the benefits of the previous phase. We informally and formally show that it is not possible to externalize behavioral relationships in a formalism supporting only direct method invocation-like communication. We show that implicit invocation is the dual of explicit method invocation and that adding an implicit invocation mechanism makes it possible to externalize behavioral relationships. We analyze common approaches and show that, even when implicit invocation is available, these approaches fail to externalize behavioral relationships. Finally, we provide rules of thumb for how to produce a model based on behavioral relationships. | |
| 650 | 4 | |a Software engineering | |
| 700 | 1 | |a Notkin, David |e Verfasser |4 aut | |
| 810 | 2 | |a Department of Computer Science: Technical report |t University of Washington <Seattle, Wash.> |v 91,9,3 |w (DE-604)BV008930431 |9 91,9,3 | |
| 999 | |a oai:aleph.bib-bvb.de:BVB01-005961129 | ||
Datensatz im Suchindex
| _version_ | 1804123364848041984 |
|---|---|
| any_adam_object | |
| author | Sullivan, Kevin J. Notkin, David |
| author_facet | Sullivan, Kevin J. Notkin, David |
| author_role | aut aut |
| author_sort | Sullivan, Kevin J. |
| author_variant | k j s kj kjs d n dn |
| building | Verbundindex |
| bvnumber | BV009015554 |
| ctrlnum | (OCoLC)28390623 (DE-599)BVBBV009015554 |
| format | Book |
| fullrecord | <?xml version="1.0" encoding="UTF-8"?><collection xmlns="http://www.loc.gov/MARC21/slim"><record><leader>02621nam a2200313 cb4500</leader><controlfield tag="001">BV009015554</controlfield><controlfield tag="003">DE-604</controlfield><controlfield tag="005">00000000000000.0</controlfield><controlfield tag="007">t</controlfield><controlfield tag="008">940206s1991 |||| 00||| eng d</controlfield><datafield tag="035" ind1=" " ind2=" "><subfield code="a">(OCoLC)28390623</subfield></datafield><datafield tag="035" ind1=" " ind2=" "><subfield code="a">(DE-599)BVBBV009015554</subfield></datafield><datafield tag="040" ind1=" " ind2=" "><subfield code="a">DE-604</subfield><subfield code="b">ger</subfield><subfield code="e">rakddb</subfield></datafield><datafield tag="041" ind1="0" ind2=" "><subfield code="a">eng</subfield></datafield><datafield tag="049" ind1=" " ind2=" "><subfield code="a">DE-29T</subfield></datafield><datafield tag="100" ind1="1" ind2=" "><subfield code="a">Sullivan, Kevin J.</subfield><subfield code="e">Verfasser</subfield><subfield code="4">aut</subfield></datafield><datafield tag="245" ind1="1" ind2="0"><subfield code="a">Behavioral relationships in object-oriented analysis</subfield><subfield code="c">Kevin J. Sullivan and David Notkin</subfield></datafield><datafield tag="264" ind1=" " ind2="1"><subfield code="a">Seattle, Wash.</subfield><subfield code="c">1991</subfield></datafield><datafield tag="300" ind1=" " ind2=" "><subfield code="a">17 S.</subfield></datafield><datafield tag="336" ind1=" " ind2=" "><subfield code="b">txt</subfield><subfield code="2">rdacontent</subfield></datafield><datafield tag="337" ind1=" " ind2=" "><subfield code="b">n</subfield><subfield code="2">rdamedia</subfield></datafield><datafield tag="338" ind1=" " ind2=" "><subfield code="b">nc</subfield><subfield code="2">rdacarrier</subfield></datafield><datafield tag="490" ind1="1" ind2=" "><subfield code="a">University of Washington <Seattle, Wash.> / Department of Computer Science: Technical report</subfield><subfield code="v">91,9,3</subfield></datafield><datafield tag="520" ind1="3" ind2=" "><subfield code="a">Abstract: "The object-modeling phase of common object-oriented analysis approaches often focuses on representing architectural (or structural) relationships among classes separately from the classes themselves. For example an employs relationship from class employer to class employee would not be represented in the attributes of the employer or employee classes, but by an arc drawn between these classes. Architectural relationships are externalized to increase the intellectual tractability, semantic clarity, reusability, and ease of evolution of the resulting model. In dynamic modeling, in contrast, object-oriented analysis generally fails to externalize representations of behavioral relationships, instead casting them in terms of direct communications among the related classes</subfield></datafield><datafield tag="520" ind1="3" ind2=" "><subfield code="a">This produces exactly the intertwining of definitions that externalizing architectural relationships was intended to avoid, largely defeating the benefits of the previous phase. We informally and formally show that it is not possible to externalize behavioral relationships in a formalism supporting only direct method invocation-like communication. We show that implicit invocation is the dual of explicit method invocation and that adding an implicit invocation mechanism makes it possible to externalize behavioral relationships. We analyze common approaches and show that, even when implicit invocation is available, these approaches fail to externalize behavioral relationships. Finally, we provide rules of thumb for how to produce a model based on behavioral relationships.</subfield></datafield><datafield tag="650" ind1=" " ind2="4"><subfield code="a">Software engineering</subfield></datafield><datafield tag="700" ind1="1" ind2=" "><subfield code="a">Notkin, David</subfield><subfield code="e">Verfasser</subfield><subfield code="4">aut</subfield></datafield><datafield tag="810" ind1="2" ind2=" "><subfield code="a">Department of Computer Science: Technical report</subfield><subfield code="t">University of Washington <Seattle, Wash.></subfield><subfield code="v">91,9,3</subfield><subfield code="w">(DE-604)BV008930431</subfield><subfield code="9">91,9,3</subfield></datafield><datafield tag="999" ind1=" " ind2=" "><subfield code="a">oai:aleph.bib-bvb.de:BVB01-005961129</subfield></datafield></record></collection> |
| id | DE-604.BV009015554 |
| illustrated | Not Illustrated |
| indexdate | 2024-07-09T17:28:36Z |
| institution | BVB |
| language | English |
| oai_aleph_id | oai:aleph.bib-bvb.de:BVB01-005961129 |
| oclc_num | 28390623 |
| open_access_boolean | |
| owner | DE-29T |
| owner_facet | DE-29T |
| physical | 17 S. |
| publishDate | 1991 |
| publishDateSearch | 1991 |
| publishDateSort | 1991 |
| record_format | marc |
| series2 | University of Washington <Seattle, Wash.> / Department of Computer Science: Technical report |
| spelling | Sullivan, Kevin J. Verfasser aut Behavioral relationships in object-oriented analysis Kevin J. Sullivan and David Notkin Seattle, Wash. 1991 17 S. txt rdacontent n rdamedia nc rdacarrier University of Washington <Seattle, Wash.> / Department of Computer Science: Technical report 91,9,3 Abstract: "The object-modeling phase of common object-oriented analysis approaches often focuses on representing architectural (or structural) relationships among classes separately from the classes themselves. For example an employs relationship from class employer to class employee would not be represented in the attributes of the employer or employee classes, but by an arc drawn between these classes. Architectural relationships are externalized to increase the intellectual tractability, semantic clarity, reusability, and ease of evolution of the resulting model. In dynamic modeling, in contrast, object-oriented analysis generally fails to externalize representations of behavioral relationships, instead casting them in terms of direct communications among the related classes This produces exactly the intertwining of definitions that externalizing architectural relationships was intended to avoid, largely defeating the benefits of the previous phase. We informally and formally show that it is not possible to externalize behavioral relationships in a formalism supporting only direct method invocation-like communication. We show that implicit invocation is the dual of explicit method invocation and that adding an implicit invocation mechanism makes it possible to externalize behavioral relationships. We analyze common approaches and show that, even when implicit invocation is available, these approaches fail to externalize behavioral relationships. Finally, we provide rules of thumb for how to produce a model based on behavioral relationships. Software engineering Notkin, David Verfasser aut Department of Computer Science: Technical report University of Washington <Seattle, Wash.> 91,9,3 (DE-604)BV008930431 91,9,3 |
| spellingShingle | Sullivan, Kevin J. Notkin, David Behavioral relationships in object-oriented analysis Software engineering |
| title | Behavioral relationships in object-oriented analysis |
| title_auth | Behavioral relationships in object-oriented analysis |
| title_exact_search | Behavioral relationships in object-oriented analysis |
| title_full | Behavioral relationships in object-oriented analysis Kevin J. Sullivan and David Notkin |
| title_fullStr | Behavioral relationships in object-oriented analysis Kevin J. Sullivan and David Notkin |
| title_full_unstemmed | Behavioral relationships in object-oriented analysis Kevin J. Sullivan and David Notkin |
| title_short | Behavioral relationships in object-oriented analysis |
| title_sort | behavioral relationships in object oriented analysis |
| topic | Software engineering |
| topic_facet | Software engineering |
| volume_link | (DE-604)BV008930431 |
| work_keys_str_mv | AT sullivankevinj behavioralrelationshipsinobjectorientedanalysis AT notkindavid behavioralrelationshipsinobjectorientedanalysis |