Prof. Alcides Calsavara PUCPR alcides@ppgia.pucpr.br O Paradigma de Orientação a Objetos no Processo de Desenvolvimento de Software Prof. Alcides Calsavara PUCPR alcides@ppgia.pucpr.br

Objetivos Apresentar um processo de desenvolvimento de software baseado em orientação a objetos Facilitar a discussão sobre a adequação de um processo similar ao apresentado no contexto da empresa

Um breve histórico 1967: Simula 1970 a 1980: Smalltalk 1985 a 1986: C++, Objective-C, Eiffel, ... 1980-1990: Booch, OMT, ... 1992: CORBA 1994: UML 1995: Java (Web) 1998: UP

The Unified Software Development Process Colaboração com os mestrandos da PUCPR: Orlando Alcantara Soares Cláudia Barcaro

Conteúdo Descrever a arquitetura do Unified Process Em suas principais fases e métodos Apresentando os produtos gerados em cada fase

Histórico do Unified Process O primeiro passo para o Unified Process foi o desenvolvimento da linguagem UML (Unified Modeling Language), primeiramente proposta por Grady Booch e Jim Rumbaugh como padrão “de fato” para modelagem de sistemas de software

Histórico do Unified Process Grady Booch foi o autor do “Booch Method”, uma das primeiras metodologias a divulgar o paradigma da orientação a objetos em conjunto com práticas de programação Jim Rumbaugh foi o principal desenvolvedor da OMT (Object Modeling Technique), no General Electric Research and Development Center

Histórico do Unified Process Ivar Jacobson foi autor de Objectory tem sua origem em metodologia de desenvolvimento de sistemas (1967-1987) desenvolvida pela Ericson sueca, segundo o conceito de “component-based development”, fortemente influenciada pelas técnicas de modularidade da área de telecomunicações

Histórico do Unified Process Na metodologia Objectory (“Object Factory”), Jacobson formalizou o conceito de “use case” , (1985-1987) uma técnica para produzir especificações com base na visão do usuário final Em 1994, Rumbaugh aderiu à Rational, onde, juntamente com Booch, propôs a versão 0.8 do então denominado UM (Unified Method), publicado em 1995

Histórico do Unified Process Com a adesão de Jacobson à Rational (1995), “os três amigos” propuseram a versão 0.9 da UML, como linguagem independente de metodologia A UML 0.9 teve a adesão da IBM, HP e Microsoft

Histórico do Unified Process Em novembro de 1997, a UML versão 1.1 foi aceita como padrão pelo OMG - Object Management Group, após um processo de análise de várias propostas (entre as quais OPEN) Na Rational, Jacobson passou a coordenar o desenvolvimento do Rational Objectory Process como proposta de metodologia dos “três amigos”, em linguagem UML

Histórico do Unified Process A partir de 1998, após numerosas complementações, o Objectory Process teve como sucessor o Rational Unified Process

Unified Process: O que é um processo ? Um processo de desenvolvimento de software é o conjunto de atividades necessárias para transformar requisitos de usuários em sistema de software.

Unified Process: Pilares O Unified Process é um processo Dirigido por Use Case Centrado em Arquitetura Iterativo e Incremental

Unified Process: Ambiente Tecnológico O Unified Process é um processo orientado a tecnologia de objetos baseado em componentes componentes de software interconectados por uma interface bem definida em linguagem UML

Unified Process: Idéias Fundamentais Dirigido por Use Case (use case driven) use case é o artefato (artifact) primário para estabelecer o comportamento desejado do sistema e para comunicação entre seus participantes use cases levam as especificações que descrevem o sistema sob o ponto de vista do usuário, sem antecipar decisões de implementação

Unified Process: Idéias Fundamentais Modelo de Use Cases

Unified Process: Idéias Fundamentais Use case textual: Retirada de Dinheiro Pré-condição: cliente possui conta que funciona com ATM 1. O ator cliente seleciona retirar dinheiro e identifica-se para a interface do ATM, possivelmente utilizando um cartão magnético com um número e uma senha 2. A interface ATM solicita ao subsistema Transaction Management a retirada do dinheiro. O Transaction Management é responsável por executar a seqüência de retirada como uma transação atômica, assim, o dinheiro é tanto deduzido da conta quanto entregue ao cliente 3. O Transaction Management solicita ao Account Management a retirada do dinheiro. O Account Management determina se o dinheiro pode ser retirado e, caso possa, deduz a quantia da conta e retorna uma resposta que especifica ser possível efetuar a retirada 4. O Transaction Management autoriza a interface ATM a entregar o dinheiro 5. A interface ATM entrega o dinheiro ao cliente

Unified Process: Idéias Fundamentais Dirigido por use case (use case driven) use case é o input básico para análise, projeto (design), implementação e teste do sistema o conjunto dos use cases constituem o modelo de use case (use case model), que descreve a funcionalidade completa do sistema com base no modelo de use case, os desenvolvedores criam uma série de modelos de projeto e implementação que realizam os use cases

Unified Process: Idéias Fundamentais Centrado em arquitetura (architecture-centric) A arquitetura de um software descreve as diferentes visões do sistema em construção A arquitetura se desenvolve a partir das visões do usuário expressas em use cases A arquitetura é também influenciada por fatores de implementação: arquitetura de computador, sistema operacional, dbms, protocolos de rede, linguagem de programação, ambiente de interface gráfica, bibliotecas de funções disponíveis, sistemas legados, necessidades de performance, portabilidade etc.

Arquitetura: Camadas de Componentes Classes específicas de negócio Classes de Serviços Pacotes Genéricos Sistema Operacional

Use Case e Arquitetura Como use case e arquitetura se relacionam? Use case é a funcionalidade; Arquitetura é a forma de realização Os use cases dirigem a seleção de arquitetura e a arquitetura influencia a seleção de use cases Use cases e arquitetura não podem ser considerados isoladamente Use cases e Arquitetura devem evoluir em paralelo.

Use Case e Arquitetura Vários fatores influenciam a arquitetura, não apenas os use cases

Use Case e Arquitetura Trabalho Inicial Buscar uma compreensão dos use cases fundamentais do sistema (de 5 a 10% do total de use cases) Delinear a arquitetura que é independente de use cases (ex.: plataforma de software) À medida em que a especificações dos use cases amadurecem, descobrem-se mais informações a respeito da arquitetura, o que leva a maior conhecimento sobre os use cases O processo continua, até que a arquitetura se torne estável

Arquitetura: Fatores que influenciam Use cases Tipo de software a ser construído: sistema operacional, sistema de apoio a decisão etc. Middleware: object broker, interfaces gráficas Sistemas legados Padrões e políticas: linguagem de definição de interfaces, padrões de telecomunicações Patterns utilizados Requisitos não funcionais: performance, tempo de recuperação Mecanismos genéricos: armazenamento em dbms Modo de distribuição: arquitetura cliente/servidor, internet

Unified Process: Idéias Fundamentais O que é uma Iteração Uma iteração é um mini-projeto que resulta em um incremento do sistema Uma iteração contém um grupo de use cases que ampliam a funcionalidade do produto até então desenvolvido Como um mini-projeto, uma iteração passa pelas fases de análise, design, implementação e teste, podendo mesmo colocar os use cases (pertencentes à iteração) sob a forma de código executável Uma iteração pode não acrescentar nova funcionalidade, mas adicionar detalhes a artefatos já existentes

Estrutura de uma Iteração Uma Iteração e seu Workflow

Concorrência de Iterações Iterações podem caminhar em paralelo

Iteração, Use Case e Arquitetura O Processo é Iterativo e Incremental Para cada iteração os desenvolvedores identificam os use cases relevantes, analisando-os segundo a arquitetura selecionada O produto da iteração são componentes (modelos ou módulos executáveis) Verifica-se então se os componentes satisfazem os use cases e a arquitetura Se a implementação atinge os objetivos (componentes satisfazem use cases e arquitetura), o desenvolvimento passa para a próxima iteração Caso contrário, os desenvolvedores devem revisar as decisões anteriores e tentar uma nova abordagem

Benefícios do Processo Iterativo Redução de Riscos Caso necessário repetir a iteração, perde-se o esforço de um único incremento, não o de todo o projeto Reduzem-se os riscos de entrega de sistema fora do prazo; problemas são detectados em fase anterior à de testes globais Iterações controladas reduzem o tempo global de desenvolvimento; os desenvolvedores trabalham mais eficientemente em objetivos menores

Benefícios do Processo Iterativo Adequação a Requisitos Iterações controladas reconhecem uma realidade inevitável: necessidades e requisitos não podem ser adequadamente definidos por antecipação; mas devem ser refinados em iterações sucessivas Este modo de operar facilita a adaptação a alterações de requisitos

Unified Process: O Sistema Os Ciclos O Unified Process é composto de uma série de ciclos Cada ciclo conclui com a entrega de um produto Cada ciclo constitui-se de quatro fases: incepção, elaboração, construção e transição cada fase se subdivide em iterações

Ciclos de um Sistema A vida de um sistema consiste de ciclos

Estrutura do Ciclo Um ciclo com suas fases e iterações

Unified Process: Fases de um Ciclo Incepção Cada iteração nesta fase focaliza a compreensão do problema e da tecnologia Essencialmente a fase corresponde às seguintes questões: O que o sistema fará para cada um de seus usuários: modelo simplificado dos principais use cases Como deve ser uma arquitetura para o sistema Qual é o plano e quanto custará para desenvolver o produto?: estimativa de custos Cada iteração está voltada para a produção de use cases de negócio e da arquitetura preliminar

Unified Process: Fases de um Ciclo Elaboração Nesta fase, as iterações estão voltadas para a produção da arquitetura básica Vários dos use cases são especificados com detalhes; a arquitetura do sistema é projetada A arquitetura é expressa em visões dos modelos do sistema: modelo de use cases modelo de análise modelo de projeto modelo de implementação modelo de distribuição (deployment) O resultado da fase é o conjunto dos modelos acrescidos de elementos de implementação

Unified Process: Fases de um Ciclo Construção Nesta fase, as iterações estão voltadas para a produção de módulos executáveis, culminando com o desenvolvimento de um produto pronto para entrega à comunidade de usuários Durante esta fase o produto é construído O sistema torna-se um produto pronto para ser posto à disposição da comunidade de usuários A arquitetura é estável, ainda que possa ser aperfeiçoada Ao final da fase, o sistema conterá todos os use cases que gerência e usuários concordaram em desenvolver para esta versão do produto Erros poderão ser encontrados e serão corrigidos

Unified Process: Fases de um Ciclo Transição Compreende o período em que o produto passa para beta-teste; a primeira versão é entregue aos usuários A fase envolve atividades de treinamento de usuários, assistência de uso do produto e correção de defeitos encontrados após a entrega Um pequeno número de usuários experientes utiliza o produto e reporta os erros e inadequações encontradas Os desenvolvedores corrigem os erros e e incorporam melhoras

Visão Global das Fases O Processo

Pontos de Revisão (Milestones) Cada fase da Metodologia conclui com um Ponto de Revisão Incepção: objetivos de negócio Elaboração: arquitetura Construção: capacidade operacional Transição: entrega do produto Dentro de cada fase podem ser definidos Pontos de Revisão de menor amplitude (por ex., a cada iteração)

Pontos de Revisão (Milestones)

Unified Process: Produtos Modelos do Unified Process

Modelos por Fases Workflow do Unified Process

Fase de Requisitos Modelo de Use Case O Modelo de use case representa os Requisitos Funcionais Um use case especifica uma seqüência de ações, incluindo variantes, que o sistema realiza e que resulta em um resultado observável produzido por um determinado ator Devem ser considerados em conjunto os use cases pertencentes a uma iteração

Fase de Requisitos Modelo de Use Case: Exemplo

Fase de Análise Modelo de Análise O Modelo de Use Cases é a entrada para o Modelo de Análise O Modelo de Análise é uma especificação detalhada dos requisitos e é uma primeira aproximação do Modelo de Projeto O MA é usado pelos desenvolvedores para uma compreensão mais precisa dos use cases, definindo-os como uma colaboração entre tipos conceituais de objetos (sem detalhes de implementação) Cada elemento conceitual do Modelo de Análise reaparecerá no correspondente Modelo de Projeto

Fase de Análise Modelo de Análise Modelo de Análise a partir de Modelo de Use Case

Fase de Análise Modelo de Análise O Modelo de Análise utiliza Diagrama de Colaboração para descrever a realização de um use case O use case é descrito em termos de interação entre objetos e atores O diagrama de colaboração pode ser complementado com texto, texto estruturado ou pseudocódigo O Modelo de Análise auxilia na descoberta dos tipos conceituais de objetos participantes do sistema e no modo como os objetos realizam atividades (funcionalidade dos objetos)

Fase de Análise Use Case: Modelo de Colaboração

Fase de Análise Modelo de Análise e definição de Classe As responsabilidades de uma classe são uma compilação dos papéis representados pela classe em todas as realizações de use cases (diagramas de colaboração) Caso uma classe seja alterada, o desenvolvedor precisa verificar se ela continua realizando seu papel em cada realização de use case

Fase de Projeto Modelo de Projeto O Modelo de Projeto é uma descrição da implementação do sistema, a partir do Modelo de Análise O Modelo de Projeto precisa adequar-se ao ambiente de implementação (tecnologia de distribuição de objetos, ambiente gráfico, dbms, reuso de sistemas legados, bibliotecas de patterns etc.) Existe um mapeamento direto entre os subsistemas do Modelo de Projeto e os componentes do Modelo de Implementação Subsistemas são grupamentos de classes e outros subsistemas

Fase de Projeto Modelo de Projeto O Modelo de Projeto define tipos de objetos, associações e colaborações entre os tipos Basicamente são as mesmas definições do Modelo de Análise. Entretanto, as definições do Modelo de Análise são “conceituais”, enquanto que as definições do Modelo de Projeto são voltadas para o ambiente operacional Ou seja: O Modelo de Projeto é “mais físico” e o Modelo de Análise é “mais conceitual”

Modelo de Projeto Levantamento de Classes

Modelo de Projeto Diagrama de Classes

Modelo de Projeto Diagrama de Classes O diagrama anterior exibe um “diagrama de classes”, não um diagrama de colaboração O diagrama de classes introduz classes pertencentes ao ambiente de implementação, o que leva ao detalhamento do modelo conceitual É necessário detalhar a interação entre os objetos pertencentes às classes de projeto - isto é feito por meio de um “diagrama de seqüência”

Modelo de Projeto Diagrama de Classe

Modelo de Projeto Diagrama de Seqüência O diagrama de seqüência mostra como o foco passa de objeto para objeto e mensagens são trocadas, durante a execução de um use case Os desenvolvedores podem usar textos e pseudocódigo para complementar os diagramas de seqüência, para explicar detalhes de interação entre os objetos

Modelo de Projeto Diagrama de Seqüência

Modelo de Projeto Diagrama de Estados Alguns objetos de projeto são controlados por estados O estado de seus atributos e operações determina o modo como o objeto reage a mensagens enviadas por outros objetos As transições de estados são representadas por Diagramas de Estados, um importante elemento a ser utilizado durante a fase de implementação da classe correspondente ao objeto analisado

Modelo de Projeto Exemplo de Diagrama de Estados

Modelo de Projeto Subsistemas O Modelo de Projeto pode conter uma quantidade excessivamente grande de classes (centenas ou milhares) É necessário um meio para grupar as classes que participam de determinados use cases, o que é feito por meio de subsistemas Um subsistema é um grupamento de classes (e outros subsistemas) que possuem alguma afinidade semântica A comunicação entre subsistemas e feita por meio de interfaces (oferecidos por classes dos subsistemas)

Modelo de Projeto Subsistemas

Camadas de subsistemas A arquitetura toma forma principalmente durante a fase de elaboração do sistema A arquitetura de um sistema é especificada por meio de sucessivas iterações, cada iteração acrescentando detalhes à iteração anterior Cada iteração segue o padrão requisitos, análise, projeto, implementação, teste Cada iteração (de definição de arquitetura) focaliza os use cases arquitetonicamente relevantes e os elementos mencionados na transparência anterior Ao final da fase de elaboração, obtem-se a “architecture baseline”, que é a coleção de modelos acrescida das especificações de arquitetura

Camadas de Subsistemas: Exemplo

Camadas de subsistemas: Layer Pattern A figura exibe o pattern de definição em camadas (Layer Pattern) Os componentes pertencentes a determinada camada apenas podem referenciar componentes pertencentes a uma camada inferior O pattern simplifica e organiza a compreensão e a organização de sistemas complexos O pattern reduz a dependência entre módulos, uma vez que camadas mais baixas desconhecem detalhes de interface com camadas situadas acima Também facilita-se a identificação dos módulos a serem reutilizados, e dos módulos a serem adquiridos ou desenvolvidos

Camadas de subsistemas: Arquitetura Um sistema desenvolvido segundo a arquitetura do “layer pattern” situa os subsistemas aplicativos na camada do topo Patterns de projeto, frameworks e bibliotecas de classes situam-se em camadas inferiores Quanto mais abaixo localiza-se a camada, maior é a reutilização de módulos A arquitetura das duas camadas inferiores pode ser estabelecida sem se levar em consideração os detalhes dos use cases, uma vez que essas camadas independem das especificações de negócios

Subsistemas e suas Interfaces Estrutura estática da visão arquitetônica do modelo de projeto: diagrama de classes que exibe subsistemas e suas interfaces

Modelo de Projeto Subsistemas Cada subsistema é representado por um “package” da UML Vantagem em se utilizar interfaces entre subsistemas: o subsistema ATM Interface pode eventualmente ser substituído por outro de diferente implementação, sem que a alteração modifique a funcionalidade oferecida a Transaction Management

Modelo de Projeto Subsistemas e Use Cases Modelo de colaboração de um use case: interação entre subsistemas e atores

Modelo de Distribuição (Deployment) O Modelo de Distribuição define a arquitetura física do sistema em termos de processadores (nodes) que se conectam Esses processadores são unidades de hardware em que os componentes de software podem ser executados Freqüentemente, a arquitetura física do sistema é conhecida antes mesmo do início de desenvolvimento do sistema Os processadores e suas conexões podem ser modelados no Modelo de Distribuição já durante o levantamento de requisitos

Diagrama de Distribuição O Modelo de Distribuição é representado em Diagramas de Distribuição (Deployment)

Modelo de Distribuição e Subsistemas

Modelo de Distribuição: Visão Aquitetônica Uma vez definidos os processadores, pode-se indicar a distribuição de funcionalidade por eles O diagrama a seguir exibe a distribuição das classes ativas segundo o modo como elas são alocadas aos processadores

Fase de Implementação Modelo de Implementação: componentes que implementam classes Um Modelo de Implementação contém todas as informações necessárias à produção de um sistema executável: componentes executáveis, componentes de bancos de dados etc. Um componente é uma parte física e substituível de um sistema; um componente provê um conjunto de interfaces O Modelo de Implementação é constituído de elementos de software, os quais incluem todos os módulos executáveis (como ActiveX e JavaBeans)

Fase de Implementação Componentes no Modelo de Implementação

Fase de Implementação Componentes no Modelo de Implementação A figura anterior exibe componentes que implementam classes pertencentes ao modelo de projeto O componente de arquivo dispenser.c contém o código fonte e implementa três classes; este componente é compilado e ligado, juntamente com client.c, dentro do componente client.exe, o qual é executável Se os componentes são implementados por meio de uma linguagem orientada a objetos, a implementação das classes é direta: cada classe do projeto corresponde a uma classe da implementação; cada componente de arquivo pode implementar várias dessas classes

Fase de Teste Teste dos Use Cases Durante a fase de teste, é verificado se o sistema implementa corretamente as especificações É desenvolvido um Modelo de Teste, que consiste de test cases e test procedures Um test case é um conjunto de entradas (input) de teste, condições de execução e resultados esperados, desenvolvidos para um objetivo particular, como verificar um determinado caminho em um use case Uma test procedure é uma especificação de como executar o setup, a execução e a avaliação de resultados de um determinado test case

Fase de Teste Exemplo de Test Case

Fase de Teste Test Case: descrição textual Input: A conta 12-121-1211 possui saldo de $350 O cliente identifica-se corretamente O cliente solicita a retirada de $200 da conta 12-121-1211 Há dinheiro suficiente no ATM (ao menos $200) Resultado O saldo da conta 12-121-1211 decresce para $150 O cliente recebe $200 da ATM Condições Nenhuma outra instância de use case está autorizada a acessar a conta 12-121-1211 durante o test case

Fundamentos da Metodologia revisitados Dirigido por Use Case (Use Case Driven): cada cada produto, em cada fase, tem sua origem em algum use case; ou seja, refere-se a algo que o usuário realmente necessita Centrado em Arquitetura (Architecture Centric): o desenvolvimento é focado no pattern arquitetônico que guiará a construção do sistema desde sua fase inicial Iterativo e Incremental: o software é desenvolvido em pequenos passos gerenciáveis; se você está satisfeito com um passo, você ajusta seu foco para o próximo passo: Você planeja um pouco Você especifica, projeta e implementa um pouco Você integra, testa e executa cada iteração um pouco

Referências [1] Jacobson, Ivar; Booch, Grady; Rumbaugh, James. The Unified Software Development Process. Addison-Wesley, 1999 [2] Rational Software Corporation. Unified Modeling Language - Notation Guide version 1.0. Rational Software Corporation, 1997 [3] IBM, Rational Software, Unisys et al. Software Process Engineering Mamagement - The Unified Process Model (UPM). OMG doc. Number ad/2000-05-05, May, 2000 [4] Kruchten, Philippe. A Rational Development Process. http://rational.com, 2000 [5] Rational, http://www.rational.com [6] Rumbaugh, James; Jacobson, Ivar; Booch, Grady. The Unified Modeling Language Reference Manual. Addison-Wesley, 1998

Anexos

Processo centrado em Arquitetura: Refinamentos Sucessivos No contexto do ciclo de vida de um software, centrado em arquitetura significa que a seleção dos elementos estruturais (expressa nos modelos do sistema) e suas interfaces são elementos importantes para conceituação, construção, administração e evolução do sistema que está em desenvolvimento Os modelos do sistema passam por refinamentos sucessivos para incorporar elementos de implementação, percorrendo o caminho do mais conceitual para o mais concreto. A incorporação sucessiva dos elementos de estrutura (detalhes de implementação) leva a uma reavaliação dos use cases

Processo centrado em Arquitetura: Modularidade A boa arquitetura é aquela que divide o sistema em subsistemas (idealmente) autônomos Cada subsistema oferece serviços a outros subsistemas por meio de uma (ou mais) interface bem definida Deste modo reduzindo os problemas de comunicação entre módulos E tornando cada módulo independente da implementação de módulos pertencentes a outros subsistemas

Processo centrado em Arquitetura: Modularidade Interfaces estáveis permitem que o software situado em cada lado da interface possa evoluir independentemente, desde que preserve a interface A modularidade de sistemas (subsistemas interligados por interfaces) facilita a escolha da arquitetura mais adequada para cada subsistema e viabiliza a utilização de bibliotecas de patterns A modularização centrada em interfaces bem definidas é o mecanismo que viabiliza o reaproveitamento de soluções

Princípios que regem a arquitetura no Processo Unificado Modularidade Funcional: as Classes são grupadas em blocos funcionais (ou subsistemas), que os usuários possam tratar como opcionais; cada subsistema possui uma forte coesão interna; alterações no sistema devem ficar restritas a determinados subsistemas, sem alterar o sistema como um todo Separação Interface/Subsistema: o projeto das interfaces deve ser separado do projeto dos subsistemas; o objetivo é conseguir projetos “plugáveis”, em que diferentes subsistemas possam oferecer as mesmas interfaces; subsistemas possam ser substituídos ou alterados sem que haja qualquer alteração em seus clientes

Princípios que regem a arquitetura no Processo Unificado Mapeamento Subsistema/Componente: cada subsistema (projeto) é mapeado a um ou mais componentes (implementação); cada componente é executado em apenas uma estação de processamento (node); caso o subsistema seja executado em diferentes processadores (ex.: cliente e servidor), cada componente envolvido deve ser instanciado isoladamente (duplicado) em cada processador; este princípio facilita a distribuição e a alteração de software em diferentes instalações

Princípios que regem a arquitetura no Processo Unificado Isolamento de subsistemas: a troca de mensagens é o único meio de comunicação entre subsistemas; como as trocas de mensagens são assíncronas (inexistência de sincronização entre uma mensagem e sua resposta), os subsistemas possibilitam não apenas encapsulamento, mas também distribuição

Modelo de Implementação: Visão Aquitetônica O Modelo de Implementação é um mapeamento direto a partir dos Modelos de Projeto e de Distribuição Cada subsistema de projeto usualmente resulta em um componente para cada processador em que o subsistema precisa ser instalado Algumas vezes, porém, o mesmo componente é instalado e executado em diferentes processadores Algumas linguagens provêm construções para a definição de packages de componentes (como JavaBeans) As Classes também podem ser organizadas em arquivos de código que contêm os componentes