Outline n n n Component against module Component

Outline n n n Component against module Component based development (CBD) Benefits of CBD Requirements of CBD Component development Architecture Why architecture? Usual architectures Design against architecture Architecture documentation

Component n n Component = Good module + plug-ability + replace-ability + reuse-ability Figure 21 -1

Object n A module with specific attributes and behavior

Module, object and component n n n Each component is an object Each object is a module Therefore each component is a module Figure 21 -2 But the reverse relation is not correct always

Component Based Development (CBD) n n Car example New product is designed and developed based on available components

Benefits of CBD n Faster and cheaper design; n n Faster and cheaper implementation and test. n n n Components are implemented and tested before In practice implementation starts by integration Faster and cheaper maintenance. n n Because no need to consider internal details of components Only detection and replacement of faulty components Developer of the component is responsible for fixing errors We only report the problem Faster and cheaper development

Benefits of CBD (Cont. ) n n Customization is possible now The component is reusable again Reaction to changes is easier Management of big projects is simple by CBD n n n Details are removed, so management can happen in higher level of abstraction Concurrent activities is possible Less concurrency problems (race, dead lock, synchronization)

Requirements of CBD n Good information about components is required n n n n There agents to do it such as: www. flashline. com & www. roguewave. com Object model has the best compatibility with CBD. So we need related knowledge Some times our required component is not available ( some thing more or less) Monopoly on a component may cause dependency Component developer my change its production The basic issue for CBD, is acceptance and application of suitable standards Having architecture is important in CBD.

Component development as a market n n n In our situation, component development is more feasible We may take part in international projects by CBD (as Indians) Invention is an exception

Requirements of component development n n n n n Needs long term approach Needs standard support Needs sever testing and maintenance Needs flexibility to handle good spectrum of needs Needs good understanding of the market Should be able to compete with bests of the world Having clear production lines and clear domain is important Having architecture is important Knowledge of objet model is required

Architecture

What is an “Architecture”? n IEEE-Std-1471 -2000 (ISO / IEC DIS 25961 2006) n n Architecture: the fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution. where: n n n – fundamental organization means essential, unifying concepts and principles – system includes application, system, platform, system of- systems, enterprise, product line, . . . – environment is developmental, operational, programmatic, … context of the system

Architecture n n Architecture is a design. But a design for designs. Architecture is a very large design Architecture specifies the major required specifications for consistency of components and sub-systems; and leaves other decisions to the designers and developers of those components and sub-systems Architecture includes high level decisions, where should be applied on several systems to make them consistent with each other

Architecture (Cont. ) n n n architecture, common and general issues of all designs are designed Architecture may include development decisions too. Examples of architectural decisions: n n n How unexpected errors should be handled in all products Using database systems of a specific data base developer A special programming language as the major tool for developing all products

Why architecture n Big projects are faced with: n n n Big volume (million lines) of code, Many (hundreds) of developers in a set of companies Complexity of interaction between different parts Deferent programming languages Deferent development environments Persistent mechanisms such as files and data bases Deferent platforms Distribution of components on different hardware platforms High concurrency between activities Geographical distribution Remote access Acceptable security

Why architecture (Cont. ) n n n Considering complexity of big systems is a serious challenge even for experienced designers and developers Millions of small or big issues should be considered These items, parts , methods and products may change along the time, or be added or removed Cooperating people, companies and responsible people may change Architecture provides uniformity and consistency among related designs, products, distinctions and changes

Designing against architecture n n n Design is for a special time, but architecture should work along the time Designing is a limited understanding of special audience; while architecture is a more complete understanding that should cover all stakeholders along the time Architecture is the common language of all stakeholders Architecture considers structure and behavior, both together In architecture effectiveness is more important than efficiency

Usual architectures n n n Data driven Data-flow Object oriented Layered Product-line Pipe line and filter Client-server Distributed computing Black board Three-tiered Service-oriented Call and return architecture

Architecture documenting n n n Long term cooperation and coordination of different groups which are working on a given architecture, without documents of the architecture is not possible Here we use HP template for its simplicity and clarity Note to different parts of this template

Major parts of the HP template n Representing interaction of the system with its stakeholders n n n Representing functional requirements (see chapter 10) n n n By using context diagram; Such as figure 10 -3 By using a set of use-case diagrams of UML and use case tables for each type of the stakeholders; Such as figure 10 -3 and table 10 -2 Representing non-functional requirements (see chapter 10); specifications that affects the development and behavior of the system n By using text; Such as figure 10 -5

Major parts of the HP template (Cont. ): n Represents general structure of the system; to show basic modules and their relations n n n By using block structure diagram Such as figure 12 -5 Represents dynamic behavior of the system n n By using sequence and cooperation diagrams of UML (see chapter) Such as figures 20 -6 and 20 -12

Major parts of the HP template (Cont. ): n Representing other views: n Process view: to show processes of the system and their relations n n n Physical view: to show different parts geographically are deployed, and how they are related to each other n n n By using class diagram of UML Such as figure 21 -4 By using deployment diagram of UML Such as figure 21 -5 Conceptual view: to show used concepts and their relations n n By using class diagram of UML and dictionary of concepts Such as figure 21 -6 and table 12 -2

Example for interaction of system with stakeholders

Example of functional requirements; using use cases

Example of non-functional requirements

Example of general structure; using block diagram

Example of dynamic behavior; using sequential diagram

Example of dynamic behavior; using cooperation diagram