FRINK Linked Data Fragments server

Matches in SemOpenAlex for { <https://semopenalex.org/work/W2056287941> ?p ?o ?g. }

• W2056287941 endingPage "60" @default.
• W2056287941 startingPage "40" @default.
• W2056287941 abstract "The need to develop and maintain large complex software systems in a competitive and dynamic environment has driven interest in new approaches to software design and development. The problems with the classical waterfall model have been cataloged in almost every software engineering text [19,23]. In response, alternative models such as the spiral [2], and fountain [9] have been proposed. Problems with traditional development using the classical life cycle include no iteration, no emphasis on reuse, and no unifying model to integrate the phases. The difference in point of view between following data flows in structured analysis and building hierarchies of tasks in structured design has always been a major problem [4]. Each system is built from scratch and maintenance costs account for a notoriously large share of total system costs. The object-oriented paradigm addresses each of these issues. A look at the object-oriented software life cycle, as described by Meyer [5], Coad and Yourdon [4], and Henderson-Sellers and Edwards [9], identifies the three traditional activities of analysis, design, and implementation. However, each of the referenced descriptions eliminates the distinct boundaries between the phases. The primary reason for this blurring of boundaries is that the items of interest in each phase are the same: objects. Objects and the relationships between objects are identified in both the analysis and design phases. Objects and relationships identified and documented in the analysis phase serve not only as input to the design phase, but as an initial layer in the design. This continuity provides for a much more seamless interface between the phases. Analysts, designers and programmers are working with a common set of items upon which to build. A second reason for the blurring of these boundaries is that the object-oriented development process is iterative. Henderson-Sellers and Edwards further refine this idea by replacing the waterfall model of software development with a fountain model. Development reaches a high level only to fall back to a previous level to begin the climb once again. As an example of the blurring of the traditional boundaries of the life cycle phases, Coad and Yourdon recommend that classification relationships between objects be captured and documented during the object-oriented analysis (OOA) phase. This classification will be directly reflected in the class inheritance structure developed in the design and in the code. This classification is in no way required in order to document the system requirements. In other words, Coad and Yourdon are recommending a traditional design activity in the analysis phase. The blurring of the traditional design and implementation phases has been fueled by the development of encapsulation and abstraction mechanisms in object-oriented and object-based languages. For example, Meyer claims [14] that Eiffel is both a design and an implementation language. He goes on to say that software design is sometimes mistakenly viewed as an activity totally secluded from actual implementation. From his point of view, much is to be gained from an approach that integrates both activities within the same conceptual framework. The object-oriented design paradigm is the next logical step in a progression that has led from a purely procedural approach to an object-based approach and now to the object-oriented approach. The progression has resulted from a gradual shift in point of view in the development process. The procedural design paradigm utilizes functional decomposition to specify the tasks to be completed in order to solve a problem. The object-based approach, typified by the techniques of Yourdon, Jackson and Booth, gives more attention to data specifications than the procedural approach but still utilizes functional decomposition to develop the architecture of a system. The object-oriented approach goes beyond the object-based technique in the emphasis given to data by utilizing the relationships between objects as a fundamental part of the system architecture. The goal in designing individual software components is to represent a concept in what will eventually be an executable form. The Abstract Data Type (ADT) is the object-based paradigm's technique for capturing this conceptual information. The class is the object-oriented paradigm's conceptual modeling tool. The design pieces resulting from the object-oriented design technique represent a tighter coupling of data and functionality than traditional ADTs. These artifacts of the design process used in conjunction with a modeling-based decomposition approach yield a paradigm, a technique, which is very natural and flexible. It is natural in the sense that the design pieces are closely identified with the real-world concepts which they model. It is flexible in the sense of quickly adapting to changes in the problem specifications. Object-oriented remains a term which is interpreted differently by different people. Before presenting an overview of a set of techniques for the design process, we will give our perspective so the reader may judge the techniques in terms of those definitions. Briefly, we adapt Wegner's [27] definition for object-oriented languages to object-oriented design. The pieces of the design are objects which are grouped into classes for specification purposes. In addition to traditional dependencies between data elements, an inheritance relation between classes is used to express specializations and generalizations of the concepts represented by the classes. As natural and flexible as the object-oriented technique is, it is still possible to produce a bad design when using it. We will consider a number of general design criteria and will discuss how the object-oriented approach assists the designer in meeting these criteria. We will refer to a number of design guidelines developed specifically for the object-oriented design paradigm and will discuss how these properties reinforce the concepts of good design. The paradigm sprang from language, has matured into design, and has recently moved into analysis. The blurring of boundaries between these phases has led us to include topics in this article that are outside the realm of design, but which we consider important to understanding the design process. Since the paradigm sprang from language, we define the concepts basic to object-oriented programming in the following section." @default.
• W2056287941 created "2016-06-24" @default.
• W2056287941 creator A5031491865 @default.
• W2056287941 creator A5068572174 @default.
• W2056287941 date "1990-09-01" @default.
• W2056287941 modified "2023-09-23" @default.
• W2056287941 title "Understanding object-oriented: a unifying paradigm" @default.
• W2056287941 cites W1989153383 @default.
• W2056287941 cites W2027657506 @default.
• W2056287941 cites W2028544887 @default.
• W2056287941 cites W2039574476 @default.
• W2056287941 cites W2042769377 @default.
• W2056287941 cites W2050645799 @default.
• W2056287941 cites W2069752849 @default.
• W2056287941 cites W2074804596 @default.
• W2056287941 cites W2091207472 @default.
• W2056287941 cites W2134062730 @default.
• W2056287941 cites W2138387375 @default.
• W2056287941 cites W2294346714 @default.
• W2056287941 cites W4255667787 @default.
• W2056287941 doi "https://doi.org/10.1145/83880.84459" @default.
• W2056287941 hasPublicationYear "1990" @default.
• W2056287941 type Work @default.
• W2056287941 sameAs 2056287941 @default.
• W2056287941 citedByCount "244" @default.
• W2056287941 countsByYear W20562879412012 @default.
• W2056287941 countsByYear W20562879412013 @default.
• W2056287941 countsByYear W20562879412014 @default.
• W2056287941 countsByYear W20562879412015 @default.
• W2056287941 countsByYear W20562879412017 @default.
• W2056287941 countsByYear W20562879412020 @default.
• W2056287941 countsByYear W20562879412021 @default.
• W2056287941 countsByYear W20562879412022 @default.
• W2056287941 crossrefType "journal-article" @default.
• W2056287941 hasAuthorship W2056287941A5031491865 @default.
• W2056287941 hasAuthorship W2056287941A5068572174 @default.
• W2056287941 hasBestOaLocation W20562879411 @default.
• W2056287941 hasConcept C115903868 @default.
• W2056287941 hasConcept C120617098 @default.
• W2056287941 hasConcept C127413603 @default.
• W2056287941 hasConcept C146054899 @default.
• W2056287941 hasConcept C154945302 @default.
• W2056287941 hasConcept C180152950 @default.
• W2056287941 hasConcept C186846655 @default.
• W2056287941 hasConcept C199360897 @default.
• W2056287941 hasConcept C202105479 @default.
• W2056287941 hasConcept C20505762 @default.
• W2056287941 hasConcept C206588197 @default.
• W2056287941 hasConcept C2524010 @default.
• W2056287941 hasConcept C2777904410 @default.
• W2056287941 hasConcept C2781238097 @default.
• W2056287941 hasConcept C28719098 @default.
• W2056287941 hasConcept C33923547 @default.
• W2056287941 hasConcept C41008148 @default.
• W2056287941 hasConcept C52913732 @default.
• W2056287941 hasConcept C529173508 @default.
• W2056287941 hasConcept C53073257 @default.
• W2056287941 hasConcept C548081761 @default.
• W2056287941 hasConceptScore W2056287941C115903868 @default.
• W2056287941 hasConceptScore W2056287941C120617098 @default.
• W2056287941 hasConceptScore W2056287941C127413603 @default.
• W2056287941 hasConceptScore W2056287941C146054899 @default.
• W2056287941 hasConceptScore W2056287941C154945302 @default.
• W2056287941 hasConceptScore W2056287941C180152950 @default.
• W2056287941 hasConceptScore W2056287941C186846655 @default.
• W2056287941 hasConceptScore W2056287941C199360897 @default.
• W2056287941 hasConceptScore W2056287941C202105479 @default.
• W2056287941 hasConceptScore W2056287941C20505762 @default.
• W2056287941 hasConceptScore W2056287941C206588197 @default.
• W2056287941 hasConceptScore W2056287941C2524010 @default.
• W2056287941 hasConceptScore W2056287941C2777904410 @default.
• W2056287941 hasConceptScore W2056287941C2781238097 @default.
• W2056287941 hasConceptScore W2056287941C28719098 @default.
• W2056287941 hasConceptScore W2056287941C33923547 @default.
• W2056287941 hasConceptScore W2056287941C41008148 @default.
• W2056287941 hasConceptScore W2056287941C52913732 @default.
• W2056287941 hasConceptScore W2056287941C529173508 @default.
• W2056287941 hasConceptScore W2056287941C53073257 @default.
• W2056287941 hasConceptScore W2056287941C548081761 @default.
• W2056287941 hasIssue "9" @default.
• W2056287941 hasLocation W20562879411 @default.
• W2056287941 hasOpenAccess W2056287941 @default.
• W2056287941 hasPrimaryLocation W20562879411 @default.
• W2056287941 hasRelatedWork W1566909275 @default.
• W2056287941 hasRelatedWork W2015302871 @default.
• W2056287941 hasRelatedWork W2148942252 @default.
• W2056287941 hasRelatedWork W2211569573 @default.
• W2056287941 hasRelatedWork W2307988617 @default.
• W2056287941 hasRelatedWork W2330428294 @default.
• W2056287941 hasRelatedWork W2970160274 @default.
• W2056287941 hasRelatedWork W4293087571 @default.
• W2056287941 hasRelatedWork W4309907077 @default.
• W2056287941 hasRelatedWork W75220433 @default.
• W2056287941 hasVolume "33" @default.
• W2056287941 isParatext "false" @default.
• W2056287941 isRetracted "false" @default.
• W2056287941 magId "2056287941" @default.
• W2056287941 workType "article" @default.