What are different component level design metrics?

Component level design focuses on internal workings of software and include measures: cohesion, coupling, and complexity. It helps in judging the quality of a component level design. Once a procedural design is developed, component level design metrics can be applied. It is possible to compute measures of the functional independence, coupling and cohesion of a component and to use these to assess the quality of design.

The cohesiveness of a module can be described by a set of metrics:
- Data slice which is defined as a backward walk that searches for data values that can affect the state of the module.
- Data tokens are variables defined for a module.
- Glue tokens are set of data tokens on data slice.
- Superglue tokens are data tokens common to every data slice in a module.
- Stickiness of glue token is directly proportional to number of data slices it binds.

Coupling metrics is an indication of connectedness of a module to other modules. The metric for module coupling encompasses data and control flow coupling, global coupling and environmental coupling.

Complexity metrics are used to predict critical information about the reliability and maintainability of software systems from automatic analysis of source code. It also provides feedback during software project to help control the design activity. Cyclomatic complexity is the most widely used complexity metric.

How is data designed at architectural and component level?

Data Design at Architectural Level

Data design translates data objects defined during analysis model into data structures at the software component level and, when necessary,a database architecture at the application level.
There are small and large businesses that contains lot of data. There are dozens of databases that serve many applications comprising of lots of data. The aim is to extract useful information from data environment especially when the information desired is cross functional.
Techniques like data mining is used to extract useful information from raw data. However, data mining becomes difficult because f some factors:
- Existence of multiple databases.
- Different structures.
- Degree of detail contained with databases.Alternative solution is concept of data warehousing which adds an additional layer to data architecture. Data warehouse encompasses all data used by a business. A data warehouse is a large, independent database that serve the set of applications required by a business. Data warehouse is a separate data environment.

Data Design at Component Level

It focuses on representation of data structures that are directly accessed by one or more software components. Set of principles applicable to data design are:
- Systematic analysis principles applied to function and behavior should also be applied to data.
- All data structures and operations to be performed on each should be identified.
- The content of each data object should be defined through a mechanism that should be established.
- Low level data design decisions should be deferred until late in design process.
- A library of data structures and operations that are applied to them should be developed.
- The representation of data structure should only be known to those modules that can directly use the data contained within the structure.
- Software design and programming language should support the specification and realization of abstract data types.

How to design conventional components - Program Design Language and Comparison of Design Notation

Conventional component level design requires the representation of data structures, interfaces, and algorithms for a program module. The designer uses one of a number of design notations that represent component level detail in either graphical, tabular, or text based formats.

PROGRAM DESIGN LANGUAGE
Program design language is also called pseudo code. In this, vocabulary of one language and overall syntax of another language is used. Program design language(PDL) is used as a generic reference for a design language.
The difference between a PDL and a real programming language lies in the use of narrative text embedded directly within PDL statements.
- PDL cannot be complied.
- Tools can translate PDL into a programming language.
- These tools also produce nesting maps, design operation index, cross reference tables and other information.
- PDL may be simple transposition of a language.
- Basic PDL syntax should include constructs for component definition, interface description, data declaration, block structuring, condition and repetition constructs.
- PDL can be extended to include keywords for multitasking, interrupt handling, interprocess synchronization.

COMPARISON OF DESIGN NOTATION
- Design notation leads to procedural representation which is easy to understand and review.
- Design notation should enhance "code to" ability.
- Design representation must be easily maintainable so that design always represents the program correctly.
- PDL offers the best combination of characteristics.
- However, it does not follow that other design notations are inferior.
- Activity diagrams and flowcharts provides a perspective on control flow that many designers prefer.

What are different steps while conducting component level designing?

The following steps represent a typical task set for component level design, when it is applied for an object oriented system. If you are working in a non object oriented environment, the first three steps focus on the refinement of data objects and processing functions identified as part of analysis model.

STEP 1: Identify all design classes that correspond to the problem domain.
STEP 2: Identify all design classes that correspond to the infrastructure domain.
STEP 3: Elaborate all design classes that are not acquired as reusable components.
In addition to all interfaces, attributes, operations, design heuristics i.e cohesion and coupling should be considered during elaboration.
- Specify message details when classes or components collaborate.
Structure of messages that are passed between objects within a system are shown as component level design proceeds.
- Identify appropriate interfaces for each component.
Interface is an abstract class that provides a controlled connection between design classes. So interfaces should be identified appropriately.
- Elaborate attributes and define data types and data structures required to implement them.
The programming language that is to be used in the project typically is a factor in the definition of the data structure and types used to describe attributes. When the component level design process is started, the name of attributes is used; as the design proceeds the UML attribute format is increasingly used.
- Describe processing flow within each operation in detail.
There are two ways to do this; through a UML activity diagram or a programming language based pseudocode. The elaboration of each software component is by doing a number of iterations and in each iteration a step-wise refinement concept is used.
STEP 4: Describe persistent data sources and identify the classes required to manage them.
As the design elaboration proceeds, an additional data should be provided about the structure and organization of these data sources which are initially specified as part of architectural design.
STEP 5: Develop and elaborate behavioral representations for a class or component.
In order to depict the externally observable behavior of the system as well as that of individual analysis classes, UML state diagrams are used. As a part of component level design, modeling the behavior of a design class may be sometimes required. The instantiation of a design class a s program executes is also known as the dynamic behavior of the object. This behavior is impacted by the current state of object as well as external events.
STEP 6: Elaborate deployment diagrams to provide additional implementation detail.
When component level design is being done, in order to make deployment diagrams simple to read and comprehend, the location of components(individual components) are generally not depicted.
STEP 7: Factor every component level design representation and always consider alternatives.
The first component level model that is created will not be consistent, complete and accurate as compared to the nth iteration that is applied to the model. It is necessary to re-factor as design work is conducted.

Designing Class based Components - Component Level Design Guidelines

As component level design proceeds, there are some guidelines other than basic design guidelines. These guidelines are applied to components and their interfaces, their dependencies and inheritance.

COMPONENTS
- Naming conventions should be established for components.
- These are specified as part of architectural model and then refined and elaborated as part of component level design.
- Architectural component names should be drawn from the problem domain.
- It should have meaning to all stakeholders.

INTERFACES
- Provides information about communication and collaboration.
- Lollipop approach to represent interface should be used in combination with UML box and dashed arrow.
- Interface should flow from left side of the component box for consistency.
- Only relevant interfaces to component should be shown.

DEPENDENCIES AND INHERITANCE
- Model dependencies from left to right.
- Model inheritance from bottom to top.
- Component interdependencies should be represented via interfaces.

Component Level Design - Designing Class based Components - Basic Design Principles

Component level design in object oriented approach focuses on elaboration of analysis classes and the definition and refinement of infrastructure classes.

BASIC DESIGN PRINCIPLES

There are four basic design principles that are adopted to component level design.
Open-Closed Principle
A component or module should be open for extension and closed for modification. It means that the component should be allowed to extend without the need to make any internal changes. Abstractions are created that serve as a buffer between functionality that is expected to be extended and the design class itself.

Liskov Substitution Principle(LSP)

This principle suggests that 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. When a derived class is created, it also conforms to the pre- and post- conditions.

Dependency Inversion Principle(DIP)

This principle depends on abstractions. It does not depend on concretions. The more a component depends on other concrete components, the more difficult it will be to extend.

Interface Segregation Principle(ISP)

This principle suggests that a specialized interface should be designed to serve each major category of clients. Operations relevant to that category of clients should be described in interface. If multiple clients require same operations, they should be specified in each of the specialized interfaces.

Release Reuse Equivalence Principle(REP)

This principle suggests that when classes and components are designed for reuse, an implicit contract is established between the developer and the people who are using it. Older versions of entity are maintained by the developer who establishes a release control system.

Common Closure Principle(CCP)

This principle suggests that classes should address the same functional or behavioral area when they are packaged as part of a design.

Common Reuse Principle(CRP)

This principle suggests that release number of the package changes when one or more classes with a package changes. All other classes or packages that rely on the package that has been changed must now update to the most recent release of the package and be tested to ensure that new release operates without incident.

Component Level Design - Designing Class based Components - Coupling

The complexity of the system increases as the amount of collaboration and communication increases. As the complexity increases, difficulty in implementing, testing, and maintaining software also increases.

Coupling is a qualitative measure of the degree to which classes are connected to each other. Coupling increases as the classes become more dependent on each other. The main objective of component level design is to minimize coupling as much as possible.

As the design for each software component is elaborated, the focus shifts to the design of specific data structures and procedural designs to manipulate the data structures. There are different categories of coupling :

- Content Coupling
Content coupling is when one module modifies or relies on the internal workings of another module. This violates the basic design concept i.e. information hiding.
- Common Coupling
In common coupling, two modules share the same global data. It can lead to uncontrolled error propagation and side effects.
- Control Coupling
In Control coupling, one module controls the flow of other module. The problem is that an unrelated change in second module can result in the change of the meaning of control flag.
- External Coupling
Two modules share an external data format. A component communicates or collaborates with infrastructure components. It is necessary but should be limited to small number of components or classes.
- Data Coupling
Data coupling is when modules share data through. The bandwidth of communication grows and the complexity also increases.
- Stamp Coupling
In this type of coupling, modules share a composite data structure. It occurs when class B is declared as an argument of an operation of class A and therefore the system becomes more complex.
- Routine Call Coupling
It occurs when one operation invokes another. This type of coupling is quite necessary but it does increase the interconnectedness of a system.
- Type Use Coupling
It occurs when component A uses a data type in component B. If the type definition changes, every component that uses the definition also changes.
- Inclusion Coupling
In this type of coupling, component A includes or imports a package or content of component B.

Component Level Design - Designing Class based Components - Cohesion

Cohesion in context with component level design refers that a component or class encapsulates only attributes and operations that are closely related to each other and to the class or component itself.

TYPES OF COHESION

Functional
It is exhibited mainly by operations. This type of cohesion occurs when a module performs one and only one computation and then returns a result.
Layer
It is exhibited by packages, components, and classes. This type of cohesion occurs when a higher layer accesses the services of a lower layer, but lower layers do not access higher layers.
Temporal
Operations that are performed to reflect a specific behavior or state.
Procedural
Components and operations are grouped together. It allows one to be invoked immediately after preceding one was invoked. It is done even if there is no data is passed between them.
Communicational
Operation on same data are defined in one class. Classes and components that exhibit functional, layer, and communicational cohesion are easy to implement, test and maintain.
Sequential
Components and operations are grouped in such a manner that the first one provides input to the second one and so on.
Utility
Components, classes, or operations exist in the same category but are otherwise unrelated are grouped together. This type is less used.

Component Level Design - Important Views that describes what a component is?

An Object Oriented View of Component

- From an object oriented viewpoint, a component is a set of collaborating classes.
- Each class within a component consists of attributes and operations relevant.
- Interfaces enabling the classes to communicate with other design classes are defined.
- Designer accomplishes this from analysis model and elaborates analysis classes and infrastructure classes.
- Analysis and design modeling are both iterative actions. Elaborating original analysis class may require additional analysis step which are then followed with design analysis steps to represent elaborated design class.
- Elaboration activity is applied to every component.
- After this, elaboration is applied to each attribute, operation, and interface.
- Data structures are specified.
- Algorithms for implementing each logic is designed.

The Conventional View

- A component is functional element of a program, also called module.
- It incorporates processing logic, internal data structures, interface that enables the component to be invoked and data to be passed to it.
- It resides within software architecture.
- It serves one of the roles control component, problem domain component or an infrastructure component.
- Conventional components are also derived from analysis classes.
- Data flow oriented element of analysis model is the basis for derivation.
- Each module is elaborated.
- Module interface is defined.
- Data structures are defined.
- Algorithm is designed using stepwise refinement approach.
- Design elaboration continues until sufficient detail is provided.

Process Related View

- The above two approaches assume that component is designed from scratch.
- Emphasize is on building systems that make use of existing software.
- As software architecture is developed, components or design patterns are chosen from catalog and used to populate the architecture.

Component Level Design - Definition, why it is important and what are the steps?

When the first iteration of architectural design is completed, component level design comes into picture. Intent of this phase is to translate the design model into operational software. The internal data structures and processing details of each component are not represented at a level of abstraction that is close to code. Component level design defines the data structures, algorithms, interface characteristics, and communication mechanisms allocated to each software component. A software engineer performs component level design.

Component level design is important because it is necessary to determine whether the software will work before you build it. The component level design represents the software in a way that allows you to review the details of the design for correctness and consistency with earlier design representations. It also provides a means for assessing whether data structures, interfaces and algorithms will work.

It is possible to represent component level design using a programming language. Component level design can also be represented by using some intermediate representation that can be translated easily into source code.

Define Component?
A component is a modular building block for computer software. Components should communicate and collaborate with other components as they reside within the software architecture. The meaning of component will differ depending on the point of view of software engineer using it. There are three different views of defining component :
- An Object oriented view
- The Conventional view
- A Process-related view

Steps in Component Level Design
- Design representations of data, architecture, and interfaces form the foundation of component level design.
- Class definition or processing narrative for each component is translated into detailed design that makes use of diagrammatic or text based forms that specify internal data structures, local interface detail, and processing logic.
- The procedural design is specified using a set of structured programming constructs.