English (United Kingdom)

https://curated-unify.zendy.io/wp-json/zendy-region/v1/featured_content/oa?rat=en

https://curated-unify.zendy.io/wp-json/zendy-region/v1/highlighted_journal/

Global: Zendy Plus annual

Presents the access of premium content as premium feature

Premium Content

Presents the keyphrase highlighting as premium feature

Keyphrase Highlighting

Presents the summarisation as premium feature

Summarisation

Insights

Presents the pdf analysis as premium feature

PDF Analysis

Presents the zaia usage as premium feature

ZAIA

Global: Zendy Tools annual

Global: Zendy Free Plan

Global: Zendy Tools monthly

Global: Zendy Plus monthly

Object-oriented software development covers analysis, design and implementation phases[i]; however, unlike the traditional waterfall software life cycle, the distinct boundaries between these phases have been eliminated[2]. A primary reason for this blurring of boundaries is that in each of these phases, we are dealing with objects and their relationships. As numerous issues are involved during the development process, even though artificial boundaries on those three phases are not necessary, there should be some limits or concentrations on some phases. And the resulting process should be less iterative. The top-down nature of current object-oriented analysis and the mainly bottom-up nature of object-oriented design make the system structure more likely to change. In this research, we address these problems by describing an integrated object-oriented development approach. The object-oriented development process is a process of developing relationships between data types and operations, and also relationships among different objects. A relationship or interaction of certain relationships belongs to an abstraction level. Based upon the abstraction levels, we should be able to divide object-oriented development into several development levels. One development level is composed of one or more abstraction levels. In each of these development levels, we concentrate on a few issues. Objects are identified at the beginning of the object-oriented analysis phase, but the decision that implies system class structure should be deferred to a later stage. We introduce a new concept pseudo-object, which is a component of an object. Pseudo-objects are determined by detection of dependent relationships among methods within an object. A pseudo-object is not viewed as an instance of a class. It relates to objects in the design process, but it does not evolve as objects in the design process do. It is more about what to do, rather than how to do it. This addresses the problem associated with the different points of view between analysis and design. We begin to build the system structure by forming objects from pseudo-objects through a composition relationship, that is to create a new class by combining several pseudo-objects or objects, while eliminating old classes that some of these objects belong to. As only one level of objects is involved, this tends to avoid unnecessary levels of system structure. If two objects have some common methods in the sense of action, not necessarily in meaning, we define these two objects to have a sharing relationship. The inheritance relationship is a special case of sharing. By carefully arranging the abstraction levels, the higher levels of abstraction should be language-independent, while the lowest ones should be language-specific. Each development level should produce reusable components. We are separating the issues of system structure and system function in the above approach. This approach may be interfaced with a software base. Then, not only can it retrieve reusable components from the software base in a more straightforward way, but it can also provide more reusable components to the software base. So the process tends to promote reusability. It may be integrated into an overall object-oriented software development life cycle.

An integrated object-oriented development approach by object relationship abstraction (abstract and references only)