Conducting Component Level Design

Conducting Component Level Design

• Introduction
• Component-level design is elaborative in nature.
• It transforms information from requirements and architectural models into a design representation that provides sufficient detail to guide the construction (coding and testing) activity. 
• The following steps represent a typical task set for component-level design, when it is applied for an object-oriented system. 
•  Step 1. Identify all design classes that correspond to the problem domain.
• Using the requirements and architectural model, each analysis class and architectural component is elaborated… 
• Step 2. Identify all design classes that correspond to the infrastructure domain. 
• These classes are not described in the requirements model and are often missing from the architecture model, but they must be described at this point. 
• Classes and components in this category include
• GUI components (often available as reusable components), 
• Operating system components, 
• Object and data management components
• Step 3. Elaborate all design classes that are not acquired (Obtain) as reusable components.
• Elaboration requires that all interfaces, attributes, and operations necessary to implement the class be described in detail. 
• Design heuristics (e.g., component cohesion and coupling).
• Step 3 (a) . Specify message details when classes or components collaborate. 
• The requirements model makes use of a collaboration diagram to show how analysis classes collaborate with one another. 
• Step 3 (b). Identify appropriate interfaces for each component.
• Within the context of component-level design, a UML interface is “a group of externally visible (i.e., public) operations.
• The interface contains no internal structure, it has no attributes, no associations . . .
• Step 3 (c). Elaborate attributes and define data types and data structures required to implement them.
• In general, data structures and types used to define attributes are defined within the context of the programming language that is to be used for implementation. 
• UML defines an attribute’s data type using the following syntax: 
• name : type-expression initial-value {property string} 
• where name is the attribute name, type expression is the data type, initial value is the value that the attribute takes when an object is created, and property-string defines a property or characteristic of the attribute. 
• Step 3 (d). Describe processing flow within each operation in detail.
• This may be accomplished using a programming language-based pseudocode or with a UML activity diagram. 
• Each software component is elaborated through a number of iterations that apply the stepwise refinement concept .
• Step 4. Describe persistent data sources (databases and files) and identify the classes required to manage them.
• Databases and files normally transcend the design description of an individual component. In most cases, these persistent data stores are initially specified as part of architectural design. 
• Step 5. Develop and elaborate behavioral representations for a class or component. 
• UML state diagrams were used as part of the requirements model to represent the externally observable behavior of the system. 
• Step 6. Elaborate deployment diagrams to provide additional implementation detail. Deployment diagrams are used as part of architectural. 
• Step 7. Refactor every component-level design representation and always consider alternatives.

Component-Level Design Guidelines | Cohesion | Coupling

Component-Level Design Guidelines

• Introduction : 
• In addition to the principles , a set of pragmatic (Practical) design guidelines can be applied as component-level design proceeds. 
• These guidelines apply to 
• Components, 
• Interfaces 
• Dependencies and inheritance 
• Components 
• Naming conventions should be established for components that are specified as part of the architectural model and then refined and elaborated as part of the component-level model
• Interfaces 
• Interfaces provide important information about communication and collaboration.
• Dependencies and Inheritance 
• it is a good idea to model dependencies from left to right and inheritance from bottom (derived classes) to top (base classes).

Cohesion

• Introduction : As per context of component-level design for 
• Conventional view:
• the “single-mindedness” of a module
• OO view (Object Oriented View):
• 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
• Levels of cohesion OR different types of cohesion
• Functional
• Layer
• Communicational

(1) Functional

• Exhibited primarily by operations, this level of cohesion occurs when a component performs a targeted computation and then returns a result.

(2) Layer

• 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.
• For example, the SafeHome security function requirement to make an outgoing phone call if an alarm is sensed. It might be possible to define a set of layered packages as shown in Figure.

(3) Communicational

• All operations that access the same data are defined within one class. In general, such classes focus only on the data for accessing and storing it.
• Classes and components that exhibit functional, layer, and communicational cohesion are relatively easy to implement, test, and maintain.
• It is important to note, however, that pragmatic (Practical) design and implementation issues sometimes force you to opt for lower levels of cohesion.

Coupling

• As per 
• Conventional view coupling is : 
• The degree to which a component is connected to other components and to the external world 
• OO view coupling is :
• A qualitative measure of the degree to which classes are connected to one another 
• As classes (and components) become more interdependent, coupling increases. An important objective in component-level design is to keep coupling as low as is possible. 
• Coupling categories  OR Level of coupling 
• Content Coupling 
• Common coupling 
• Control coupling 
• Stamp coupling 
• Data coupling 
• Routine call coupling 
• Type use coupling 
• Inclusion or import coupling 
• External coupling
• Content Coupling 
• It occurs when one component “secretly modifies data that is internal to another component” 
• This violates information hiding—a basic design concept.
• Common coupling 
• It Occurs when a number of components all make use of a global variable. 
• Although this is sometimes necessary (e.g., for establishing default values that are applicable throughout an application)
• Control coupling 
• It Occurs when operation A() invokes operation B() and passes a control flag to B. The control flag then “directs” logical flow within B. 
• Stamp coupling
• It Occurs when ClassB is declared as a type for an argument of an operation of ClassA. Because ClassB is now a part of the definition of ClassA, modifying the system becomes more complex.
• Data coupling
• It Occurs when operations pass long strings of data arguments.
• The “bandwidth” of communication between classes and components grows and the complexity of the interface increases. 
• Testing and maintenance are more difficult. 
• Routine call coupling 
• It Occurs when one operation invokes another.
• This level of coupling is common and is often quite necessary. 
• However, it does increase the connectedness of a system.
• Type use coupling 
• It Occurs, when component A uses a data type defined in component B (e.g., this occurs whenever “a class declares an instance variable or a local variable as having another class for its type”.
• If the type definition changes, every component that uses the definition must also change.
• Inclusion or import coupling
• It  Occurs when component A imports or includes a package or the content of component B. 
• External coupling 
• It Occurs when a component communicates or collaborates with infrastructure components (e.g., operating system functions, database capability, telecommunication functions).
• Although this type of coupling is necessary, it should be limited to a small number of components or classes within a system.

Designing Class base Components | Basic Design Principles applicable to component level design | The Open-Closed Principle (OCP) | The Liskov Substitution Principle (LSP) | Dependency Inversion Principle (DIP) | The Interface Segregation Principle (ISP) | The Release Reuse Equivalency Principle (REP) | The Common Closure Principle (CCP) | The Common Reuse Principle (CRP)

Designing Class base Components

• Introduction:
• Component-level design 
• Draws on information developed as part of the requirements model 
• Represented as part of the architectural model. 
• When an object-oriented software engineering approach is chosen, component-level design focuses on the elaboration of problem domain specific classes 
• The definition and refinement of infrastructure classes contained in the requirements model. The detailed description of the attributes, operations, and interfaces used by these classes is the design detail.

Basic Design Principles applicable to component level design

• Introduction : Four basic design principles are applicable to component-level design and have been widely adopted when object-oriented software engineering is applied. 
• The Open-Closed Principle (OCP).  “A module [component] should be open for extension but closed for modification.
• The Liskov Substitution Principle (LSP).  “Subclasses should be substitutable for their base classes. 
• Dependency Inversion Principle (DIP). “Depend on abstractions. Do not depend on concretions.” 
• The Interface Segregation (Separation) Principle (ISP). “Many client-specific interfaces are better than one general purpose interface. 
• The Release Reuse Equivalency Principle (REP). “The granule of reuse is the granule of release.” 
• The Common Closure Principle (CCP). “Classes that change together belong together.” 
• The Common Reuse Principle (CRP). “Classes that aren’t reused together should not be grouped together.”

The Open-Closed Principle (OCP)

• Design should specify the component in a way that allows it to be extended (within the functional domain that it addresses) without the need to make internal (code or logic-level) modifications to the component itself. 
• To accomplish this, you create abstractions that serve as a buffer between the functionality that is likely to be extended and the design class itself.
• For example : assume that the SafeHome security function makes use of a Detector class that must check the status of each type of security sensor. It is likely that as time passes, the number and types of security sensors will grow. 
• If internal processing logic is implemented as a sequence of if-then-else constructs, each addressing a different sensor type, the addition of a new sensor type will require additional internal processing logic (still another if-then-else). This is a violation of OCP. 
• One way to accomplish OCP for the Detector class is illustrated in Figure 1. The sensor interface presents a consistent view of sensors to the detector component. If a new type of sensor is added no change is required for the Detector class (component). The OCP is preserved

The Liskov Substitution Principle (LSP)

• Subclasses should be substitutable for their base classes”.
• It 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.
• LSP demands that any class derived from a base class must honor any implied contract between the base class and the components that use it
• In the context of this discussion, a “contract” is a precondition that must be true before the component uses a base class and a postcondition that should be true after the component uses a base class. 
• When you create derived classes, be sure they conform to the pre and postconditions.

Dependency Inversion Principle (DIP)

• Depend on abstractions. Do not depend on concretions”.
• Here abstractions are the place where a design can be extended without great complication. 
• The more a component depends on other concrete components (rather than on abstractions such as an interface), the more difficult it will be to extend.

The Interface Segregation Principle (ISP)

• Many client-specific interfaces are better than one general purpose interface”.
• There are many instances in which multiple client components use the operations provided by a server class. 
• ISP suggests that, you should create a specialized interface to serve each major category of clients. Only those operations that are relevant to a particular category of clients should be specified in the interface for that client. 
• If multiple clients require the same operations, it should be specified in each of the specialized interfaces.

The Release Reuse Equivalency Principle (REP)

• “The granule of reuse is the granule of release”.
• When classes or components are designed for reuse, there is an implicit contract that is established between the developer of the reusable entity and the people who will use it. 
• The developer commits to establish a release control system that supports and maintains older versions of the entity while the users slowly upgrade to the most current version. 
• Rather than addressing each class individually, it is often advisable to group reusable classes into packages that can be managed and controlled as newer versions evolve

The Common Closure Principle (CCP)

• “Classes that change together belong together.” 
• Classes should be packaged cohesively.
• That is, when classes are packaged as part of a design, they should address the same functional or behavioral area. 
• When some characteristic of that area must change, it is likely that only those classes within the package will require modification.

The Common Reuse Principle (CRP)

• Classes that aren’t reused together should not be grouped together”.
• Classes that are reused together should be included within a package.

What is a Component? | An Object-Oriented View | The Traditional View | A Process-Related View

What is a Component?

• A component is a modular building block for computer software. 
• As per OMG Unified Modeling Language Specification defines 
• A component is a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces. 
• The true meaning of the term component will differ depending on the point of view of the software engineer who uses it. Based on that, 

Three different views of Components

• Three important views of what a component is and how it is used as design modeling proceeds. 
• (1) An Object-Oriented View
• (2) The Traditional View 
• (3) A Process-Related View

(1) An Object-Oriented View

• In the context of object-oriented 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 part of the design elaboration, all interfaces that enable the classes to communicate and collaborate with other design classes must also be defined.
• To accomplish this, you begin with the requirements model and elaborate analysis classes (for components that relate to the problem domain)

Explanation of Figure : 

• To illustrate this process of design elaboration, consider software to be built for a sophisticated print shop. 
• The overall objective of the software is to collect the customer’s requirements at the front counter, cost a print job, and then pass the job on to an automated production facility. 
• During requirements engineering, an analysis class called PrintJob was derived. The attributes and operations defined during analysis are noted at the top of Figure. 
• During architectural design, PrintJob is defined as a component within the software architecture and is represented using the shorthand UML notation shown in the middle right of the figure.
• Note that PrintJob has two interfaces, computeJob, which provides job costing capability, and initiateJob, which passes the job along to the production facility. These are represented using the “lollipop” symbols shown to the left of the component box. 
• Component-level design begins at this point. The details of the component PrintJob must be elaborated to provide sufficient information to guide implementation. The original analysis class is elaborated to flesh out all attributes and operations required to implement the class as the component PrintJob.

(2) The Traditional View

• In the context of traditional software engineering, a component is a functional element of a program that incorporates 
• Processing logic, 
• The internal data structures that are required to implement the processing logic, 
• An interface that enables the component to be invoked and data to be passed to it. 
• A traditional component, also called a module, resides within the software architecture and serves one of three important 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.

(3) A Process-Related View

• Assume that the component is being designed from scratch or used an existing components for new development. 
• That is, you have to create a new component based on specifications derived from the requirements model. 
• There is, of course, another approach. 
• The software engineering community has emphasized the need to build systems that make use of existing software components or design patterns. 
• In essence, a catalog of proven design or code-level components is made available to you as design work proceeds. 
• As the software architecture is developed, you choose components or design patterns from the catalog and use them to populate the architecture. 
• Because these components have been created with reusability in mind, a complete description of their interface, the function(s) they perform, and the communication and collaboration they require are all available to you.

Architectural Mapping Using Data Flow | Transform Mapping

Architectural Mapping Using Data Flow

• A mapping technique, called structured design, is often characterized as a data flow-oriented design method because it provides a convenient transition from a data flow diagram to software architecture. 
• The transition from information flow to program structure is accomplished as part of a six step process: 
• (1) The type of information flow is established, 
• (2) Flow boundaries are indicated,
• (3) The DFD is mapped into the program structure, 
• (4) Control hierarchy is defined, 
• (5) The resultant structure is refined using design measures. 
• (6) The architectural description is refined and elaborated.
• Example of data flow mapping, a step-by-step “transform” mapping for a small part of the SafeHome security function. 
• In order to perform the mapping,
• The type of information flow must be determined. It is called transform flow and exhibits a linear quality. 
• Data flows into the system along an incoming flow path where it is transformed from an external world representation into internalized form. Once it has been internalized, it is processed at a transform center. 
• Finally, it flows out of the system along an outgoing flow path that transforms the data into external world form.

 Transform Mapping

• Transform mapping is a set of design steps that allows a DFD with transform flow characteristics to be mapped into a specific architectural style. 
• To illustrate this approach, we again consider the SafeHome security function. 
• To map these data flow diagrams into a software architecture, you would initiate the following design steps: 
• Step 1. Review the fundamental system model.
• Step 2. Review and refine data flow diagrams for the software. 
• Step 3. Determine whether the DFD has transform or transaction flow characteristics. 
• Step 4. Isolate the transform center by specifying incoming and outgoing flow boundaries. 
• Step 5. Perform “first-level factoring.”
• Step 6. Perform “second-level factoring.” 
• Step 7. Refine the first-iteration architecture using design heuristic for improved software quality. 

Assessing Alternative Architectural Design | An Architecture Trade-Off Analysis Method | Architectural Complexity | Architectural Description Language | An Architectural Design Method | Deriving Program Architecture

Assessing Alternative Architectural Design

• Design results in a number of architectural alternatives that are each assessed to determine which is the most appropriate for the problem to be solved. 
• Two different approaches for the assessment of alternative architectural designs. 
• (1) The first method uses an iterative method to assess design trade-offs.
• (2)The second approach applies a pseudo-quantitative technique for assessing design quality.

An Architecture Trade-Off Analysis Method

• The Software Engineering Institute (SEI) has developed an architecture trade-off analysis method (ATAM) that establishes an iterative evaluation process for software architectures. 
• The design analysis activities that follow are performed iteratively. 
• 1. Collect scenarios : A set of use cases is developed to represent the system from the user’s point of view. 
• 2. Elicit (Bring out) requirements, constraints, and environment description. This information is determined as part of requirements engineering and is used to be certain that all stakeholder concerns have been addressed. 
• 3. Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements. 
• The architectural style(s) should be described using one of the following architectural views… 
• Module view for analysis of work assignments with components and the degree to which information hiding has been achieved. 
• Process view for analysis of system performance. 
• Data flow view for analysis of the degree to which the architecture meets functional requirements.
• 4. Evaluate quality attributes : Quality attributes for architectural design assessment include reliability, performance, security, maintainability, flexibility, testability, portability, reusability, and interoperability. 
• 5.Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style. This can be accomplished by making small changes in the architecture and determining how sensitive a quality attribute, say performance, is to the change. Any attributes that are significantly affected by variationin the architecture are termed sensitivity points.. 
• 6. Critique (Assess) candidate architectures (developed in step 3) using the sensitivity analysis conducted in step 5. 
• The Software Engineering Institute (SEI) describes this approach in the following manner 
• Once the architectural sensitivity points have been determined, finding trade-off points is simply the identification of architectural elements to which multiple attributes are sensitive. For example, the performance of a client-server architecture might be highly sensitive to the number of servers (performance increases, within some range, by increasing the number of servers). . . . The number of servers, then, is a trade-off point with respect to this architecture.

Architectural Complexity

• A useful technique for assessing the overall complexity of a proposed architecture is to consider dependencies between components within the architecture. 
• These dependencies are driven by information/control flow within the system. Zhao suggests three types of dependencies:
• Sharing dependencies represent dependence relationships among consumers who use the same resource or producers who produce for the same consumers. 
• For example, for two components u and v, if u and v refer to the same global data, then there exists a shared dependence relationship between u and v. 
• Flow dependencies represent dependence relationships between producers and consumers of resources 
• Constrained dependencies represent constraints on the relative flow of control among a set of activities. For example, for two components u and v, u and v cannot execute at the same time (mutual exclusion), then there exists a constrained dependence relationship between u and v.

Architectural Description Language

• Introduction:
• The architect of a house has a set of standardized tools and notation that allow the design to be represented in an unambiguous, understandable fashion. 
• The software architect can draw on Unified Modeling Language (UML) notation, other diagrammatic forms, and a few related tools, there is a need for a more formal approach to the specification of an architectural design. 
• Architectural description language (ADL) provides a semantics and syntax for describing a software architecture. 
• Hofmann and his colleagues suggest that 
• An ADL should provide the designer with the ability to decompose architectural components, 
• Compose individual components into larger architectural blocks, 
• Represent interfaces (connection mechanisms) between components. 
• Once descriptive, language based techniques for architectural design have been established, it is more likely that effective assessment methods for architectures will be established as the design evolves.

An Architectural Design Method

Deriving Program Architecture

Architectural Design | Representing the System in Context | Defining Archetypes | Refining the Architecture into Components | Describing Instantiations of the System

Architectural Design

• Introduction : 
• As architectural design begins, the software to be developed must be put into context— 
• That is, the design should define the external entities (other systems, devices, people) that the software interacts with and the nature of the interaction. 
• This information can generally be acquired from the requirements model and all other information gathered during requirements engineering. 
• Once context is modeled and all external software interfaces have been described, you can identify a set of architectural archetypes.
• An archetype is an abstraction (similar to a class) that represents one element of system behavior. 
• The set of archetypes provides a collection of abstractions that must be modeled architecturally if the system is to be constructed, but the archetypes themselves do not provide enough implementation detail. 
• Therefore, the designer specifies the structure of the system by defining and refining software components that implement each archetype. 
• This process continues iteratively until a complete architectural structure has been derived..

Representing the System in Context

• At the architectural design level, a software architect uses an architectural context diagram (ACD) to model the manner in which software interacts with entities external to its boundaries. 
• The generic structure of the architectural context diagram is illustrated in Figure.

• In figure, systems that interoperate with the target system (the system for which an architectural design is to be developed) are represented as
• Super ordinate systems : those systems that use the target system as part of some higher-level processing scheme. 
• Subordinate systems—those systems that are used by the target system and provide data or processing that are necessary to complete target system functionality. 
• Peer-level systems—those systems that interact on a peer-to- peer basis (i.e., information is either produced or consumed by the peers and the target system. 
• Actors—entities (people, devices) that interact with the target system by producing or consuming information. 
• Each of these external entities communicates with the target system through an interface (the small shaded rectangles).

Defining Archetypes

• An archetype is a class or pattern that represents a core abstraction that is critical to the design of an architecture for the target system. 
• In general, a relatively small set of archetypes is required to design even relatively complex systems. 
• Archetypes are the abstract building blocks of an architectural design.
• In many cases, archetypes can be derived by examining the analysis classes defined as part of the requirements model. 
• An archetype is a generic, idealized model of a person, object, or concept from which similar instances are derived, copied, patterned, or emulated. 
• For example, an archetype for a car: wheels, doors, seats, engine In software engineering
• As per in previous figure : The SafeHome home security function, you might define the following archetypes : 
• Node : Represents a cohesive collection of input and output elements of the home security function.
• For example a node might be included of (1) various sensors and (2) a variety of alarm (output) indicators. 
• Detector : An abstraction that covers all sensing equipment that feeds information into the target system. 
• Indicator. An abstraction that represents all mechanisms (e.g., alarm siren, flashing lights, bell) for indicating that an alarm condition is occurring. 
• Controller. An abstraction that describes the mechanism that allows the arming (Supporting) or disarming of a node. If controllers reside on a network, they have the ability to communicate with one another.

 Refining the Architecture into Components

• As the software architecture is refined into components. 
• Analysis classes represent entities within the application (business) domain that must be addressed within the software architecture. 
• In some cases (e.g., a graphical user interface), a complete subsystem architecture with many components must be designed. 
• For Example : The SafeHome home security function example, you might define the set of top-level components that address the following functionality: 
• External communication management — coordinates communication of the security function with external entities such as other Internet-based systems and external alarm notification. 
• Control panel processing— manages all control panel functionality. 
• Detector management — coordinates access to all detectors attached to the system. 
• Alarm processing — verifies and acts on all alarm conditions
• The overall architectural structure (represented as a UML component diagram) is in the following Figure.

Describing Instantiations of the System

• The architectural design that has been modeled to this point is still relatively high level. 
• The context of the system has been represented 
• Archetypes that indicate the important abstractions within the problem domain have been defined, 
• The overall structure of the system is apparent, and the major software components have been identified. 
• However, further refinement is still necessary. 
• To accomplish this, an actual instantiation of the architecture is developed.It means, again it simplify by more details. 
• The figure demonstrates this concept.

Architectural Pattern

Architectural Pattern

• As the requirements model is developed, you’ll notice that the software must addressa number of broadproblems that span the entire application. 
• For example, the requirements model for virtually every e-commerce application is faced with the following problem:
• How do we offer a broad array of goods to a broad array of customers? 
• Allow those customers to purchase our goods online?
• The requirements model also defines a context in which this question must be answered. 
• For example, an e-commerce business that sells golf equipment to consumers will operate in a different context than an e-commerce business that sells high-priced industrialequipment to medium and large corporations.
• In addition, a set of limitations and constraints may affect the way in which you addressthe problem to be solved. 
• Architectural patterns address an application-specific problem within a specific context and under a set of limitations and constraints. 
• The pattern proposes an architectural solution that can serve as the basis for architectural design…

Architectural Styles | Taxonomy of Architectural Styles | Data-Centered Architecture | Data Flow architectures | Call and return architectures | Object-oriented architectures | Layered architectures

Architectural Styles

• Introduction : 
• For example (For understanding purpose)
• When a builder uses the phrase “center hall colonial” to describe a house, most people familiar with houses in a general image of what the house will look like and what the floor plan is likely to be. 
• The builder has used an architectural style as a descriptive mechanism to differentiate the house from other styles (e.g., A-frame, raised ranch, Cape Cod). 
• The architectural style is also a template for construction. 
• Further details of the house must be defined, its final dimensions must be specified, customized features may be added, building materials are to be determined, but the style—a “center hall colonial”—guides the builder in his work. 
• software architecture represents a structure in which some collection of entities (often called components) is connected by a set of defined relationships (often called connectors). 
• Both components and connectors are associated with a set of properties that allow the designer to differentiate the types of components and connectors that can be used.

• Introduction: 
• 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 (e.g., a database, computational modules) 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;
• (4) Semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts.

Taxonomy of Architectural Styles

• Introduction:
• Millions of computer-based systems have been created over the past 60 years, the vast majority can be categorized into one of a relatively small number of architectural styles 
• The following are the Taxonomy (Classification) of Architectural Style
• (1) Data-centered architectures 
• (2) Data flow architectures 
• (3) Call and return architectures 
• (4) Object-oriented architectures
• (5) Layered architectures

Data-Centered Architecture

• Introduction:
• A data store (e.g., a file or database) 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. 
• Figure in slide, illustrates a typical data-centered style. Client software accesses a central repository (Storage area).
• Data-centered architectures promote inerrability. That is, existing components can be changed and new client components added to the architecture without concern about other clients 
• (because the client components operate independently). 
• In addition, data can be passed among clients using the black-board mechanism (i.e., the blackboard component serves to coordinate the transfer of information between clients). 
• Client components independently execute processes.

Data Flow architectures

• This architecture is applied when input data are to be transformed through a series of computational or manipulative components into output data. 
• A pipe-and-filter pattern (in Figure) has a set of components, called filters, connected by pipes that transmit data from one component to the next.
• Each filter works independently of those components upstream and downstream, is designed to expect data input of a certain form, and produces data output (to the next filter) of a specified form. 
• However, the filter does not require knowledge of the workings of its neighboring filters. 
• If the data flow degenerates into a single line of transforms, it is termed batch sequential. This structure accepts a batch of data and then applies a series of sequential components (filters) to transform it

An example of the pipe and filter architecture

Call and return architectures

• This architectural style enables you to achieve a program structure that is relatively easy to modify and scale.
• A number of substyles exist within this category…
• 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. an architecture of this type.
• Remote procedure call architectures. The components of a main program/subprogram architecture are distributed across multiple computers on a network.

Object-oriented architectures

• The components of a system encapsulate data and the operations that must be applied to manipulate the data.
• Communication and coordination between components are accomplished via message passing…

Layered architectures

• The basic structure of a layered architecture is illustrated in Figure.
• A number of different layers are defined, each accomplishing operations that progressively become closer to the machine instruction set.
• At the outer layer, components service user interface operations.
• At the inner layer, components perform operating system interfacing.
• Intermediate layers provide utility services and application software functions…

Architectural design | What is Architecture? | Difference between Architectural & Design

Introduction of Architectural design

• Architectural design represents
• The structure of data
• Program components ,that are required to build a computerbased system.
• Architectural design considers the architectural style that the system will take, 
• The structure and properties of the components that constitute the system, 
• The interrelationships that occur among all architectural components of a system.

What is Architecture?

• Bass, Clements, and Kazman define this term in the following way:
• The software architecture of a program or computing system is the structure or structures of the system, which comprise (include) software components, the externally visible properties of those components, and the relationships among them. 
• For example : It is something like building a home and prepare a model of it. Finally, it is an art. 
• The architecture is not the operational software. Rather, it is a representation that enables you to 
• (1) Analyze the effectiveness of the design in meeting its stated requirements, 
• (2) Consider architectural alternatives at a stage when making design changes is still relatively easy, 
• (3) Reduce the risks associated with the construction of the software.
• The definition emphasizes the role of “software components” in any architectural representation. 
• In the context of architectural design, a software component can be something as simple as a 
• Program module or an object-oriented class, 
• Database
• Middleware
• The properties of components are those characteristics that are necessary for an understanding of how the components interact with other components. 
• At the architectural level, internal properties (e.g., details of an algorithm) are not specified. 
• The relationships between components can be as simple as a procedure call from one module to another or as complex as a database access protocol.

Difference between Architectural & Design

• Introduction : 
• For example (For understanding purpose)
• When a builder uses the phrase “center hall colonial” to describe a house, most people familiar with houses in a general image of what the house will look like and what the floor plan is likely to be. 
• The builder has used an architectural style as a descriptive mechanism to differentiate the house from other styles (e.g., A-frame, raised ranch, Cape Cod). 
• The architectural style is also a template for construction. 
• Further details of the house must be defined, its final dimensions must be specified, customized features may be added, building materials are to be determined, but the style—a “center hall colonial”—guides the builder in his work. 
• software architecture represents a structure in which some collection of entities (often called components) is connected by a set of defined relationships (often called connectors). 
• Both components and connectors are associated with a set of properties that allow the designer to differentiate the types of components and connectors that can be used.

Design Model | Dimensions of the Design Model | Data Design Elements | Architectural Design Elements | Interface Design Elements | Component-Level Design Elements | Deployment-Level Design Elements

Introduction of Design Model

• The design model can be viewed in two different dimensions.
• (Horizontally) The process dimension
• It indicates the evolution of the parts of the design model as each design task is executed.
• (Vertically) The abstraction dimension 
• It  represents the level of detail as each element of the analysis model is transformed into the design model and then iteratively refined. 
• The elements of the design model use many of the same UML diagrams that were used in the analysis model.
• The difference is that these diagrams are
• Refined and elaborated as part of design; 
• More implementation-specific detail is provided, 
• Architectural structure and style, components that reside within the architecture, 
• Interfaces between the components and with the outside world are all emphasized.

Design Model Introduction

Dimensions of the Design Model

Data Design Elements

• Customer’s/ User’s View:
• Data Architecting (Creates a model of data that is represented at a high level of abstraction). (Build Architecture of Data) 
• Program Component Level: The design of Data structure & algorithms. 
• Application Level: Translate Data Model into a database. 
• Business Level: Data warehouse(Reporting & Analysis of DB) & Data mining(Analysis). 
• At last it means creation of Data Dictionary.

Architectural Design Elements

• Provides an overall view of the software product(Similar like Floor Plan of house) 
• The architectural model [Sha96] is derived from three sources:
• (1) Information about the application domain for the software to be built; 
• (2) Specific requirements model elements such as data flow diagrams or analysis classes, their relationships and collaborations for the problem at hand; 
• (3) The availability of architectural styles (Chapter 9) and patterns
• Difference: An architectural style is a conceptual way of how the system will be created / will work. 
• An architectural pattern describes a solution for implementing a style at the level of subsystems or modules and their relationships.

Interface Design Elements

• The interface design elements for software represent information flows into and out of the system and how it is communicated among the components defined as part of the architecture. 
• For example : A set of detailed drawings (and specifications) for the doors, windows, and external utilities of a house. These drawings describe the size and shape of doors and windows, the manner in which they operate, the way in which utility connections (e.g., water, electrical, gas, telephone) come into the house and are distributed among the rooms depicted in the floor plan.
• There are three important elements of interface design: 
• (1) The user interface (UI); 
• (2) External interfaces to other systems, devices, networks, or other producers or consumers of information; 
• (3) Internal interfaces between various design components. 
• UI design (increasingly called usability design) is a major software engineering action
• Usability design incorporates 
• Visual elements (e.g., layout, color, graphics, interaction mechanisms), 
• Ergonomic elements (e.g., information layout and placement, metaphors, UI navigation), 
• Technical elements (e.g., UI patterns, reusable components). 
• In general, the UI is a unique subsystem within the overall application architecture.

• The design of external interfaces requires perfect information about the entity to which information is sent or received. 
• The design of external interfaces should incorporate error checking and (when necessary) appropriate security features 
• For example, the SafeHome security function makes use of a control panel that allows a homeowner to control certain aspects of the security function. 
• In an advanced version of the system, control panel functions may be implemented via a wireless PDA or mobile phone. 
• The ControlPanel class (in Figure ) provides the behavior associated with a keypad, and therefore, it must implement the operations readKeyStroke () and decodeKey (). 
• If these operations are to be provided to other classes (in this case, WirelessPDA and MobilePhone), it is useful to define an interface as shown in the figure. 
• The interface, named KeyPad, is shown as an <<interface>> stereotype or as a small, labeled circle connected to the class with a line. The interface is defined with no attributes and the set of operations that are necessary to achieve the behavior of a keypad.

Component-Level Design Elements

• The component-level design for software fully describes the internal detail of each software component. 
• Component elements (detailed drawing of each room, wiring, place of switches…) 
• Internal details of each software component
• Data structures, 
• algorithmic details, 
• interface to access component operation (behavior).

Deployment-Level Design Elements

• Deployment-level design elements indicate how software functionality and subsystems will be allocated within the physical computing environment that will support the software. 
• For example, the elements of the SafeHome product are configured to operate within three primary computing environments
• A home-based PC, 
• The SafeHome control panel, 
• Server housed at CPI Corp. (providing Internet-based access to the system).

• The diagram shown in Figure is in descriptor form. 
• This means that the deployment diagram shows the computing environment but does not explicitly indicate configuration details. 
• For example, the “personal computer” is not further identified. It could be a Mac or a Windows-based PC, a Sun workstation, or a Linux-box.
• These details are provided when the deployment diagram is revisited in instance form during . 
• Each instance of the deployment (a specific, named hardware configuration) is identified…

Design Concepts | Abstraction | Architecture | Patterns | Separation | Modularity | Information Hiding | Functional Independence | Refinement | Aspects | Refactoring | Object-Oriented Design Concepts | Design Classes | Cohesion | Coupling

Design Concepts

• Introduction : A set of fundamental software design concepts have developed over the history of software engineering. 
• Although the degree of interest in each concept has varied over the years, each has stood the test of time. 
• Each provides the software designer with a foundation from which more sophisticated design methods can be applied. 
• The following important software design concepts that span both traditional and object-oriented software development. 
• (1) Abstraction [data, procedure, control]
• (2) Architecture [The overall structure of the software] 
• (3) Patterns [conveys the essence” of a proven design solution] 
• (4) Separation of Concerns [Divide complex problem in small parts] 
• (5) Modularity [Small Components] 
• (6) Information Hiding [controlled interfaces] 
• (7) Functional Independence
• (8) Refinement
• (9) Aspects
• (10) Refactoring
• (11) Object-Oriented Design Concepts
• (12) Design Classes

(1) Abstraction  (Concept / Generalization)

• Introduction : When you consider a modular solution to any problem, many levels of abstraction can be created. 
• At the highest level of abstraction, a solution is stated in broad terms using the language of the problem environment. 
• At lower levels of abstraction, a more detailed description of the solution is provided. 
• Finally, at the lowest level of abstraction, the solution is stated in a manner that can be directly implemented. 
• As different levels of abstraction are developed, you work to create both 
• Procedural abstractions 
• Data abstractions.
• A procedural abstraction refers to a sequence of instructions that have a specific and limited function. The name of a procedural abstraction implies these functions, but specific details are suppressed.
• An example of a procedural abstraction would be the word open for a door. Open implies a long sequence of procedural steps (e.g., walk to the door, reach out and grasp knob, turn knob and pull door, step away from moving door, etc.)

• A data abstraction is a named collection of data that describes a data object. 
• In the context of the procedural abstraction open, we can define a data abstraction called door. 
• A set of attributes that describe the door (e.g., door type, swing direction, opening mechanism, weight, dimensions). 
• It follows that the procedural abstraction open would make use of information contained in the attributes of the data abstraction door.

(2) Architecture

[The overall structure of the software]

• Software architecture refers to “the overall structure of the software and the ways in which that structure provides conceptual integrity for a system” [Sha95a]
• Architecture is the structure or organization of program components (modules), the manner in which these components interact, and the structure of data that are used by the components.
• The following set of properties that should be specified as part of an architectural design.
• Structural properties.
• Extra-functional properties
• Families of related systems
• Structural properties : This representation defines the components of a system e.g., modules, objects, filters
• The manner in which those components are packaged and interact with one another.
• For example, objects are packaged to encapsulate both data and methods.
• Extra-functional properties : The architectural design description should address the following.
• How the design architecture achieves requirements for performance, capacity, reliability, security, adaptability, and other system characteristics.
• Families of related systems : The architectural design should draw upon repeatable patterns that are commonly encountered in the design of families of similar systems.
• The design should have the ability to reuse architectural building blocks.

(3) Pattern [”conveys the essence (Fundamental nature) ” of a proven design solution]

• Design pattern describes a design structure that solves a particular design problem within a specific context.
• The objective of each design pattern is to provide a description that enables a designer to determine 
• (1) whether the pattern is applicable to the current work,
• (2) whether the pattern can be reused (hence, saving design time),
• (3) whether the pattern can serve as a guide for developing a similar, but functionally or structurally different pattern.

(4) Separation of Concerns
[Divide complex problem in small parts]

• Separation of concerns is a design concept, that suggests any complex problem can be more easily handled if it is subdivided into pieces that can each be solved and/or optimized independently.
• A concern is a feature or behavior that is specified as part of the requirements model for the software. By separating concerns into smaller, and therefore more manageable pieces, a problem takes less effort and time to solve. 
• Separation of concern is manifested (Marked / Visible) in other related design concepts: 
• Modularity,
• Aspects, 
• Functional independence, 
• Refinement.

(5) Modularity
[Divide complex problem in small parts]

• Modularity is the most common manifestation of separation of concerns. Software is divided into separately named and addressable components, sometimes called modules, that are integrated to satisfy problem requirements. 
• It has been stated that “modularity is the single attribute of software that allows a program to be intellectually manageable” [Mye78].
• Monolithic software (i.e., a large program composed of a single module) cannot be easily grasped by a software engineer. 
• You modularize a design (and the resulting program) so that 
• Development can be more easily planned; 
• Software increments can be defined and delivered;
• Changes can be more easily accommodated;
• Testing and debugging can be conducted more efficiently, 
• Long-term maintenance can be conducted without serious side effects

(6) Information Hiding[Controlled interfaces]

• The concept of modularity leads you to a fundamental question: “How do I decompose a software solution to obtain the best set of modules?”
• The principle of information hiding [Par72] suggests that modules be “characterized by design decisions that (each) hides from all others.” In other words, modules should be specified and designed so that information (algorithms and data) contained within a module is inaccessible to other modules that have no need for such information. 
• Hiding implies that effective modularity can be achieved by defining a set of independent modules that communicate with one another only that information necessary to achieve software function.
• The use of information hiding as a design criterion for modular systems provides the greatest benefits when modifications are required during testing and later during software maintenance. Because most data and procedural detail are hidden from other parts of the software

(7) Functional Independence

• The concept of functional independence is a direct result of separation of concerns, modularity, and the concepts of abstraction and information hiding.
• Functional independence is achieved by developing modules with “singleminded” function.
• Functional independence is a key to good design, and design is the key to software quality. 
• Independence is assessed using two qualitative criteria which evaluate quality of design : 
• Cohesion
• Coupling

Cohesion :

• Cohesion measures how strongly each of the functions are related within a program module.
• Well structured classes guide to highly cohesive programs. If a certain class is performing a set of highly related functions, that class is said to be cohesive.
• On the other hand, if a class is performing a bunch of totally unrelated functionalities that means the class is not cohesive at all.

Coupling:

• Coupling measures how much each of the program modules are dependent on the other program modules.
• Interactions between two objects occur because there is coupling.
• Loosely-coupled programs are high in flexibility and extensibility.
• Strong coupling is never good because one object can be highly dependent on some other object.

Difference of Cohesion - Coupling

(8) Refinement

(Modification / Improvement)

• Stepwise refinement is a top-down design strategy originally proposed by Niklaus Wirth. 
• Refinement is actually a process of elaboration. You begin with a statement of function (or description of information) that is defined at a high level of abstraction. That is, the statement describes function or information conceptually but provides no information about the internal workings of the function or the internal structure of the information. 
• You then elaborate on the original statement, providing more and more detail as each successive refinement (elaboration) occurs.

• Abstraction and refinement are complementary concepts. 
• Abstraction enables you to specify procedure and data internally but suppress the need for “outsiders” to have knowledge of low-level details. 
• Refinement helps you to reveal (disclose) low-level details as design progresses. Both concepts allow you to create a complete design model as the design develops.

(9) Aspects

( Features / phases )

• A representation of a cross-cutting concern that must be accommodated as refinement and modularization occur.
• For example : (Module A cross cut Module B means B cannot be satisfied without considering A).

(10)Refactoring

( Features / phases )

• Refactoring is a reorganization technique that simplifies the design (or code) of a component without changing its function or behavior.
• Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code [design] yet improves its internal structure.
• When software is refactored, the existing design is examined for redundancy, unused design elements, inefficient or unnecessary algorithms, poorly constructed or inappropriate data structures, or any other design failure that can be corrected to yield a better design.

(11) Object-Oriented Design Concepts 

• The object-oriented (OO) paradigm is widely used in modern software engineering. 
• OO design concepts such as classes and objects, inheritance, messages, and polymorphism, among others are the different features of oo paradigm.

(12) Design Class 

• Refine analysis classes by providing detail needed to implement the classes and implement a software infrastructure the support the business solution 
• Five types of design classes can be developed to support the design architecture…..
• User interface classes – abstractions needed for human-computer interaction (HCI) 
• Business domain classes – refinements of earlier analysis classes 
• Process classes – implement lower level business abstractions required to fully manage the business domain classes. 
• Persistent classes – represents data stores that will persist beyond software execution 
• System classes – implement software management and control functions…