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.

How to design conventional components - Graphical Design Notation and Tabular Design Notation

There were some logical constructs developed from which any program could be formed. Each construct has a logical structure. The constructs are sequence, condition, and repetition.
- Sequence implements processing the steps that are essential in the specification of any algorithm.
- Condition provides the facility for selected processing based on some logical occurrence.
- Repetition allows for looping.
Structured programming is a design technique that constrains logic flow to three constructs: sequence, condition and repetition. The structured constructs were supposed to limit the procedural design of software to a small number of predictable operations.

GRAPHICAL DESIGN NOTATION
Activity diagram allows a designer to represent sequence,condition and repetition. Flowchart, like an activity diagram, is quite simple pictorially.
The dogmatic use of only structured constructs can introduce inefficiency when an escape from a set of nested loops or nested conditions is required. Additional complication of all logical tests along the path of escape can hinder the control flow, increase the possibility of error and have a negative impact.
There are two options:
- procedural representation is redesigned so that escape branch is not required at a nested location.
- structured constructs are violated in a controlled manner; that is , a constrained branch out of the nested flow is redesigned.

TABULAR DESIGN NOTATION
Decision tables translates actions and conditions in a tabular form. It is difficult to misinterpret. A decision table is divided into quadrants:
- Upper left quadrant: contains a list of all conditions.
- Lower left quadrant: contains a list of all actions that are possible based on combinations of conditions.
- Right hand quadrant: a matrix that indicates condition combinations and corresponding actions. Each column of matrix may be interpreted as a processing rule.

-

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.

Performing User Interface Design - Design Evaluation

Design should be evaluated to check whether it meets the user needs or not once an operational user interface prototype has been created. Evaluation spans a formality spectrum that ranges from an informal test drive in which a user provides an impromptu feedback to a formally designed study.

- After design model has been completed, a first level prototype is created.
- Prototype is evaluated by user.
- User provides designer with direct comments about the efficacy of interface.
- Evaluation cycle continues until no further modifications to interface design are necessary.
- Once first prototype is built, designer collects a variety of qualitative and quantitative data that will assist in evaluating the interface.
- Qualitative data includes questionnaires like simple yes/no, numeric response, scaled response, likert scales, percentage response or open ended.
- Quantitative data can be got by a form of time study analysis can be conducted.

The evaluation criterion applied during early design reviews are:
- length and complexity of written specification of the system.
- number of user tasks specified and average number of actions per task.
- number of actions, tasks, and system states indicated by the design model imply memory load.
- interface styles, help facilities, and error handling protocol provides an indication of interface complexity.

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.