CS 413 - Advanced Software Engineering

Quiz no. 1

Software Reuse

Using existing software components to build new systems.

Main Goal of Software Reuse

Achieve better software more quickly and at lower cost by reusing existing components.

Benefits of Software Reuse

• Increased Dependability: tested, fault-fixed software is reused.

• Reduced Process Risk: costs of reused software are known.

• Effective Use of Specialists: knowledge encapsulated in reusable components.

• Standards Compliance: consistent UIs, fewer user errors

• Accelerated Development: reduced dev + validation time.

Increased Dependability

tested, fault-fixed software is reused

Reduced Process Risk

costs of reused software are known

Effective use of specialists

knowledge encapsulated in reusable components

Standards compliance

consistent UIs, fewer user errors

Accelerated development

reduced dev + validation time.

Process Risk

Costs of reused software known, reduces uncertainty in estimates.

Dependability

Reused, proven software increases reliability.

Maintenance Cost

May increase if source code is unavailable or reused elements become incompatible

Reuse-based Software Engineering

• Application System Reuse: whole app may be reused to COTS or application families

• Component Reuse: components of an app from subsystems to single objects.

• Object/Function Reuse: well-defined object or function.

Application System Reuse

whole app may be reused by incorporating it into other systems (COTS) or by developing application families

Component Reuse

components of an application from subsystems to single objects may be reused

Object and Function Reuse

software components that implement a single well-defined object or function may be reused

Reuse Planning

Factors:

• Development Schedule

• Expected Lifetime

• Team Background and Experience

• Criticality, Non-Functional Requirements

• Application Domain

• Execution Platform

Execution Platform

Must be considered in reuse planning (OS, environment).

System Infrastructure Framework

Frameworks supporting communications, UIs, compilers.

Communication Support

Provided by system infrastructure and middleware frameworks.

Compiler Support

Frameworks include compiler infrastructures.

Web Application Framework (WAF)

• Builds dynamic websites for web applications.

• Interaction model: Model-View-Controller (MVC) patttern.

• Features: security (auth/login), dynamic pages, DB support, session management, AJAX for interactive pages.

Model-View-Controller

• Infrastructure Framework for GUI design.

• Separates object presentations from interactions.

Commercial-Off-The-Shelf Product Reuse

• COTS: adaptable software systems without source modification

• Adaptation: built-in config mechanisms.

• Benefits: faster deployment, reduced risks, vendor handles platform updates.

• Problems: requirements adapted to COTS, vendor control evolution, lack of documentation/expertise.

Legacy System Reuse

Wrapped with defined interfaces, providing access through wrappers

Software Product Line

• Related applications with common architecture + shared components.

• Adaptation: config, adding components, modifying requirements.

• Specialization: platform, environment, function, process.

Shared Architecture

Essential in product lines to separate subsystems and enable modifications.

ERP (Enterprise Resource Planning) Systems

• Generic systems supporting business processes (ordering, invoicing, manufacturing).

• Adapted using modules, process rules, business data models.

• Architecture: multiple modules, business processes, common DB, rules

Vendor Control / System Evolution

COTS vendors control updates and evolution, not users.

COTS Integration Problems

• Lack of functionality control

• Interoperability issues (different assumptions)

• Vendor controls evolution

• Vendor support may be limited.

Framework Complexity

Frameworks are powerful but context, requiring time to use effectively.

Reuse Dependability

Dependability increases with reuse of tried-and-tested software.

Component-Based Software Engineering

• Emphasizes design/construction using reusable components.

• Systems are sets of off-the-shelf components integrated into architectures.

Software Component

• Independent, replicable, fulfills a clear function within a defined architecture.

• Executable entity, may contain multiple objects.

Component Characteristics

1. Standardized

2. Independent

3. Composable

4. Deployable

5. Documented.

Component Qualification

Ensures a candidate component:

• Performs required function

• Fits architecture

• Meets required quality characteristics

Component Wrapping

Adaptation technique to remove conflicts:

• White-box: modify code directly

• Grey-box: use extension language/API

• Black-box: use pre/post-processing at interface

White-box Wrapping

modify code directly

Grey-box Wrapping

use extension language/API

Black-box Wrapping

use pre/post-processing at interfaces

Integration Conflicts

Occur even with qualified documents; wrapping resolves mismatches.

Interoperability

Ensured by underlying object model and data exchange standards

Underlying Object Model

Enables components in different languages/platforms to interoperate

Data Exchange Model

Drag-and-drop-like mechanisms for transferring data between components.

Automation

Tools/scripts/macros to facilitate component interaction

Domain Engineering

• Identifies, constructs, catalogs reusable components.

• Activities: analysis, construction, dissemination

Component Composition

Involves 4 architectural ingredients:

• Data exchange model

• Automation

• Structured storage

• Underlying object model

Advantages of CBSE

• Reduced dev time, increased productivity, lower cost, reliability, complexity management, flexibility.

Disadvantages of CBSE

• Quality of components questionable

• Component dev + maintenance costs

• Sensitive to changes

Maintainability of CBSE

CBSE increases maintainability/evolvability.

Reusability of CBSE

Core concept: build from existing, reusable components

Distributed System

• Collection of independent computers functioning as a single coherent system.

• Information processing spread across multiple machines.

Independent Computers Functioning as One

Users perceive as a single system, even if managed separately.

Characteristics of Distributed Systems

• Resource sharing

• Openness

• Scalability

• Fault tolerance

Resource Sharing

sharing of hardware and software resources

Openness

use of equipment and software from different vendors

Transparency

• resources should be abstracted and addressed logically rather than physically.

• middleware maps logical to physical resources.

Scalability

Increased throughput by adding new resources.

• Maintain quality with increased demand

• Scaling-up: stronger systems

• Scaling-out: more instances

Fault-Tolerance

The ability to continue in operation after a fault has occurred

Interception

loss of confidentiality

Interruption

service unavailable (DoS)

Modification

data altered

Fabrication

fake data injected

Middleware

Manages heterogeneous components, enables communication/exchange.

Client-Server Architecture

• User interacts locally (client), server provides services remotely.

• Layers: presentation, data handling, application processing, database

Multi-tier Client-Server Model

• used when there is a high volume of transactions to be processed by the server

• presentation, data management, application, DB on separate processes/machines

Thin-Client Model

• used when legacy systems are migrated to client server architectures

• Client only handles presentation; processing/data handles by server

Fat-Client Model

• more processing is delegated to the client as the application processing is locally executed

• Client handles significant processing; sever handles data/database

Reliability in Distributed Systems

Must continue providing services even if some components fail

Communication and Data Exchange

Implemented via RPC (remote procedure calls) or message passing

SaaS (Software as a Service)

• Software hosted remotely, accessed via browser

• Owned/managed by provider

• Paid by subscription/usage

Multi-tenancy

• Many user share system while believing they have exclusive access

• Achieved by strict separation of functionality and data