Lecture 11 Component-based Software Engineering Client server Software Engineering

Lecture 11 Component-based Software Engineering Client/server Software Engineering Web Engineering

Component-Based Software Engineering

The Key Questions When faced with the possibility of reuse, the software team asks: Are commercial off-the-shelf (COTS) components available to implement the requirement? Are internally-developed reusable components available to implement the requirement? Are the interfaces for available components compatible within the architecture of the system to be built? At the same time, they are faced with the following impediments to reuse. . .

Impediments to Reuse Lack of a comprehensive software reusability plan. Majority of software developers do not use tools or components that provide direct assistance for software reuse. Relatively little training is available to help software engineers and managers understand apply reuse.

…Impediments The belief that reuse is “more trouble than it’s worth. ” is still around Software development methodologies that do not facilitate reuse are still encouraged. Few companies provide an incentives to produce reusable program components.

The CBSE Process Software Architecture Development Domain Analysis Domain Model Analysis Architectural Design Reusable Component Development Repository Reusable Artifacts/ Components Structural Model Component Qualification Component Adaptation Component Composition Component Engineering Component Update Applicatio n Software Testing

Domain Engineering 1. Define the domain to be investigated. 2. Categorize the items extracted from the domain. 3. Collect a representative sample of applications in the domain. 4. Analyze each application in the sample. 5. Develop an analysis model for the objects.

Identifying Reusable Components Is component functionality required on future implementations? How common is the component's function within the domain? Is there duplication of the component's function within the domain? Is the component hardware-dependent? Does the hardware remain unchanged between implementations?

…Identifying Can the hardware specifics be removed to another component? Is the design optimized enough for the next implementation? Can we parameterize a nonreusable component or decompose it so that it becomes reusable? Is the component reusable in many implementations with only minor changes? Is reuse through modification feasible?

Structural Modeling Every application has structural patterns that have the potential for reuse A “structure point” is a construct with the structure limited number of instances. (OO – small class hierarchy). the rules should be easily understood. the interface should be relatively simple. information hiding should be implemented

Component-Based Development a library of components must be available components should have a consistent structure a standard should exist, e. g. , OMG/CORBA MS COM Java. Beans

CBSE Activities Component qualification adaptation composition update

Qualification Before a component can be used, consider: application programming interface (API) development and integration tools required run-time requirements including resource usage, timing or speed, and network protocol service requirements including OS interfaces and support from other components security features including access controls and authentication protocol embedded design assumptions exception handling

Adaptation The implication of “easy integration” is: that consistent methods of resource management have been implemented for all components in the library; that common activities such as data management exist for all components, and that interfaces within the architecture and with the external environment have been implemented in a consistent manner.

Composition An infrastructure must be established to bind components together Architectural ingredients for composition include: Data exchange model Automation Structured storage Underlying object model

Classification Enumerated classification—components are described by defining a hierarchical structure in which classes and varying levels of subclasses of software components are defined Faceted classification—a domain area is analyzed and a set of basic descriptive features are identified Attribute-value classification—a set of attributes are defined for all components in a domain area

Client/Server Software Engineering

C/S Architectures

Architecture Options User-level PC Clients User-level PC LAN record request/reply SQL request/reply transaction group communication Server

Software Components User Interaction/Presentation Component— implements all functions associated with a graphical user interface (GUI). Application Component—implements the requirements defined Database Management—performs the data manipulation and management required by an application.

… Components Middleware—comprises software elements that exist on both the client and the server elements of network operating systems software that supports database specific applications object-request broker (ORB) standards groupware technologies communication management other features that facilitate the client-server connection

C/S Configurations Distributed presentation — all logic runs on the server (including screen display) Remote presentation — presentation logic at client side Distributed logic — presentation and data entry logic at client side Remote data management — distributed data source Distributed databases — multiple data servers

Object-Request Brokers

C/S Software Engineering conventional and/or OO analysis methods are generally applicable basic design principles and methods can be applied but data design dominates event driven paradigm is chosen GUI design is almost always required specialized construction tools are desirable testing strategy differs

C/S Testing Application function tests. The functionality of client applications is tested using conventional methods Server tests. The coordination and data management functions of the server are tested. Server performance (overall response time and data throughput) is also considered. Database tests. The accuracy and integrity of data stored by the server is tested. Archiving is also tested.

… C/S Testing Transaction testing. A series of tests are created to ensure that each class of transactions is processed according to requirements. Network communication testing. These tests verify the communication among the nodes of the network occurs correctly and that message passing, transactions, and related network traffic occur without error. Network security tests may also be conducted.

Web Engineering

Attributes of Web. App Network intensive. It resides on a network and must serve the needs of a diverse community of clients. Content-Driven. The primary function of a Web. App is to use hypermedia to present text, graphics, audio, and video content. Continuous evolution. Unlike conventional application software that evolves over a series of planned, chronologically-spaced releases, Web. App evolve continuously.

Web. App Characteristics Immediacy. The time to market for a complete Web-site can be a matter of a few days or weeks. Security. Sensitive content need to be protected by strong security measures throughout the infrastructure that supports a Web. App and within the application itself. Aesthetics. When an application has been designed to market or sell products or ideas, the website’s look and feel may have as much to do with success as technical design.

Web. App Quality Factors Usability Global site understandability Online feedback and help features Interface and aesthetic features Special features Functionality Web Application Quality Searching and retrieving capability Navigation and browsing features Application domain-related features Reliability Correct link processing Error recovery User input validation and recovery Efficiency Response time performance Page generation speed Graphics generation speed Maintainability Ease of correction Adaptability Extensibility

The Web. E Process Planning Analysis Formulation Architectural Design Content Design Navigation Design Engineering Production Customer Evaluation Page Generation & Testing Interface Design

Formulation Allows the customer and developer to establish a common set of goals Address three questions: What is the main motivation for the Web. App? Why is the Web. App needed? Who will use the Web. App? Defines two categories of “goals” Informational goals—indicate an intention to provide specific content and/or information Applicative goals—indicate the ability to perform some task within the Web. App

Analysis for Web. E Content Analysis Data modeling can be used to identify and describe each of the data objects (content) Interaction Analysis Develop use cases to provide detailed descriptions of the Web. App-user interactions Functional Analysis All operations and functions are described in detail, starting from the use cases Configuration Analysis The environment and infrastructure in which the Web. App resides are described in detail

Design for Web. E Architectural design — laying out the page structure of the Web. App Navigation design — defining the manner in which pages will be navigated Interface design — establishing consistent and effective user interaction mechanisms

Architectural Styles Grid structure Hierarchical structure Linear with optional flow Linear with diversions Grid

Styles … Networked Hierarchical

Navigation Design identify the semantics of navigation for different users of the site User roles Semantics of navigation for each role A semantic navigation unit (SNU) for each goal associated with each user Ways of navigating (Wo. N) are defined define the mechanics (syntax) of achieving the navigation options are text-based links, icons, buttons and switches, and graphical metaphors

Interface Design Guidelines Server errors will send customer elsewhere Do not force the user to read voluminous amounts of text – read 25% slower on screen Avoid “under construction” signs Users prefer not to scroll Navigation menus should be designed consistently and options obvious Aesthetics should never supersede functionality.

Testing for Web. E – I 1. The content model for the Web. App is reviewed to uncover errors. 2. The design model for the Web. App is reviewed to uncover navigation errors. (Usecases 3. Selected processing components and Web pages are unit tested. 4. The architecture is constructed and integration tests are conducted.

Testing for Web. Apps – II 5. The assembled Web. App is tested for overall functionality and content delivery. (validation) 6. A cross reference matrix that defines all probable operating systems, browsers, hardware platforms, and communications protocols is created to guide the test for compatibility. 7. The Web. App is tested by a controlled and monitored population of end-users.

Project Management for Web. E Initiate the project Many of the analysis activities should be performed internally even if the project is outsourced. A rough design for the Web. App should be developed internally. A rough project schedule, including not only final delivery dates, but also milestone dates should be developed. The degree of oversight and interaction by the contractor with the vendor should be identified.

Project Management for Web. E Select candidate outsourcing vendors interview past clients to determine the Web vendor’s professionalism, ability to meet schedule and cost commitments, and ability to communicate effectively. determine the name of the vendor’s chief Web engineer(s) for successful past projects carefully examine samples of the vendor’s work that are similar in look and feel (and business area) to the Web. App that is to be contracted.

Project Management for Web. E Assess the validity of price quotes and the reliability of estimates Does the quote has direct or indirect return-oninvestment that justifies the project? Does the vendor exhibits the professionalism and experience we require? Establish the degree of project management expected from both parties Assess the development schedule WBS should have high granularity Milestones should be defined at tight intervals