Please enable JavaScript.

Coggle requires JavaScript to display documents.

Topic 3: Software Reuse - Coggle Diagram

- - - - Code components: functions, modules, subsystems etc
      - Abstract Products: specifications, designs etc.
    - - Sub-system reuse: Major sub-systems of an application may be reuse.
      - Module or object reuse: Components of a system representing a collection of functions may be reuse. For eg., a C++ object implementing a binary tree may be reused in different applications.
      - Application system reuse: The whole of an application system may be reused. For this the software must be portable i.e. it should execute on different platforms.
      - Function reuse: Software components which implement a single function, such as mathematical functions, may be reused.
    - - A systematic reuse in the development process leads to the following
        
        . System reliability is increased: These components have been tested in operational systems and have therefore been exposed to realistic operating conditions.
        
        Overall process risk is reduced (not free of risk): Less uncertainty in the costs of reusing that component than in the costs of development. It reduces uncertainties in project cost estimation.
        
        Effective use can be made of specialists: Instead of application specialists doing the same work on different projects, these specialists can develop reusable components which encapsulate their knowledge.
        
        Standard Compliance: Organizational standards can be embodied in reusable components. Eg. user interfaces.
        
        Software development time can be reduced: Reusing components speeds up system production because both development and validation time should be reduced.
- - - - Reuse Strengths
        
        Pervades all life-cycle, abstraction and executability levels
        
        Associated with detailed engineering processes and methods
        
        Classes bundle a structural and a behavioral template that is reused each time an object of the class is created
        
        OO platforms usually come with vast libraries of built-in classes
        
        Inheritance provides structural and behavioral model and code reuse through specialization
        
        Abstract class and interfaces provide structural and service specification reuse through variable realization/implementation
        
        7.Private attributes accessible only through public access methods provide encapsulation, making classes and objects reusable units
        
        Overloading, polymorphism and dynamic binding provide client reuse across diverse realizations of servers sharing a common specification
        
        Entity-centered modeling at gradual abstraction levels and associated standard visual notation (UML) greatly facilitates OO model and code comprehension for white-box reuse
      - Reuse Weaknesses
        
        Public attributes break encapsulation along associations, hindering model and code element locality and thus ease of reuse
        
        Protected attributes and methods break encapsulation down the class hierarchy,
        
        Attribute value and method realization overriding down the class hierarchy breaks interface semantics inheritance and thus encapsulation
        
        Classes too fine grained reuse units
        
        Packages more adequate and more variable grained reuse units but lack most reuse-fostering features of classes
    - - Architectural patterns
        
        Coarse-grained modeling patterns
        
        Specified in special-purpose architectural languages or in UML
        
        Template for decomposition of system into
        modules/components with names and roles
        together with their data flows, structural and behavioral relationships
      - Design patterns (generally object-oriented)
        
        Finer grained modeling patterns
        
        Template for associated classes that together provide a given generic service
      - Modeling patterns
        
        Mapping view: pair associating a set of requirements (generic design problem)
        to a analysis/design template known to satisfy it (generic design solution)
        
        Capture know how of experienced analysts
        
        Two granularity levels: architectural, design
        
        Two complementary aspects: structural/static and behavioral/dynamic
        
        Artifact view: abstract analysis/design template which instances recur across domains and applications
      - Programming patterns (idioms, styles):
        
        Conventional, restricted use of programming language constructs to realize design pattern
    - - What is framework?
        
        In contrast to patterns, frameworks are specific to a given domain, but independents of any particular application requirements
      - Two main elements (separation of interfaces):
        
        Set of interrelated interfaces and abstract classes that represent a
        predefined software architecture skeleton
        
        Set of interrelated concrete classes that provide as built-in the conceptual entities of the domain and the common services shared by most applications in the domain
      - Building an application with a
        framework consists of:
        
        Reusing the concrete classes by specializing them, with or without overriding
        
        Reusing the abstract classes and interfaces by realizing them
        
        All three guided by the application’s requirements
        
        Reusing the concrete classes by calling their methods
      - Reuse occurs massively at the domain engineering and design stages (almost entirely avoided) and partially at the implementation stage
      - Sometimes comes associated with
        
        A domain-specific development process/method
        
        A domain-specific CASE tool and/or IDE
    - - any software unit that:Is “independently” deployable (albeit) reuses/requires a set of typed and constrained operations (typically provided by other components that its uses at servers). To provide a set of typed and constrained operations. Executable by either: Humans through a user interface (stand-alone deployment)or Other software through an calling interface (for which it then acts as a server). Encapsulates:Meta-data allowing the deployment platform or development environment to automatically assemble it with other components to provide complex services Several related classes, routines, or functions
      - Component vs. object
        
        component
        
        Independently deployable
        
        Possesses user-interface for stand-alone deployment
        
        Not necessarily object-oriented
        
        Mid-size grained unit intermediate between objects and systems
        
        At run time subject to service invocation
        
        At deployment time subject to composition/assembly
        
        object
        
        But be wrapped inside a program to be executed
        Only subject to method invocation
      - Component diversity
        
        Component class vs. component instance
        
        Distinction relevant mostly for
        components within OO paradigm
        
        Component instance: run-time entity
        
        Component class: subject to specialization, instantiation and inheritance
        
        Deployment-only components
        
        UML 1, Java Beans, .Net DLL, Web Services
        
        Packaging and assembly mechanisms for abstract services implemented by classes and objects
        
        Full-life cycle components:
        
        UML 2, KobrA
        
        Encapsulates requirements, model, code, test suites
        
        With composition/assembly meta-data at each stage/abstraction level
        
        With traceability meta-data between each stage/abstraction level
      - Component-based architectures
        
        Architectural and design patterns using components instead of objects as basic building blocks
        
        Arbitrary assembly based on various relations between components
        
        At run-time between component instances
        Composition
        Clientship
        
        At design-time between component types
        Ownership/Nesting
        Access
        Specialization/Generalization
    - - Define.
        
        Mapping often specified declaratively and executed by generator tool
        
        Raises asset abstraction:
        
        to meta-artifact defining mapping/transformation/generation
        
        from artifact template at stage S to artifact template at stage S+1
        
        From artifact at given development stage S
      - Assembly reuse vs. generative reuse
      - Current OOSE
    - - Separation of concern
        
        Problem
        
        Object-oriented design structures models and code solely based on the entity classes of the application and their relationships
        This results into an non-isomorphic mapping between The N concerns of the software being developed & The M entity classes of the model and code.
        
        This makes adding or changing a single concern extremely costly for it requires
        
        Inspecting the entire OO model/code
        
        Coherently modifying the many different classes in which it is scattered
        
        It also prevents exploiting the high concern reuse potential. Most concerns are conceptually orthogonal to one another and to the entity class structure of the application domain. Yet they end-up entangled together in its model and code
    - - Define
        
        Practice of Encapsulating orthogonal concerns in different aspects, to cleanly separate them from the core program and from one another. Link each aspect with the core program (that captures the dominant decomposition) through point-cuts . Automatically generate the complete source code by using AOP tools that weave together the aspects with the core program at the indicated point-cuts
      - Generalize aspect-oriented approach throughout the entire life-cycle at all level of abstraction and development stage
      - Aspects such as persistence, distribution, security, logging/tracing are largely orthogonal to the domain and functional requirement of any particular applications
        Once modeled and implemented separately as aspects they can be reused
        Even various ontological features of an application domain display a large extent of orthogonality than can be exploited using AOD
    - - Most reuse techniques are complementary and can be combined in synergy
        
        MDA/AOD synergy
        
        Modeling aspect weaving can be implemented by generic model transformation
        
        Separation between platform independent and platform dependent aspects further foster reuse
        
        At the various MDA model levels (CIM, PIM, PSM)
        
        PLE/AOD synergy: Many PLE variations correspond to inclusion/exclusion of different aspects
        
        Recent reuse-oriented software engineering methods combined most of them: Combines objects, patterns, frameworks, components, product lines, MDA.
- - - - Additional effort needed to develop a reusable component.
      - Costs to store and manage a reusable component in a repository.
      - Costs to retrieve a component, to adapt and to integrate it.