CBSE -
Component-based software engineering (CBSE) is an approach to software development that relies on software reuse.
It emerged from the failure of object-oriented development to support effective reuse. Single object classes are too detailed and specific.
Components are more abstract than object classes and can be considered to be stand-alone service providers.
Essentials
Independent components specified by t 343i83d heir interfaces.
Component standards to facilitate component integration.
Middleware that provides support for component inter-operability.
A development process that is geared to reuse.
Design and principles
Apart from the benefits of reuse, CBSE is based on sound software engineering design principles:
Components are independent so do not interfere with each other;
Component implementations are hidden;
Communication is through well-defined interfaces;
Component platforms are shared and reduce development costs.
Problems
Component trustworthiness - how can a component with no available source code be trusted?
Component certification - who will certify the quality of components?
Emergent property prediction - how can the emergent properties of component compositions be predicted?
Requirements trade-offs - how do we do trade-off analysis between the features of one component and another?
2.Graphical(Analog) better than digital presentation of numerical values
Digital presentation
Compact - takes up little screen space;
Precise values can be communicated.
Analogue presentation
Easier to get an 'at a glance' impression of a value;
Possible to show relative values;
Easier to see exceptional data values.
Concerned with techniques for displaying large amounts of information.
Visualisation can reveal relationships between entities and trends in the data.
Possible data visualisations are:
Weather information collected from a number of sources;
The state of a telephone network as a linked set of nodes;
Chemical plant visualised by showing pressures and temperatures in a linked set of tanks and pipes;
A model of a molecule displayed in 3 dimensions;
Web pages displayed as a hyperbolic tree.
3.Application Frameworks
Frameworks are a sub-system design made up of a collection of abstract and concrete classes and the interfaces between them.
The sub-system is implemented by adding components to fill in parts of the design and by extending the abstract classes in the framework.
Frameworks are moderately large entities that can be reused.
Framework classes:
Frameworks are a sub-system design made up of a collection of abstract and concrete classes and the interfaces between them.
The sub-system is implemented by adding components to fill in parts of the design and by extending the abstract classes in the framework.
Frameworks are moderately large entities that can be reused.
Extending Frameworks
Frameworks are generic and are extended to create a more specific application or sub-system.
Extending the framework involves
Adding concrete classes that inherit operations from abstract classes in the framework;
Adding methods that are called in response to events that are recognised by the framework.
Problem with frameworks is their complexity which means that it takes a long time to use them effectively.
4.Object oriented SE, object models:
Approach to the whole software development process:
Express system requirements using an object model; represent both system data and its processing.
Design using objects.
Develop the system in an OO programming language.
Object Models
Object models describe the system in terms of object classes and their associations.
An object class is an abstraction over a set of objects with common attributes and the services (operations) provided by each object.
Various object models may be produced
Inheritance models;
Aggregation models;
Interaction models.
Natural ways of reflecting the real-world entities manipulated by the system
More abstract entities are more difficult to model using this approach
Object class identification is recognised as a difficult process requiring a deep understanding of the application domain
Object classes reflecting domain entities are reusable across systems
5.Requirements completeness and consistency
In principle, requirements should be both complete and consistent.
Complete
They should include descriptions of all facilities required.
Consistent
There should be no conflicts or contradictions in the descriptions of the system facilities.
In practice, it is impossible to produce a complete and consistent requirements document.
6.lab_DesignPatterns_3.pdf
- 
Participants:
Component
declares the interface for objects in the composition.
implements default behavior for the interface common to all classes, as appropriate.
declares an interface for accessing and managing its child components.
(optional) defines an interface for accessing a component.s parent in the recursive
structure, and implements it if that.s appropriate.
Leaf
represents leaf objects in the composirion; a leaf has no children.
defines behavior for primitive objects in the composition.
Composite
defines behavior for components having children.
stores child components.
implements child-related operations in the Component interface.
Client
manipulates objects in the composition through the Component interface.
Aplicability when:
you want to represent part-whole hierarchies of objects.
you want clients to be able to ignore the difference between compositions of objects and
individual objects; clients will treat all objects in the composite structure uniformly.
Applying COMPOSITE design pattern to our example, the class diagram will be:
The constructor of the Client class gets a reference to the top component of the tree structure.
On this component the method print( is called. Being a composite, it will start another iteration
on its components, and print() will be called recursivelly until leaf components are encountered.
On all leaf components the metod print( will actualy print the information about the student
coresponding to the leaf.
In the previous example we have used an internal iterator
The same structure can be traversed using an external iterator obtained by combining the
COMPOSITE design pattern with the ITERATOR design pattern.
An external iterator introduces more flexibility, allowing us to apply filters on the listed components.
|
