Chapter :11 Component-Level Design

1. Chapter :11 Component-Level Design

2. What is Component? A component is a modular building block for computer software. A component is a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces. Because components reside within the software architecture, they must communicate and collaborate with other components and with entities that exist outside the boundaries of the software.

3. An Object-oriented view • In a context of OO software engineering, a component contains a set of collaborating classes. • Each class within a component has been fully elaborated to include all attributes and operations that are relevant to its implementation. • As a part of the design elaboration, all interfaces that enable the classes to communicate and collaborate with other design classes must be defined. • To accomplish this, begin with requirements model and elaborate analysis classes and infrastructure classes.

4. The Traditional View • In the context of traditional software engineering, a component is a functional element of a program that incorporates processing logic, and interface that enables the component to be invoked and data to be passed to it. • It is also called module resides within the s.w architecture and serves one of the three important roles as: (1)A control component that coordinates the invocation of all other problem domain components,

5. (2)A problem domain component that implements a complete or partial function that is required by the customer (3)An infrastructure component that is responsible for the functions that support the processing required in the problem domain. • Traditional components are derived from the analysis model the analysis model. • The data flow oriented element of the analysis model serve as a basis for the derivation.

6. Each transform (bubble) represented at the lowest level of the data flow diagram is mapped into a module hierarchy. • Control components reside near the top of the hierarchy and problem domain components tend to reside toward the bottom of the hierarchy. • To achieve effective modularity, design concepts like functional independence are applied as components are elaborated.

7. The Process Related View • There is a need to build systems that make use of existing software components or design patterns. • A catalog of proven design or code-level component is made available as design work proceeds. • As the software architecture is developed, choose a component design or code level components or design patterns from the catalog and use them to populate the architecture. • A complete description of interface, the function the component perform, and required communication and collaboration are all available.

8. Designing Class-Based Components Basic Design Principles Four basic design principles are applicable to component level design and have been adopted when object-oriented software engineering is applied. • The Open-Closed Principle : “A module should be open for extension but closed for modification”. The component should be extended without the need to make internal modifications to the component itself.

9. The Liskov Substitution Principle : “Subclasses should be substitutable for their base classes”. A component that uses a base class should continue to function properly if a class derived from the base class is passed to the component instead. • Dependency Inversion Principle : “Depend on abstractions. Do not depend on constructions.” Abstractions are the place where a design can be extended without great complication. The more a components depends on the concrete components, the more difficult it will be to extend.

10. The Interface Segregation Principle : “Many client-specific interfaces are better than one general purpose interface.” Multiple clients components use the operations provided by a server class. We should create a specialized interface to serve each major category of clients. Packaging Principles • The Release Reuse Equivalency Principle : “The granule of reuse is the granule of release.” It is advisable to group reusable classes into packages that can be managed and controlled as newer versions evolve.

11. The Common Closure Principle : “Classes that change together belong together.” When classes are packaged as a part of a design, they should address the same functional or behavioral area. • The Common Reuse Principle : “Classes that aren’t reused together should not be grouped together.” If classes are not grouped cohesively, it is possible that a class with no relationship to other classes within a package is changed. So only classes that are reused together should be included within a package.

12. Component-Level Design Guidelines A set of pragmatic design guidelines can be applied as component-level design proceeds. • Component : Naming conventions should be established for components that are specified as part of the architectural model and then refined and elaborated as a part of the component-level model. Use stereotypes to help identify the nature of components at a detailed design level.

13. 2) Interfaces : Interfaces should flow from the left-hand side of component box. Only those interfaces that are relevant to the component under consideration should be shown. 3) Dependencies and Inheritance : Dependencies should be modeled from left to right and inheritance should be modeled from bottom to top.

14. Cohesion • In a context of component-level design for OO system, cohesion implies that a component or class encapsulates only attributes and operations that are closely related to one another and to the class or component itself. • A number of different types of cohesion • Functional : Exhibited by operations, this level of cohesion occurs when a component performs a targeted computation and then returns a result. • Layer : Exhibited by packages, components, and classes, this type of cohesion occurs when higher layer accesses

15. Cohesion • In a context of component-level design for OO system, cohesion implies that a component or class encapsulates only attributes and operations that are closely related to one another and to the class or component itself. • A number of different types of cohesion • Functional : Exhibited by operations, this level of cohesion occurs when a component performs a targeted computation and then returns a result. • Layer : Exhibited by packages, components, and classes, this type of cohesion occurs when higher layer accesses the service of a lower layer,

16. but lower layer do not access higher layers . 3) Communicational : All operations that access the same data are defined within one class. • Classes and components that exhibit functional, layer and communicational cohesion are relatively easy to implement, test and maintain.

17. Coupling • Coupling is a qualitative measure of the degree to which classes are connected to one another. • Coupling categories : • Content coupling : Occurs when one component modifies data that is internal to another component. • Common coupling : Occurs when a number of components all make use of a global variable. • Control coupling : Occurs when operation A() invokes operation B() and passes control flag to B.

18. 4) Stamp coupling : Occurs when class B is declared as a type for an argument of an operation of class A. 5) Data coupling : Occurs when operations pass long strings of data arguments. 6) Routine call coupling : Occurs when one operation invokes another. 7) Type use coupling : Occurs when component A uses a data type defined in component B. 8) Inclusion or import coupling : Occurs when component A imports or includes a package or content of component B. 9)External coupling : Occurs when a component communicates or collaborates with infrastructure components.

19. Conducting Component Level Design The following steps represent a typical task set for component-level design, when it is applied for OO system. • Identify all design classes that correspond to the problem domain : Using the requirements and architectural model, each analysis class and architectural component is elaborated. 2) Identify all design classes that correspond to the infrastructure domain : Classes and components in this category include GUI components, OS components, and object and data management components.

20. 3)Elaborate all design classes that are not acquired as reusable components. a.) Specify message details when classes or components collaborate: It is sometimes useful to show the details of these collaboration by specifying the structure of the messages that are passed between objects. b.) Identify appropriate interfaces for each component. c.) Elaborate attributes and define data types and data structures required to implement them. d.) Describe processing flow within each operation in detail.

21. 4)Describe and elaborate behavioral representation for class or component : Databases and files normally transcend the design description of individual components. 5) Develop and elaborate behavioral representation for a class or a component : The transition between states are represented using statechart. 6)Elaborate deployment diagrams to provide additional implementation detail. 7) Refactor every component-level design representation and always considers alternatives.

22. Component Level Design For WebApps Content Design At The Component Level • Content design at component level focuses on content objects and the manner in which they may be packaged for presentation to a WebApp end user. • The formality of content design at component level should be tuned to the characteristics of the WebApp to be built.

23. Functional Design At The Component Lev • WebApp functionality is delivered as a series of components developed in parallel with the information architecture to ensure that they are consistent. • During architectural design, WebApp content and functionality are combined to create a functional architecture, • A functional architecture is a representation of the functional domain of the WebApp and describes the key functional components in WebApp and how these components interact with each other.

24. Designing Traditional Component Graphical Design Notation • Activity diagram or the flowchart provides useful pictorial patterns that depict procedural detail. • The activity diagram allows to represent sequence, condition, and repetition. • Flow chart: • Box: used to indicate processing step. • Diamond: represents logical condition • Arrow: shows flow of control. • Flow chart constructs: (figure 10.10)

25. Tabular Design Notation • In many software application, a module may be required to evaluate a complex combination of conditions and select appropriate actions based on these conditions. • Decision table provides a notation that translates actions and conditions into tabular form. • It is made of four sections: (1)Condition statements (2) Condition entries (3) Action statements (4) Action entries

26. General Form of Decision Table Condition Decision rules Condition statements Condition entries Action statements Action entries • Example

27. Program Design Language • PDL is also called Structured English or pseudo code. • The difference between PDL and real programming language lies in the use of narrative text(e.g English) embedded directly within PDL statements. • Basic PDL syntax should include constructs for component definition, interface desc., data declaration, condition and repetition constructs, I/O constructs etc. • Example

28. Component Based Development • Component-based software engineering is a process that emphasizes the design and construction of computer-based systems using reusable software components. Domain Engineering • The intent of domain engineering is to identify, construct, catalog, and disseminate a set of software components that have applicability to existing and future software in a particular application domain.

29. The steps in the process are defined as : • Define the domain to be investigated. • Categorize the items extracted from the domain. • Collect a representative sample of applications in the domain. • Analyze each application in sample and define analysis classes. • Develop a requirements model for the classes.

30. Component Qualification, Adaptation, and Composition Component Qualification • Component qualification ensures that a candidate component will perform the function required, will properly fit into architectural style, and will exhibit the quality characteristics that are required for the application. • In addition to interface description, many other factors considered during component qualification are: API, Development and integration tools, Exception handling etc.

31. Component Adaptation • In reality, even after a component has been qualified for use within an application architecture, conflicts may occur in one or more of the areas. • To avoid these conflicts, an adaptation technique called Component Wrapping is used. • When a software team has a full access to the internal design and code for a component white-box wrapping is applied. • Gray-box wrapping is applied when component library

32. provides a component extension language or API that enables conflicts to be removed or masked. • Black-box wrapping requires the introduction of pre- and post processing at the component interface to remove or mask conflicts.

33. Component Composition • The component composition task assembles qualified, adapted, and engineered components to populate the architecture established for an application. • To accomplish this, an infrastructure must be established to bind the components into an operational system. • The infrastructure provides a model for the coordination of components and specific services that enable components to coordinate with one another and perform common tasks.

34. Standard for component software 1)OMG/CORBA : An object request broker (ORB) provides a variety of services that enable reusable components to communicate with other components. 2)Microsoft COM and .NET : Microsoft has developed a component object model (COM) that provides a specification for using components produced by various vendors within a single application running under the Windows OS. The .NET framework encompasses COM and provides a reusable class library that covers a wide array of application domains. 3)Sun JavaBeans Components : The JavaBeans

35. component system encompasses a set of tools, called Bean Development Kit (BDK), that allows developers to (i) analyze how existing beans work, (ii) customize their behavior and appearance, (iii) establish mechanism for coordination and communication, (iv) develop custom beans for use in a specific application and (5) test and evaluate Bean behavior.

36. Analysis And Design For Reuse • Although CBSE process encourages the use of existing components, there are times when new components must be developed and integrated with existing COTS and in-house components. • New components should be engineered for reuse. • Design concepts such as abstraction, hiding, functional independence all contribute to the creation of software components that are reusable. • Key issues that form a basis for design for reuse:

37. Standard Data : The application domain should be investigated and standard global data structures should be identified. All design components can be characterized to make use of these standard data structure. • Standard interface protocols : Three levels of interface protocol should be established : the nature of intramodular interfaces, the design of external technical interfaces, and human-computer interface. • Program templates : An architectural style is chosen and can serve as a template for architectural design of a new software.

38. Classifying and Retrieving Components • Tens of thousands of reusable software components reside in component repository. But how to find out the one that is needed? • A reusable component can be described using 3C model – concept, content and context. • The concept is a description of what the component does. • The content is information that is hidden from casual users and need be known only to those who intend to modify or test the component.

39. The context places the reusable software component within its domain of applicability. • Classification enables you to find and retrieve candidate reusable components but reusable environment must exist. • Characteristics of reusable environment are : • A component database capable of storing software components and the classification information necessary to retrieve them. • A library management system that provides access to the database.

40. 3) A software component retrieval system that enables a client application to retrieve components and services from the library server. 4) CBSE tools that support the integration of reused components into a new design or implementation. The reuse library is one element of a larger software repository and provides facilities for the storage of software components and a wide variety of reusable work products (e.g. designs, patterns, frameworks). The library encompasses a database and the tools that are necessary to query the database and retrieve components from it.