Componentes de Software Resumido e Adaptado dos apontamentos do Prof. José Tavares (Ambientes de Desenvolvimento Avaçados)

Slides:



Advertisements
Similar presentations
P SATel Institute for Information Processing University of Pisa SantAnna school Pisa Today trends in Software Engineering 1. Distributed Objects 2. Component.
Advertisements

Building Bug-Free O-O Software: An Introduction to Design By Contract A presentation about Design By Contract and the Eiffel software development tool.
Basic Concepts in Component-Based Software Engineering
Introduction To System Analysis and Design
CBSD – Component Based Software Development - Introduction -
CS 501: Software Engineering Fall 2000 Lecture 16 System Architecture III Distributed Objects.
- 1 - Component Based Development R&D SDM Theo Schouten.
Feb. 23, 2004CS WPI1 CS 509 Design of Software Systems Lecture #5 Monday, Feb. 23, 2004.
Software Engineering Module 1 -Components Teaching unit 3 – Advanced development Ernesto Damiani Free University of Bozen - Bolzano Lesson 2 – Components.
Software Issues Derived from Dr. Fawcett’s Slides Phil Pratt-Szeliga Fall 2009.
1 An introduction to design patterns Based on material produced by John Vlissides and Douglas C. Schmidt.
Component-Based Software Engineering CSM-15 Paul Krause.
 1. Introduction  2. Development Life-Cycle  3. Current Component Technologies  4. Component Quality Assurance  5. Advantages and Disadvantages.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 8 Slide 1 Software Prototyping l Rapid software development to validate requirements l.
Computer Science 340 Software Design & Testing Design By Contract.
Component-Based Software Engineering Components and Interfaces Paul Krause.
Introduction To System Analysis and design
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 19 Slide 1 Component-based software engineering 1.
Introduction to Object-oriented programming and software development Lecture 1.
Design Patterns OOD. Course topics Design Principles UML –Class Diagrams –Sequence Diagrams Design Patterns C#,.NET (all the course examples) Design Principles.
1/19 Component Design On-demand Learning Series Software Engineering of Web Application - Principles of Good Component Design Hunan University, Software.
Objects and Components. The adaptive organization The competitive environment of businesses continuously changing, and the pace of that change is increasing.
1 CS 456 Software Engineering. 2 Contents 3 Chapter 1: Introduction.
An Introduction to Software Architecture
Software Models (Cont.) 9/22/2015ICS 413 – Software Engineering1 -Component-based software engineering -Formal Development Model.
Software Component Technology and Component Tracing CSC532 Presentation Developed & Presented by Feifei Xu.
Introduction CS 3358 Data Structures. What is Computer Science? Computer Science is the study of algorithms, including their  Formal and mathematical.
Component-Based Software Engineering Using Interfaces Paul Krause.
An Introduction to Design Patterns. Introduction Promote reuse. Use the experiences of software developers. A shared library/lingo used by developers.
Chapter 2 Introducing Interfaces Summary prepared by Kirk Scott.
Component Technology. Challenges Facing the Software Industry Today’s applications are large & complex – time consuming to develop, difficult and costly.
Introduction CS 3358 Data Structures. What is Computer Science? Computer Science is the study of algorithms, including their  Formal and mathematical.
Component Oriented Programming 1 Introduction to COP.
Distribution and components. 2 What is the problem? Enterprise computing is Large scale & complex: It supports large scale and complex organisations Spanning.
Object-Oriented Modeling: Static Models. Object-Oriented Modeling Model the system as interacting objects Model the system as interacting objects Match.
Component-Based Systems X LIU, School of Computing, Napier University TIP As computing systems become more and more complex, software reuse and component-based.
Software Prototyping Rapid software development to validate requirements.
Lecture 2 Intro. To Software Engineering and Object-Oriented Programming (1/2)
Testing OO software. State Based Testing State machine: implementation-independent specification (model) of the dynamic behaviour of the system State:
1 Devon M. Simmonds, Computer Science Department Design by Contract Devon M. Simmonds Computer Science Department University of North Carolina, Wilmington.
Review of Parnas’ Criteria for Decomposing Systems into Modules Zheng Wang, Yuan Zhang Michigan State University 04/19/2002.
Evaluating an Object-Oriented Design ©SoftMoore ConsultingSlide 1.
SWE 4743 Abstract Data Types Richard Gesick. SWE Abstract Data Types Object-oriented design is based on the theory of abstract data types Domain.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 15. Review Interaction-Oriented Software Architectures – MVC.
Enterprise Computing Distribution and components.
Lesson 1 1 LESSON 1 l Background information l Introduction to Java Introduction and a Taste of Java.
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
Object Design More Design Patterns Object Constraint Language Object Design Specifying Interfaces Review Exam 2 CEN 4010 Class 18 – 11/03.
Introduction to Service Orientation MIS 181.9: Service Oriented Architecture 2 nd Semester,
 Description of Inheritance  Base Class Object  Subclass, Subtype, and Substitutability  Forms of Inheritance  Modifiers and Inheritance  The Benefits.
Lecture 2 Intro. To Software Engineering and Object-Oriented Programming (1/2)
CLASSIFICATION OF DESIGN PATTERNS Hladchuk Maksym.
Component-Based Software Engineering Components and Interfaces Paul Krause and Sotiris Moschoyiannis.
Design Patterns: MORE Examples
Prototyping in the software process
Software Prototyping.
Design by Contract Jim Fawcett CSE784 – Software Studio
Design by Contract Jim Fawcett CSE784 – Software Studio
Module 4. Component Software 4.2 Introduction
Component Based Software Engineering
Chapter 11 Object-Oriented Design
Distribution and components
An Introduction to Software Factories
Component-based Software Engineering
An Introduction to Software Architecture
ISpec: A Compositional Approach to Interface Specification
Component-Based Software Engineering
Assertions References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 4/25/2019.
Object-Oriented PHP (1)
Presentation transcript:

Componentes de Software Resumido e Adaptado dos apontamentos do Prof. José Tavares (Ambientes de Desenvolvimento Avaçados)

1 Componentes de software Software Components mean? The main driver behind software components is reuse. That means we must modularise applications if they are to have potentially reusable parts. The expectation is that if the parts (often collections of classes) can be reused then costs will be reduced (in the long run…). Easily maintaining and customizing those parts to produce new features Goals (user´s demands) Build more reliable software Less time between versions

Componentes de software Why use Software Component? Components are the way to go because all other engineering disciplines introduced components as they became mature - and still use them. Use component paradigm to simulate “Software Integrated Circuit” to resolve software crisis. Component software represents the maturation (industrialization) of software development practices. 2

Componentes de software Some traditional software problems large software systems are extremely complex large, monolithic systems are difficult to design and build and even harder to maintain. Reliability and robustness is a major problem. It is difficult to reuse assets-- e.g. design knowledge, software--across multiple projects. Tailoring of software products for different user requirements is difficult. 3

Componentes de software Two traditional software development extremes. Custom-Made Software - develop from scratch Advantages:  Flexible, competitive edge  Optimally adapted to client’s business model  Take advantage of any in-house proprietary knowledge or practice Disadvantages:  Burden of maintenance, product evolution, and interoperability  Expensive undertaking  In a world of rapidly changing business requirements is often too late to be productive before becoming obsolete  Lead to project fail partially or completely 4

Bought and parameterized software Advantages: Limit financial risk Minimize time-to-market risk Burden of maintenance, product evolution, and interoperability is left to vendor Disadvantages: May necessitate a greater reorganization of business processes No competitive edge using a standard software that is also available to competitor Not nimble enough to adapt to changing needs 5

Benefits of Using Components Provides a middle path between the 2 extremes of traditional software development Although each bought component is a standardized product, the process of component assembly allows significant customization. Individual component can be custom-made to suit specific requirements or to foster strategic advantages. Puts an end of massive upgrade cycles since evolution replace revolution. Individual upgrading of components as needed and ‘out of phase’ can allow for smoother operations. 6

7 Componentes de software Drivers for CBD The development of the WWW and Internet Systems of loosely coordinated services Object-oriented design techniques and languages Move from Mainframe to client-server based computing Rapid pace of technological change Economic necessity of maximizing reuse Utility computing

8 Componentes de software So what’s new? Modularisation of software is not new. What we want of a component is that l It may be used by other program elements (clients)  (encapsulation and low coupling – good strategies for any modular design) The clients and their authors do not need to be known to the component’s authors  This is a little bit new, and only works if all the respective authors work to a common standard

9 Componentes de software Are Components New? Subroutines Turing, 1949, Checking a Large Routine Structured Programming Dijkstra, 1968 Libraries, Packages NAG, 1971 Information Hiding, Encapsulation Parnas, 1972

10 Componentes de software

11 Componentes de software Num contexto Service Oriented Architecture

12 Componentes de software Software Components Components are for composition Already existing “things” can be reused by rearranging them to make a new composite So components are about reuse This drives many of the engineering requirements for software components

13 Componentes de software Definition A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties European Conference on Object-Oriented Programming

14 Componentes de software Definition A self-contained piece of software that can be independently deployed and plugged into an environment that provides a compatible socket. It has well-defined run-time interfaces, and it can cooperate out of the box with other components (Peter Herzum, Olivier Sims, "Business Component Factory")

Definition An independently deliverable unit of software that encapsulates its design and implementation and offers interfaces to the outside, by which it may be composed with other components to form a larger whole. (From: Objects, Components, and Frameworks with UML--The Catalysis Approach, by D. D’Souza and A. Wills, Addison Wesley, 1998.) 15

16 Componentes de software Characteristic properties (1) Independent Deployment Separated from its environment and other components Encapsulate its constituent features Cannot be partially deployed Hide the construction details

Characteristic properties (2) Third-party composition  Self-contained  Must have clear specifications of what it requires, as well as what it provides  Needs to encapsulate its implementation  Interact with its environment by means of well-defined interfaces 17

18 Componentes de software Interfaces Define component’s access points - allow the clients of a component to access the services provided by a component Interfaces specifies signature and behavior Interface nominally consists of a set of named operations (methods). The semantics (behavior) of each operation must be precisely specified. Different interfaces will normally provide access to different services Each interface specification could be viewed as a contract between the component and a client

19 Componentes de software Explicit context dependencies Components must also specify their needs i.e. the context of composition and deployment This means both The component’s requires interfaces, and The component world it is prepared for OMG CORBA  Microsoft COM, CLR  Sun’s Java Interoperability

20 Componentes de software Interfaces as contracts Provider (supplier): The entity (component) that implements the operations of an interface. Client (user): An entity that uses (invokes) the services provided by an interface. Can view an interface specification as a “contract” between the client and a provider So the interface specification must state: What the client needs to do What a provider can rely on What a provider must promise in return What the client can rely on

21 Componentes de software Interfaces: A contract is an apropriate aproach, with pre- and pos- conditions atached to every operation decouple clients and providers The same interface may be used by large numbers of different clients also be supported by large numbers of providers

22 Componentes de software Pre- and Post-Conditions Pre-conditions: What the client must establish before calling the operation The provider can rely on this condition being true whenever the operation is called Post-conditions: What the provider must establish before returning to the client The client can rely on this condition being true whenever the call to the operation returns

23 Componentes de software Pre- and Post-Conditions

24 Documentation - JAVA Use and as special tags for pre- conditions and post-conditions: /** precondition postcondition **/ public void method1(...) { // … }

25 Documentation – CLR (.NET) Use “ ” and “ ” as special tags for pre- conditions and post-conditions if XML comments are used: /// pre-condition /// post-condition /// public void method1(...) { // … }

26 Example - JAVA /** * Returns the i-th element in the list * i >= 0 && i < size( */ public Object element(int i);

27 Example – C# /// /// Returns the i-th element in the list /// /// i >= 0 && i /// public Object element(int i);

28 Other logical expressions ==>logical implication logical x : Expression Universally quantified x : Expression [m … n]Integer range from m to n

29 A example /** * Inserts a new element into a list * at the i-th position * item != null && i >= 0 && i <= size( ) size( ) == size( + k : [0.. size( ) - *(k == element(k)) && *(k == i ==> == element(k)) *(k > i ==> == element(k) */ public void insert(Object item, int i);

30 An exercise Use this method to specify the interface to a method that inserts a new element to the head of a list

31 Solution /** * Inserts a new element at the head of a list * item != null size( ) == size( + 1 k : [1.. size( ) - == element(k) */ public void insertHead(Object item);

32 How does this help? This separation between what a function does and how the function works is extremely important As this stands, the comments provide guidance only They prescribe what should be done, but are agnostic about whether a specific implementation satisfies them We can, however, provide run-time checks through the use of Assertions

33 Componentes de software OO Interface Sometimes we may find two or more different subclasses share some common behaviour In this case, they are not strictly “kinds of” some common parent Rather, they “behave like” some common pattern (under certain circumstances) We say that they both implement a common interface

34 Componentes de software Interfaces public interface Cashier { public void deposit( int id, double amount); public boolean withdraw( int id, double amount); } An interface is pure specification - it contains no implementation Identical in C#

35 Componentes de software

36 Componentes de software Abstract class An abstract class is one whose main purpose is to define a common interface for its subclassesabstract class

37 Componentes de software public abstract class EllipticalShape { public abstract double area( ); public abstract double circumference( ); } public interface Cashier { public void deposit(int id, double amount); public boolean withdraw(int id, double amount); }

38 Componentes de software Abstract Class Can include class and instance fields May include concrete implementations of methods A concrete class can only extend a single abstract class Interface Can only include static final fields All methods must be abstract declarations - no implementation A class can implement multiple interfaces

39 Componentes de software Interface / Abstract class public abstract class EllipticalShape { public abstract double area( ); public abstract double circumference( ); } public interface Cashier { public void deposit(int id, double amount); public boolean withdraw(int id, double amount); }

40 Componentes de software Design Guideline: “When the functionality supported by a class can be implemented in different ways, it is advisable to separate the interface from the implementation” Xiaoping Jia Object-Oriented Software Development Using Java

41 Class V Interface Uma classe define o estado interno do objecto e a implementação das suas operações. Um tipo de objectos apenas se refere à sua interface – conjunto de pedidos a que pode responder Um objecto pode ter vários tipos e objectos de várias classes podem ser do mesmo tipo. Herança de classes define uma implementação do objecto baseada na implementação de outro objecto – super Herança de interface ( subtyping) descreve quando um objecto pode ser usado no lugar de outro

42 Componentes de software List as an example public interface List { public int size( ); public boolean isEmpty( ); public Object element(int i); public Object head( ); public Object last( ); public void insert(Object item, int i); public void insertHead(Object item); public void insertLast(Object item); // more… }

43 Componentes de software Implementations of List We can have several different implementations of the List interface: public class LinkedList implements List { } or: public class DynamicArray implements List { }

44 Componentes de software Interfaces (cont) Separar a interface da implementação permite múltiplas implementações da mesma ideia. Para manter o código genérico, deve-se trabalhar com a interface e não com o tipo de uma implementação particular Separar a interface da implementação permite alterar a implementação sem afectar a interface Permite alterar a implementação sem afectar os clientes dessa interface Clientes não estão ligados às classes de implementação As interfaces devem ser imutáveis de modo a não quebrar o contracto estabelecido com os clientes Herança de interfaces permite o “upgrade” de uma interface. Uma variável do tipo interface pode fazer referência a qualquer objecto que implemente essa interface Programming to an Interface, not an Implementation [ GOF Design Patterns: Elements of Reusable Object-Oriented Software. ]Design Patterns: Elements of Reusable Object-Oriented Software

45 Componentes de software Meyer: "Seven Criteria for Components“"Seven Criteria for Components“ May be used by other software elements (clients). May be used by clients without the intervention of the component's developers. Includes a specification of all dependencies (hardware and software platform, versions, other components). Includes a precise specification of the functionalities it offers. Is usable on the sole basis of that specification. Is composable with other components. Can be integrated into a system quickly and smoothly.

46 Design by Contract DBC was first introduced by Bertrand Meyer as part of the Eiffel Project. Under the DBC theory, a software system is viewed as a set of communicating components whose interaction is based on precisely defined specifications of the mutual obligations – contracts. DBC provides a formal way to incorporate specification information, which is obtained from comments, into the code. By doing this, the code’s implicit contracts are transformed into explicit requirements that must be satisfied.