Embed Size (px)
Citation preview
1
Engenharia de Software20071
Projeto com Reuso310507
2
Reutilizaccedilatildeo de software Na maioria das disciplinas de engenharia sistemas
satildeo projetados com base na composiccedilatildeo de componentes existentes que foram utilizados em outros sistemas
A engenharia de software ateacute entatildeo tinha como base o desenvolvimento tradicional
Para alcanccedilar software com mais qualidade de forma mais raacutepida e com baixo custo eacute necessaacuterio adotar um processo de desenvolvimento baseado na reutilizaccedilatildeo generalizada e sistemaacutetica de software
3
Engenharia de software baseado no reuso de software Reuso de sistemas de aplicaccedilotildees
Todo o sistema pode ser reutilizado pela sua incorporaccedilatildeo sem mudanccedila em outros sistemas
Reuso de Componentes Componentes de uma aplicaccedilatildeo que variam
desde subsistemas ateacute objetos isolados podem ser reutilizados
Reuso de funccedilotildees Componentes de software que implementam uma
uacutenica funccedilatildeo podem ser reutilizados
4
Artefatos reusaacuteveisAfinal o que se pode ldquoreusarrdquo
Coacutedigo compiladoCasos de testesModelos e projetos frameworks e padrotildees Interface de usuaacuterioPlanos estrateacutegias e regras arquiteturaisSoluccedilotildees Ideacuteias
5
Reuso de SoftwareldquoSoftware reuse is the use of existing
software knowledge or artifacts to build new software artifactsrdquo [Frakes 1995]
Vantagens (em POTENCIAL)MAIS QualidadeMENOS Tempo de desenvolvimentoMENORES custos TOTAIS no ciclo de vida
Implementaccedilatildeo testes integraccedilatildeo documentaccedilatildeo manutenccedilatildeo evoluccedilatildeo
6
Benefiacutecios do Reuso Maior confiabilidade
Os componentes jaacute foram experimentados e testados em sistemas que jaacute estatildeo funcionando
Reduccedilatildeo dos riscos de processo Menos incertezas sobre as estimativas de custos de
desenvolvimento Uso efetivo de especialistas
Reuso de componentes ao inveacutes de pessoas Conformidade com padrotildees
Os padrotildees satildeo embutidos ao se reutilizar componentes Ex padrotildees de interfaces com o usuaacuterio
Desenvolvimento acelerado Reduz tempo do desenvolvimento e validaccedilatildeo acelerando
a produccedilatildeo
7
Resumindo -gt Produtividade Trabalhar mais raacutepido
Automaccedilatildeo ambientes ferramentasSubstituir trabalho humano
Trabalhar mais inteligentementeMelhoria do(s) processo(s)Evitarreduzir tarefas de pouco valor
Evitar o trabalho propriamente ditoReuso de ARTEFATOS do CICLO DE VIDA
Evitarreduzir o desenvolvimento de artefatos especiacuteficos para cada projeto
Benefiacutecios do Reuso
8
Modelo Incremental para adoccedilatildeo de Reuso
None
Code leverage
Black box code reuse
Managed workproducts
Architecturereuse
Systematic Domain- specific reuse
Reduced Developmenttime
Reduced maintenance costs
Broader coverage
High reuse levels
Reuse enabled business
Investment experience
Benefit
9
O que satildeo Padrotildees O que eacute
Nova categoria de conhecimentoConhecimento natildeo eacute novo mas falar sobre ele eacuteObjetivo conhecer o que vocecirc jaacute conhece
Como Partindo de problemas e soluccedilotildees recorrentes
em diferentes aacutereas do conhecimento
10
O que eacute um Padratildeo (Cont) Aplicaccedilatildeo
Arquitetura Ciecircncia da Computaccedilatildeo
Engenharia de software Engenharia Mecacircnica Telecomunicaccedilotildees
11
O que eacute um Padratildeo (Cont) Por que padrotildees de software
engenheiros de software natildeo iniciam o seu projeto do nada
ao contraacuterio noacutes reutilizamos ldquoideacuteiasrdquoque jaacute vimos antes
as mesmas teacutecnicas satildeo utilizadas repetitivamente
a induacutestria de software necessita documentar o que noacutes fazemos
12
Diferentes Definiccedilotildees ldquoUm padratildeo eacute uma entidade que descreve
um problema que ocorre repetidamente em um ambiente e entatildeo descreve a essecircncia da soluccedilatildeo para este problema de tal forma que vocecirc use esta soluccedilatildeo milhotildees de vezes sem nunca utilizaacute-la do mesmo modordquo Christopher Alexander
13
Diferentes Definiccedilotildees (Cont) ldquoUm padratildeo eacute um pedaccedilo de literatura que
descreve um problema de projeto e uma soluccedilatildeo geral para o problema num contexto particular rdquo James Coplien
14
Diferentes Definiccedilotildees (Cont) ldquoUm padratildeo eacute uma soluccedilatildeo provada para um
problema em um contexto rdquo Comunidade de Software
15
Um Pouco da Histoacuteria Object-Oriented (OO)
Metade do anos 80 Padrotildees de software emergiram de objetos Ward Cunningham and Kent Beck
1987 linguagem de padrotildees para interface de usuaacuterio James Coplien
1988 idioms Erich Gamma Richard Helm Ralph Johnson and John
Vlissides 1990 1995 Padrotildees de projeto (Design Patterns)
16
Diferentes tipos de padrotildees Etapas de Desenvolvimento de Sistemas
Requisitos Anaacutelise Projeto Implementaccedilatildeo e Teste Domiacutenio de Aplicaccedilatildeo
Seguranccedila BD GUI XML Web Sistemas Distribuiacutedos
Camada de Aplicaccedilatildeo do Padratildeo Negoacutecios Apresentaccedilatildeo Integraccedilatildeo (Sun)
Classificaccedilatildeo de Autores GoF Estrutural Comportamental Criaccedilatildeo POSA Sistemas Interativos Organizaccedilatildeo do
Trabalho Comunicaccedilatildeo
17
Classificaccedilatildeo dos Padrotildees de Software (Cont)
Requisitos Anaacutelise Projeto Implementaccedilatildeo
Padrotildees de Requisitos
Padrotildees de Anaacutelise
Padrotildees de Projeto
Meta-Padrotildees
Padrotildees Arquiteturais
Idiomas
18
Padrotildees de Requisitos Documentam as necessidades do usuaacuterio e
o comportamento geneacuterico do sistema em um alto niacutevel de abstraccedilatildeo
Accedilotildees que os desenvolvedores de software podem tomar para melhorar os requisitos natildeo-funcionais
Mostram os relacionamentos entre o usuaacuterio ou o operador e o sistema
19
Padrotildees de Requisitos (Cont)
Fault-tolerant telecommunication patterns Visa a manutenccedilatildeo dos sistemas de comutaccedilatildeo Medidas apropriadas para serem tomadas no estaacutegio
de desenvolvimento de requisitos Padrotildees relacionados a confiabilidade (mensagens
do sistema e falhas do sistema) Five minutes of no escalation messages
Padrotildees relacionados aos fatores humanos
20
Padrotildees de Anaacutelise Inicialmente apresentados como complementos
aos padrotildees de projeto Um passo antes do projeto
Modelo de anaacutelise que focaliza nas estruturas conceituais
Padrotildees de anaacutelise do Martin Fowler Domiacutenio de conhecimento de software de negoacutecios Party quantity subtype state machines entre outros
21
Padrotildees de Anaacutelise (Cont) Party Problema pessoas e organizaccedilotildees tecircm
responsabilidades semelhantes Soluccedilatildeo Crie um tipo party como um
supertype de uma pessoa ou organizaccedilatildeo
22
Padrotildees de Projeto Estrutura repetida de elementos de projeto ldquoUm esquema para o refinamento de subsistemas ou de
componentes de sistemas ou as relaccedilotildees entre elesrdquo ldquoresolvem um problema geral de projeto num contexto particularrdquo GoF
Padrotildees de projeto que incluem detalhes de coacutedigo de baixo niacutevel
Aplicados a diferentes tipos de problemas Padrotildees Arquiteturais e Meta-Padrotildees podem ser
considerados Padrotildees de Projeto
23
Idiomas Relacionados com a implementaccedilatildeo de
caracteriacutesticas de projeto especiacuteficas Padratildeo de baixo niacutevel especiacutefico para uma
linguagem de programaccedilatildeo Idiomas em C++
C++ Programming Styles and Idioms James Coplien 1991
24
Idiomas (Cont)
Nome Counted Body Contexto A interface de uma classe eacute separada de sua
implementaccedilatildeo (respectivamente classes handle e body) Problema atribuiccedilatildeo em C++ eacute definida recursivamente
como membro-por-membro com coacutepia quando a recursatildeo termina
Soluccedilatildeo Um contador de referecircncia eacute adicionado agrave classe body para facilitar o gerenciamento de memoacuteria
Autor e data James Coplien 1994
25
A Comunidade de Padrotildees
Uma hierarquia de workshops de escritores Grupos de leitura local Grupo Hillside Livros com os artigos da conferecircncia Conferecircncias PLoP ao redor do mundo
26
Eacutetica de Padrotildees Regra de Buschmann nunca capture suas
proacuteprias ideacuteias em um padratildeo Natildeo pense que padrotildees resolvem tudo Tente sempre encorajar as pessoas a repassar os
conhecimentos Sempre reconheccedila aqueles que criaram as
teacutecnicas ou que primeiro se empenharam a escrever sobre elas
Padrotildees satildeo ldquoapenasrdquo mais uma teacutecnica para ajudaacute-lo no desenvolvimento de software
27
Reuso
Conheccedila os padrotildees que estatildeo disponiacuteveis Cataacutelogo de padrotildees de 2000 Escolha aquele que satisfaz as suas necessidades
Um padratildeo eacute difiacutecil de entender se vocecirc natildeo necessita dele
Apenas tenha uma visatildeo geral Utilize o vocabulaacuterio dos padrotildees em revisotildees e
sessotildees de projeto
28
Reuso (Cont) GoF
Bastante utilizado entre a comunidade de software Core J2EE Pattern Catalog
httpjavasuncomblueprintscorej2eepatterns Padrotildees Arquiteturais
Frank Bushmann Regine Meunier Hans Rohnert Peter Sommerlad Michael Stal (Gang of Five)
29
GoF Design Patterns
Creational patternsAbstract factory BuilderFactory method Prototype Singleton
Behavioral PatternsChain of Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor
Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
2
Reutilizaccedilatildeo de software Na maioria das disciplinas de engenharia sistemas
satildeo projetados com base na composiccedilatildeo de componentes existentes que foram utilizados em outros sistemas
A engenharia de software ateacute entatildeo tinha como base o desenvolvimento tradicional
Para alcanccedilar software com mais qualidade de forma mais raacutepida e com baixo custo eacute necessaacuterio adotar um processo de desenvolvimento baseado na reutilizaccedilatildeo generalizada e sistemaacutetica de software
3
Engenharia de software baseado no reuso de software Reuso de sistemas de aplicaccedilotildees
Todo o sistema pode ser reutilizado pela sua incorporaccedilatildeo sem mudanccedila em outros sistemas
Reuso de Componentes Componentes de uma aplicaccedilatildeo que variam
desde subsistemas ateacute objetos isolados podem ser reutilizados
Reuso de funccedilotildees Componentes de software que implementam uma
uacutenica funccedilatildeo podem ser reutilizados
4
Artefatos reusaacuteveisAfinal o que se pode ldquoreusarrdquo
Coacutedigo compiladoCasos de testesModelos e projetos frameworks e padrotildees Interface de usuaacuterioPlanos estrateacutegias e regras arquiteturaisSoluccedilotildees Ideacuteias
5
Reuso de SoftwareldquoSoftware reuse is the use of existing
software knowledge or artifacts to build new software artifactsrdquo [Frakes 1995]
Vantagens (em POTENCIAL)MAIS QualidadeMENOS Tempo de desenvolvimentoMENORES custos TOTAIS no ciclo de vida
Implementaccedilatildeo testes integraccedilatildeo documentaccedilatildeo manutenccedilatildeo evoluccedilatildeo
6
Benefiacutecios do Reuso Maior confiabilidade
Os componentes jaacute foram experimentados e testados em sistemas que jaacute estatildeo funcionando
Reduccedilatildeo dos riscos de processo Menos incertezas sobre as estimativas de custos de
desenvolvimento Uso efetivo de especialistas
Reuso de componentes ao inveacutes de pessoas Conformidade com padrotildees
Os padrotildees satildeo embutidos ao se reutilizar componentes Ex padrotildees de interfaces com o usuaacuterio
Desenvolvimento acelerado Reduz tempo do desenvolvimento e validaccedilatildeo acelerando
a produccedilatildeo
7
Resumindo -gt Produtividade Trabalhar mais raacutepido
Automaccedilatildeo ambientes ferramentasSubstituir trabalho humano
Trabalhar mais inteligentementeMelhoria do(s) processo(s)Evitarreduzir tarefas de pouco valor
Evitar o trabalho propriamente ditoReuso de ARTEFATOS do CICLO DE VIDA
Evitarreduzir o desenvolvimento de artefatos especiacuteficos para cada projeto
Benefiacutecios do Reuso
8
Modelo Incremental para adoccedilatildeo de Reuso
None
Code leverage
Black box code reuse
Managed workproducts
Architecturereuse
Systematic Domain- specific reuse
Reduced Developmenttime
Reduced maintenance costs
Broader coverage
High reuse levels
Reuse enabled business
Investment experience
Benefit
9
O que satildeo Padrotildees O que eacute
Nova categoria de conhecimentoConhecimento natildeo eacute novo mas falar sobre ele eacuteObjetivo conhecer o que vocecirc jaacute conhece
Como Partindo de problemas e soluccedilotildees recorrentes
em diferentes aacutereas do conhecimento
10
O que eacute um Padratildeo (Cont) Aplicaccedilatildeo
Arquitetura Ciecircncia da Computaccedilatildeo
Engenharia de software Engenharia Mecacircnica Telecomunicaccedilotildees
11
O que eacute um Padratildeo (Cont) Por que padrotildees de software
engenheiros de software natildeo iniciam o seu projeto do nada
ao contraacuterio noacutes reutilizamos ldquoideacuteiasrdquoque jaacute vimos antes
as mesmas teacutecnicas satildeo utilizadas repetitivamente
a induacutestria de software necessita documentar o que noacutes fazemos
12
Diferentes Definiccedilotildees ldquoUm padratildeo eacute uma entidade que descreve
um problema que ocorre repetidamente em um ambiente e entatildeo descreve a essecircncia da soluccedilatildeo para este problema de tal forma que vocecirc use esta soluccedilatildeo milhotildees de vezes sem nunca utilizaacute-la do mesmo modordquo Christopher Alexander
13
Diferentes Definiccedilotildees (Cont) ldquoUm padratildeo eacute um pedaccedilo de literatura que
descreve um problema de projeto e uma soluccedilatildeo geral para o problema num contexto particular rdquo James Coplien
14
Diferentes Definiccedilotildees (Cont) ldquoUm padratildeo eacute uma soluccedilatildeo provada para um
problema em um contexto rdquo Comunidade de Software
15
Um Pouco da Histoacuteria Object-Oriented (OO)
Metade do anos 80 Padrotildees de software emergiram de objetos Ward Cunningham and Kent Beck
1987 linguagem de padrotildees para interface de usuaacuterio James Coplien
1988 idioms Erich Gamma Richard Helm Ralph Johnson and John
Vlissides 1990 1995 Padrotildees de projeto (Design Patterns)
16
Diferentes tipos de padrotildees Etapas de Desenvolvimento de Sistemas
Requisitos Anaacutelise Projeto Implementaccedilatildeo e Teste Domiacutenio de Aplicaccedilatildeo
Seguranccedila BD GUI XML Web Sistemas Distribuiacutedos
Camada de Aplicaccedilatildeo do Padratildeo Negoacutecios Apresentaccedilatildeo Integraccedilatildeo (Sun)
Classificaccedilatildeo de Autores GoF Estrutural Comportamental Criaccedilatildeo POSA Sistemas Interativos Organizaccedilatildeo do
Trabalho Comunicaccedilatildeo
17
Classificaccedilatildeo dos Padrotildees de Software (Cont)
Requisitos Anaacutelise Projeto Implementaccedilatildeo
Padrotildees de Requisitos
Padrotildees de Anaacutelise
Padrotildees de Projeto
Meta-Padrotildees
Padrotildees Arquiteturais
Idiomas
18
Padrotildees de Requisitos Documentam as necessidades do usuaacuterio e
o comportamento geneacuterico do sistema em um alto niacutevel de abstraccedilatildeo
Accedilotildees que os desenvolvedores de software podem tomar para melhorar os requisitos natildeo-funcionais
Mostram os relacionamentos entre o usuaacuterio ou o operador e o sistema
19
Padrotildees de Requisitos (Cont)
Fault-tolerant telecommunication patterns Visa a manutenccedilatildeo dos sistemas de comutaccedilatildeo Medidas apropriadas para serem tomadas no estaacutegio
de desenvolvimento de requisitos Padrotildees relacionados a confiabilidade (mensagens
do sistema e falhas do sistema) Five minutes of no escalation messages
Padrotildees relacionados aos fatores humanos
20
Padrotildees de Anaacutelise Inicialmente apresentados como complementos
aos padrotildees de projeto Um passo antes do projeto
Modelo de anaacutelise que focaliza nas estruturas conceituais
Padrotildees de anaacutelise do Martin Fowler Domiacutenio de conhecimento de software de negoacutecios Party quantity subtype state machines entre outros
21
Padrotildees de Anaacutelise (Cont) Party Problema pessoas e organizaccedilotildees tecircm
responsabilidades semelhantes Soluccedilatildeo Crie um tipo party como um
supertype de uma pessoa ou organizaccedilatildeo
22
Padrotildees de Projeto Estrutura repetida de elementos de projeto ldquoUm esquema para o refinamento de subsistemas ou de
componentes de sistemas ou as relaccedilotildees entre elesrdquo ldquoresolvem um problema geral de projeto num contexto particularrdquo GoF
Padrotildees de projeto que incluem detalhes de coacutedigo de baixo niacutevel
Aplicados a diferentes tipos de problemas Padrotildees Arquiteturais e Meta-Padrotildees podem ser
considerados Padrotildees de Projeto
23
Idiomas Relacionados com a implementaccedilatildeo de
caracteriacutesticas de projeto especiacuteficas Padratildeo de baixo niacutevel especiacutefico para uma
linguagem de programaccedilatildeo Idiomas em C++
C++ Programming Styles and Idioms James Coplien 1991
24
Idiomas (Cont)
Nome Counted Body Contexto A interface de uma classe eacute separada de sua
implementaccedilatildeo (respectivamente classes handle e body) Problema atribuiccedilatildeo em C++ eacute definida recursivamente
como membro-por-membro com coacutepia quando a recursatildeo termina
Soluccedilatildeo Um contador de referecircncia eacute adicionado agrave classe body para facilitar o gerenciamento de memoacuteria
Autor e data James Coplien 1994
25
A Comunidade de Padrotildees
Uma hierarquia de workshops de escritores Grupos de leitura local Grupo Hillside Livros com os artigos da conferecircncia Conferecircncias PLoP ao redor do mundo
26
Eacutetica de Padrotildees Regra de Buschmann nunca capture suas
proacuteprias ideacuteias em um padratildeo Natildeo pense que padrotildees resolvem tudo Tente sempre encorajar as pessoas a repassar os
conhecimentos Sempre reconheccedila aqueles que criaram as
teacutecnicas ou que primeiro se empenharam a escrever sobre elas
Padrotildees satildeo ldquoapenasrdquo mais uma teacutecnica para ajudaacute-lo no desenvolvimento de software
27
Reuso
Conheccedila os padrotildees que estatildeo disponiacuteveis Cataacutelogo de padrotildees de 2000 Escolha aquele que satisfaz as suas necessidades
Um padratildeo eacute difiacutecil de entender se vocecirc natildeo necessita dele
Apenas tenha uma visatildeo geral Utilize o vocabulaacuterio dos padrotildees em revisotildees e
sessotildees de projeto
28
Reuso (Cont) GoF
Bastante utilizado entre a comunidade de software Core J2EE Pattern Catalog
httpjavasuncomblueprintscorej2eepatterns Padrotildees Arquiteturais
Frank Bushmann Regine Meunier Hans Rohnert Peter Sommerlad Michael Stal (Gang of Five)
29
GoF Design Patterns
Creational patternsAbstract factory BuilderFactory method Prototype Singleton
Behavioral PatternsChain of Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor
Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
3
Engenharia de software baseado no reuso de software Reuso de sistemas de aplicaccedilotildees
Todo o sistema pode ser reutilizado pela sua incorporaccedilatildeo sem mudanccedila em outros sistemas
Reuso de Componentes Componentes de uma aplicaccedilatildeo que variam
desde subsistemas ateacute objetos isolados podem ser reutilizados
Reuso de funccedilotildees Componentes de software que implementam uma
uacutenica funccedilatildeo podem ser reutilizados
4
Artefatos reusaacuteveisAfinal o que se pode ldquoreusarrdquo
Coacutedigo compiladoCasos de testesModelos e projetos frameworks e padrotildees Interface de usuaacuterioPlanos estrateacutegias e regras arquiteturaisSoluccedilotildees Ideacuteias
5
Reuso de SoftwareldquoSoftware reuse is the use of existing
software knowledge or artifacts to build new software artifactsrdquo [Frakes 1995]
Vantagens (em POTENCIAL)MAIS QualidadeMENOS Tempo de desenvolvimentoMENORES custos TOTAIS no ciclo de vida
Implementaccedilatildeo testes integraccedilatildeo documentaccedilatildeo manutenccedilatildeo evoluccedilatildeo
6
Benefiacutecios do Reuso Maior confiabilidade
Os componentes jaacute foram experimentados e testados em sistemas que jaacute estatildeo funcionando
Reduccedilatildeo dos riscos de processo Menos incertezas sobre as estimativas de custos de
desenvolvimento Uso efetivo de especialistas
Reuso de componentes ao inveacutes de pessoas Conformidade com padrotildees
Os padrotildees satildeo embutidos ao se reutilizar componentes Ex padrotildees de interfaces com o usuaacuterio
Desenvolvimento acelerado Reduz tempo do desenvolvimento e validaccedilatildeo acelerando
a produccedilatildeo
7
Resumindo -gt Produtividade Trabalhar mais raacutepido
Automaccedilatildeo ambientes ferramentasSubstituir trabalho humano
Trabalhar mais inteligentementeMelhoria do(s) processo(s)Evitarreduzir tarefas de pouco valor
Evitar o trabalho propriamente ditoReuso de ARTEFATOS do CICLO DE VIDA
Evitarreduzir o desenvolvimento de artefatos especiacuteficos para cada projeto
Benefiacutecios do Reuso
8
Modelo Incremental para adoccedilatildeo de Reuso
None
Code leverage
Black box code reuse
Managed workproducts
Architecturereuse
Systematic Domain- specific reuse
Reduced Developmenttime
Reduced maintenance costs
Broader coverage
High reuse levels
Reuse enabled business
Investment experience
Benefit
9
O que satildeo Padrotildees O que eacute
Nova categoria de conhecimentoConhecimento natildeo eacute novo mas falar sobre ele eacuteObjetivo conhecer o que vocecirc jaacute conhece
Como Partindo de problemas e soluccedilotildees recorrentes
em diferentes aacutereas do conhecimento
10
O que eacute um Padratildeo (Cont) Aplicaccedilatildeo
Arquitetura Ciecircncia da Computaccedilatildeo
Engenharia de software Engenharia Mecacircnica Telecomunicaccedilotildees
11
O que eacute um Padratildeo (Cont) Por que padrotildees de software
engenheiros de software natildeo iniciam o seu projeto do nada
ao contraacuterio noacutes reutilizamos ldquoideacuteiasrdquoque jaacute vimos antes
as mesmas teacutecnicas satildeo utilizadas repetitivamente
a induacutestria de software necessita documentar o que noacutes fazemos
12
Diferentes Definiccedilotildees ldquoUm padratildeo eacute uma entidade que descreve
um problema que ocorre repetidamente em um ambiente e entatildeo descreve a essecircncia da soluccedilatildeo para este problema de tal forma que vocecirc use esta soluccedilatildeo milhotildees de vezes sem nunca utilizaacute-la do mesmo modordquo Christopher Alexander
13
Diferentes Definiccedilotildees (Cont) ldquoUm padratildeo eacute um pedaccedilo de literatura que
descreve um problema de projeto e uma soluccedilatildeo geral para o problema num contexto particular rdquo James Coplien
14
Diferentes Definiccedilotildees (Cont) ldquoUm padratildeo eacute uma soluccedilatildeo provada para um
problema em um contexto rdquo Comunidade de Software
15
Um Pouco da Histoacuteria Object-Oriented (OO)
Metade do anos 80 Padrotildees de software emergiram de objetos Ward Cunningham and Kent Beck
1987 linguagem de padrotildees para interface de usuaacuterio James Coplien
1988 idioms Erich Gamma Richard Helm Ralph Johnson and John
Vlissides 1990 1995 Padrotildees de projeto (Design Patterns)
16
Diferentes tipos de padrotildees Etapas de Desenvolvimento de Sistemas
Requisitos Anaacutelise Projeto Implementaccedilatildeo e Teste Domiacutenio de Aplicaccedilatildeo
Seguranccedila BD GUI XML Web Sistemas Distribuiacutedos
Camada de Aplicaccedilatildeo do Padratildeo Negoacutecios Apresentaccedilatildeo Integraccedilatildeo (Sun)
Classificaccedilatildeo de Autores GoF Estrutural Comportamental Criaccedilatildeo POSA Sistemas Interativos Organizaccedilatildeo do
Trabalho Comunicaccedilatildeo
17
Classificaccedilatildeo dos Padrotildees de Software (Cont)
Requisitos Anaacutelise Projeto Implementaccedilatildeo
Padrotildees de Requisitos
Padrotildees de Anaacutelise
Padrotildees de Projeto
Meta-Padrotildees
Padrotildees Arquiteturais
Idiomas
18
Padrotildees de Requisitos Documentam as necessidades do usuaacuterio e
o comportamento geneacuterico do sistema em um alto niacutevel de abstraccedilatildeo
Accedilotildees que os desenvolvedores de software podem tomar para melhorar os requisitos natildeo-funcionais
Mostram os relacionamentos entre o usuaacuterio ou o operador e o sistema
19
Padrotildees de Requisitos (Cont)
Fault-tolerant telecommunication patterns Visa a manutenccedilatildeo dos sistemas de comutaccedilatildeo Medidas apropriadas para serem tomadas no estaacutegio
de desenvolvimento de requisitos Padrotildees relacionados a confiabilidade (mensagens
do sistema e falhas do sistema) Five minutes of no escalation messages
Padrotildees relacionados aos fatores humanos
20
Padrotildees de Anaacutelise Inicialmente apresentados como complementos
aos padrotildees de projeto Um passo antes do projeto
Modelo de anaacutelise que focaliza nas estruturas conceituais
Padrotildees de anaacutelise do Martin Fowler Domiacutenio de conhecimento de software de negoacutecios Party quantity subtype state machines entre outros
21
Padrotildees de Anaacutelise (Cont) Party Problema pessoas e organizaccedilotildees tecircm
responsabilidades semelhantes Soluccedilatildeo Crie um tipo party como um
supertype de uma pessoa ou organizaccedilatildeo
22
Padrotildees de Projeto Estrutura repetida de elementos de projeto ldquoUm esquema para o refinamento de subsistemas ou de
componentes de sistemas ou as relaccedilotildees entre elesrdquo ldquoresolvem um problema geral de projeto num contexto particularrdquo GoF
Padrotildees de projeto que incluem detalhes de coacutedigo de baixo niacutevel
Aplicados a diferentes tipos de problemas Padrotildees Arquiteturais e Meta-Padrotildees podem ser
considerados Padrotildees de Projeto
23
Idiomas Relacionados com a implementaccedilatildeo de
caracteriacutesticas de projeto especiacuteficas Padratildeo de baixo niacutevel especiacutefico para uma
linguagem de programaccedilatildeo Idiomas em C++
C++ Programming Styles and Idioms James Coplien 1991
24
Idiomas (Cont)
Nome Counted Body Contexto A interface de uma classe eacute separada de sua
implementaccedilatildeo (respectivamente classes handle e body) Problema atribuiccedilatildeo em C++ eacute definida recursivamente
como membro-por-membro com coacutepia quando a recursatildeo termina
Soluccedilatildeo Um contador de referecircncia eacute adicionado agrave classe body para facilitar o gerenciamento de memoacuteria
Autor e data James Coplien 1994
25
A Comunidade de Padrotildees
Uma hierarquia de workshops de escritores Grupos de leitura local Grupo Hillside Livros com os artigos da conferecircncia Conferecircncias PLoP ao redor do mundo
26
Eacutetica de Padrotildees Regra de Buschmann nunca capture suas
proacuteprias ideacuteias em um padratildeo Natildeo pense que padrotildees resolvem tudo Tente sempre encorajar as pessoas a repassar os
conhecimentos Sempre reconheccedila aqueles que criaram as
teacutecnicas ou que primeiro se empenharam a escrever sobre elas
Padrotildees satildeo ldquoapenasrdquo mais uma teacutecnica para ajudaacute-lo no desenvolvimento de software
27
Reuso
Conheccedila os padrotildees que estatildeo disponiacuteveis Cataacutelogo de padrotildees de 2000 Escolha aquele que satisfaz as suas necessidades
Um padratildeo eacute difiacutecil de entender se vocecirc natildeo necessita dele
Apenas tenha uma visatildeo geral Utilize o vocabulaacuterio dos padrotildees em revisotildees e
sessotildees de projeto
28
Reuso (Cont) GoF
Bastante utilizado entre a comunidade de software Core J2EE Pattern Catalog
httpjavasuncomblueprintscorej2eepatterns Padrotildees Arquiteturais
Frank Bushmann Regine Meunier Hans Rohnert Peter Sommerlad Michael Stal (Gang of Five)
29
GoF Design Patterns
Creational patternsAbstract factory BuilderFactory method Prototype Singleton
Behavioral PatternsChain of Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor
Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
4
Artefatos reusaacuteveisAfinal o que se pode ldquoreusarrdquo
Coacutedigo compiladoCasos de testesModelos e projetos frameworks e padrotildees Interface de usuaacuterioPlanos estrateacutegias e regras arquiteturaisSoluccedilotildees Ideacuteias
5
Reuso de SoftwareldquoSoftware reuse is the use of existing
software knowledge or artifacts to build new software artifactsrdquo [Frakes 1995]
Vantagens (em POTENCIAL)MAIS QualidadeMENOS Tempo de desenvolvimentoMENORES custos TOTAIS no ciclo de vida
Implementaccedilatildeo testes integraccedilatildeo documentaccedilatildeo manutenccedilatildeo evoluccedilatildeo
6
Benefiacutecios do Reuso Maior confiabilidade
Os componentes jaacute foram experimentados e testados em sistemas que jaacute estatildeo funcionando
Reduccedilatildeo dos riscos de processo Menos incertezas sobre as estimativas de custos de
desenvolvimento Uso efetivo de especialistas
Reuso de componentes ao inveacutes de pessoas Conformidade com padrotildees
Os padrotildees satildeo embutidos ao se reutilizar componentes Ex padrotildees de interfaces com o usuaacuterio
Desenvolvimento acelerado Reduz tempo do desenvolvimento e validaccedilatildeo acelerando
a produccedilatildeo
7
Resumindo -gt Produtividade Trabalhar mais raacutepido
Automaccedilatildeo ambientes ferramentasSubstituir trabalho humano
Trabalhar mais inteligentementeMelhoria do(s) processo(s)Evitarreduzir tarefas de pouco valor
Evitar o trabalho propriamente ditoReuso de ARTEFATOS do CICLO DE VIDA
Evitarreduzir o desenvolvimento de artefatos especiacuteficos para cada projeto
Benefiacutecios do Reuso
8
Modelo Incremental para adoccedilatildeo de Reuso
None
Code leverage
Black box code reuse
Managed workproducts
Architecturereuse
Systematic Domain- specific reuse
Reduced Developmenttime
Reduced maintenance costs
Broader coverage
High reuse levels
Reuse enabled business
Investment experience
Benefit
9
O que satildeo Padrotildees O que eacute
Nova categoria de conhecimentoConhecimento natildeo eacute novo mas falar sobre ele eacuteObjetivo conhecer o que vocecirc jaacute conhece
Como Partindo de problemas e soluccedilotildees recorrentes
em diferentes aacutereas do conhecimento
10
O que eacute um Padratildeo (Cont) Aplicaccedilatildeo
Arquitetura Ciecircncia da Computaccedilatildeo
Engenharia de software Engenharia Mecacircnica Telecomunicaccedilotildees
11
O que eacute um Padratildeo (Cont) Por que padrotildees de software
engenheiros de software natildeo iniciam o seu projeto do nada
ao contraacuterio noacutes reutilizamos ldquoideacuteiasrdquoque jaacute vimos antes
as mesmas teacutecnicas satildeo utilizadas repetitivamente
a induacutestria de software necessita documentar o que noacutes fazemos
12
Diferentes Definiccedilotildees ldquoUm padratildeo eacute uma entidade que descreve
um problema que ocorre repetidamente em um ambiente e entatildeo descreve a essecircncia da soluccedilatildeo para este problema de tal forma que vocecirc use esta soluccedilatildeo milhotildees de vezes sem nunca utilizaacute-la do mesmo modordquo Christopher Alexander
13
Diferentes Definiccedilotildees (Cont) ldquoUm padratildeo eacute um pedaccedilo de literatura que
descreve um problema de projeto e uma soluccedilatildeo geral para o problema num contexto particular rdquo James Coplien
14
Diferentes Definiccedilotildees (Cont) ldquoUm padratildeo eacute uma soluccedilatildeo provada para um
problema em um contexto rdquo Comunidade de Software
15
Um Pouco da Histoacuteria Object-Oriented (OO)
Metade do anos 80 Padrotildees de software emergiram de objetos Ward Cunningham and Kent Beck
1987 linguagem de padrotildees para interface de usuaacuterio James Coplien
1988 idioms Erich Gamma Richard Helm Ralph Johnson and John
Vlissides 1990 1995 Padrotildees de projeto (Design Patterns)
16
Diferentes tipos de padrotildees Etapas de Desenvolvimento de Sistemas
Requisitos Anaacutelise Projeto Implementaccedilatildeo e Teste Domiacutenio de Aplicaccedilatildeo
Seguranccedila BD GUI XML Web Sistemas Distribuiacutedos
Camada de Aplicaccedilatildeo do Padratildeo Negoacutecios Apresentaccedilatildeo Integraccedilatildeo (Sun)
Classificaccedilatildeo de Autores GoF Estrutural Comportamental Criaccedilatildeo POSA Sistemas Interativos Organizaccedilatildeo do
Trabalho Comunicaccedilatildeo
17
Classificaccedilatildeo dos Padrotildees de Software (Cont)
Requisitos Anaacutelise Projeto Implementaccedilatildeo
Padrotildees de Requisitos
Padrotildees de Anaacutelise
Padrotildees de Projeto
Meta-Padrotildees
Padrotildees Arquiteturais
Idiomas
18
Padrotildees de Requisitos Documentam as necessidades do usuaacuterio e
o comportamento geneacuterico do sistema em um alto niacutevel de abstraccedilatildeo
Accedilotildees que os desenvolvedores de software podem tomar para melhorar os requisitos natildeo-funcionais
Mostram os relacionamentos entre o usuaacuterio ou o operador e o sistema
19
Padrotildees de Requisitos (Cont)
Fault-tolerant telecommunication patterns Visa a manutenccedilatildeo dos sistemas de comutaccedilatildeo Medidas apropriadas para serem tomadas no estaacutegio
de desenvolvimento de requisitos Padrotildees relacionados a confiabilidade (mensagens
do sistema e falhas do sistema) Five minutes of no escalation messages
Padrotildees relacionados aos fatores humanos
20
Padrotildees de Anaacutelise Inicialmente apresentados como complementos
aos padrotildees de projeto Um passo antes do projeto
Modelo de anaacutelise que focaliza nas estruturas conceituais
Padrotildees de anaacutelise do Martin Fowler Domiacutenio de conhecimento de software de negoacutecios Party quantity subtype state machines entre outros
21
Padrotildees de Anaacutelise (Cont) Party Problema pessoas e organizaccedilotildees tecircm
responsabilidades semelhantes Soluccedilatildeo Crie um tipo party como um
supertype de uma pessoa ou organizaccedilatildeo
22
Padrotildees de Projeto Estrutura repetida de elementos de projeto ldquoUm esquema para o refinamento de subsistemas ou de
componentes de sistemas ou as relaccedilotildees entre elesrdquo ldquoresolvem um problema geral de projeto num contexto particularrdquo GoF
Padrotildees de projeto que incluem detalhes de coacutedigo de baixo niacutevel
Aplicados a diferentes tipos de problemas Padrotildees Arquiteturais e Meta-Padrotildees podem ser
considerados Padrotildees de Projeto
23
Idiomas Relacionados com a implementaccedilatildeo de
caracteriacutesticas de projeto especiacuteficas Padratildeo de baixo niacutevel especiacutefico para uma
linguagem de programaccedilatildeo Idiomas em C++
C++ Programming Styles and Idioms James Coplien 1991
24
Idiomas (Cont)
Nome Counted Body Contexto A interface de uma classe eacute separada de sua
implementaccedilatildeo (respectivamente classes handle e body) Problema atribuiccedilatildeo em C++ eacute definida recursivamente
como membro-por-membro com coacutepia quando a recursatildeo termina
Soluccedilatildeo Um contador de referecircncia eacute adicionado agrave classe body para facilitar o gerenciamento de memoacuteria
Autor e data James Coplien 1994
25
A Comunidade de Padrotildees
Uma hierarquia de workshops de escritores Grupos de leitura local Grupo Hillside Livros com os artigos da conferecircncia Conferecircncias PLoP ao redor do mundo
26
Eacutetica de Padrotildees Regra de Buschmann nunca capture suas
proacuteprias ideacuteias em um padratildeo Natildeo pense que padrotildees resolvem tudo Tente sempre encorajar as pessoas a repassar os
conhecimentos Sempre reconheccedila aqueles que criaram as
teacutecnicas ou que primeiro se empenharam a escrever sobre elas
Padrotildees satildeo ldquoapenasrdquo mais uma teacutecnica para ajudaacute-lo no desenvolvimento de software
27
Reuso
Conheccedila os padrotildees que estatildeo disponiacuteveis Cataacutelogo de padrotildees de 2000 Escolha aquele que satisfaz as suas necessidades
Um padratildeo eacute difiacutecil de entender se vocecirc natildeo necessita dele
Apenas tenha uma visatildeo geral Utilize o vocabulaacuterio dos padrotildees em revisotildees e
sessotildees de projeto
28
Reuso (Cont) GoF
Bastante utilizado entre a comunidade de software Core J2EE Pattern Catalog
httpjavasuncomblueprintscorej2eepatterns Padrotildees Arquiteturais
Frank Bushmann Regine Meunier Hans Rohnert Peter Sommerlad Michael Stal (Gang of Five)
29
GoF Design Patterns
Creational patternsAbstract factory BuilderFactory method Prototype Singleton
Behavioral PatternsChain of Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor
Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
5
Reuso de SoftwareldquoSoftware reuse is the use of existing
software knowledge or artifacts to build new software artifactsrdquo [Frakes 1995]
Vantagens (em POTENCIAL)MAIS QualidadeMENOS Tempo de desenvolvimentoMENORES custos TOTAIS no ciclo de vida
Implementaccedilatildeo testes integraccedilatildeo documentaccedilatildeo manutenccedilatildeo evoluccedilatildeo
6
Benefiacutecios do Reuso Maior confiabilidade
Os componentes jaacute foram experimentados e testados em sistemas que jaacute estatildeo funcionando
Reduccedilatildeo dos riscos de processo Menos incertezas sobre as estimativas de custos de
desenvolvimento Uso efetivo de especialistas
Reuso de componentes ao inveacutes de pessoas Conformidade com padrotildees
Os padrotildees satildeo embutidos ao se reutilizar componentes Ex padrotildees de interfaces com o usuaacuterio
Desenvolvimento acelerado Reduz tempo do desenvolvimento e validaccedilatildeo acelerando
a produccedilatildeo
7
Resumindo -gt Produtividade Trabalhar mais raacutepido
Automaccedilatildeo ambientes ferramentasSubstituir trabalho humano
Trabalhar mais inteligentementeMelhoria do(s) processo(s)Evitarreduzir tarefas de pouco valor
Evitar o trabalho propriamente ditoReuso de ARTEFATOS do CICLO DE VIDA
Evitarreduzir o desenvolvimento de artefatos especiacuteficos para cada projeto
Benefiacutecios do Reuso
8
Modelo Incremental para adoccedilatildeo de Reuso
None
Code leverage
Black box code reuse
Managed workproducts
Architecturereuse
Systematic Domain- specific reuse
Reduced Developmenttime
Reduced maintenance costs
Broader coverage
High reuse levels
Reuse enabled business
Investment experience
Benefit
9
O que satildeo Padrotildees O que eacute
Nova categoria de conhecimentoConhecimento natildeo eacute novo mas falar sobre ele eacuteObjetivo conhecer o que vocecirc jaacute conhece
Como Partindo de problemas e soluccedilotildees recorrentes
em diferentes aacutereas do conhecimento
10
O que eacute um Padratildeo (Cont) Aplicaccedilatildeo
Arquitetura Ciecircncia da Computaccedilatildeo
Engenharia de software Engenharia Mecacircnica Telecomunicaccedilotildees
11
O que eacute um Padratildeo (Cont) Por que padrotildees de software
engenheiros de software natildeo iniciam o seu projeto do nada
ao contraacuterio noacutes reutilizamos ldquoideacuteiasrdquoque jaacute vimos antes
as mesmas teacutecnicas satildeo utilizadas repetitivamente
a induacutestria de software necessita documentar o que noacutes fazemos
12
Diferentes Definiccedilotildees ldquoUm padratildeo eacute uma entidade que descreve
um problema que ocorre repetidamente em um ambiente e entatildeo descreve a essecircncia da soluccedilatildeo para este problema de tal forma que vocecirc use esta soluccedilatildeo milhotildees de vezes sem nunca utilizaacute-la do mesmo modordquo Christopher Alexander
13
Diferentes Definiccedilotildees (Cont) ldquoUm padratildeo eacute um pedaccedilo de literatura que
descreve um problema de projeto e uma soluccedilatildeo geral para o problema num contexto particular rdquo James Coplien
14
Diferentes Definiccedilotildees (Cont) ldquoUm padratildeo eacute uma soluccedilatildeo provada para um
problema em um contexto rdquo Comunidade de Software
15
Um Pouco da Histoacuteria Object-Oriented (OO)
Metade do anos 80 Padrotildees de software emergiram de objetos Ward Cunningham and Kent Beck
1987 linguagem de padrotildees para interface de usuaacuterio James Coplien
1988 idioms Erich Gamma Richard Helm Ralph Johnson and John
Vlissides 1990 1995 Padrotildees de projeto (Design Patterns)
16
Diferentes tipos de padrotildees Etapas de Desenvolvimento de Sistemas
Requisitos Anaacutelise Projeto Implementaccedilatildeo e Teste Domiacutenio de Aplicaccedilatildeo
Seguranccedila BD GUI XML Web Sistemas Distribuiacutedos
Camada de Aplicaccedilatildeo do Padratildeo Negoacutecios Apresentaccedilatildeo Integraccedilatildeo (Sun)
Classificaccedilatildeo de Autores GoF Estrutural Comportamental Criaccedilatildeo POSA Sistemas Interativos Organizaccedilatildeo do
Trabalho Comunicaccedilatildeo
17
Classificaccedilatildeo dos Padrotildees de Software (Cont)
Requisitos Anaacutelise Projeto Implementaccedilatildeo
Padrotildees de Requisitos
Padrotildees de Anaacutelise
Padrotildees de Projeto
Meta-Padrotildees
Padrotildees Arquiteturais
Idiomas
18
Padrotildees de Requisitos Documentam as necessidades do usuaacuterio e
o comportamento geneacuterico do sistema em um alto niacutevel de abstraccedilatildeo
Accedilotildees que os desenvolvedores de software podem tomar para melhorar os requisitos natildeo-funcionais
Mostram os relacionamentos entre o usuaacuterio ou o operador e o sistema
19
Padrotildees de Requisitos (Cont)
Fault-tolerant telecommunication patterns Visa a manutenccedilatildeo dos sistemas de comutaccedilatildeo Medidas apropriadas para serem tomadas no estaacutegio
de desenvolvimento de requisitos Padrotildees relacionados a confiabilidade (mensagens
do sistema e falhas do sistema) Five minutes of no escalation messages
Padrotildees relacionados aos fatores humanos
20
Padrotildees de Anaacutelise Inicialmente apresentados como complementos
aos padrotildees de projeto Um passo antes do projeto
Modelo de anaacutelise que focaliza nas estruturas conceituais
Padrotildees de anaacutelise do Martin Fowler Domiacutenio de conhecimento de software de negoacutecios Party quantity subtype state machines entre outros
21
Padrotildees de Anaacutelise (Cont) Party Problema pessoas e organizaccedilotildees tecircm
responsabilidades semelhantes Soluccedilatildeo Crie um tipo party como um
supertype de uma pessoa ou organizaccedilatildeo
22
Padrotildees de Projeto Estrutura repetida de elementos de projeto ldquoUm esquema para o refinamento de subsistemas ou de
componentes de sistemas ou as relaccedilotildees entre elesrdquo ldquoresolvem um problema geral de projeto num contexto particularrdquo GoF
Padrotildees de projeto que incluem detalhes de coacutedigo de baixo niacutevel
Aplicados a diferentes tipos de problemas Padrotildees Arquiteturais e Meta-Padrotildees podem ser
considerados Padrotildees de Projeto
23
Idiomas Relacionados com a implementaccedilatildeo de
caracteriacutesticas de projeto especiacuteficas Padratildeo de baixo niacutevel especiacutefico para uma
linguagem de programaccedilatildeo Idiomas em C++
C++ Programming Styles and Idioms James Coplien 1991
24
Idiomas (Cont)
Nome Counted Body Contexto A interface de uma classe eacute separada de sua
implementaccedilatildeo (respectivamente classes handle e body) Problema atribuiccedilatildeo em C++ eacute definida recursivamente
como membro-por-membro com coacutepia quando a recursatildeo termina
Soluccedilatildeo Um contador de referecircncia eacute adicionado agrave classe body para facilitar o gerenciamento de memoacuteria
Autor e data James Coplien 1994
25
A Comunidade de Padrotildees
Uma hierarquia de workshops de escritores Grupos de leitura local Grupo Hillside Livros com os artigos da conferecircncia Conferecircncias PLoP ao redor do mundo
26
Eacutetica de Padrotildees Regra de Buschmann nunca capture suas
proacuteprias ideacuteias em um padratildeo Natildeo pense que padrotildees resolvem tudo Tente sempre encorajar as pessoas a repassar os
conhecimentos Sempre reconheccedila aqueles que criaram as
teacutecnicas ou que primeiro se empenharam a escrever sobre elas
Padrotildees satildeo ldquoapenasrdquo mais uma teacutecnica para ajudaacute-lo no desenvolvimento de software
27
Reuso
Conheccedila os padrotildees que estatildeo disponiacuteveis Cataacutelogo de padrotildees de 2000 Escolha aquele que satisfaz as suas necessidades
Um padratildeo eacute difiacutecil de entender se vocecirc natildeo necessita dele
Apenas tenha uma visatildeo geral Utilize o vocabulaacuterio dos padrotildees em revisotildees e
sessotildees de projeto
28
Reuso (Cont) GoF
Bastante utilizado entre a comunidade de software Core J2EE Pattern Catalog
httpjavasuncomblueprintscorej2eepatterns Padrotildees Arquiteturais
Frank Bushmann Regine Meunier Hans Rohnert Peter Sommerlad Michael Stal (Gang of Five)
29
GoF Design Patterns
Creational patternsAbstract factory BuilderFactory method Prototype Singleton
Behavioral PatternsChain of Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor
Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
6
Benefiacutecios do Reuso Maior confiabilidade
Os componentes jaacute foram experimentados e testados em sistemas que jaacute estatildeo funcionando
Reduccedilatildeo dos riscos de processo Menos incertezas sobre as estimativas de custos de
desenvolvimento Uso efetivo de especialistas
Reuso de componentes ao inveacutes de pessoas Conformidade com padrotildees
Os padrotildees satildeo embutidos ao se reutilizar componentes Ex padrotildees de interfaces com o usuaacuterio
Desenvolvimento acelerado Reduz tempo do desenvolvimento e validaccedilatildeo acelerando
a produccedilatildeo
7
Resumindo -gt Produtividade Trabalhar mais raacutepido
Automaccedilatildeo ambientes ferramentasSubstituir trabalho humano
Trabalhar mais inteligentementeMelhoria do(s) processo(s)Evitarreduzir tarefas de pouco valor
Evitar o trabalho propriamente ditoReuso de ARTEFATOS do CICLO DE VIDA
Evitarreduzir o desenvolvimento de artefatos especiacuteficos para cada projeto
Benefiacutecios do Reuso
8
Modelo Incremental para adoccedilatildeo de Reuso
None
Code leverage
Black box code reuse
Managed workproducts
Architecturereuse
Systematic Domain- specific reuse
Reduced Developmenttime
Reduced maintenance costs
Broader coverage
High reuse levels
Reuse enabled business
Investment experience
Benefit
9
O que satildeo Padrotildees O que eacute
Nova categoria de conhecimentoConhecimento natildeo eacute novo mas falar sobre ele eacuteObjetivo conhecer o que vocecirc jaacute conhece
Como Partindo de problemas e soluccedilotildees recorrentes
em diferentes aacutereas do conhecimento
10
O que eacute um Padratildeo (Cont) Aplicaccedilatildeo
Arquitetura Ciecircncia da Computaccedilatildeo
Engenharia de software Engenharia Mecacircnica Telecomunicaccedilotildees
11
O que eacute um Padratildeo (Cont) Por que padrotildees de software
engenheiros de software natildeo iniciam o seu projeto do nada
ao contraacuterio noacutes reutilizamos ldquoideacuteiasrdquoque jaacute vimos antes
as mesmas teacutecnicas satildeo utilizadas repetitivamente
a induacutestria de software necessita documentar o que noacutes fazemos
12
Diferentes Definiccedilotildees ldquoUm padratildeo eacute uma entidade que descreve
um problema que ocorre repetidamente em um ambiente e entatildeo descreve a essecircncia da soluccedilatildeo para este problema de tal forma que vocecirc use esta soluccedilatildeo milhotildees de vezes sem nunca utilizaacute-la do mesmo modordquo Christopher Alexander
13
Diferentes Definiccedilotildees (Cont) ldquoUm padratildeo eacute um pedaccedilo de literatura que
descreve um problema de projeto e uma soluccedilatildeo geral para o problema num contexto particular rdquo James Coplien
14
Diferentes Definiccedilotildees (Cont) ldquoUm padratildeo eacute uma soluccedilatildeo provada para um
problema em um contexto rdquo Comunidade de Software
15
Um Pouco da Histoacuteria Object-Oriented (OO)
Metade do anos 80 Padrotildees de software emergiram de objetos Ward Cunningham and Kent Beck
1987 linguagem de padrotildees para interface de usuaacuterio James Coplien
1988 idioms Erich Gamma Richard Helm Ralph Johnson and John
Vlissides 1990 1995 Padrotildees de projeto (Design Patterns)
16
Diferentes tipos de padrotildees Etapas de Desenvolvimento de Sistemas
Requisitos Anaacutelise Projeto Implementaccedilatildeo e Teste Domiacutenio de Aplicaccedilatildeo
Seguranccedila BD GUI XML Web Sistemas Distribuiacutedos
Camada de Aplicaccedilatildeo do Padratildeo Negoacutecios Apresentaccedilatildeo Integraccedilatildeo (Sun)
Classificaccedilatildeo de Autores GoF Estrutural Comportamental Criaccedilatildeo POSA Sistemas Interativos Organizaccedilatildeo do
Trabalho Comunicaccedilatildeo
17
Classificaccedilatildeo dos Padrotildees de Software (Cont)
Requisitos Anaacutelise Projeto Implementaccedilatildeo
Padrotildees de Requisitos
Padrotildees de Anaacutelise
Padrotildees de Projeto
Meta-Padrotildees
Padrotildees Arquiteturais
Idiomas
18
Padrotildees de Requisitos Documentam as necessidades do usuaacuterio e
o comportamento geneacuterico do sistema em um alto niacutevel de abstraccedilatildeo
Accedilotildees que os desenvolvedores de software podem tomar para melhorar os requisitos natildeo-funcionais
Mostram os relacionamentos entre o usuaacuterio ou o operador e o sistema
19
Padrotildees de Requisitos (Cont)
Fault-tolerant telecommunication patterns Visa a manutenccedilatildeo dos sistemas de comutaccedilatildeo Medidas apropriadas para serem tomadas no estaacutegio
de desenvolvimento de requisitos Padrotildees relacionados a confiabilidade (mensagens
do sistema e falhas do sistema) Five minutes of no escalation messages
Padrotildees relacionados aos fatores humanos
20
Padrotildees de Anaacutelise Inicialmente apresentados como complementos
aos padrotildees de projeto Um passo antes do projeto
Modelo de anaacutelise que focaliza nas estruturas conceituais
Padrotildees de anaacutelise do Martin Fowler Domiacutenio de conhecimento de software de negoacutecios Party quantity subtype state machines entre outros
21
Padrotildees de Anaacutelise (Cont) Party Problema pessoas e organizaccedilotildees tecircm
responsabilidades semelhantes Soluccedilatildeo Crie um tipo party como um
supertype de uma pessoa ou organizaccedilatildeo
22
Padrotildees de Projeto Estrutura repetida de elementos de projeto ldquoUm esquema para o refinamento de subsistemas ou de
componentes de sistemas ou as relaccedilotildees entre elesrdquo ldquoresolvem um problema geral de projeto num contexto particularrdquo GoF
Padrotildees de projeto que incluem detalhes de coacutedigo de baixo niacutevel
Aplicados a diferentes tipos de problemas Padrotildees Arquiteturais e Meta-Padrotildees podem ser
considerados Padrotildees de Projeto
23
Idiomas Relacionados com a implementaccedilatildeo de
caracteriacutesticas de projeto especiacuteficas Padratildeo de baixo niacutevel especiacutefico para uma
linguagem de programaccedilatildeo Idiomas em C++
C++ Programming Styles and Idioms James Coplien 1991
24
Idiomas (Cont)
Nome Counted Body Contexto A interface de uma classe eacute separada de sua
implementaccedilatildeo (respectivamente classes handle e body) Problema atribuiccedilatildeo em C++ eacute definida recursivamente
como membro-por-membro com coacutepia quando a recursatildeo termina
Soluccedilatildeo Um contador de referecircncia eacute adicionado agrave classe body para facilitar o gerenciamento de memoacuteria
Autor e data James Coplien 1994
25
A Comunidade de Padrotildees
Uma hierarquia de workshops de escritores Grupos de leitura local Grupo Hillside Livros com os artigos da conferecircncia Conferecircncias PLoP ao redor do mundo
26
Eacutetica de Padrotildees Regra de Buschmann nunca capture suas
proacuteprias ideacuteias em um padratildeo Natildeo pense que padrotildees resolvem tudo Tente sempre encorajar as pessoas a repassar os
conhecimentos Sempre reconheccedila aqueles que criaram as
teacutecnicas ou que primeiro se empenharam a escrever sobre elas
Padrotildees satildeo ldquoapenasrdquo mais uma teacutecnica para ajudaacute-lo no desenvolvimento de software
27
Reuso
Conheccedila os padrotildees que estatildeo disponiacuteveis Cataacutelogo de padrotildees de 2000 Escolha aquele que satisfaz as suas necessidades
Um padratildeo eacute difiacutecil de entender se vocecirc natildeo necessita dele
Apenas tenha uma visatildeo geral Utilize o vocabulaacuterio dos padrotildees em revisotildees e
sessotildees de projeto
28
Reuso (Cont) GoF
Bastante utilizado entre a comunidade de software Core J2EE Pattern Catalog
httpjavasuncomblueprintscorej2eepatterns Padrotildees Arquiteturais
Frank Bushmann Regine Meunier Hans Rohnert Peter Sommerlad Michael Stal (Gang of Five)
29
GoF Design Patterns
Creational patternsAbstract factory BuilderFactory method Prototype Singleton
Behavioral PatternsChain of Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor
Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
7
Resumindo -gt Produtividade Trabalhar mais raacutepido
Automaccedilatildeo ambientes ferramentasSubstituir trabalho humano
Trabalhar mais inteligentementeMelhoria do(s) processo(s)Evitarreduzir tarefas de pouco valor
Evitar o trabalho propriamente ditoReuso de ARTEFATOS do CICLO DE VIDA
Evitarreduzir o desenvolvimento de artefatos especiacuteficos para cada projeto
Benefiacutecios do Reuso
8
Modelo Incremental para adoccedilatildeo de Reuso
None
Code leverage
Black box code reuse
Managed workproducts
Architecturereuse
Systematic Domain- specific reuse
Reduced Developmenttime
Reduced maintenance costs
Broader coverage
High reuse levels
Reuse enabled business
Investment experience
Benefit
9
O que satildeo Padrotildees O que eacute
Nova categoria de conhecimentoConhecimento natildeo eacute novo mas falar sobre ele eacuteObjetivo conhecer o que vocecirc jaacute conhece
Como Partindo de problemas e soluccedilotildees recorrentes
em diferentes aacutereas do conhecimento
10
O que eacute um Padratildeo (Cont) Aplicaccedilatildeo
Arquitetura Ciecircncia da Computaccedilatildeo
Engenharia de software Engenharia Mecacircnica Telecomunicaccedilotildees
11
O que eacute um Padratildeo (Cont) Por que padrotildees de software
engenheiros de software natildeo iniciam o seu projeto do nada
ao contraacuterio noacutes reutilizamos ldquoideacuteiasrdquoque jaacute vimos antes
as mesmas teacutecnicas satildeo utilizadas repetitivamente
a induacutestria de software necessita documentar o que noacutes fazemos
12
Diferentes Definiccedilotildees ldquoUm padratildeo eacute uma entidade que descreve
um problema que ocorre repetidamente em um ambiente e entatildeo descreve a essecircncia da soluccedilatildeo para este problema de tal forma que vocecirc use esta soluccedilatildeo milhotildees de vezes sem nunca utilizaacute-la do mesmo modordquo Christopher Alexander
13
Diferentes Definiccedilotildees (Cont) ldquoUm padratildeo eacute um pedaccedilo de literatura que
descreve um problema de projeto e uma soluccedilatildeo geral para o problema num contexto particular rdquo James Coplien
14
Diferentes Definiccedilotildees (Cont) ldquoUm padratildeo eacute uma soluccedilatildeo provada para um
problema em um contexto rdquo Comunidade de Software
15
Um Pouco da Histoacuteria Object-Oriented (OO)
Metade do anos 80 Padrotildees de software emergiram de objetos Ward Cunningham and Kent Beck
1987 linguagem de padrotildees para interface de usuaacuterio James Coplien
1988 idioms Erich Gamma Richard Helm Ralph Johnson and John
Vlissides 1990 1995 Padrotildees de projeto (Design Patterns)
16
Diferentes tipos de padrotildees Etapas de Desenvolvimento de Sistemas
Requisitos Anaacutelise Projeto Implementaccedilatildeo e Teste Domiacutenio de Aplicaccedilatildeo
Seguranccedila BD GUI XML Web Sistemas Distribuiacutedos
Camada de Aplicaccedilatildeo do Padratildeo Negoacutecios Apresentaccedilatildeo Integraccedilatildeo (Sun)
Classificaccedilatildeo de Autores GoF Estrutural Comportamental Criaccedilatildeo POSA Sistemas Interativos Organizaccedilatildeo do
Trabalho Comunicaccedilatildeo
17
Classificaccedilatildeo dos Padrotildees de Software (Cont)
Requisitos Anaacutelise Projeto Implementaccedilatildeo
Padrotildees de Requisitos
Padrotildees de Anaacutelise
Padrotildees de Projeto
Meta-Padrotildees
Padrotildees Arquiteturais
Idiomas
18
Padrotildees de Requisitos Documentam as necessidades do usuaacuterio e
o comportamento geneacuterico do sistema em um alto niacutevel de abstraccedilatildeo
Accedilotildees que os desenvolvedores de software podem tomar para melhorar os requisitos natildeo-funcionais
Mostram os relacionamentos entre o usuaacuterio ou o operador e o sistema
19
Padrotildees de Requisitos (Cont)
Fault-tolerant telecommunication patterns Visa a manutenccedilatildeo dos sistemas de comutaccedilatildeo Medidas apropriadas para serem tomadas no estaacutegio
de desenvolvimento de requisitos Padrotildees relacionados a confiabilidade (mensagens
do sistema e falhas do sistema) Five minutes of no escalation messages
Padrotildees relacionados aos fatores humanos
20
Padrotildees de Anaacutelise Inicialmente apresentados como complementos
aos padrotildees de projeto Um passo antes do projeto
Modelo de anaacutelise que focaliza nas estruturas conceituais
Padrotildees de anaacutelise do Martin Fowler Domiacutenio de conhecimento de software de negoacutecios Party quantity subtype state machines entre outros
21
Padrotildees de Anaacutelise (Cont) Party Problema pessoas e organizaccedilotildees tecircm
responsabilidades semelhantes Soluccedilatildeo Crie um tipo party como um
supertype de uma pessoa ou organizaccedilatildeo
22
Padrotildees de Projeto Estrutura repetida de elementos de projeto ldquoUm esquema para o refinamento de subsistemas ou de
componentes de sistemas ou as relaccedilotildees entre elesrdquo ldquoresolvem um problema geral de projeto num contexto particularrdquo GoF
Padrotildees de projeto que incluem detalhes de coacutedigo de baixo niacutevel
Aplicados a diferentes tipos de problemas Padrotildees Arquiteturais e Meta-Padrotildees podem ser
considerados Padrotildees de Projeto
23
Idiomas Relacionados com a implementaccedilatildeo de
caracteriacutesticas de projeto especiacuteficas Padratildeo de baixo niacutevel especiacutefico para uma
linguagem de programaccedilatildeo Idiomas em C++
C++ Programming Styles and Idioms James Coplien 1991
24
Idiomas (Cont)
Nome Counted Body Contexto A interface de uma classe eacute separada de sua
implementaccedilatildeo (respectivamente classes handle e body) Problema atribuiccedilatildeo em C++ eacute definida recursivamente
como membro-por-membro com coacutepia quando a recursatildeo termina
Soluccedilatildeo Um contador de referecircncia eacute adicionado agrave classe body para facilitar o gerenciamento de memoacuteria
Autor e data James Coplien 1994
25
A Comunidade de Padrotildees
Uma hierarquia de workshops de escritores Grupos de leitura local Grupo Hillside Livros com os artigos da conferecircncia Conferecircncias PLoP ao redor do mundo
26
Eacutetica de Padrotildees Regra de Buschmann nunca capture suas
proacuteprias ideacuteias em um padratildeo Natildeo pense que padrotildees resolvem tudo Tente sempre encorajar as pessoas a repassar os
conhecimentos Sempre reconheccedila aqueles que criaram as
teacutecnicas ou que primeiro se empenharam a escrever sobre elas
Padrotildees satildeo ldquoapenasrdquo mais uma teacutecnica para ajudaacute-lo no desenvolvimento de software
27
Reuso
Conheccedila os padrotildees que estatildeo disponiacuteveis Cataacutelogo de padrotildees de 2000 Escolha aquele que satisfaz as suas necessidades
Um padratildeo eacute difiacutecil de entender se vocecirc natildeo necessita dele
Apenas tenha uma visatildeo geral Utilize o vocabulaacuterio dos padrotildees em revisotildees e
sessotildees de projeto
28
Reuso (Cont) GoF
Bastante utilizado entre a comunidade de software Core J2EE Pattern Catalog
httpjavasuncomblueprintscorej2eepatterns Padrotildees Arquiteturais
Frank Bushmann Regine Meunier Hans Rohnert Peter Sommerlad Michael Stal (Gang of Five)
29
GoF Design Patterns
Creational patternsAbstract factory BuilderFactory method Prototype Singleton
Behavioral PatternsChain of Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor
Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
8
Modelo Incremental para adoccedilatildeo de Reuso
None
Code leverage
Black box code reuse
Managed workproducts
Architecturereuse
Systematic Domain- specific reuse
Reduced Developmenttime
Reduced maintenance costs
Broader coverage
High reuse levels
Reuse enabled business
Investment experience
Benefit
9
O que satildeo Padrotildees O que eacute
Nova categoria de conhecimentoConhecimento natildeo eacute novo mas falar sobre ele eacuteObjetivo conhecer o que vocecirc jaacute conhece
Como Partindo de problemas e soluccedilotildees recorrentes
em diferentes aacutereas do conhecimento
10
O que eacute um Padratildeo (Cont) Aplicaccedilatildeo
Arquitetura Ciecircncia da Computaccedilatildeo
Engenharia de software Engenharia Mecacircnica Telecomunicaccedilotildees
11
O que eacute um Padratildeo (Cont) Por que padrotildees de software
engenheiros de software natildeo iniciam o seu projeto do nada
ao contraacuterio noacutes reutilizamos ldquoideacuteiasrdquoque jaacute vimos antes
as mesmas teacutecnicas satildeo utilizadas repetitivamente
a induacutestria de software necessita documentar o que noacutes fazemos
12
Diferentes Definiccedilotildees ldquoUm padratildeo eacute uma entidade que descreve
um problema que ocorre repetidamente em um ambiente e entatildeo descreve a essecircncia da soluccedilatildeo para este problema de tal forma que vocecirc use esta soluccedilatildeo milhotildees de vezes sem nunca utilizaacute-la do mesmo modordquo Christopher Alexander
13
Diferentes Definiccedilotildees (Cont) ldquoUm padratildeo eacute um pedaccedilo de literatura que
descreve um problema de projeto e uma soluccedilatildeo geral para o problema num contexto particular rdquo James Coplien
14
Diferentes Definiccedilotildees (Cont) ldquoUm padratildeo eacute uma soluccedilatildeo provada para um
problema em um contexto rdquo Comunidade de Software
15
Um Pouco da Histoacuteria Object-Oriented (OO)
Metade do anos 80 Padrotildees de software emergiram de objetos Ward Cunningham and Kent Beck
1987 linguagem de padrotildees para interface de usuaacuterio James Coplien
1988 idioms Erich Gamma Richard Helm Ralph Johnson and John
Vlissides 1990 1995 Padrotildees de projeto (Design Patterns)
16
Diferentes tipos de padrotildees Etapas de Desenvolvimento de Sistemas
Requisitos Anaacutelise Projeto Implementaccedilatildeo e Teste Domiacutenio de Aplicaccedilatildeo
Seguranccedila BD GUI XML Web Sistemas Distribuiacutedos
Camada de Aplicaccedilatildeo do Padratildeo Negoacutecios Apresentaccedilatildeo Integraccedilatildeo (Sun)
Classificaccedilatildeo de Autores GoF Estrutural Comportamental Criaccedilatildeo POSA Sistemas Interativos Organizaccedilatildeo do
Trabalho Comunicaccedilatildeo
17
Classificaccedilatildeo dos Padrotildees de Software (Cont)
Requisitos Anaacutelise Projeto Implementaccedilatildeo
Padrotildees de Requisitos
Padrotildees de Anaacutelise
Padrotildees de Projeto
Meta-Padrotildees
Padrotildees Arquiteturais
Idiomas
18
Padrotildees de Requisitos Documentam as necessidades do usuaacuterio e
o comportamento geneacuterico do sistema em um alto niacutevel de abstraccedilatildeo
Accedilotildees que os desenvolvedores de software podem tomar para melhorar os requisitos natildeo-funcionais
Mostram os relacionamentos entre o usuaacuterio ou o operador e o sistema
19
Padrotildees de Requisitos (Cont)
Fault-tolerant telecommunication patterns Visa a manutenccedilatildeo dos sistemas de comutaccedilatildeo Medidas apropriadas para serem tomadas no estaacutegio
de desenvolvimento de requisitos Padrotildees relacionados a confiabilidade (mensagens
do sistema e falhas do sistema) Five minutes of no escalation messages
Padrotildees relacionados aos fatores humanos
20
Padrotildees de Anaacutelise Inicialmente apresentados como complementos
aos padrotildees de projeto Um passo antes do projeto
Modelo de anaacutelise que focaliza nas estruturas conceituais
Padrotildees de anaacutelise do Martin Fowler Domiacutenio de conhecimento de software de negoacutecios Party quantity subtype state machines entre outros
21
Padrotildees de Anaacutelise (Cont) Party Problema pessoas e organizaccedilotildees tecircm
responsabilidades semelhantes Soluccedilatildeo Crie um tipo party como um
supertype de uma pessoa ou organizaccedilatildeo
22
Padrotildees de Projeto Estrutura repetida de elementos de projeto ldquoUm esquema para o refinamento de subsistemas ou de
componentes de sistemas ou as relaccedilotildees entre elesrdquo ldquoresolvem um problema geral de projeto num contexto particularrdquo GoF
Padrotildees de projeto que incluem detalhes de coacutedigo de baixo niacutevel
Aplicados a diferentes tipos de problemas Padrotildees Arquiteturais e Meta-Padrotildees podem ser
considerados Padrotildees de Projeto
23
Idiomas Relacionados com a implementaccedilatildeo de
caracteriacutesticas de projeto especiacuteficas Padratildeo de baixo niacutevel especiacutefico para uma
linguagem de programaccedilatildeo Idiomas em C++
C++ Programming Styles and Idioms James Coplien 1991
24
Idiomas (Cont)
Nome Counted Body Contexto A interface de uma classe eacute separada de sua
implementaccedilatildeo (respectivamente classes handle e body) Problema atribuiccedilatildeo em C++ eacute definida recursivamente
como membro-por-membro com coacutepia quando a recursatildeo termina
Soluccedilatildeo Um contador de referecircncia eacute adicionado agrave classe body para facilitar o gerenciamento de memoacuteria
Autor e data James Coplien 1994
25
A Comunidade de Padrotildees
Uma hierarquia de workshops de escritores Grupos de leitura local Grupo Hillside Livros com os artigos da conferecircncia Conferecircncias PLoP ao redor do mundo
26
Eacutetica de Padrotildees Regra de Buschmann nunca capture suas
proacuteprias ideacuteias em um padratildeo Natildeo pense que padrotildees resolvem tudo Tente sempre encorajar as pessoas a repassar os
conhecimentos Sempre reconheccedila aqueles que criaram as
teacutecnicas ou que primeiro se empenharam a escrever sobre elas
Padrotildees satildeo ldquoapenasrdquo mais uma teacutecnica para ajudaacute-lo no desenvolvimento de software
27
Reuso
Conheccedila os padrotildees que estatildeo disponiacuteveis Cataacutelogo de padrotildees de 2000 Escolha aquele que satisfaz as suas necessidades
Um padratildeo eacute difiacutecil de entender se vocecirc natildeo necessita dele
Apenas tenha uma visatildeo geral Utilize o vocabulaacuterio dos padrotildees em revisotildees e
sessotildees de projeto
28
Reuso (Cont) GoF
Bastante utilizado entre a comunidade de software Core J2EE Pattern Catalog
httpjavasuncomblueprintscorej2eepatterns Padrotildees Arquiteturais
Frank Bushmann Regine Meunier Hans Rohnert Peter Sommerlad Michael Stal (Gang of Five)
29
GoF Design Patterns
Creational patternsAbstract factory BuilderFactory method Prototype Singleton
Behavioral PatternsChain of Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor
Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
9
O que satildeo Padrotildees O que eacute
Nova categoria de conhecimentoConhecimento natildeo eacute novo mas falar sobre ele eacuteObjetivo conhecer o que vocecirc jaacute conhece
Como Partindo de problemas e soluccedilotildees recorrentes
em diferentes aacutereas do conhecimento
10
O que eacute um Padratildeo (Cont) Aplicaccedilatildeo
Arquitetura Ciecircncia da Computaccedilatildeo
Engenharia de software Engenharia Mecacircnica Telecomunicaccedilotildees
11
O que eacute um Padratildeo (Cont) Por que padrotildees de software
engenheiros de software natildeo iniciam o seu projeto do nada
ao contraacuterio noacutes reutilizamos ldquoideacuteiasrdquoque jaacute vimos antes
as mesmas teacutecnicas satildeo utilizadas repetitivamente
a induacutestria de software necessita documentar o que noacutes fazemos
12
Diferentes Definiccedilotildees ldquoUm padratildeo eacute uma entidade que descreve
um problema que ocorre repetidamente em um ambiente e entatildeo descreve a essecircncia da soluccedilatildeo para este problema de tal forma que vocecirc use esta soluccedilatildeo milhotildees de vezes sem nunca utilizaacute-la do mesmo modordquo Christopher Alexander
13
Diferentes Definiccedilotildees (Cont) ldquoUm padratildeo eacute um pedaccedilo de literatura que
descreve um problema de projeto e uma soluccedilatildeo geral para o problema num contexto particular rdquo James Coplien
14
Diferentes Definiccedilotildees (Cont) ldquoUm padratildeo eacute uma soluccedilatildeo provada para um
problema em um contexto rdquo Comunidade de Software
15
Um Pouco da Histoacuteria Object-Oriented (OO)
Metade do anos 80 Padrotildees de software emergiram de objetos Ward Cunningham and Kent Beck
1987 linguagem de padrotildees para interface de usuaacuterio James Coplien
1988 idioms Erich Gamma Richard Helm Ralph Johnson and John
Vlissides 1990 1995 Padrotildees de projeto (Design Patterns)
16
Diferentes tipos de padrotildees Etapas de Desenvolvimento de Sistemas
Requisitos Anaacutelise Projeto Implementaccedilatildeo e Teste Domiacutenio de Aplicaccedilatildeo
Seguranccedila BD GUI XML Web Sistemas Distribuiacutedos
Camada de Aplicaccedilatildeo do Padratildeo Negoacutecios Apresentaccedilatildeo Integraccedilatildeo (Sun)
Classificaccedilatildeo de Autores GoF Estrutural Comportamental Criaccedilatildeo POSA Sistemas Interativos Organizaccedilatildeo do
Trabalho Comunicaccedilatildeo
17
Classificaccedilatildeo dos Padrotildees de Software (Cont)
Requisitos Anaacutelise Projeto Implementaccedilatildeo
Padrotildees de Requisitos
Padrotildees de Anaacutelise
Padrotildees de Projeto
Meta-Padrotildees
Padrotildees Arquiteturais
Idiomas
18
Padrotildees de Requisitos Documentam as necessidades do usuaacuterio e
o comportamento geneacuterico do sistema em um alto niacutevel de abstraccedilatildeo
Accedilotildees que os desenvolvedores de software podem tomar para melhorar os requisitos natildeo-funcionais
Mostram os relacionamentos entre o usuaacuterio ou o operador e o sistema
19
Padrotildees de Requisitos (Cont)
Fault-tolerant telecommunication patterns Visa a manutenccedilatildeo dos sistemas de comutaccedilatildeo Medidas apropriadas para serem tomadas no estaacutegio
de desenvolvimento de requisitos Padrotildees relacionados a confiabilidade (mensagens
do sistema e falhas do sistema) Five minutes of no escalation messages
Padrotildees relacionados aos fatores humanos
20
Padrotildees de Anaacutelise Inicialmente apresentados como complementos
aos padrotildees de projeto Um passo antes do projeto
Modelo de anaacutelise que focaliza nas estruturas conceituais
Padrotildees de anaacutelise do Martin Fowler Domiacutenio de conhecimento de software de negoacutecios Party quantity subtype state machines entre outros
21
Padrotildees de Anaacutelise (Cont) Party Problema pessoas e organizaccedilotildees tecircm
responsabilidades semelhantes Soluccedilatildeo Crie um tipo party como um
supertype de uma pessoa ou organizaccedilatildeo
22
Padrotildees de Projeto Estrutura repetida de elementos de projeto ldquoUm esquema para o refinamento de subsistemas ou de
componentes de sistemas ou as relaccedilotildees entre elesrdquo ldquoresolvem um problema geral de projeto num contexto particularrdquo GoF
Padrotildees de projeto que incluem detalhes de coacutedigo de baixo niacutevel
Aplicados a diferentes tipos de problemas Padrotildees Arquiteturais e Meta-Padrotildees podem ser
considerados Padrotildees de Projeto
23
Idiomas Relacionados com a implementaccedilatildeo de
caracteriacutesticas de projeto especiacuteficas Padratildeo de baixo niacutevel especiacutefico para uma
linguagem de programaccedilatildeo Idiomas em C++
C++ Programming Styles and Idioms James Coplien 1991
24
Idiomas (Cont)
Nome Counted Body Contexto A interface de uma classe eacute separada de sua
implementaccedilatildeo (respectivamente classes handle e body) Problema atribuiccedilatildeo em C++ eacute definida recursivamente
como membro-por-membro com coacutepia quando a recursatildeo termina
Soluccedilatildeo Um contador de referecircncia eacute adicionado agrave classe body para facilitar o gerenciamento de memoacuteria
Autor e data James Coplien 1994
25
A Comunidade de Padrotildees
Uma hierarquia de workshops de escritores Grupos de leitura local Grupo Hillside Livros com os artigos da conferecircncia Conferecircncias PLoP ao redor do mundo
26
Eacutetica de Padrotildees Regra de Buschmann nunca capture suas
proacuteprias ideacuteias em um padratildeo Natildeo pense que padrotildees resolvem tudo Tente sempre encorajar as pessoas a repassar os
conhecimentos Sempre reconheccedila aqueles que criaram as
teacutecnicas ou que primeiro se empenharam a escrever sobre elas
Padrotildees satildeo ldquoapenasrdquo mais uma teacutecnica para ajudaacute-lo no desenvolvimento de software
27
Reuso
Conheccedila os padrotildees que estatildeo disponiacuteveis Cataacutelogo de padrotildees de 2000 Escolha aquele que satisfaz as suas necessidades
Um padratildeo eacute difiacutecil de entender se vocecirc natildeo necessita dele
Apenas tenha uma visatildeo geral Utilize o vocabulaacuterio dos padrotildees em revisotildees e
sessotildees de projeto
28
Reuso (Cont) GoF
Bastante utilizado entre a comunidade de software Core J2EE Pattern Catalog
httpjavasuncomblueprintscorej2eepatterns Padrotildees Arquiteturais
Frank Bushmann Regine Meunier Hans Rohnert Peter Sommerlad Michael Stal (Gang of Five)
29
GoF Design Patterns
Creational patternsAbstract factory BuilderFactory method Prototype Singleton
Behavioral PatternsChain of Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor
Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
10
O que eacute um Padratildeo (Cont) Aplicaccedilatildeo
Arquitetura Ciecircncia da Computaccedilatildeo
Engenharia de software Engenharia Mecacircnica Telecomunicaccedilotildees
11
O que eacute um Padratildeo (Cont) Por que padrotildees de software
engenheiros de software natildeo iniciam o seu projeto do nada
ao contraacuterio noacutes reutilizamos ldquoideacuteiasrdquoque jaacute vimos antes
as mesmas teacutecnicas satildeo utilizadas repetitivamente
a induacutestria de software necessita documentar o que noacutes fazemos
12
Diferentes Definiccedilotildees ldquoUm padratildeo eacute uma entidade que descreve
um problema que ocorre repetidamente em um ambiente e entatildeo descreve a essecircncia da soluccedilatildeo para este problema de tal forma que vocecirc use esta soluccedilatildeo milhotildees de vezes sem nunca utilizaacute-la do mesmo modordquo Christopher Alexander
13
Diferentes Definiccedilotildees (Cont) ldquoUm padratildeo eacute um pedaccedilo de literatura que
descreve um problema de projeto e uma soluccedilatildeo geral para o problema num contexto particular rdquo James Coplien
14
Diferentes Definiccedilotildees (Cont) ldquoUm padratildeo eacute uma soluccedilatildeo provada para um
problema em um contexto rdquo Comunidade de Software
15
Um Pouco da Histoacuteria Object-Oriented (OO)
Metade do anos 80 Padrotildees de software emergiram de objetos Ward Cunningham and Kent Beck
1987 linguagem de padrotildees para interface de usuaacuterio James Coplien
1988 idioms Erich Gamma Richard Helm Ralph Johnson and John
Vlissides 1990 1995 Padrotildees de projeto (Design Patterns)
16
Diferentes tipos de padrotildees Etapas de Desenvolvimento de Sistemas
Requisitos Anaacutelise Projeto Implementaccedilatildeo e Teste Domiacutenio de Aplicaccedilatildeo
Seguranccedila BD GUI XML Web Sistemas Distribuiacutedos
Camada de Aplicaccedilatildeo do Padratildeo Negoacutecios Apresentaccedilatildeo Integraccedilatildeo (Sun)
Classificaccedilatildeo de Autores GoF Estrutural Comportamental Criaccedilatildeo POSA Sistemas Interativos Organizaccedilatildeo do
Trabalho Comunicaccedilatildeo
17
Classificaccedilatildeo dos Padrotildees de Software (Cont)
Requisitos Anaacutelise Projeto Implementaccedilatildeo
Padrotildees de Requisitos
Padrotildees de Anaacutelise
Padrotildees de Projeto
Meta-Padrotildees
Padrotildees Arquiteturais
Idiomas
18
Padrotildees de Requisitos Documentam as necessidades do usuaacuterio e
o comportamento geneacuterico do sistema em um alto niacutevel de abstraccedilatildeo
Accedilotildees que os desenvolvedores de software podem tomar para melhorar os requisitos natildeo-funcionais
Mostram os relacionamentos entre o usuaacuterio ou o operador e o sistema
19
Padrotildees de Requisitos (Cont)
Fault-tolerant telecommunication patterns Visa a manutenccedilatildeo dos sistemas de comutaccedilatildeo Medidas apropriadas para serem tomadas no estaacutegio
de desenvolvimento de requisitos Padrotildees relacionados a confiabilidade (mensagens
do sistema e falhas do sistema) Five minutes of no escalation messages
Padrotildees relacionados aos fatores humanos
20
Padrotildees de Anaacutelise Inicialmente apresentados como complementos
aos padrotildees de projeto Um passo antes do projeto
Modelo de anaacutelise que focaliza nas estruturas conceituais
Padrotildees de anaacutelise do Martin Fowler Domiacutenio de conhecimento de software de negoacutecios Party quantity subtype state machines entre outros
21
Padrotildees de Anaacutelise (Cont) Party Problema pessoas e organizaccedilotildees tecircm
responsabilidades semelhantes Soluccedilatildeo Crie um tipo party como um
supertype de uma pessoa ou organizaccedilatildeo
22
Padrotildees de Projeto Estrutura repetida de elementos de projeto ldquoUm esquema para o refinamento de subsistemas ou de
componentes de sistemas ou as relaccedilotildees entre elesrdquo ldquoresolvem um problema geral de projeto num contexto particularrdquo GoF
Padrotildees de projeto que incluem detalhes de coacutedigo de baixo niacutevel
Aplicados a diferentes tipos de problemas Padrotildees Arquiteturais e Meta-Padrotildees podem ser
considerados Padrotildees de Projeto
23
Idiomas Relacionados com a implementaccedilatildeo de
caracteriacutesticas de projeto especiacuteficas Padratildeo de baixo niacutevel especiacutefico para uma
linguagem de programaccedilatildeo Idiomas em C++
C++ Programming Styles and Idioms James Coplien 1991
24
Idiomas (Cont)
Nome Counted Body Contexto A interface de uma classe eacute separada de sua
implementaccedilatildeo (respectivamente classes handle e body) Problema atribuiccedilatildeo em C++ eacute definida recursivamente
como membro-por-membro com coacutepia quando a recursatildeo termina
Soluccedilatildeo Um contador de referecircncia eacute adicionado agrave classe body para facilitar o gerenciamento de memoacuteria
Autor e data James Coplien 1994
25
A Comunidade de Padrotildees
Uma hierarquia de workshops de escritores Grupos de leitura local Grupo Hillside Livros com os artigos da conferecircncia Conferecircncias PLoP ao redor do mundo
26
Eacutetica de Padrotildees Regra de Buschmann nunca capture suas
proacuteprias ideacuteias em um padratildeo Natildeo pense que padrotildees resolvem tudo Tente sempre encorajar as pessoas a repassar os
conhecimentos Sempre reconheccedila aqueles que criaram as
teacutecnicas ou que primeiro se empenharam a escrever sobre elas
Padrotildees satildeo ldquoapenasrdquo mais uma teacutecnica para ajudaacute-lo no desenvolvimento de software
27
Reuso
Conheccedila os padrotildees que estatildeo disponiacuteveis Cataacutelogo de padrotildees de 2000 Escolha aquele que satisfaz as suas necessidades
Um padratildeo eacute difiacutecil de entender se vocecirc natildeo necessita dele
Apenas tenha uma visatildeo geral Utilize o vocabulaacuterio dos padrotildees em revisotildees e
sessotildees de projeto
28
Reuso (Cont) GoF
Bastante utilizado entre a comunidade de software Core J2EE Pattern Catalog
httpjavasuncomblueprintscorej2eepatterns Padrotildees Arquiteturais
Frank Bushmann Regine Meunier Hans Rohnert Peter Sommerlad Michael Stal (Gang of Five)
29
GoF Design Patterns
Creational patternsAbstract factory BuilderFactory method Prototype Singleton
Behavioral PatternsChain of Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor
Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
11
O que eacute um Padratildeo (Cont) Por que padrotildees de software
engenheiros de software natildeo iniciam o seu projeto do nada
ao contraacuterio noacutes reutilizamos ldquoideacuteiasrdquoque jaacute vimos antes
as mesmas teacutecnicas satildeo utilizadas repetitivamente
a induacutestria de software necessita documentar o que noacutes fazemos
12
Diferentes Definiccedilotildees ldquoUm padratildeo eacute uma entidade que descreve
um problema que ocorre repetidamente em um ambiente e entatildeo descreve a essecircncia da soluccedilatildeo para este problema de tal forma que vocecirc use esta soluccedilatildeo milhotildees de vezes sem nunca utilizaacute-la do mesmo modordquo Christopher Alexander
13
Diferentes Definiccedilotildees (Cont) ldquoUm padratildeo eacute um pedaccedilo de literatura que
descreve um problema de projeto e uma soluccedilatildeo geral para o problema num contexto particular rdquo James Coplien
14
Diferentes Definiccedilotildees (Cont) ldquoUm padratildeo eacute uma soluccedilatildeo provada para um
problema em um contexto rdquo Comunidade de Software
15
Um Pouco da Histoacuteria Object-Oriented (OO)
Metade do anos 80 Padrotildees de software emergiram de objetos Ward Cunningham and Kent Beck
1987 linguagem de padrotildees para interface de usuaacuterio James Coplien
1988 idioms Erich Gamma Richard Helm Ralph Johnson and John
Vlissides 1990 1995 Padrotildees de projeto (Design Patterns)
16
Diferentes tipos de padrotildees Etapas de Desenvolvimento de Sistemas
Requisitos Anaacutelise Projeto Implementaccedilatildeo e Teste Domiacutenio de Aplicaccedilatildeo
Seguranccedila BD GUI XML Web Sistemas Distribuiacutedos
Camada de Aplicaccedilatildeo do Padratildeo Negoacutecios Apresentaccedilatildeo Integraccedilatildeo (Sun)
Classificaccedilatildeo de Autores GoF Estrutural Comportamental Criaccedilatildeo POSA Sistemas Interativos Organizaccedilatildeo do
Trabalho Comunicaccedilatildeo
17
Classificaccedilatildeo dos Padrotildees de Software (Cont)
Requisitos Anaacutelise Projeto Implementaccedilatildeo
Padrotildees de Requisitos
Padrotildees de Anaacutelise
Padrotildees de Projeto
Meta-Padrotildees
Padrotildees Arquiteturais
Idiomas
18
Padrotildees de Requisitos Documentam as necessidades do usuaacuterio e
o comportamento geneacuterico do sistema em um alto niacutevel de abstraccedilatildeo
Accedilotildees que os desenvolvedores de software podem tomar para melhorar os requisitos natildeo-funcionais
Mostram os relacionamentos entre o usuaacuterio ou o operador e o sistema
19
Padrotildees de Requisitos (Cont)
Fault-tolerant telecommunication patterns Visa a manutenccedilatildeo dos sistemas de comutaccedilatildeo Medidas apropriadas para serem tomadas no estaacutegio
de desenvolvimento de requisitos Padrotildees relacionados a confiabilidade (mensagens
do sistema e falhas do sistema) Five minutes of no escalation messages
Padrotildees relacionados aos fatores humanos
20
Padrotildees de Anaacutelise Inicialmente apresentados como complementos
aos padrotildees de projeto Um passo antes do projeto
Modelo de anaacutelise que focaliza nas estruturas conceituais
Padrotildees de anaacutelise do Martin Fowler Domiacutenio de conhecimento de software de negoacutecios Party quantity subtype state machines entre outros
21
Padrotildees de Anaacutelise (Cont) Party Problema pessoas e organizaccedilotildees tecircm
responsabilidades semelhantes Soluccedilatildeo Crie um tipo party como um
supertype de uma pessoa ou organizaccedilatildeo
22
Padrotildees de Projeto Estrutura repetida de elementos de projeto ldquoUm esquema para o refinamento de subsistemas ou de
componentes de sistemas ou as relaccedilotildees entre elesrdquo ldquoresolvem um problema geral de projeto num contexto particularrdquo GoF
Padrotildees de projeto que incluem detalhes de coacutedigo de baixo niacutevel
Aplicados a diferentes tipos de problemas Padrotildees Arquiteturais e Meta-Padrotildees podem ser
considerados Padrotildees de Projeto
23
Idiomas Relacionados com a implementaccedilatildeo de
caracteriacutesticas de projeto especiacuteficas Padratildeo de baixo niacutevel especiacutefico para uma
linguagem de programaccedilatildeo Idiomas em C++
C++ Programming Styles and Idioms James Coplien 1991
24
Idiomas (Cont)
Nome Counted Body Contexto A interface de uma classe eacute separada de sua
implementaccedilatildeo (respectivamente classes handle e body) Problema atribuiccedilatildeo em C++ eacute definida recursivamente
como membro-por-membro com coacutepia quando a recursatildeo termina
Soluccedilatildeo Um contador de referecircncia eacute adicionado agrave classe body para facilitar o gerenciamento de memoacuteria
Autor e data James Coplien 1994
25
A Comunidade de Padrotildees
Uma hierarquia de workshops de escritores Grupos de leitura local Grupo Hillside Livros com os artigos da conferecircncia Conferecircncias PLoP ao redor do mundo
26
Eacutetica de Padrotildees Regra de Buschmann nunca capture suas
proacuteprias ideacuteias em um padratildeo Natildeo pense que padrotildees resolvem tudo Tente sempre encorajar as pessoas a repassar os
conhecimentos Sempre reconheccedila aqueles que criaram as
teacutecnicas ou que primeiro se empenharam a escrever sobre elas
Padrotildees satildeo ldquoapenasrdquo mais uma teacutecnica para ajudaacute-lo no desenvolvimento de software
27
Reuso
Conheccedila os padrotildees que estatildeo disponiacuteveis Cataacutelogo de padrotildees de 2000 Escolha aquele que satisfaz as suas necessidades
Um padratildeo eacute difiacutecil de entender se vocecirc natildeo necessita dele
Apenas tenha uma visatildeo geral Utilize o vocabulaacuterio dos padrotildees em revisotildees e
sessotildees de projeto
28
Reuso (Cont) GoF
Bastante utilizado entre a comunidade de software Core J2EE Pattern Catalog
httpjavasuncomblueprintscorej2eepatterns Padrotildees Arquiteturais
Frank Bushmann Regine Meunier Hans Rohnert Peter Sommerlad Michael Stal (Gang of Five)
29
GoF Design Patterns
Creational patternsAbstract factory BuilderFactory method Prototype Singleton
Behavioral PatternsChain of Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor
Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
12
Diferentes Definiccedilotildees ldquoUm padratildeo eacute uma entidade que descreve
um problema que ocorre repetidamente em um ambiente e entatildeo descreve a essecircncia da soluccedilatildeo para este problema de tal forma que vocecirc use esta soluccedilatildeo milhotildees de vezes sem nunca utilizaacute-la do mesmo modordquo Christopher Alexander
13
Diferentes Definiccedilotildees (Cont) ldquoUm padratildeo eacute um pedaccedilo de literatura que
descreve um problema de projeto e uma soluccedilatildeo geral para o problema num contexto particular rdquo James Coplien
14
Diferentes Definiccedilotildees (Cont) ldquoUm padratildeo eacute uma soluccedilatildeo provada para um
problema em um contexto rdquo Comunidade de Software
15
Um Pouco da Histoacuteria Object-Oriented (OO)
Metade do anos 80 Padrotildees de software emergiram de objetos Ward Cunningham and Kent Beck
1987 linguagem de padrotildees para interface de usuaacuterio James Coplien
1988 idioms Erich Gamma Richard Helm Ralph Johnson and John
Vlissides 1990 1995 Padrotildees de projeto (Design Patterns)
16
Diferentes tipos de padrotildees Etapas de Desenvolvimento de Sistemas
Requisitos Anaacutelise Projeto Implementaccedilatildeo e Teste Domiacutenio de Aplicaccedilatildeo
Seguranccedila BD GUI XML Web Sistemas Distribuiacutedos
Camada de Aplicaccedilatildeo do Padratildeo Negoacutecios Apresentaccedilatildeo Integraccedilatildeo (Sun)
Classificaccedilatildeo de Autores GoF Estrutural Comportamental Criaccedilatildeo POSA Sistemas Interativos Organizaccedilatildeo do
Trabalho Comunicaccedilatildeo
17
Classificaccedilatildeo dos Padrotildees de Software (Cont)
Requisitos Anaacutelise Projeto Implementaccedilatildeo
Padrotildees de Requisitos
Padrotildees de Anaacutelise
Padrotildees de Projeto
Meta-Padrotildees
Padrotildees Arquiteturais
Idiomas
18
Padrotildees de Requisitos Documentam as necessidades do usuaacuterio e
o comportamento geneacuterico do sistema em um alto niacutevel de abstraccedilatildeo
Accedilotildees que os desenvolvedores de software podem tomar para melhorar os requisitos natildeo-funcionais
Mostram os relacionamentos entre o usuaacuterio ou o operador e o sistema
19
Padrotildees de Requisitos (Cont)
Fault-tolerant telecommunication patterns Visa a manutenccedilatildeo dos sistemas de comutaccedilatildeo Medidas apropriadas para serem tomadas no estaacutegio
de desenvolvimento de requisitos Padrotildees relacionados a confiabilidade (mensagens
do sistema e falhas do sistema) Five minutes of no escalation messages
Padrotildees relacionados aos fatores humanos
20
Padrotildees de Anaacutelise Inicialmente apresentados como complementos
aos padrotildees de projeto Um passo antes do projeto
Modelo de anaacutelise que focaliza nas estruturas conceituais
Padrotildees de anaacutelise do Martin Fowler Domiacutenio de conhecimento de software de negoacutecios Party quantity subtype state machines entre outros
21
Padrotildees de Anaacutelise (Cont) Party Problema pessoas e organizaccedilotildees tecircm
responsabilidades semelhantes Soluccedilatildeo Crie um tipo party como um
supertype de uma pessoa ou organizaccedilatildeo
22
Padrotildees de Projeto Estrutura repetida de elementos de projeto ldquoUm esquema para o refinamento de subsistemas ou de
componentes de sistemas ou as relaccedilotildees entre elesrdquo ldquoresolvem um problema geral de projeto num contexto particularrdquo GoF
Padrotildees de projeto que incluem detalhes de coacutedigo de baixo niacutevel
Aplicados a diferentes tipos de problemas Padrotildees Arquiteturais e Meta-Padrotildees podem ser
considerados Padrotildees de Projeto
23
Idiomas Relacionados com a implementaccedilatildeo de
caracteriacutesticas de projeto especiacuteficas Padratildeo de baixo niacutevel especiacutefico para uma
linguagem de programaccedilatildeo Idiomas em C++
C++ Programming Styles and Idioms James Coplien 1991
24
Idiomas (Cont)
Nome Counted Body Contexto A interface de uma classe eacute separada de sua
implementaccedilatildeo (respectivamente classes handle e body) Problema atribuiccedilatildeo em C++ eacute definida recursivamente
como membro-por-membro com coacutepia quando a recursatildeo termina
Soluccedilatildeo Um contador de referecircncia eacute adicionado agrave classe body para facilitar o gerenciamento de memoacuteria
Autor e data James Coplien 1994
25
A Comunidade de Padrotildees
Uma hierarquia de workshops de escritores Grupos de leitura local Grupo Hillside Livros com os artigos da conferecircncia Conferecircncias PLoP ao redor do mundo
26
Eacutetica de Padrotildees Regra de Buschmann nunca capture suas
proacuteprias ideacuteias em um padratildeo Natildeo pense que padrotildees resolvem tudo Tente sempre encorajar as pessoas a repassar os
conhecimentos Sempre reconheccedila aqueles que criaram as
teacutecnicas ou que primeiro se empenharam a escrever sobre elas
Padrotildees satildeo ldquoapenasrdquo mais uma teacutecnica para ajudaacute-lo no desenvolvimento de software
27
Reuso
Conheccedila os padrotildees que estatildeo disponiacuteveis Cataacutelogo de padrotildees de 2000 Escolha aquele que satisfaz as suas necessidades
Um padratildeo eacute difiacutecil de entender se vocecirc natildeo necessita dele
Apenas tenha uma visatildeo geral Utilize o vocabulaacuterio dos padrotildees em revisotildees e
sessotildees de projeto
28
Reuso (Cont) GoF
Bastante utilizado entre a comunidade de software Core J2EE Pattern Catalog
httpjavasuncomblueprintscorej2eepatterns Padrotildees Arquiteturais
Frank Bushmann Regine Meunier Hans Rohnert Peter Sommerlad Michael Stal (Gang of Five)
29
GoF Design Patterns
Creational patternsAbstract factory BuilderFactory method Prototype Singleton
Behavioral PatternsChain of Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor
Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
13
Diferentes Definiccedilotildees (Cont) ldquoUm padratildeo eacute um pedaccedilo de literatura que
descreve um problema de projeto e uma soluccedilatildeo geral para o problema num contexto particular rdquo James Coplien
14
Diferentes Definiccedilotildees (Cont) ldquoUm padratildeo eacute uma soluccedilatildeo provada para um
problema em um contexto rdquo Comunidade de Software
15
Um Pouco da Histoacuteria Object-Oriented (OO)
Metade do anos 80 Padrotildees de software emergiram de objetos Ward Cunningham and Kent Beck
1987 linguagem de padrotildees para interface de usuaacuterio James Coplien
1988 idioms Erich Gamma Richard Helm Ralph Johnson and John
Vlissides 1990 1995 Padrotildees de projeto (Design Patterns)
16
Diferentes tipos de padrotildees Etapas de Desenvolvimento de Sistemas
Requisitos Anaacutelise Projeto Implementaccedilatildeo e Teste Domiacutenio de Aplicaccedilatildeo
Seguranccedila BD GUI XML Web Sistemas Distribuiacutedos
Camada de Aplicaccedilatildeo do Padratildeo Negoacutecios Apresentaccedilatildeo Integraccedilatildeo (Sun)
Classificaccedilatildeo de Autores GoF Estrutural Comportamental Criaccedilatildeo POSA Sistemas Interativos Organizaccedilatildeo do
Trabalho Comunicaccedilatildeo
17
Classificaccedilatildeo dos Padrotildees de Software (Cont)
Requisitos Anaacutelise Projeto Implementaccedilatildeo
Padrotildees de Requisitos
Padrotildees de Anaacutelise
Padrotildees de Projeto
Meta-Padrotildees
Padrotildees Arquiteturais
Idiomas
18
Padrotildees de Requisitos Documentam as necessidades do usuaacuterio e
o comportamento geneacuterico do sistema em um alto niacutevel de abstraccedilatildeo
Accedilotildees que os desenvolvedores de software podem tomar para melhorar os requisitos natildeo-funcionais
Mostram os relacionamentos entre o usuaacuterio ou o operador e o sistema
19
Padrotildees de Requisitos (Cont)
Fault-tolerant telecommunication patterns Visa a manutenccedilatildeo dos sistemas de comutaccedilatildeo Medidas apropriadas para serem tomadas no estaacutegio
de desenvolvimento de requisitos Padrotildees relacionados a confiabilidade (mensagens
do sistema e falhas do sistema) Five minutes of no escalation messages
Padrotildees relacionados aos fatores humanos
20
Padrotildees de Anaacutelise Inicialmente apresentados como complementos
aos padrotildees de projeto Um passo antes do projeto
Modelo de anaacutelise que focaliza nas estruturas conceituais
Padrotildees de anaacutelise do Martin Fowler Domiacutenio de conhecimento de software de negoacutecios Party quantity subtype state machines entre outros
21
Padrotildees de Anaacutelise (Cont) Party Problema pessoas e organizaccedilotildees tecircm
responsabilidades semelhantes Soluccedilatildeo Crie um tipo party como um
supertype de uma pessoa ou organizaccedilatildeo
22
Padrotildees de Projeto Estrutura repetida de elementos de projeto ldquoUm esquema para o refinamento de subsistemas ou de
componentes de sistemas ou as relaccedilotildees entre elesrdquo ldquoresolvem um problema geral de projeto num contexto particularrdquo GoF
Padrotildees de projeto que incluem detalhes de coacutedigo de baixo niacutevel
Aplicados a diferentes tipos de problemas Padrotildees Arquiteturais e Meta-Padrotildees podem ser
considerados Padrotildees de Projeto
23
Idiomas Relacionados com a implementaccedilatildeo de
caracteriacutesticas de projeto especiacuteficas Padratildeo de baixo niacutevel especiacutefico para uma
linguagem de programaccedilatildeo Idiomas em C++
C++ Programming Styles and Idioms James Coplien 1991
24
Idiomas (Cont)
Nome Counted Body Contexto A interface de uma classe eacute separada de sua
implementaccedilatildeo (respectivamente classes handle e body) Problema atribuiccedilatildeo em C++ eacute definida recursivamente
como membro-por-membro com coacutepia quando a recursatildeo termina
Soluccedilatildeo Um contador de referecircncia eacute adicionado agrave classe body para facilitar o gerenciamento de memoacuteria
Autor e data James Coplien 1994
25
A Comunidade de Padrotildees
Uma hierarquia de workshops de escritores Grupos de leitura local Grupo Hillside Livros com os artigos da conferecircncia Conferecircncias PLoP ao redor do mundo
26
Eacutetica de Padrotildees Regra de Buschmann nunca capture suas
proacuteprias ideacuteias em um padratildeo Natildeo pense que padrotildees resolvem tudo Tente sempre encorajar as pessoas a repassar os
conhecimentos Sempre reconheccedila aqueles que criaram as
teacutecnicas ou que primeiro se empenharam a escrever sobre elas
Padrotildees satildeo ldquoapenasrdquo mais uma teacutecnica para ajudaacute-lo no desenvolvimento de software
27
Reuso
Conheccedila os padrotildees que estatildeo disponiacuteveis Cataacutelogo de padrotildees de 2000 Escolha aquele que satisfaz as suas necessidades
Um padratildeo eacute difiacutecil de entender se vocecirc natildeo necessita dele
Apenas tenha uma visatildeo geral Utilize o vocabulaacuterio dos padrotildees em revisotildees e
sessotildees de projeto
28
Reuso (Cont) GoF
Bastante utilizado entre a comunidade de software Core J2EE Pattern Catalog
httpjavasuncomblueprintscorej2eepatterns Padrotildees Arquiteturais
Frank Bushmann Regine Meunier Hans Rohnert Peter Sommerlad Michael Stal (Gang of Five)
29
GoF Design Patterns
Creational patternsAbstract factory BuilderFactory method Prototype Singleton
Behavioral PatternsChain of Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor
Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
14
Diferentes Definiccedilotildees (Cont) ldquoUm padratildeo eacute uma soluccedilatildeo provada para um
problema em um contexto rdquo Comunidade de Software
15
Um Pouco da Histoacuteria Object-Oriented (OO)
Metade do anos 80 Padrotildees de software emergiram de objetos Ward Cunningham and Kent Beck
1987 linguagem de padrotildees para interface de usuaacuterio James Coplien
1988 idioms Erich Gamma Richard Helm Ralph Johnson and John
Vlissides 1990 1995 Padrotildees de projeto (Design Patterns)
16
Diferentes tipos de padrotildees Etapas de Desenvolvimento de Sistemas
Requisitos Anaacutelise Projeto Implementaccedilatildeo e Teste Domiacutenio de Aplicaccedilatildeo
Seguranccedila BD GUI XML Web Sistemas Distribuiacutedos
Camada de Aplicaccedilatildeo do Padratildeo Negoacutecios Apresentaccedilatildeo Integraccedilatildeo (Sun)
Classificaccedilatildeo de Autores GoF Estrutural Comportamental Criaccedilatildeo POSA Sistemas Interativos Organizaccedilatildeo do
Trabalho Comunicaccedilatildeo
17
Classificaccedilatildeo dos Padrotildees de Software (Cont)
Requisitos Anaacutelise Projeto Implementaccedilatildeo
Padrotildees de Requisitos
Padrotildees de Anaacutelise
Padrotildees de Projeto
Meta-Padrotildees
Padrotildees Arquiteturais
Idiomas
18
Padrotildees de Requisitos Documentam as necessidades do usuaacuterio e
o comportamento geneacuterico do sistema em um alto niacutevel de abstraccedilatildeo
Accedilotildees que os desenvolvedores de software podem tomar para melhorar os requisitos natildeo-funcionais
Mostram os relacionamentos entre o usuaacuterio ou o operador e o sistema
19
Padrotildees de Requisitos (Cont)
Fault-tolerant telecommunication patterns Visa a manutenccedilatildeo dos sistemas de comutaccedilatildeo Medidas apropriadas para serem tomadas no estaacutegio
de desenvolvimento de requisitos Padrotildees relacionados a confiabilidade (mensagens
do sistema e falhas do sistema) Five minutes of no escalation messages
Padrotildees relacionados aos fatores humanos
20
Padrotildees de Anaacutelise Inicialmente apresentados como complementos
aos padrotildees de projeto Um passo antes do projeto
Modelo de anaacutelise que focaliza nas estruturas conceituais
Padrotildees de anaacutelise do Martin Fowler Domiacutenio de conhecimento de software de negoacutecios Party quantity subtype state machines entre outros
21
Padrotildees de Anaacutelise (Cont) Party Problema pessoas e organizaccedilotildees tecircm
responsabilidades semelhantes Soluccedilatildeo Crie um tipo party como um
supertype de uma pessoa ou organizaccedilatildeo
22
Padrotildees de Projeto Estrutura repetida de elementos de projeto ldquoUm esquema para o refinamento de subsistemas ou de
componentes de sistemas ou as relaccedilotildees entre elesrdquo ldquoresolvem um problema geral de projeto num contexto particularrdquo GoF
Padrotildees de projeto que incluem detalhes de coacutedigo de baixo niacutevel
Aplicados a diferentes tipos de problemas Padrotildees Arquiteturais e Meta-Padrotildees podem ser
considerados Padrotildees de Projeto
23
Idiomas Relacionados com a implementaccedilatildeo de
caracteriacutesticas de projeto especiacuteficas Padratildeo de baixo niacutevel especiacutefico para uma
linguagem de programaccedilatildeo Idiomas em C++
C++ Programming Styles and Idioms James Coplien 1991
24
Idiomas (Cont)
Nome Counted Body Contexto A interface de uma classe eacute separada de sua
implementaccedilatildeo (respectivamente classes handle e body) Problema atribuiccedilatildeo em C++ eacute definida recursivamente
como membro-por-membro com coacutepia quando a recursatildeo termina
Soluccedilatildeo Um contador de referecircncia eacute adicionado agrave classe body para facilitar o gerenciamento de memoacuteria
Autor e data James Coplien 1994
25
A Comunidade de Padrotildees
Uma hierarquia de workshops de escritores Grupos de leitura local Grupo Hillside Livros com os artigos da conferecircncia Conferecircncias PLoP ao redor do mundo
26
Eacutetica de Padrotildees Regra de Buschmann nunca capture suas
proacuteprias ideacuteias em um padratildeo Natildeo pense que padrotildees resolvem tudo Tente sempre encorajar as pessoas a repassar os
conhecimentos Sempre reconheccedila aqueles que criaram as
teacutecnicas ou que primeiro se empenharam a escrever sobre elas
Padrotildees satildeo ldquoapenasrdquo mais uma teacutecnica para ajudaacute-lo no desenvolvimento de software
27
Reuso
Conheccedila os padrotildees que estatildeo disponiacuteveis Cataacutelogo de padrotildees de 2000 Escolha aquele que satisfaz as suas necessidades
Um padratildeo eacute difiacutecil de entender se vocecirc natildeo necessita dele
Apenas tenha uma visatildeo geral Utilize o vocabulaacuterio dos padrotildees em revisotildees e
sessotildees de projeto
28
Reuso (Cont) GoF
Bastante utilizado entre a comunidade de software Core J2EE Pattern Catalog
httpjavasuncomblueprintscorej2eepatterns Padrotildees Arquiteturais
Frank Bushmann Regine Meunier Hans Rohnert Peter Sommerlad Michael Stal (Gang of Five)
29
GoF Design Patterns
Creational patternsAbstract factory BuilderFactory method Prototype Singleton
Behavioral PatternsChain of Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor
Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
15
Um Pouco da Histoacuteria Object-Oriented (OO)
Metade do anos 80 Padrotildees de software emergiram de objetos Ward Cunningham and Kent Beck
1987 linguagem de padrotildees para interface de usuaacuterio James Coplien
1988 idioms Erich Gamma Richard Helm Ralph Johnson and John
Vlissides 1990 1995 Padrotildees de projeto (Design Patterns)
16
Diferentes tipos de padrotildees Etapas de Desenvolvimento de Sistemas
Requisitos Anaacutelise Projeto Implementaccedilatildeo e Teste Domiacutenio de Aplicaccedilatildeo
Seguranccedila BD GUI XML Web Sistemas Distribuiacutedos
Camada de Aplicaccedilatildeo do Padratildeo Negoacutecios Apresentaccedilatildeo Integraccedilatildeo (Sun)
Classificaccedilatildeo de Autores GoF Estrutural Comportamental Criaccedilatildeo POSA Sistemas Interativos Organizaccedilatildeo do
Trabalho Comunicaccedilatildeo
17
Classificaccedilatildeo dos Padrotildees de Software (Cont)
Requisitos Anaacutelise Projeto Implementaccedilatildeo
Padrotildees de Requisitos
Padrotildees de Anaacutelise
Padrotildees de Projeto
Meta-Padrotildees
Padrotildees Arquiteturais
Idiomas
18
Padrotildees de Requisitos Documentam as necessidades do usuaacuterio e
o comportamento geneacuterico do sistema em um alto niacutevel de abstraccedilatildeo
Accedilotildees que os desenvolvedores de software podem tomar para melhorar os requisitos natildeo-funcionais
Mostram os relacionamentos entre o usuaacuterio ou o operador e o sistema
19
Padrotildees de Requisitos (Cont)
Fault-tolerant telecommunication patterns Visa a manutenccedilatildeo dos sistemas de comutaccedilatildeo Medidas apropriadas para serem tomadas no estaacutegio
de desenvolvimento de requisitos Padrotildees relacionados a confiabilidade (mensagens
do sistema e falhas do sistema) Five minutes of no escalation messages
Padrotildees relacionados aos fatores humanos
20
Padrotildees de Anaacutelise Inicialmente apresentados como complementos
aos padrotildees de projeto Um passo antes do projeto
Modelo de anaacutelise que focaliza nas estruturas conceituais
Padrotildees de anaacutelise do Martin Fowler Domiacutenio de conhecimento de software de negoacutecios Party quantity subtype state machines entre outros
21
Padrotildees de Anaacutelise (Cont) Party Problema pessoas e organizaccedilotildees tecircm
responsabilidades semelhantes Soluccedilatildeo Crie um tipo party como um
supertype de uma pessoa ou organizaccedilatildeo
22
Padrotildees de Projeto Estrutura repetida de elementos de projeto ldquoUm esquema para o refinamento de subsistemas ou de
componentes de sistemas ou as relaccedilotildees entre elesrdquo ldquoresolvem um problema geral de projeto num contexto particularrdquo GoF
Padrotildees de projeto que incluem detalhes de coacutedigo de baixo niacutevel
Aplicados a diferentes tipos de problemas Padrotildees Arquiteturais e Meta-Padrotildees podem ser
considerados Padrotildees de Projeto
23
Idiomas Relacionados com a implementaccedilatildeo de
caracteriacutesticas de projeto especiacuteficas Padratildeo de baixo niacutevel especiacutefico para uma
linguagem de programaccedilatildeo Idiomas em C++
C++ Programming Styles and Idioms James Coplien 1991
24
Idiomas (Cont)
Nome Counted Body Contexto A interface de uma classe eacute separada de sua
implementaccedilatildeo (respectivamente classes handle e body) Problema atribuiccedilatildeo em C++ eacute definida recursivamente
como membro-por-membro com coacutepia quando a recursatildeo termina
Soluccedilatildeo Um contador de referecircncia eacute adicionado agrave classe body para facilitar o gerenciamento de memoacuteria
Autor e data James Coplien 1994
25
A Comunidade de Padrotildees
Uma hierarquia de workshops de escritores Grupos de leitura local Grupo Hillside Livros com os artigos da conferecircncia Conferecircncias PLoP ao redor do mundo
26
Eacutetica de Padrotildees Regra de Buschmann nunca capture suas
proacuteprias ideacuteias em um padratildeo Natildeo pense que padrotildees resolvem tudo Tente sempre encorajar as pessoas a repassar os
conhecimentos Sempre reconheccedila aqueles que criaram as
teacutecnicas ou que primeiro se empenharam a escrever sobre elas
Padrotildees satildeo ldquoapenasrdquo mais uma teacutecnica para ajudaacute-lo no desenvolvimento de software
27
Reuso
Conheccedila os padrotildees que estatildeo disponiacuteveis Cataacutelogo de padrotildees de 2000 Escolha aquele que satisfaz as suas necessidades
Um padratildeo eacute difiacutecil de entender se vocecirc natildeo necessita dele
Apenas tenha uma visatildeo geral Utilize o vocabulaacuterio dos padrotildees em revisotildees e
sessotildees de projeto
28
Reuso (Cont) GoF
Bastante utilizado entre a comunidade de software Core J2EE Pattern Catalog
httpjavasuncomblueprintscorej2eepatterns Padrotildees Arquiteturais
Frank Bushmann Regine Meunier Hans Rohnert Peter Sommerlad Michael Stal (Gang of Five)
29
GoF Design Patterns
Creational patternsAbstract factory BuilderFactory method Prototype Singleton
Behavioral PatternsChain of Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor
Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
16
Diferentes tipos de padrotildees Etapas de Desenvolvimento de Sistemas
Requisitos Anaacutelise Projeto Implementaccedilatildeo e Teste Domiacutenio de Aplicaccedilatildeo
Seguranccedila BD GUI XML Web Sistemas Distribuiacutedos
Camada de Aplicaccedilatildeo do Padratildeo Negoacutecios Apresentaccedilatildeo Integraccedilatildeo (Sun)
Classificaccedilatildeo de Autores GoF Estrutural Comportamental Criaccedilatildeo POSA Sistemas Interativos Organizaccedilatildeo do
Trabalho Comunicaccedilatildeo
17
Classificaccedilatildeo dos Padrotildees de Software (Cont)
Requisitos Anaacutelise Projeto Implementaccedilatildeo
Padrotildees de Requisitos
Padrotildees de Anaacutelise
Padrotildees de Projeto
Meta-Padrotildees
Padrotildees Arquiteturais
Idiomas
18
Padrotildees de Requisitos Documentam as necessidades do usuaacuterio e
o comportamento geneacuterico do sistema em um alto niacutevel de abstraccedilatildeo
Accedilotildees que os desenvolvedores de software podem tomar para melhorar os requisitos natildeo-funcionais
Mostram os relacionamentos entre o usuaacuterio ou o operador e o sistema
19
Padrotildees de Requisitos (Cont)
Fault-tolerant telecommunication patterns Visa a manutenccedilatildeo dos sistemas de comutaccedilatildeo Medidas apropriadas para serem tomadas no estaacutegio
de desenvolvimento de requisitos Padrotildees relacionados a confiabilidade (mensagens
do sistema e falhas do sistema) Five minutes of no escalation messages
Padrotildees relacionados aos fatores humanos
20
Padrotildees de Anaacutelise Inicialmente apresentados como complementos
aos padrotildees de projeto Um passo antes do projeto
Modelo de anaacutelise que focaliza nas estruturas conceituais
Padrotildees de anaacutelise do Martin Fowler Domiacutenio de conhecimento de software de negoacutecios Party quantity subtype state machines entre outros
21
Padrotildees de Anaacutelise (Cont) Party Problema pessoas e organizaccedilotildees tecircm
responsabilidades semelhantes Soluccedilatildeo Crie um tipo party como um
supertype de uma pessoa ou organizaccedilatildeo
22
Padrotildees de Projeto Estrutura repetida de elementos de projeto ldquoUm esquema para o refinamento de subsistemas ou de
componentes de sistemas ou as relaccedilotildees entre elesrdquo ldquoresolvem um problema geral de projeto num contexto particularrdquo GoF
Padrotildees de projeto que incluem detalhes de coacutedigo de baixo niacutevel
Aplicados a diferentes tipos de problemas Padrotildees Arquiteturais e Meta-Padrotildees podem ser
considerados Padrotildees de Projeto
23
Idiomas Relacionados com a implementaccedilatildeo de
caracteriacutesticas de projeto especiacuteficas Padratildeo de baixo niacutevel especiacutefico para uma
linguagem de programaccedilatildeo Idiomas em C++
C++ Programming Styles and Idioms James Coplien 1991
24
Idiomas (Cont)
Nome Counted Body Contexto A interface de uma classe eacute separada de sua
implementaccedilatildeo (respectivamente classes handle e body) Problema atribuiccedilatildeo em C++ eacute definida recursivamente
como membro-por-membro com coacutepia quando a recursatildeo termina
Soluccedilatildeo Um contador de referecircncia eacute adicionado agrave classe body para facilitar o gerenciamento de memoacuteria
Autor e data James Coplien 1994
25
A Comunidade de Padrotildees
Uma hierarquia de workshops de escritores Grupos de leitura local Grupo Hillside Livros com os artigos da conferecircncia Conferecircncias PLoP ao redor do mundo
26
Eacutetica de Padrotildees Regra de Buschmann nunca capture suas
proacuteprias ideacuteias em um padratildeo Natildeo pense que padrotildees resolvem tudo Tente sempre encorajar as pessoas a repassar os
conhecimentos Sempre reconheccedila aqueles que criaram as
teacutecnicas ou que primeiro se empenharam a escrever sobre elas
Padrotildees satildeo ldquoapenasrdquo mais uma teacutecnica para ajudaacute-lo no desenvolvimento de software
27
Reuso
Conheccedila os padrotildees que estatildeo disponiacuteveis Cataacutelogo de padrotildees de 2000 Escolha aquele que satisfaz as suas necessidades
Um padratildeo eacute difiacutecil de entender se vocecirc natildeo necessita dele
Apenas tenha uma visatildeo geral Utilize o vocabulaacuterio dos padrotildees em revisotildees e
sessotildees de projeto
28
Reuso (Cont) GoF
Bastante utilizado entre a comunidade de software Core J2EE Pattern Catalog
httpjavasuncomblueprintscorej2eepatterns Padrotildees Arquiteturais
Frank Bushmann Regine Meunier Hans Rohnert Peter Sommerlad Michael Stal (Gang of Five)
29
GoF Design Patterns
Creational patternsAbstract factory BuilderFactory method Prototype Singleton
Behavioral PatternsChain of Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor
Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
17
Classificaccedilatildeo dos Padrotildees de Software (Cont)
Requisitos Anaacutelise Projeto Implementaccedilatildeo
Padrotildees de Requisitos
Padrotildees de Anaacutelise
Padrotildees de Projeto
Meta-Padrotildees
Padrotildees Arquiteturais
Idiomas
18
Padrotildees de Requisitos Documentam as necessidades do usuaacuterio e
o comportamento geneacuterico do sistema em um alto niacutevel de abstraccedilatildeo
Accedilotildees que os desenvolvedores de software podem tomar para melhorar os requisitos natildeo-funcionais
Mostram os relacionamentos entre o usuaacuterio ou o operador e o sistema
19
Padrotildees de Requisitos (Cont)
Fault-tolerant telecommunication patterns Visa a manutenccedilatildeo dos sistemas de comutaccedilatildeo Medidas apropriadas para serem tomadas no estaacutegio
de desenvolvimento de requisitos Padrotildees relacionados a confiabilidade (mensagens
do sistema e falhas do sistema) Five minutes of no escalation messages
Padrotildees relacionados aos fatores humanos
20
Padrotildees de Anaacutelise Inicialmente apresentados como complementos
aos padrotildees de projeto Um passo antes do projeto
Modelo de anaacutelise que focaliza nas estruturas conceituais
Padrotildees de anaacutelise do Martin Fowler Domiacutenio de conhecimento de software de negoacutecios Party quantity subtype state machines entre outros
21
Padrotildees de Anaacutelise (Cont) Party Problema pessoas e organizaccedilotildees tecircm
responsabilidades semelhantes Soluccedilatildeo Crie um tipo party como um
supertype de uma pessoa ou organizaccedilatildeo
22
Padrotildees de Projeto Estrutura repetida de elementos de projeto ldquoUm esquema para o refinamento de subsistemas ou de
componentes de sistemas ou as relaccedilotildees entre elesrdquo ldquoresolvem um problema geral de projeto num contexto particularrdquo GoF
Padrotildees de projeto que incluem detalhes de coacutedigo de baixo niacutevel
Aplicados a diferentes tipos de problemas Padrotildees Arquiteturais e Meta-Padrotildees podem ser
considerados Padrotildees de Projeto
23
Idiomas Relacionados com a implementaccedilatildeo de
caracteriacutesticas de projeto especiacuteficas Padratildeo de baixo niacutevel especiacutefico para uma
linguagem de programaccedilatildeo Idiomas em C++
C++ Programming Styles and Idioms James Coplien 1991
24
Idiomas (Cont)
Nome Counted Body Contexto A interface de uma classe eacute separada de sua
implementaccedilatildeo (respectivamente classes handle e body) Problema atribuiccedilatildeo em C++ eacute definida recursivamente
como membro-por-membro com coacutepia quando a recursatildeo termina
Soluccedilatildeo Um contador de referecircncia eacute adicionado agrave classe body para facilitar o gerenciamento de memoacuteria
Autor e data James Coplien 1994
25
A Comunidade de Padrotildees
Uma hierarquia de workshops de escritores Grupos de leitura local Grupo Hillside Livros com os artigos da conferecircncia Conferecircncias PLoP ao redor do mundo
26
Eacutetica de Padrotildees Regra de Buschmann nunca capture suas
proacuteprias ideacuteias em um padratildeo Natildeo pense que padrotildees resolvem tudo Tente sempre encorajar as pessoas a repassar os
conhecimentos Sempre reconheccedila aqueles que criaram as
teacutecnicas ou que primeiro se empenharam a escrever sobre elas
Padrotildees satildeo ldquoapenasrdquo mais uma teacutecnica para ajudaacute-lo no desenvolvimento de software
27
Reuso
Conheccedila os padrotildees que estatildeo disponiacuteveis Cataacutelogo de padrotildees de 2000 Escolha aquele que satisfaz as suas necessidades
Um padratildeo eacute difiacutecil de entender se vocecirc natildeo necessita dele
Apenas tenha uma visatildeo geral Utilize o vocabulaacuterio dos padrotildees em revisotildees e
sessotildees de projeto
28
Reuso (Cont) GoF
Bastante utilizado entre a comunidade de software Core J2EE Pattern Catalog
httpjavasuncomblueprintscorej2eepatterns Padrotildees Arquiteturais
Frank Bushmann Regine Meunier Hans Rohnert Peter Sommerlad Michael Stal (Gang of Five)
29
GoF Design Patterns
Creational patternsAbstract factory BuilderFactory method Prototype Singleton
Behavioral PatternsChain of Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor
Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
18
Padrotildees de Requisitos Documentam as necessidades do usuaacuterio e
o comportamento geneacuterico do sistema em um alto niacutevel de abstraccedilatildeo
Accedilotildees que os desenvolvedores de software podem tomar para melhorar os requisitos natildeo-funcionais
Mostram os relacionamentos entre o usuaacuterio ou o operador e o sistema
19
Padrotildees de Requisitos (Cont)
Fault-tolerant telecommunication patterns Visa a manutenccedilatildeo dos sistemas de comutaccedilatildeo Medidas apropriadas para serem tomadas no estaacutegio
de desenvolvimento de requisitos Padrotildees relacionados a confiabilidade (mensagens
do sistema e falhas do sistema) Five minutes of no escalation messages
Padrotildees relacionados aos fatores humanos
20
Padrotildees de Anaacutelise Inicialmente apresentados como complementos
aos padrotildees de projeto Um passo antes do projeto
Modelo de anaacutelise que focaliza nas estruturas conceituais
Padrotildees de anaacutelise do Martin Fowler Domiacutenio de conhecimento de software de negoacutecios Party quantity subtype state machines entre outros
21
Padrotildees de Anaacutelise (Cont) Party Problema pessoas e organizaccedilotildees tecircm
responsabilidades semelhantes Soluccedilatildeo Crie um tipo party como um
supertype de uma pessoa ou organizaccedilatildeo
22
Padrotildees de Projeto Estrutura repetida de elementos de projeto ldquoUm esquema para o refinamento de subsistemas ou de
componentes de sistemas ou as relaccedilotildees entre elesrdquo ldquoresolvem um problema geral de projeto num contexto particularrdquo GoF
Padrotildees de projeto que incluem detalhes de coacutedigo de baixo niacutevel
Aplicados a diferentes tipos de problemas Padrotildees Arquiteturais e Meta-Padrotildees podem ser
considerados Padrotildees de Projeto
23
Idiomas Relacionados com a implementaccedilatildeo de
caracteriacutesticas de projeto especiacuteficas Padratildeo de baixo niacutevel especiacutefico para uma
linguagem de programaccedilatildeo Idiomas em C++
C++ Programming Styles and Idioms James Coplien 1991
24
Idiomas (Cont)
Nome Counted Body Contexto A interface de uma classe eacute separada de sua
implementaccedilatildeo (respectivamente classes handle e body) Problema atribuiccedilatildeo em C++ eacute definida recursivamente
como membro-por-membro com coacutepia quando a recursatildeo termina
Soluccedilatildeo Um contador de referecircncia eacute adicionado agrave classe body para facilitar o gerenciamento de memoacuteria
Autor e data James Coplien 1994
25
A Comunidade de Padrotildees
Uma hierarquia de workshops de escritores Grupos de leitura local Grupo Hillside Livros com os artigos da conferecircncia Conferecircncias PLoP ao redor do mundo
26
Eacutetica de Padrotildees Regra de Buschmann nunca capture suas
proacuteprias ideacuteias em um padratildeo Natildeo pense que padrotildees resolvem tudo Tente sempre encorajar as pessoas a repassar os
conhecimentos Sempre reconheccedila aqueles que criaram as
teacutecnicas ou que primeiro se empenharam a escrever sobre elas
Padrotildees satildeo ldquoapenasrdquo mais uma teacutecnica para ajudaacute-lo no desenvolvimento de software
27
Reuso
Conheccedila os padrotildees que estatildeo disponiacuteveis Cataacutelogo de padrotildees de 2000 Escolha aquele que satisfaz as suas necessidades
Um padratildeo eacute difiacutecil de entender se vocecirc natildeo necessita dele
Apenas tenha uma visatildeo geral Utilize o vocabulaacuterio dos padrotildees em revisotildees e
sessotildees de projeto
28
Reuso (Cont) GoF
Bastante utilizado entre a comunidade de software Core J2EE Pattern Catalog
httpjavasuncomblueprintscorej2eepatterns Padrotildees Arquiteturais
Frank Bushmann Regine Meunier Hans Rohnert Peter Sommerlad Michael Stal (Gang of Five)
29
GoF Design Patterns
Creational patternsAbstract factory BuilderFactory method Prototype Singleton
Behavioral PatternsChain of Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor
Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
19
Padrotildees de Requisitos (Cont)
Fault-tolerant telecommunication patterns Visa a manutenccedilatildeo dos sistemas de comutaccedilatildeo Medidas apropriadas para serem tomadas no estaacutegio
de desenvolvimento de requisitos Padrotildees relacionados a confiabilidade (mensagens
do sistema e falhas do sistema) Five minutes of no escalation messages
Padrotildees relacionados aos fatores humanos
20
Padrotildees de Anaacutelise Inicialmente apresentados como complementos
aos padrotildees de projeto Um passo antes do projeto
Modelo de anaacutelise que focaliza nas estruturas conceituais
Padrotildees de anaacutelise do Martin Fowler Domiacutenio de conhecimento de software de negoacutecios Party quantity subtype state machines entre outros
21
Padrotildees de Anaacutelise (Cont) Party Problema pessoas e organizaccedilotildees tecircm
responsabilidades semelhantes Soluccedilatildeo Crie um tipo party como um
supertype de uma pessoa ou organizaccedilatildeo
22
Padrotildees de Projeto Estrutura repetida de elementos de projeto ldquoUm esquema para o refinamento de subsistemas ou de
componentes de sistemas ou as relaccedilotildees entre elesrdquo ldquoresolvem um problema geral de projeto num contexto particularrdquo GoF
Padrotildees de projeto que incluem detalhes de coacutedigo de baixo niacutevel
Aplicados a diferentes tipos de problemas Padrotildees Arquiteturais e Meta-Padrotildees podem ser
considerados Padrotildees de Projeto
23
Idiomas Relacionados com a implementaccedilatildeo de
caracteriacutesticas de projeto especiacuteficas Padratildeo de baixo niacutevel especiacutefico para uma
linguagem de programaccedilatildeo Idiomas em C++
C++ Programming Styles and Idioms James Coplien 1991
24
Idiomas (Cont)
Nome Counted Body Contexto A interface de uma classe eacute separada de sua
implementaccedilatildeo (respectivamente classes handle e body) Problema atribuiccedilatildeo em C++ eacute definida recursivamente
como membro-por-membro com coacutepia quando a recursatildeo termina
Soluccedilatildeo Um contador de referecircncia eacute adicionado agrave classe body para facilitar o gerenciamento de memoacuteria
Autor e data James Coplien 1994
25
A Comunidade de Padrotildees
Uma hierarquia de workshops de escritores Grupos de leitura local Grupo Hillside Livros com os artigos da conferecircncia Conferecircncias PLoP ao redor do mundo
26
Eacutetica de Padrotildees Regra de Buschmann nunca capture suas
proacuteprias ideacuteias em um padratildeo Natildeo pense que padrotildees resolvem tudo Tente sempre encorajar as pessoas a repassar os
conhecimentos Sempre reconheccedila aqueles que criaram as
teacutecnicas ou que primeiro se empenharam a escrever sobre elas
Padrotildees satildeo ldquoapenasrdquo mais uma teacutecnica para ajudaacute-lo no desenvolvimento de software
27
Reuso
Conheccedila os padrotildees que estatildeo disponiacuteveis Cataacutelogo de padrotildees de 2000 Escolha aquele que satisfaz as suas necessidades
Um padratildeo eacute difiacutecil de entender se vocecirc natildeo necessita dele
Apenas tenha uma visatildeo geral Utilize o vocabulaacuterio dos padrotildees em revisotildees e
sessotildees de projeto
28
Reuso (Cont) GoF
Bastante utilizado entre a comunidade de software Core J2EE Pattern Catalog
httpjavasuncomblueprintscorej2eepatterns Padrotildees Arquiteturais
Frank Bushmann Regine Meunier Hans Rohnert Peter Sommerlad Michael Stal (Gang of Five)
29
GoF Design Patterns
Creational patternsAbstract factory BuilderFactory method Prototype Singleton
Behavioral PatternsChain of Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor
Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
20
Padrotildees de Anaacutelise Inicialmente apresentados como complementos
aos padrotildees de projeto Um passo antes do projeto
Modelo de anaacutelise que focaliza nas estruturas conceituais
Padrotildees de anaacutelise do Martin Fowler Domiacutenio de conhecimento de software de negoacutecios Party quantity subtype state machines entre outros
21
Padrotildees de Anaacutelise (Cont) Party Problema pessoas e organizaccedilotildees tecircm
responsabilidades semelhantes Soluccedilatildeo Crie um tipo party como um
supertype de uma pessoa ou organizaccedilatildeo
22
Padrotildees de Projeto Estrutura repetida de elementos de projeto ldquoUm esquema para o refinamento de subsistemas ou de
componentes de sistemas ou as relaccedilotildees entre elesrdquo ldquoresolvem um problema geral de projeto num contexto particularrdquo GoF
Padrotildees de projeto que incluem detalhes de coacutedigo de baixo niacutevel
Aplicados a diferentes tipos de problemas Padrotildees Arquiteturais e Meta-Padrotildees podem ser
considerados Padrotildees de Projeto
23
Idiomas Relacionados com a implementaccedilatildeo de
caracteriacutesticas de projeto especiacuteficas Padratildeo de baixo niacutevel especiacutefico para uma
linguagem de programaccedilatildeo Idiomas em C++
C++ Programming Styles and Idioms James Coplien 1991
24
Idiomas (Cont)
Nome Counted Body Contexto A interface de uma classe eacute separada de sua
implementaccedilatildeo (respectivamente classes handle e body) Problema atribuiccedilatildeo em C++ eacute definida recursivamente
como membro-por-membro com coacutepia quando a recursatildeo termina
Soluccedilatildeo Um contador de referecircncia eacute adicionado agrave classe body para facilitar o gerenciamento de memoacuteria
Autor e data James Coplien 1994
25
A Comunidade de Padrotildees
Uma hierarquia de workshops de escritores Grupos de leitura local Grupo Hillside Livros com os artigos da conferecircncia Conferecircncias PLoP ao redor do mundo
26
Eacutetica de Padrotildees Regra de Buschmann nunca capture suas
proacuteprias ideacuteias em um padratildeo Natildeo pense que padrotildees resolvem tudo Tente sempre encorajar as pessoas a repassar os
conhecimentos Sempre reconheccedila aqueles que criaram as
teacutecnicas ou que primeiro se empenharam a escrever sobre elas
Padrotildees satildeo ldquoapenasrdquo mais uma teacutecnica para ajudaacute-lo no desenvolvimento de software
27
Reuso
Conheccedila os padrotildees que estatildeo disponiacuteveis Cataacutelogo de padrotildees de 2000 Escolha aquele que satisfaz as suas necessidades
Um padratildeo eacute difiacutecil de entender se vocecirc natildeo necessita dele
Apenas tenha uma visatildeo geral Utilize o vocabulaacuterio dos padrotildees em revisotildees e
sessotildees de projeto
28
Reuso (Cont) GoF
Bastante utilizado entre a comunidade de software Core J2EE Pattern Catalog
httpjavasuncomblueprintscorej2eepatterns Padrotildees Arquiteturais
Frank Bushmann Regine Meunier Hans Rohnert Peter Sommerlad Michael Stal (Gang of Five)
29
GoF Design Patterns
Creational patternsAbstract factory BuilderFactory method Prototype Singleton
Behavioral PatternsChain of Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor
Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
21
Padrotildees de Anaacutelise (Cont) Party Problema pessoas e organizaccedilotildees tecircm
responsabilidades semelhantes Soluccedilatildeo Crie um tipo party como um
supertype de uma pessoa ou organizaccedilatildeo
22
Padrotildees de Projeto Estrutura repetida de elementos de projeto ldquoUm esquema para o refinamento de subsistemas ou de
componentes de sistemas ou as relaccedilotildees entre elesrdquo ldquoresolvem um problema geral de projeto num contexto particularrdquo GoF
Padrotildees de projeto que incluem detalhes de coacutedigo de baixo niacutevel
Aplicados a diferentes tipos de problemas Padrotildees Arquiteturais e Meta-Padrotildees podem ser
considerados Padrotildees de Projeto
23
Idiomas Relacionados com a implementaccedilatildeo de
caracteriacutesticas de projeto especiacuteficas Padratildeo de baixo niacutevel especiacutefico para uma
linguagem de programaccedilatildeo Idiomas em C++
C++ Programming Styles and Idioms James Coplien 1991
24
Idiomas (Cont)
Nome Counted Body Contexto A interface de uma classe eacute separada de sua
implementaccedilatildeo (respectivamente classes handle e body) Problema atribuiccedilatildeo em C++ eacute definida recursivamente
como membro-por-membro com coacutepia quando a recursatildeo termina
Soluccedilatildeo Um contador de referecircncia eacute adicionado agrave classe body para facilitar o gerenciamento de memoacuteria
Autor e data James Coplien 1994
25
A Comunidade de Padrotildees
Uma hierarquia de workshops de escritores Grupos de leitura local Grupo Hillside Livros com os artigos da conferecircncia Conferecircncias PLoP ao redor do mundo
26
Eacutetica de Padrotildees Regra de Buschmann nunca capture suas
proacuteprias ideacuteias em um padratildeo Natildeo pense que padrotildees resolvem tudo Tente sempre encorajar as pessoas a repassar os
conhecimentos Sempre reconheccedila aqueles que criaram as
teacutecnicas ou que primeiro se empenharam a escrever sobre elas
Padrotildees satildeo ldquoapenasrdquo mais uma teacutecnica para ajudaacute-lo no desenvolvimento de software
27
Reuso
Conheccedila os padrotildees que estatildeo disponiacuteveis Cataacutelogo de padrotildees de 2000 Escolha aquele que satisfaz as suas necessidades
Um padratildeo eacute difiacutecil de entender se vocecirc natildeo necessita dele
Apenas tenha uma visatildeo geral Utilize o vocabulaacuterio dos padrotildees em revisotildees e
sessotildees de projeto
28
Reuso (Cont) GoF
Bastante utilizado entre a comunidade de software Core J2EE Pattern Catalog
httpjavasuncomblueprintscorej2eepatterns Padrotildees Arquiteturais
Frank Bushmann Regine Meunier Hans Rohnert Peter Sommerlad Michael Stal (Gang of Five)
29
GoF Design Patterns
Creational patternsAbstract factory BuilderFactory method Prototype Singleton
Behavioral PatternsChain of Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor
Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
22
Padrotildees de Projeto Estrutura repetida de elementos de projeto ldquoUm esquema para o refinamento de subsistemas ou de
componentes de sistemas ou as relaccedilotildees entre elesrdquo ldquoresolvem um problema geral de projeto num contexto particularrdquo GoF
Padrotildees de projeto que incluem detalhes de coacutedigo de baixo niacutevel
Aplicados a diferentes tipos de problemas Padrotildees Arquiteturais e Meta-Padrotildees podem ser
considerados Padrotildees de Projeto
23
Idiomas Relacionados com a implementaccedilatildeo de
caracteriacutesticas de projeto especiacuteficas Padratildeo de baixo niacutevel especiacutefico para uma
linguagem de programaccedilatildeo Idiomas em C++
C++ Programming Styles and Idioms James Coplien 1991
24
Idiomas (Cont)
Nome Counted Body Contexto A interface de uma classe eacute separada de sua
implementaccedilatildeo (respectivamente classes handle e body) Problema atribuiccedilatildeo em C++ eacute definida recursivamente
como membro-por-membro com coacutepia quando a recursatildeo termina
Soluccedilatildeo Um contador de referecircncia eacute adicionado agrave classe body para facilitar o gerenciamento de memoacuteria
Autor e data James Coplien 1994
25
A Comunidade de Padrotildees
Uma hierarquia de workshops de escritores Grupos de leitura local Grupo Hillside Livros com os artigos da conferecircncia Conferecircncias PLoP ao redor do mundo
26
Eacutetica de Padrotildees Regra de Buschmann nunca capture suas
proacuteprias ideacuteias em um padratildeo Natildeo pense que padrotildees resolvem tudo Tente sempre encorajar as pessoas a repassar os
conhecimentos Sempre reconheccedila aqueles que criaram as
teacutecnicas ou que primeiro se empenharam a escrever sobre elas
Padrotildees satildeo ldquoapenasrdquo mais uma teacutecnica para ajudaacute-lo no desenvolvimento de software
27
Reuso
Conheccedila os padrotildees que estatildeo disponiacuteveis Cataacutelogo de padrotildees de 2000 Escolha aquele que satisfaz as suas necessidades
Um padratildeo eacute difiacutecil de entender se vocecirc natildeo necessita dele
Apenas tenha uma visatildeo geral Utilize o vocabulaacuterio dos padrotildees em revisotildees e
sessotildees de projeto
28
Reuso (Cont) GoF
Bastante utilizado entre a comunidade de software Core J2EE Pattern Catalog
httpjavasuncomblueprintscorej2eepatterns Padrotildees Arquiteturais
Frank Bushmann Regine Meunier Hans Rohnert Peter Sommerlad Michael Stal (Gang of Five)
29
GoF Design Patterns
Creational patternsAbstract factory BuilderFactory method Prototype Singleton
Behavioral PatternsChain of Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor
Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
23
Idiomas Relacionados com a implementaccedilatildeo de
caracteriacutesticas de projeto especiacuteficas Padratildeo de baixo niacutevel especiacutefico para uma
linguagem de programaccedilatildeo Idiomas em C++
C++ Programming Styles and Idioms James Coplien 1991
24
Idiomas (Cont)
Nome Counted Body Contexto A interface de uma classe eacute separada de sua
implementaccedilatildeo (respectivamente classes handle e body) Problema atribuiccedilatildeo em C++ eacute definida recursivamente
como membro-por-membro com coacutepia quando a recursatildeo termina
Soluccedilatildeo Um contador de referecircncia eacute adicionado agrave classe body para facilitar o gerenciamento de memoacuteria
Autor e data James Coplien 1994
25
A Comunidade de Padrotildees
Uma hierarquia de workshops de escritores Grupos de leitura local Grupo Hillside Livros com os artigos da conferecircncia Conferecircncias PLoP ao redor do mundo
26
Eacutetica de Padrotildees Regra de Buschmann nunca capture suas
proacuteprias ideacuteias em um padratildeo Natildeo pense que padrotildees resolvem tudo Tente sempre encorajar as pessoas a repassar os
conhecimentos Sempre reconheccedila aqueles que criaram as
teacutecnicas ou que primeiro se empenharam a escrever sobre elas
Padrotildees satildeo ldquoapenasrdquo mais uma teacutecnica para ajudaacute-lo no desenvolvimento de software
27
Reuso
Conheccedila os padrotildees que estatildeo disponiacuteveis Cataacutelogo de padrotildees de 2000 Escolha aquele que satisfaz as suas necessidades
Um padratildeo eacute difiacutecil de entender se vocecirc natildeo necessita dele
Apenas tenha uma visatildeo geral Utilize o vocabulaacuterio dos padrotildees em revisotildees e
sessotildees de projeto
28
Reuso (Cont) GoF
Bastante utilizado entre a comunidade de software Core J2EE Pattern Catalog
httpjavasuncomblueprintscorej2eepatterns Padrotildees Arquiteturais
Frank Bushmann Regine Meunier Hans Rohnert Peter Sommerlad Michael Stal (Gang of Five)
29
GoF Design Patterns
Creational patternsAbstract factory BuilderFactory method Prototype Singleton
Behavioral PatternsChain of Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor
Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
24
Idiomas (Cont)
Nome Counted Body Contexto A interface de uma classe eacute separada de sua
implementaccedilatildeo (respectivamente classes handle e body) Problema atribuiccedilatildeo em C++ eacute definida recursivamente
como membro-por-membro com coacutepia quando a recursatildeo termina
Soluccedilatildeo Um contador de referecircncia eacute adicionado agrave classe body para facilitar o gerenciamento de memoacuteria
Autor e data James Coplien 1994
25
A Comunidade de Padrotildees
Uma hierarquia de workshops de escritores Grupos de leitura local Grupo Hillside Livros com os artigos da conferecircncia Conferecircncias PLoP ao redor do mundo
26
Eacutetica de Padrotildees Regra de Buschmann nunca capture suas
proacuteprias ideacuteias em um padratildeo Natildeo pense que padrotildees resolvem tudo Tente sempre encorajar as pessoas a repassar os
conhecimentos Sempre reconheccedila aqueles que criaram as
teacutecnicas ou que primeiro se empenharam a escrever sobre elas
Padrotildees satildeo ldquoapenasrdquo mais uma teacutecnica para ajudaacute-lo no desenvolvimento de software
27
Reuso
Conheccedila os padrotildees que estatildeo disponiacuteveis Cataacutelogo de padrotildees de 2000 Escolha aquele que satisfaz as suas necessidades
Um padratildeo eacute difiacutecil de entender se vocecirc natildeo necessita dele
Apenas tenha uma visatildeo geral Utilize o vocabulaacuterio dos padrotildees em revisotildees e
sessotildees de projeto
28
Reuso (Cont) GoF
Bastante utilizado entre a comunidade de software Core J2EE Pattern Catalog
httpjavasuncomblueprintscorej2eepatterns Padrotildees Arquiteturais
Frank Bushmann Regine Meunier Hans Rohnert Peter Sommerlad Michael Stal (Gang of Five)
29
GoF Design Patterns
Creational patternsAbstract factory BuilderFactory method Prototype Singleton
Behavioral PatternsChain of Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor
Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
25
A Comunidade de Padrotildees
Uma hierarquia de workshops de escritores Grupos de leitura local Grupo Hillside Livros com os artigos da conferecircncia Conferecircncias PLoP ao redor do mundo
26
Eacutetica de Padrotildees Regra de Buschmann nunca capture suas
proacuteprias ideacuteias em um padratildeo Natildeo pense que padrotildees resolvem tudo Tente sempre encorajar as pessoas a repassar os
conhecimentos Sempre reconheccedila aqueles que criaram as
teacutecnicas ou que primeiro se empenharam a escrever sobre elas
Padrotildees satildeo ldquoapenasrdquo mais uma teacutecnica para ajudaacute-lo no desenvolvimento de software
27
Reuso
Conheccedila os padrotildees que estatildeo disponiacuteveis Cataacutelogo de padrotildees de 2000 Escolha aquele que satisfaz as suas necessidades
Um padratildeo eacute difiacutecil de entender se vocecirc natildeo necessita dele
Apenas tenha uma visatildeo geral Utilize o vocabulaacuterio dos padrotildees em revisotildees e
sessotildees de projeto
28
Reuso (Cont) GoF
Bastante utilizado entre a comunidade de software Core J2EE Pattern Catalog
httpjavasuncomblueprintscorej2eepatterns Padrotildees Arquiteturais
Frank Bushmann Regine Meunier Hans Rohnert Peter Sommerlad Michael Stal (Gang of Five)
29
GoF Design Patterns
Creational patternsAbstract factory BuilderFactory method Prototype Singleton
Behavioral PatternsChain of Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor
Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
26
Eacutetica de Padrotildees Regra de Buschmann nunca capture suas
proacuteprias ideacuteias em um padratildeo Natildeo pense que padrotildees resolvem tudo Tente sempre encorajar as pessoas a repassar os
conhecimentos Sempre reconheccedila aqueles que criaram as
teacutecnicas ou que primeiro se empenharam a escrever sobre elas
Padrotildees satildeo ldquoapenasrdquo mais uma teacutecnica para ajudaacute-lo no desenvolvimento de software
27
Reuso
Conheccedila os padrotildees que estatildeo disponiacuteveis Cataacutelogo de padrotildees de 2000 Escolha aquele que satisfaz as suas necessidades
Um padratildeo eacute difiacutecil de entender se vocecirc natildeo necessita dele
Apenas tenha uma visatildeo geral Utilize o vocabulaacuterio dos padrotildees em revisotildees e
sessotildees de projeto
28
Reuso (Cont) GoF
Bastante utilizado entre a comunidade de software Core J2EE Pattern Catalog
httpjavasuncomblueprintscorej2eepatterns Padrotildees Arquiteturais
Frank Bushmann Regine Meunier Hans Rohnert Peter Sommerlad Michael Stal (Gang of Five)
29
GoF Design Patterns
Creational patternsAbstract factory BuilderFactory method Prototype Singleton
Behavioral PatternsChain of Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor
Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
27
Reuso
Conheccedila os padrotildees que estatildeo disponiacuteveis Cataacutelogo de padrotildees de 2000 Escolha aquele que satisfaz as suas necessidades
Um padratildeo eacute difiacutecil de entender se vocecirc natildeo necessita dele
Apenas tenha uma visatildeo geral Utilize o vocabulaacuterio dos padrotildees em revisotildees e
sessotildees de projeto
28
Reuso (Cont) GoF
Bastante utilizado entre a comunidade de software Core J2EE Pattern Catalog
httpjavasuncomblueprintscorej2eepatterns Padrotildees Arquiteturais
Frank Bushmann Regine Meunier Hans Rohnert Peter Sommerlad Michael Stal (Gang of Five)
29
GoF Design Patterns
Creational patternsAbstract factory BuilderFactory method Prototype Singleton
Behavioral PatternsChain of Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor
Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
28
Reuso (Cont) GoF
Bastante utilizado entre a comunidade de software Core J2EE Pattern Catalog
httpjavasuncomblueprintscorej2eepatterns Padrotildees Arquiteturais
Frank Bushmann Regine Meunier Hans Rohnert Peter Sommerlad Michael Stal (Gang of Five)
29
GoF Design Patterns
Creational patternsAbstract factory BuilderFactory method Prototype Singleton
Behavioral PatternsChain of Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor
Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
29
GoF Design Patterns
Creational patternsAbstract factory BuilderFactory method Prototype Singleton
Behavioral PatternsChain of Responsibility Command Interpreter Iterator MediatorMementoObserver State Strategy Template Method Visitor
Structural patternsAdapter BridgeCompositeDecorator Facade FlyweightProxy
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
30
Core J2EE Pattern CatalogPresentation Tier
Intercepting Filter Front ControllerView Helper Composite View
Service to WorkerDispatcher View
Integration TierData Access Object Service Activator
Business TierBusiness Delegate
Service LocatorSession facadeTransfer Object Transfer Object
Assembler
Value List HandlerComposite Entity
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
31
Architectural Patterns
From Mud to StructureLayers Pipes and FiltersBlackboard
Adaptable SystemsReflection Microkernel
Interactive SystemsModel-View-
Controller Presentation-
Abstraction-Control
Distributed SystemsBroker Pipes and FiltersMicrokernel
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
32
Template
GoF J2EE Coplien POSA
NomeClassificaccedilatildeoIntenccedilatildeoTambeacutem ConhecidoComoMotivaccedilatildeoAplicabilidadeEstruturaParticipantesColaboraccedilotildeesImplementaccedilatildeoCoacutedigo ExemploConsequecircnciasUsos ConhecidosPadrotildeesRelacionados
NomeProblemaForccedilasSoluccedilatildeo- Estrutura- EstrateacutegiasConsequecircnciasCoacutedigo ExemploPadrotildees Relacionados
NomeContextoProblemaForccedilasSoluccedilatildeoSketchContexto ResultanteArgumentaccedilatildeo(Rationale)
NomeTambeacutem Conhecido ComoExemploContextoProblemaSoluccedilatildeoEstruturaDinacircmicaImplementaccedilatildeoExemplo ResolvidoVariantesUsos ConhecidosConsequecircnciasVeja Tambeacutem
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
33
Maiores Informaccedilotildees Paacutegina de Padrotildees do Grupo Hillside
httphillsidenet Apontadores para listas livros arquivos ftp padrotildees on-line
conferecircncias entre outros Listas
Gang-of-4-patterns-requestcsuiucedu Patterns-requestcsuiucedu Patterns-discussion-requestcsuiuceduPadroes-lgreatufcbr
Repositoacuterio de Padrotildees Portland httpc2compprindexhtml
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
34
Em resumo Arquitetos experientes natildeo tecircm consciecircncia que
utilizam padrotildees Bons para compartilhar informaccedilatildeo e capturar
conhecimento Padrotildees funcionam como uma porta para troca
de experiecircncias Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes Vocabulaacuterio Comum Padrotildees datildeo uma competecircncia arquitetural de
organizaccedilatildeo
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
35
Em resumo (Cont) Vocecirc deve escrever padrotildees para
Aprender mais sobre padrotildees Compartilhar conhecimento
Provavelmente vocecirc usa alguma coisa que natildeo foi documentada ainda
Tarefa difiacutecil e nem todos tem tempo ou vontade Vocecirc deve reutilizar padrotildees
Em busca de uma melhoria no desenvolvimento de software
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
36
Component Dictionary definition
A unit of part of a model Hardware components Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
bull Differences
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
37
What is a component (1)1 A component is a nontrivial nearly independent and
replaceable part of a system that fulfills a clear function in the context of a well-defined architecture A component conforms to and provides the physical realization of a set of interfaces (Philippe Krutchen Rational Software)
2 A runtime software component is a dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at runtime (Gartner Group)
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
38
What is a component (2)3 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 third-party composition (Clemens Szyperski)
4 A business component represents the software implementation of an ldquoautonomousrdquo business concept or business process It consists of the software artifacts necessary to express implement and deploy the concept as a reusable element of a larger business system (Wojtek Kozaczynski SSA)
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
39
What is a component (3)5 A reusable part of software which is
independently developed and can be brought together with other components to build larger units It may be adapted but may not be modified
A component can be for example a compiled code without a program source or a part of a model andor design
--- DSouza and Wills
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
40
What is a component (4)6 A software component is a software element that
conforms to a component model and can be independently deployed and composed without modification according to a composition standard
--- Councill and Heineman
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
41
What are in common A piece of software Independently deployable Composable Self-contained Reusable
A set of interfaces provided to or required from the environment
An executable code which can be coupled to the code of other components via interfaces
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
42
Implications The following implications arise as a result of
Szyperskirsquos definition For a component to be deployed independently a
clear distinction from its environment and other components is required
A component must have clearly specified interfaces
The implementation must be encapsulated in the component and is not directly reachable from the environment
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
43
Implications A software component simply cannot be
differentiated from other software elements by the programming language used to implement the component
The difference is in how software components are used
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
44
DBC Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de vida do desenvolvimento incluindo anaacutelise de requerimentos arquitetura projeto construccedilatildeo testes distribuiccedilatildeo suporte teacutecnico e tambeacutem a gerecircncia de projeto satildeo baseados em componentes
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
45
Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming)
What are common What are different
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
46
SP OOP COP
Divide and conquer for managing complexity break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function a software entity combines data and the functions processing those data improve cohesion
Yes Yes
Encapsulation The client of a software entity is insulated from how that software entityrsquos data is stored or how its functions are implemented Reduce coupling
Yes Yes
Identity Each software entity has a unique identity
Yes Yes
Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency
Yes
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
47
Composability Software entity and its ability of being integrated
with other entities
SP ndash functions procedures low
OOP ndash classes objects high
COP ndash components very high
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
48
The Interchangeability Interchangeable parts are components of any device
designed to specifications which insure that they will fit within any device of the same type
SP Two different implementations can never be interchangeable
OOP Two different objects implementing the same specification are interchangeable
COP Two different components with different specifications are interchangeable as long as they satisfy those interface requirements for all client components
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
49
Component Goals
If you are asked to name three goals for usingcomponent technology what are they
1 Conquering complexity2 Managing change3 Reuse
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
50
Conquering Complexity We are living in a complex world ldquoThe world produces between 1 and 2
exabytes of unique information per year which is roughly 250 megabytes for every man woman and child on earth An exabyte is a billion gigabytes or 1018 bytesrdquo
httpwwwsimsberkeleyeduresearchprojectshow-much-infosummaryhtml
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
51
Managing Change Change is inherent in software engineering The user requirements change specifications
change personnel change budgets change technology change etc etc
This means building for change design for change is necessary
It is important to place primary emphasis during architecture and design on the dependencies between the components and the management of those dependencies
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
52
Reuse Design and implement something once and
use it over and over again in different contexts
This will realize large productivity gains taking advantage of best-in-class solutions the consequent improved quality and so forth
Develop for reuse and develop with reuse
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
53
CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities
Development for reuse Development with reuse
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
54
Para se criar um componente devemos primeiro garantir Que os serviccedilos que o componente oferece
independam do contexto Que os dados que o componente trabalha sejam
acessiacuteveis em qualquer projeto Que o componente defina e implemente sua
interface padratildeo Que o componente esteja dentro de um container
padratildeo
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
55
Conclusatildeo Objeto vs Componente
Componentes satildeo independentes do contexto onde satildeo usados Criado de tal forma que funciona em qualquer projeto
de software moacutedulo ou container Objetos satildeo projetados para um fim especiacutefico e
natildeo podem (ou natildeo devem) ser utilizados em outros contextos Ex se vocecirc criar um objeto Pedido para um sistema
de atacado dificilmente este objeto poderaacute ser utilizado em outro aplicativo como um aplicativo de gestatildeo de recursos humanos
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
56
Conclusatildeo Objeto vs Componente
Quando modelamos objetos pensamos primeiramente no problema que tentamos resolver
Componentes satildeo projetados para serem elementos chave de qualquer aplicativo de software Todo componente deve ter suas interfaces bem
definidas 3rsquos C (Containers Conectors and Components)
Exemplos
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
57
Problemas com Reuso Aumento nos custos de manutenccedilatildeo
raquoCoacutedigo fonte de componentes natildeo disponiacuteveis Falta de ferramentas de apoio
raquoFalta integraccedilatildeo de CASEs com bibliotecas de componentes
Siacutendrome do ldquonatildeo foi inventado aquirdquo Manutenccedilatildeo de uma biblioteca de componentes Encontrar e adaptar componentes reutilizaacuteveis Eacute preciso ser planejado e incorporado por meio de
um programa de reuso da organizaccedilatildeo
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
58
ReferecircnciasAndrade RMC ldquoCapture Reuse and Validation of Requirements
and Analysis Patterns for Mobile Systemsrdquo PhD Thesis University of Ottawa Ottawa 2001
Alexander C Ishikawa S Silverstein M Jacobson M Fiksdahl-King I and Angel S A Pattern Language Towns Buildings Construction Oxford University Press New York NY 1977
Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern-Oriented Software Architecture John Wiley and Sons New York NY 1996
Coplien J O Software Patterns SIGS books and Multimedia June 1996
Fowler M Analysis Patterns Reusable Object Models Addison-Wesley Reading MA 1997
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
59
Referecircncias (Cont)Gamma E Helm R Johnson R Vlissides J ldquoDesign Patterns
Element of Reusable Object-Oriented Softwarerdquo 1995Pattern Languages of Program Design I II III amp IV Patterns from the
PLoP Conference at Allerton Park in Illinois US and EuroPLoP in Europe Addison-Wesley 1994-95-96-98
Rising Linda ldquoPatterns A Way to Reuse Expertiserdquo IEEE Communications Magazine Vol 37 No 4 April 1999
Rising Linda The Pattern Almanac 2000 Software Pattern Series Addison-Wesley 2000 ISBN 0-201-61567-3
Metodologias para o DBCWang AJA Qian K Component Oriented ProgrammingUML Components1048708J JCheesman and JDaniels Catalysis httpwwwiconcompcomcatalysis D DSouza andA A
WillsKobrA CAtkinson et al
