Component based development | what, why and how
Download as PPTX, PDF0 likes296 views
The document outlines the principles and advantages of component-based development (CBD), emphasizing the creation of modular, reusable components that encapsulate specific functionalities while maintaining independence and clear interfaces. It details a structured approach to coding, emphasizing the importance of requirement clarity, scenario identification, and follow-up steps to ensure effective component design and development. The document also compares components to traditional methods, highlighting cost reduction, ease of maintenance, and improved reliability as key benefits of CBD.
Component based development | what, why and how
- 2. What we are looking? • Standarised • Independent • Compassable • Deployable • Documented Components needed in – qualified -> Adapted ->Assembled -> Updated
- 3. What is Component Based Development (CBD)? • A component is a modular, portable, replaceable, and reusable set of well-defined functionality that encapsulates its implementation and exporting it as a higher-level interface • Component-based architecture focuses on the decomposition of the design into individual, functional or logical components • With well-defined communication interfaces containing methods, events, and properties. • It provides a higher level of abstraction and divides the problem into sub-problems • Primary objective of component-based architecture is to ensure component reusability
- 4. What is a Component? • It is a modular, portable, replaceable, and reusable set of well-defined functionality that encapsulates its implementation Characteristics : • Reusability − • Components are usually designed to be reused in different situations in different applications • some components may be designed for a specific task. • Replaceable − • Components may be freely substituted with other similar components. • Not context specific − • Components are designed to operate in different environments and contexts. • Extensible − • A component can be extended from existing components to provide new behavior. • Encapsulated − • A component depicts the interfaces, which allow the caller to use its functionality, and do not expose details of the internal processes or any internal variables or state. • Independent − • Components are designed to have minimal dependencies on other components.
- 5. Principles of Component−Based Design • The software system is decomposed into reusable, cohesive, and encapsulated component units. • Each component has its own interface that specifies required ports and provided ports; each component hides its detailed implementation. • A component should be extended without the need to make internal code or design modifications to the existing parts of the component. • Depend on abstractions component do not depend on other concrete components, which increase difficulty in expendability. • Connectors connected components, specifying and ruling the interaction among components. The interaction type is specified by the interfaces of the components. • Components interaction can take the form of method invocations, asynchronous invocations, broadcasting, message driven interactions, data stream communications, and other protocol specific interactions. • For a server class, specialized interfaces should be created to serve major categories of clients. Only those operations that are relevant to a particular category of clients should be specified in the interface. • A component can extend to other components and still offer its own extension points. It is the concept of plug-in based architecture. This allows a plugin to offer another plugin API.
- 6. Component-Level Design Guidelines • Attains architectural component names from the problem domain and ensures that they have meaning to all stakeholders who view the architectural model. • Extracts the business process entities that can exist independently without any associated dependency on other entities. • Recognizes and discover these independent entities as new components. • Uses infrastructure component names that reflect their implementation-specific meaning. • Models any dependencies from left to right and inheritance from top (base class) to bottom (derived classes). • Model any component dependencies as interfaces rather than representing them as a direct component-to-component dependency.
- 7. Advantages • Ease of deployment − As new compatible versions become available, it is easier to replace existing versions with no impact on the other components or the system as a whole. • Reduced cost − The use of third-party components allows you to spread the cost of development and maintenance. • Ease of development − Components implement well-known interfaces to provide defined functionality, allowing development without impacting other parts of the system. • Reusable − The use of reusable components means that they can be used to spread the development and maintenance cost across several applications or systems. • Modification of technical complexity − A component modifies the complexity through the use of a component container and its services.
- 8. Advantages • Reliability − The overall system reliability increases since the reliability of each individual component enhances the reliability of the whole system via reuse. • System maintenance and evolution − Easy to change and update the implementation without affecting the rest of the system. • Independent − Independency and flexible connectivity of components. Independent development of components by different group in parallel. Productivity for the software development and future software development.
- 9. What to think before code - Coding Standards in CBD • Step 1: Is The Requirement Clear to You? • Understanding of the Requirement clearly. • First step to start with the coding is understanding the requirement clearly. • If Yes, proceed with the second step. • If No, discuss with the Business Head or the Project Manager and after the clear understanding about the requirement proceed with the step 2. • Step 2: All Possible Scenarios. • We must cover all possible scenarios. • First, we should get a clear picture about the customer requirement scenarios and for which purpose the code will be working. • If Yes, means if we have got to know about the scenarios that should be handled in the code then we can proceed to the Step 3. • If No, get the clear understanding about the scenarios by asking with your project manager and then proceed to the step 3.
- 10. Coding Standards in CBD • Step 3: Business Domain. • We should get to know about the business domain on which we are working. Example: Retail, telecom, Hospitals…etc. • Step 4: Possible Negative Scenarios. • We should get rid of the Negative Scenarios by handling it properly. Example: when the user enters the wrong username or password or if the network connection is slow then we should handle that situation. We should discuss with the project manager about what scenarios should be handled. • Step 5: Create Application Flow. • We should plan the flow of the application according to the code. we should also perform the operations accordingly.
- 11. Coding Standards in CBD • Step 6: Doable?? • After the Understanding of the scenarios and the requirements. We should think whether it’s possible to complete the work with our knowledge or not. If yes, you can go to the next Step. if No, request for the training from the Project manager. • Step 7: Development. • After the clear understanding about the project and the scenarios that should be taken care of, you can start with the coding but while coding you should follow some rules and regulations. • Nomenclature: The naming standards for the class, methods, variables they should contain proper name according to the project. • We need to give proper comments for each code in the method.
- 13. Phase in CBD Three phases 1. Discovery 2. Design and 3. Development 4. Governance
- 14. What to do with CBD?
- 15. What to do with CBD • Deals with SoC ( Separation of concern) • reuse-based • loosely coupled independent components • Remove UI inconsistency • Remove duplication of effort • Cost reduction • Faster time to market – GTM • Modular & scalable web site • Ready with COTS
- 16. What to do with CBD? • Common code base • Common vocabulary • "Buy" the component, "don't build" the component
- 17. What Next?
- 18. Need your help