» CREATING ARCHITECTURAL DESIGN
» SERVICE ORIENTED ARCHITECTURE
» ARCHITECTURAL DESIGN
» OBJECT CONSTRAINT LANGUAGE

CREATING ARCHITECTURAL DESIGN

Architectural design represents the structure of data and program components that are required to build a computer–based system. It considers the architectural style that the system will take, the structure and properties of the components that constitutes the system, and the interrelationship that occurs among all architectural components of a system.

Data Design

The data design action translates data defined as part of the analysis model into data structures at the software component level and. When necessary into a database architecture at the application level.

a) Data Design at the Architectural Level

The challenge in data design is to extract useful information from this data environment, particularly when the information desired is cross-functional.

To solve this challenge, the business IT community has developed data mining techniques, also called knowledge discovery in database (KDD) , that navigate through existing databases in an attempt to extract appropriate business-level information. An alternative solution, called a data warehouse, adds an additional layer to the data architecture.

A data warehouse is a separate data environment that is not directly integrated with day –to-day application but encompasses all data used by a business.

b) Data Design at the Component Level

Data design at the component level focuses on the representation of the data structures that are directly accessed by one or more software components. We consider the following set of principles (adapted from for data specification):

1. The systematic analysis principles applied to function and behavior should also be applied to data.
2. All data structure and the operations to be performed on each should be identified.
3. A mechanism for defining the content of each data object should be established and used to define both data and the operation applied it.
4. Low-level design decision should be known only to those modules that must make direct use of the data contained within the structure.
5. The representation of a data structure should be known only to those modules that must make direct use of the data contained within the structure.
6. A library of useful data structures and the operations that may be applied to them should be developed.
7. A software design and programming language should support the specification and realization of abstract data types.

Architectural Styles

The software that is built for computer- based systems also exhibits one of many architectural styles. Each styles describes a system category that encompasses (1) a set of components that performs a function required by a system; (2) a set of connectors that enables “communication, coordination and cooperation “between 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 unknown properties of its constituent parts.

a) Data-centered architecture. 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 4 .1 illustrates a typical data- centered style. Client software accesses a central repository.

b) Data-flow architecture. The architecture is applied when input data are to be transformed through a series of computational or manipulate components into output data. A pipe and filter structure in figure 4.2 has a set of components, called filters, connected by pips that transmit data from one component to accept data input of a certain form , and produces data output ( to the next filters) of a specified form. However, the filter does not require knowledge of the workings of its neighboring filters.

c) Call and return architecture. This architectural style enables a software designer (system architect) to achieve a program structure that is relatively easy to modify and scale. Two sub styles within category:

• Main programs/ subprograms architecture. This classic program structure decomposes functions into a control hierarchy where a “main” program invokes a number of program components, which in turn may invoke still other components.
• Remote procedure called architecture. The components of a main program/sub- program architecture are distributed across multiple computers on a network.

d) Object-oriented architecture. The components of a system encapsulate data and the operations that must be applied to manipulate the data. Communication and coordination between components is accomplished via message passing.

e) Architectural Design. As architectural design begins, the software to be developed must be put into context that is, the design should define the external entities that the software interacts with and the nature of the interactions. Once context is modeled and all external software interfaces have been described, the designer specifies the structure of the system by defining and refining software components that implement the architecture. This process continues iteratively until complete architectural structure has been derived.

f) Defining Archetypes. An archetypes is a class or pattern that represents a core abstraction that is critical to the design of architecture for the target system.

Archetypes can be derived by examining the analysis model. Continuing our discussion of the safehome home security function, we 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 comprised of (1) various sensors and (2) a variety of alarm (output) indications.
• Detector. An abstraction that represents all mechanism s (e.g., alarm siren. Flashing lights, bell) for indicating that an alarm condition is occurring.
• Controller. An abstraction that depicts the mechanism that allows the aiming or disarming of a node. If controllers reside on a network, they have the ability to communicate with one another.

g) Refining the Architecture into components. As the software architecture is refined in to components, the structure of the system begins to emerge. These analysis classes represents entities within the application domain is one source for the derivation and refinement of components. Another source is the infrastructure domain. The architecture must accommodate many infrastructure components that enable application components.

Continuing the safehome home security function example, we might define the set of top-level components that address the following functionally:

• External communication management—coordinates communication of the security function with external entities, for example, Internal based system, external alarm notification.
• Control panel processing- manages all control panel functionally.
• Detector management- coordinates access to all detectors attached to the system.
• Alarm processing-verifies and acts on all alarm conditions.

The design details of all attributes and operations would not be specified until components- level design, is generated.

SERVICE ORIENTED ARCHITECTURE

Service–oriented architecture (SOA) is an architectural style that modularizes information systems into services. You then orchestrate collections of these services to bring business processes to life. In a successful processes. The Service- oriented architecture allows us to manage the usage (delivery, acquisition, consumption, and so on) in terms of, and in sets of, related services.

SOA is a logical evolutionary descendant of the software modularization techniques that began more than 50 years ago with the introduction of structured programming. SOA’s novelty is that it gives you increased flexibility in the choice of implementation technologies and locations for the service providers and consumers. The abstracted service interfaces also enable providers and consumers to evolve independently - as long as the interfaces remain stable.

The benefits of an SOA derive primarily from a single characteristic: the stability of the service interface. This stability, relative to the overall rate of systems changes and thus reduces the cost of subsequent changes. You derive a much larger benefit when you are able to reuse services--- exactly as they are. Reuse avoids the cost of re- implementing or modifying the functionality encapsulated in the service.

Here we will identify the characteristics of a well formed service, and provide guidance on how to deliver service oriented applications.

Principles and Definitions

We‘ll begin by looking at definitions of basic Service concepts.

Service

• A Component capable of performing a task. A WSDL service: A collection of end points (W3C).
• A type of capability described using WSDL (CBDI).

A Service Definition

• A vehicle by which a consumer’s need or want is satisfied according to a negotiated contract (implied or explicit) which includes Service Agreement, Function Offered and so on (CBDI).

A Service Fulfillment

• An instance of a capability execution (CBDI).

Web service

• A software system designed to support interoperable machine interaction over a network. It has an interface described in a format that machines can process (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with XML serialization in conjunction with other Web-related (W3C).
• A programmatic interface to a capability that is in conformance with W Snn protocols (CBDI).

From these definitions, it will be clear that the W3C have adopted a somewhat narrower approach to defining services and other related artifacts than CBDI differs slightly insofar as not all Services are Components , nor do they all perform a task. Also CBDI recommends it is useful to manage the type, definition and fulfillment as separate items. However it is in the definition of SOA that CBDI really parts company with the W3C.

Service-Oriented Architecture:

• A set of components which can be invoked, and whose interface descriptions can be published and discovered (W3C).

SOA Basics

It‘s would be easy to conclude that the move to service Orientation really commenced with Web services----about three years ago. However, web services were merely a step along a much longer road. The notion of a service is an integral part of component thinking, and it is clear that distributed architectures were early attempts to implement service- oriented architecture. What’s important to recognize is that web services are part of the wider picture that is SOA.

In fact Web services are not a mandatory component of a SOA, although increasingly they will become so. SOA is potentially much wider in its scope than simply defining service implementation, addressing the quality of the service from the perspective of the provider and the consumer. You can draw a parallel with CBD and component technologies, COM and UML component packaging address components from the technology perspective, but CBD, or indeed Component-Based Software Engineering (CBSE), is the discipline by which you ensure you are building components that are aligned with the business. In the same way, Web services are purely the implementation. SOA is the approach, not just the service equivalent of a UML component packing diagram.

Many of these SOA characteristics were illustrated in a recent CBDI report, which compared web services published by two dotcom companies as alternatives to their normal browser-based access, enabling users to incorporate the functionality offered into their own applications. In one case it was immediately obvious that the Web services were meaningful business services--- for example enabling the Service Consumer to retrieve prices, generate lists, or add an item to the shopping cart.

In contrast the other organization’s services are quite different. It implemented a general purpose API, which simply provides Create, Read, Update, and Delete (CRUD) access to their database through Web services, while there is nothing at all wrong with this implementation, it requires that users understand the underlying model and comply with the business rules to ensure that your data integrity is protected. The WSDL tells you nothing about the business or the entities. This is an example of web services without SOA.

SOA is not just an architecture of services seen from a technology perspective, but the policies, practices, and frameworks by which we ensure the right services are provided and consumed.

So what we need is a framework for understanding what constitutes a good service. If, as we have seen in the previous example, we have varying levels of usefulness, we need some principles of Service Orientation that allow us to set policies, benchmarks and so on.

Architectures

This process view that we have examined at is a prerequisite to thinking about the type of architecture required and the horizons of interest, responsibility and integrity. For SOA there are three important architectural perspective as discussed below.

• The Application Architecture. This is the business facing solution which consumes services from one or more providers and integrates them into the business processes.
• The Service Architecture. This provides a bridge between the implementations and the consuming applications, creating a logical view of sets of services which are available for use, invoked by a common interface and management architecture.
• The Component Architecture. This describes the various environments supporting the implemented applications, the business objects and their implementations.

The Service Architecture

At the core of the SOA is the need to be able to manage services as first order deliverables. It is the service that we have constantly emphasized that is the key to communication between the provider and consumer. So we need a Service Architecture that ensures that services don’t get reduced to the status of interfaces, rather they have an identity of their own, and can be managed individually and in sets.

CBDI developed the concept of the Business Service Bus (BSB) precisely to meet this need. The BSB is a logical view of the available and used services for a particular business domain, such as Human resources or Logistics us answer questions such as:

• What service do I need?
• What services are available to me?
• What services will operate together? ( common semantics, business rules)
• What substitute services are available?
• What are the dependencies between services and versions of services?

Rather than leaving developers to discover individual services and put them into context, the Business Service Bus is instead their starting point that guides them to a coherent set that has assembled for their domain.

• The purpose of the BSB is so that common specifications, policies, etc. can be made at the bus level, rather than for each individual service. For example, services on a bus should all follow the same semantic standards, adhere to the same security policy, and all point to the same global model of the domain. It also facilitates the implementation of a number of common, lower- level business infrastructure services that can be aggregated into other higher level business services on the same bus ( for example, they could all use the same product code validation service).Each business domain develops a vocabulary and a business model of both process and object.

A key question for the service Architecture is ‘What is the scope of the service that is published to the Business Service Bus?’ A simplistic answer is ‘At a business level of abstraction‘. However this answer is open to interpretation—better to have some heuristics that ensure that the service is the lowest common denominator that meets the criteria of business, and is consumer oriented, agreed, and meaningful to the business. The key point here is that there is a process of aggregation and collaboration that should probably happen separately from the implementing component. By making it separate, there is a level of flexibility that allows the exposed service(s) to be adjusted without modifying the underlying components. In principle, the level of abstraction will be developed such that services are at a level that is relevant and appropriate to the consumer. The level might be one or all of the following:

• Business Services
• Service Consumer Oriented
• Agreed by both Provider and Consumer
• Combine low-level implementation-based services into something meaningful to business
• Coarser Grained
• Suitable for External Use
• Conforms to pre-existing connection design

The SOA Platform

The key to separation is to define a virtual platform that is equally relevant to a number of real Platforms. The objective of the virtual platform is to enable the separation of services from the implementation to be as complete as possible and allow components built on various implementation platforms to offer services which have no implementation dependency.

The virtual SOA platform comprises a blueprint which covers the development and implementation platforms. The blueprint provides guidance on the development and implementation of applications to ensure that the published services confirm to the same set of structural principles that are relevant to the management and consumer view of the services.

When a number of different applications can all share the same structure, and where the relationships between the parts of the structure are the same, then we have what might be called a common architectural style. The style may be implemented in various ways; it might be a common technical environment, a set of policies, frameworks or practices. Example platform components of a virtual platform include:

• Host environment
• Consumer environment
• Middleware
• Integration and assembly environment
• Development environment
• Asset management
• Publishing & Discovery
• Service level management
• Security infrastructure
• Monitoring & measurement
• Diagnostics & failure
• Consumer/ Subscriber management
• Web service protocols
• Identity management
• Certification
• Deployment & Versioning

The Enterprise SOA

Enterprise SOA (ESOA) brings the two main threads---web services and CBD (or CBSE) - together. The result is an enterprise SOA that applies to both Web services made available externally and also to core business component services built or specified for internal use. It is beyond the scope of this article to explore ESOA in more depth.

Summary

The goal for a SOA is a worldwide mesh of collaborating services, which are published and available for invocation on the Service Bus. Adopting SOA is essential to deliver the business agility and IT flexibility promised by Web Services. These benefits are delivered not by just viewing service architecture from a technology perspective and the adoption of Web Service protocols, but require the creation of a service Oriented Environment that is based on the following key principals we have articulated in this article:

• Service is the important concept. Web Services are the set of protocols by which Services can be published, discovered and used in a technology neutral, standard form.
• SOA is not just architecture of services seen from a technology perspective, but the policies, practices, and frameworks by which we ensure the right services are provided and consumed.
• With SOA it is critical to implement processes to ensure that there are at least two different and separate processes - for provider and consumer.
• Rather than leaving developers to discover individual services and put them into context, the Business Service Bus is instead their starting point that guides them to a coherent set that has been assembled for their domain.

Describing Instantiations of the System:

The architectural design that has been modified to this point is still relatively of a 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 (recall that all design are iterative) is still necessary.

To accomplish this, an actual instantiation of the architecture is developed. By this we mean that the architecture is applied to a specific problem with the intent of demonstrating that the structure and components are appropriate.

ARCHITECTURAL DESIGN

Objective: Architectural design tools model the overall software structure by representing component interfaces, dependencies and relationships, and interactions.

Mechanics: Tools mechanics vary. In most cases, architectural design capability is part of the functionality provided by automated tools for analysis and design modeling.

Representative Tools:
Adalon, developed by Synthis Corp. (www.synthis.com), is a specialized design tool for the design and construction of specific Web-based component architectures.

ObjectiF, developed mico Tools GmbH (www.microtool.com), is a UML-based design tool that leads to architectures (e.g., Coldfusion, j2EE, Fusebox) amenable to component- based software engineering.

Rational Rose, developed by Rational (www.ra is a UML- based design tool that support all aspects of architectural design).

Pattern–Based Software Design:
The best designers in any field have an uncanny ability to see patterns that characterize a problem and corresponding patterns that can be combined to create a solution. Throughout the design process, a software engineer should look for every opportunity to reuse existing design patterns (when they meet the needs of the design) rather than creating new ones.

Describing a Design Pattern
Mature engineering disciplines make use of thousands of design patterns, For example, a mechanical engineer uses a two- step, keyed shaft as a design pattern. Inherent in the pattern are attributes (the diameters of the shaft, the dimensions of the keyway, etc.) and operations (e.g., shaft rotation, shaft connection). An electrical engineer uses an integrated circuit (an extremely complex design pattern) to solve a specific element of a new problem. Design patterns may be described using the template shown in the sidebar.

Design Pattern Template:

Pattern name describes the essence of the pattern in a short but expressive name.

Intent - describes the pattern and what it does.

Also - known - as - lists any synonyms for the pattern.

Motivation - provides an example of the problem.

Applicability – notes specific design situations in which the pattern is applicable.

Structure - describes the responsibilities of the classes that are required to implement the pattern.

Participants - describes the responsibilities of the classes that are required to implement the pattern.

Collaborations - describes the responsibilities of the classes that are required to implement the pattern.

Collaborations – describes how the participants collaborate to carry out their responsibilities.

Consequences - describes the “design forces” that affect the pattern and the potential trade- offs that must be considered when the pattern is implemented.

Related Patterns - cross- references related design patterns.

A description of the design pattern may also consider a set of design forces. Design forces describe non- functional requirements (e.g., ease of maintainability, portability) associated with the software for which the pattern is to applied. In addition forces define the constraints that may restrict the manner in which the design is to be implemented. In essence, design forces describe the environment and conditions that must exist to make the design pattern applicable. The pattern characteristics (classes, responsibilities, and collaborations) indicate the attributes of the design that may be adjusted to enable the pattern to accommodate a variety of problems. These attributes represent characteristics of the design that can be searched (e.g., via a database) so that an appropriate pattern can be found. Finally, guidance associated with the use of a design pattern provides an indication of the ramifications of design decisions.

Martin Fowler “patterns are half- baked—meaning you always have to finish them yourself and adapt them to your own environment.”

The names of design patterns should be chosen with care. One of the key technical problems in software reuse is the inability to find existing reusable patterns when hundreds or thousands of candidate pattern exist. The search for the “right” pattern is aided immeasurably by a meaningful pattern name.

Using Patterns in design

Design patterns can be used throughout software design. Once the analysis model has been developed, the designer can examine a detailed representation of the problem to be solved and the constraints that are imposed by the problem. The problem description is examined at various levels of abstraction to determine if it is amenable to one or more of the following types of design patterns:

Architectural patterns: These patterns define the overall structure of the software and indicate the relationship among subsystems and software components, and ages, components, subsystems) of the architecture.

Design patterns: These patterns address a specific element of the design such as an aggregation of components to solve some design problem, among components, or the mechanisms of effecting components-to-components communications.

Idioms: Sometimes called coding patterns, these language – specific patterns generally implement an algorithmic element of a component, a specific protocol, or a mechanism for communication among components.

Each of these pattern types differs in the level of abstraction with which it is represented and the degree to which it provides direct guidance for the construction activity ( in this case, coding) of the software process.

Frameworks:

In some cases it may be necessary to provide an implementation- specific skeletal infrastructure, called a framework, for design work. That is, the designer may select a “reusable mini- architecture that provides the generic structure and behavior for a family of software abstractions, along with a context… which specifies their collaboration and use within domain.”

A framework is not an architectural pattern, but rather a skeleton with a collection with a collection of “plug points” (also called hooks and slots) that enables it to be adapted to specific classes or functionality within the skeleton. In an object- oriented context, a framework is a collection of cooperating classes.

In essence, the designer of a framework will argue that one reusable mini – architecture is applicable to all software to be developed within a limited domain of application. To be most effective, frameworks are applied with no changes. Additional design elements may be added, but only via the plug points that allow the designer to flush out the framework skeleton.

Design engineering commences, as the first iteration of requirements engineering comes to a conclusion. The intent of software design is to apply a set of principles, concepts, and practices that lead to the development of a high- quality system or product. The goal design is to create a model of software that will implement all customer requirements correctly and bring delight to those who use it. Design engineers must shift through many design alternatives and coverage on a solution that best suits the needs of project stakeholders.

The design process moves from a “big picture” view of software to a more narrow view that defines the details required to implement a system. The process begins by focusing on architecture. Subsystems are defined; communication mechanisms among subsystems are established; components are identified; and a detailed description of each component is developed. In addition, external, internal, and user interfaces are designed.

Design concepts have evolved over the first half-century of software engineering work. They describe attributes of computer software that should be present regardless of the software engineering process that is chosen, the design methods that are applied, or the programming languages that are used.

The design model encompasses four different elements. As each of these elements is developed, a more complete view of the design evolves. The architectural elements used information derived from the application domain, the analysis model, and available catalogs for patterns and styles to derive a complete structural representation of the software, its subsystems and components. Interface design elements model external and internal interfaces and the user interface. Component- level elements define each of the modules (components) that populates the architecture. Finally, deployment- level design elements allocate the architecture, its components, and the interfaces to the physical configuration that will house the software.

Pattern- based design is a technique that ruses design elements that have proven successful in the past. Each architectural pattern, design pattern, or idiom is cataloged, thoroughly documented, and carefully considered as it assessed for inclusion in a specific application. Frameworks, an extension of patterns, provide an architectural skeleton for the design of complete subsystems within a specific application domain.

Alternative Designs

Design results in a number of architectural alternatives that are accessed to determine which is most appropriate for the problem to be solved. In the section that follow, we consider the assessment of alternative architectural designs.

a) An architecture Trade- off Analysis Method

The architecture trade- off analysis method establishes an iterative evaluation process for software architecture. 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 requirements, constraints, and environment description. This information is a requirement as part of requirement engineering and is used to feel certain that all stakeholder concerns have been addressed.

3. Describe the architectural styles/ patterns that have chosen to scenarios and requirements.

4. Evaluate quality attributes by considering each attribute in isolation. 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.

6. Critique candidate architectures (developed in steep3) using the sensitivity analysis conducted in step 5.

b) Architectural Complexity

A useful technique for assessing the overall complexity of proposed architecture is to consider long tendencies between components within the architecture. These dependencies are driven by information/ control flow within the system and the types of dependencies.

Sharing dependencies represent dependence relationships among consumers who use the same resource or producers who produce for the same consumers.

Flow dependencies represent dependences relationship between producers and consumers of resource or producers who produce for the same consumers.

Constrained dependencies represent constraints on the relative flow of control among a set of activities.

Mapping Data Flow Into a Software Architecture

To illustrate one approach to architectural mapping we consider a mapping technique for the call and return architectures from data flow diagrams within the analysis model.

a) Transform Flow
Information must enter and exit software in an “external world” form. Information enters the system along paths that transforms external data in to an internal form.

Incoming data are passed through a transform center and the data begin to move along paths that lead “out” of the software. Data moving along these paths are called out—going flow. The overall flow of data occurs in a sequential manner and follows one another. Only in a few of these characteristics, transform flow is present.

b) Transaction Flow
Information flow is often characterized by a single data item, called a transaction that triggers other data flow one of many paths. When a DFD takes the form shown in 4.8 transaction flow is present.

Transaction flow is characterized by data moving along an incoming path that converts external world information into a transaction that is evaluated and based on its value the flow one of many action paths emanate is called a transaction center.

c) Transform Mapping
Transform mapping is a set of design steps that allows DFD. It transforms flow characteristics to be mapped into a specific architectural style. To illustrate this application approach, we consider the Safe Home security function. To map these data flow diagram into an architecture the following design steps are initiated:

Step 1. Review the fundamental system model. Fundamental system model or context diagram depicts the security function as a single transforming representing the external producer and consumer of data that flow into and out of the function.

Step 2. Review and refine data flow diagrams for the software. B Information obtained from the analysis model is refined to produce greater detail.

Step 3. Determine whether the DFD has transform or transaction flow characteristics. In general, information flow with in a system can also be represented as transform. However, when an obvious transaction characteristic is encountered, a different design mapping is recommended. In this step, the designer selects global (software-wide) flow characteristics based on a prevailing nature of the DFD. In addition, reasons of transform for transaction flow are isolated. These sub flows can be used to refine program architecture derived from a global characteristic described previously.

Step 4. Isolate the transform center by specifying incoming and outgoing flow boundaries. In the proceeding section incoming flow was described as a path that converts information from external to internal form; outgoing flow converts internal forms to external form. Incoming and outgoing flow boundaries are open to interpretation. That is, different designers may select slightly different points in the flow as boundary location.

Step 5. Perform “first- level factoring.” The program architecture derived using this mapping results in a top- down distribution of control. Factoring results in a program structure in which top-level components perform most input, computation and output work. Middle-level components perform some control and do moderate amounts of work.

Step 6. Perform “second – level factoring.” Second- level factoring is accomplished by mapping individual transforms (bubbles) of a DFD into appropriate modules within the architecture. Beginning at the transform center boundary and moving outward along incoming and then outgoing paths, transform centers are mapped into sub-coordinate levels of software structure.

Step 7. Refine the first- iteration architecture using design heuristics for improved software quality. First – iteration architecture can always be refined by applying concepts of functional independence. Components are exploded or imploded to produce sensible factoring, good cohesion, minimal coupling and most importantly, a structure that can be implemented without difficulty, tested without confusion, and maintained without grief.

Transaction Mapping

In this section we consider design steps used to map transaction flow into software architecture.

Transaction mapping will be illustrated by considering the user interaction subsystem of the SafeHome security function. Refining the flow. The data object User commands, flow into the system and result in additional information flow along one of three actions path. A single data item, command type, causes the data flow to fan outward from a hub. Therefore, the overall data flow characteristic is transaction oriented.

The design steps for transaction mapping are similar and in some cases identical to steps for transform mapping.

Modeling Component-Level Design

(i) Class Base Component

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. As part of the design elaboration, all interfaces (messages) that enable the classes to communicate and collaborate with other design classes must also be defined. To accomplish this, the designer begins with analysis model and elaborate analysis classes (for components that relate to the problem domain) and infrastructure classes (for components that provide support services for the problem domain).

(ii) Component – Level Design Guidelines

The guidelines are

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. Architectural component names should be drawn from the problem domain and should have meaning to all stakeholders who view the architectural model.

Interfaces
Interfaces provide important information about communication and collaboration. Ambler recommends that (1) lollipop representation of an interface should be used in lieu of the more formal UML box and dashed arrow approach, when diagram grows complex; (2) for consistency, interfaces should flow from the left-hand side of the component box; (3) only those interfaces that are relevant to the component under consideration should be shown, even if other interfaces are available. These recommendations are intended to simplify the visual nature of UML component diagram.

Dependencies and inheritance.
For improved readability, it is a good idea to model dependencies from left to right and inheritance from bottom (derived classes) to top (base classes). In addition, component- to component dependency.

(iii) Conducting Component-Level Design

The designer must transform information from the analysis and architectural models into a design representation that provides sufficient detail to guide thee 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. Identity all design classes that correspond to the problem domain.
Using the analysis and architectural models, each analysis class and architectural component are elaborated.

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.
Elaboration requires that all interfaces, attributes, and operations necessary to implement the class be described in detail.

a. Specify message details when classes or components collaborate.
The analysis model makes use of a collaboration diagram to show how analysis classes collaborate with one another. As component- level design proceeds, it is sometimes useful to show the details of these collaborations by specifying the structure of message that are passed between objects within a system. Although this design is optional, it can be used as a precursor to thee specification of interfaces that show how components within the system communicate and collaborate.

b. Identify appropriate interfaces for each component.
Within the context of component- level design, a UML interface is “a group of externally visible operations.”

c. Elaborate attributes and define data types and data structures required to implement them.
Data structures and types used to describe attributes are defined within the context of the programming language that is to be used.

d. Describe proceeding flow within each operation in detail.
This may be accomplished using a programming language- based pseudo code or with a UML activity diagram each software component is elaborated through a number of iterations that apply the stepwise refinement concept.

Step 4. Develop and elaborate behavioral representations for a class or component.
UML state diagrams were used as part of the analysis model to resent the externally observable behavior of the system and more localized behavior of individual analysis classes. During component- level- design, it is sometimes necessary to model the behavior of a design class.

The dynamic behavior of an object is affected by events that are external to it and the current state of the object. To understand the dynamic behavior of an object, the designer must examine all use cases that are relevant to the design class throughout its life. These use – cases provide information that helps the designer to delineate the event that affects the object and the stats in which the object resides as time passes and events occur.

Step 6. Elaborate deployment diagrams to provide additional detail.
During component—level design, deployment diagram can be elaborated to represent the location of key packages of components. However, components generally are not represented individually within a component diagram. The reason for this is to avoid diagrammatic complexity.

Step 7. Factor every component- level design representation and always consider alternatives.

OBJECT CONSTRAINT LANGUAGE

The object constraint language (OCL) complements UML by allowing a software engineer to use a formal grammar and syntax to construct unambiguous statements about various design model elements (e.g., classes and objects. Events, messages, interfaces). The simplest OCL language statements are constructed in four parts: (1) a context that defines the limited situation in which the statement is valid; (2) a property that represents some characteristics of the context 9 e.g., if the context is a class, a property might be an attribute); (3) an operation ( e.g., arithmetic, set oriented) that manipulates or qualifies a property; and (4) keywords ( e.g., if, then, else, and or, not, implies) that are used to specify conditional expressions.

As a simple example of an OCL expression, consider the guard condition placed on the job cost accepted vent that causes a transition between the states computing job cost forming job within the state chart diagram for the print job class.

Customer Self. Authorization authority = ‘yes’

Authorization authority, of the class (actually a specific instance of the class) named customer must be set to yes for the guard condition to be satisfied.

As the design model is created, there are often instances where pre- or post- conditions must be satisfied prior to completion of some action specified by the design. OCL provides a powerful tool for specifying pre-and post-conditions in a format manner. As an example, consider an extension to the print shop system in which the customer provides an upper cost bound for the print job and a “drop-dead” delivery date at the same time as other print job characteristics are specified. If cost and delivery estimates exceed these bounds, the job is not submitted and the customer must be notified. In OCL, a set of pre-and post- conditions may be specified in the following manner.

Context printjob: validate ( upper cost bound: integer, cust deliveryreq: Integer)

Pre: upper cost bound >0

And cost delivery req >o

And self. Job authorization = ‘no’

Post: if self. Delivery date < = cust delivery req

Then Self job authorization= “yes’

End if
This job authorization = ‘yes’

End if

This OCL statement defines invariant- conditions that must exist prior) to (pre) and after (post) some behavior. Initially, a precondition establishes that bounding cost and delivery date must be specified by the customer, and authorization must be set to “no”. After cost and delivery are determined, the post-condition is applied. It should also be noted that the expression: self. Job authorization= “yes’ is not assigning the value ”yes”, but is declaring that the job authorization must have been set to “yes” by the time the operation finishes.

What is it?
User interface design creates an effective communication medium between a human and a computer. Following a set of interface design principles, design identifies interface object and actions and then creates a screen layout that forms the basis for a user interface prototype.

Who does it?
A software engineer designs the user interface by applying an iterative process that draws on widely accepted design principles.

Why is it important?
If software is difficult to use, if it forces you into mistakes, or if it frustrates your efforts to accomplish your goals, you won’t like it, regardless of the computational power it exhibits or the functionality it offers. The interface has to be right because it models a user’s perception of the software.

What are the steps?
User interface design begins with the identification of user, task, and environmental requirements. Once user tasks have been identified, user scenarios are created and analyzed to define a set of interface objects and actions. These form the basis for the creation of screen layouts that depict graphical design and placement of icons, definition of descriptive screen, text, specification of major and minor menu items. Tools are used to prototype and ultimately implement the design model, and the result is evaluated for quality.

Summary

• The architecture of a system is a comprehensive frame work that describes its form and structure its components and how they fit together.
• Transform mapping is a set of design steps that allows a DFD with transform flow characteristics to be mapped into a specific architectural style.
• Component level design is applied for the object oriented system/ concept.
• Designers should always follow the golden rule mentioned in interface design.
• Variety of implementation tools are used to build a prototype for evaluation by the user.