Component-Level Design for Traditional Software Component

Component-Level Design for Traditional Software Component

A component is a modular building block for computer software. More formally, the OMG Unified Modeling Language Specification defines a component as “. . . a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.”

A traditional component, also called a module, resides within the software architecture.

Three Roles

(1) a control component that coordinates the invocation of all other problem domain components

(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 functions that support the processing required in the problem domain.

traditional software components are derived from the analysis model.

Control components (modules) reside near the top of the hierarchy, and problem domain components tend to reside toward the bottom of the hierarchy.

A set of data flow diagrams would be derived during requirements modeling. Assume that these are mapped into architecture.

Each box represents a software component. 

Structure chart for a traditional system

The module interface is defined explicitly. That is, each data or control object that flows across the interface is represented.

The data structures that are used internal to the module are defined. The algorithm that allows the module to accomplish its intended function is designed using the step wise refinement approach.

The behavior of the module is sometimes represented using a state diagram.

consider the module ComputePageCost. The intent of this module is to compute the printing cost per page based on specifications provided by the customer. Data required to perform this function are: number of pages in the document, total number of documents to be produced, one- or two-side printing, color requirements, and size requirements.

These data are passed to ComputePageCost via the module’s interface.

Architectural Style and categories of architectural styles

Architectural Style and categories of architectural styles

• The software that is built for computer-based systems also exhibits one of many architectural styles.
• Each style describes a system category that encompasses (1) a set of components that perform a function required by a system; (2) a set of connectors that enable “communication, coordination and cooperation” among components; (3) constraints that define how components can be integrated to form the system; and (4) semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts.
• An architectural style is a transformation that is imposed on the design of an entire system.
• The intent is to establish a structure for all components of the system.

the imposition of an architectural style will result in fundamental changes to the structure of the software including a reassignment of the functionality of components.

Categories of Architectural style

·         Data-centered architectures.

o    A data store resides at the center of this architecture and is accessed frequently by other components that update, add, delete, or otherwise modify data within the store.

o    client software accesses the data independent of any changes to the data or the actions of other client software.

o    A variation on this approach transforms the repository into a “blackboard” that sends notifications to client software when data of interest to the client changes.

Data-centered architectures promote integrability.That is, existing components can be changed and new client components added to the architecture without concern about other clients.

·         Data-flow architectures.

o    This architecture is applied when input data are to be transformed through a series of computational or manipulative components into output data.

o    A pipe-and-filter pattern has a set of components, called filters, connected by pipes that transmit data from one component to the next.

o    Each filter works independently of those components upstream and downstream, is designed to expect data input of a certain form, and produces data output of a specified form.

If the data flow degenerates into a single line of transforms, it is termed batch sequential.

·         Call and return architectures

o   This architectural style enables you to achieve a program structure that is relatively easy to modify and scale.

§  Main program/subprogram architectures.

·         This classic program structure decomposes function into a control hierarchy where a “main” program invokes a number of program components that in turn may invoke still other components.

·         Object-oriented architectures.

o   The components of a system encapsulate data and the operations that must be applied to manipulate the data.

o   Communication and coordination between components are accomplished via message passing.

·         Layered architectures.

o   A number of different layers are defined, each accomplishing operations that progressively become closer to the machine instruction set.

o   At the outer layer, components service user interface operations.

o   At the inner layer, components perform operating system interfacing.

o   Intermediate layers provide utility services and application software functions.

Quality function deployment

Quality function deployment

• Quality function deployment (QFD) is a quality management technique that translates the needs of the customer into technical requirements for software. 
• concentrates on maximizing customer satisfaction from the software engineering process. 
• an understanding of what is valuable to the customer and then deploys these values throughout the engineering process. 
• Three types of functions:

o   Normal requirements.

§  The objectives and goals that are stated for a product or system during meetings with the customer. If these requirements are present, the customer is satisfied.

§  graphical displays, specific system functions, and defined levels of performance are examples.

o   Expected requirements.

§  These requirements are implicit to the product or system and may be so fundamental that the customer does not explicitly state them. Their absence will be a cause for significant dissatisfaction.

§  ease of human/machine interaction, overall operational correctness and reliability, and ease of software installation are examples.

o   Exciting requirements.

§  These features go beyond the customer’s expectations and prove to be very satisfying when present.

§  For example, software for a new mobile phone comes with standard features, but is coupled with a set of unexpected capabilities (e.g., multitouch screen, visual voice mail) that delight every user of the product.

• QFD uses customer interviews and observation, surveys, and examination of historical data (e.g., problem reports) as raw data for the requirements gathering activity. 
• These data are then translated into a table of requirements called the customer voice table.that is reviewed with the customer and other stakeholders. A variety of diagrams, matrices, and evaluation methods are then used to extract expected requirements and to attempt to derive exciting requirements.

Requirements Engineering and Seven distinct tasks

Requirements Engineering and Seven distinct tasks

• The broad spectrum of tasks and techniques that lead to an understanding of requirements is called requirements engineering. 
• From a software process perspective, requirements engineering is a major software engineering action that begins during the communication activity and continues into the modeling activity. 
• It must be adapted to the needs of the process, the project, the product, and the people doing the work. 
• Requirements engineering builds a bridge to design and construction. 
• Requirements engineering provides the appropriate mechanism for understanding what the customer wants, analyzing need, ssessing feasibility, negotiating a reasonable solution, specifying the solution unambiguously, validating the specification, and managing the requirements as they are transformed into an operational system. 
• Seven distinct tasks 
• inception, 
• elicitation, 
• elaboration, 
• negotiation, 
• specification, 
• validation, and 
• management.
• Some tasks occurs in parallel.

The Spiral Model

The Spiral Model

• Proposed by Barry Boehm.
• Spiral model is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model.
• It provides the potential for rapid development of increasingly more complete versions of the software
• A risk-driven process model generator that is used to guide multi-stakeholder concurrent engineering of software intensive systems.
• Two Fetures of spiral model.
• 1.Cyclic
• Incrementally growing a system's degree of definition and implementation while decreasing its degree of risk.
• 2.Anchor Point Milestones
• Assure that stakeholder commitment to feasible and mutually satisfactory system solutions.
• divided into a set of framework activities defined by the software engineering team.
• evolutionary process begins, the software team performs activities that are implied by a circuit around the spiral in a clockwise direction, beginning at the center.
• Risk is considered as each revolution.
• A combination of work products and conditions that are attained along the path of the spiral—are noted for each evolutionary pass.
• Each pass results in adjustments to the project plan.Cost and schedule are adjusted based on feedback derived from the customer.
• The spiral model is a realistic approach to the development of large-scale systems and software.
• The spiral model is not a solution.
• Difficult to convince customers that the evolutionary approach is controllable.
• If a major risk is not uncovered and managed, problems will undoubtedly occur.