Análise e Projeto Orientado a Objetos Aula 1 (Versão )

Transcrição

1 Análise e Projeto Orientado a Objetos Aula 1 (Versão ) Histórico das Metodologias Professor Gabriel Baptista ( gabriel.baptista@uninove.br ) ( ) Para começar! Horário 19:15 às 23:00 Intervalo 20:50 às 21:15 Avaliações: [Soma da maiores notas (A1, A2, A3)] / 2 >= 6 A1 = Caso 1 + Caso 2 + Caso 3 + Caso 4 A2 = Integrada A3 = Integrada Ementa do Curso Apresentação da importância da modelagem no desenvolvimento de sistemas, histórico da evolução das metodologias de modelagem, modelagem tradicional, estruturada e essencial. Modelagem orientada a objeto, padrões e normas de UML, notação da interface, subtipos, composição e agregação. 1

2 Objetivos do Curso Desenvolver soluções através da Análise e Projeto Orientado a Objetos fazendo uso dos conceitos de UML. Conteúdo Programático Histórico das metodologias de desenvolvimento de sistemas Conceitos de Orientação a Objetos Introdução à UML Os diagramas da UML Diagrama e Especificação de Casos de Uso Diagrama de Classes Diagrama de Sequência Diagrama de Atividades Diagrama de Máquina de Estados Diagrama de Componentes Diagrama de Implantação Bibliografia Básica BLAHA, Michael; RUMBAUGH, James. Modelagem e projetos baseados em objetos com UML 2 2ª Edição. Rio de Janeiro: Campus, BOOCK, Grady; JACOBSON, Ivar; RUMBAUGH, James. UML: guia do usuário. Rio de Janeiro: Campus, CARLSON, David. Modelagem de aplicações XML com UML: aplicações práticas de e-business. São Paulo: Pearson,

3 Bibliografia Complementar BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. 2ª ed. Rio de Janeiro: Elsevier, LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e ao projeto orientado a objeto e ao desenvolvimento iterativo. 3ª ed. Porto Alegre: Bookman, OBJECT MANAGEMENT GROUP (OMG) UML (UNIFIED MODELING LANGUAGE), UML Resource Page, em acessado em agosto de SOMMERVILLE, Ian. Engenharia de software. São Paulo: Addison Wesley, E agora? O que vocês imaginam que irá acontecer após esta disciplina? Relembrando... Crise do Software 1972 Dijsktra: De um desenvolvimento informal para atender à necessidades pessoais, passamos para um desenvolvimento corporativo, tendo cada dia mais hardwares mais potentes. 3

4 Com isso: Custo acima do estipulado Diversos atrasos Funcionalidades abaixo do esperado Baixa qualidade Pessoas insatisfeitas Solução Engenharia de Software Disciplina da engenharia que se ocupa de todos os aspectos da produção de software (SOMMERVILLE, 2003) Atividades fundamentais do Software Especificação: Definição de funcionalidades e restrições. Projeto (Desenho): Definição dos desenhos que servirão como auxílio para a produção do software. Implementação: Produção do software de acordo com o especificado / desenhado. Validação: Garantia que o software faz o que foi especificado. Evolução: Evolução natural para atender às necessidades do cliente. 4

5 Quais os desafios enfrentados pela Engenharia de Software? - Custo - Qualidade - Prazo - Pessoas - Funcionalidades Pessoas Funcionalidades Qualidade Prazo Custo Metodologias para Análise e Projeto de Sistemas Análise Estruturada Análise Essencial Análise Orientada a Objetos Análise Estruturada (Decomposição Funcional) Perspectiva das funções Apresentação dos processos Artefatos produzidos Diagrama de Entidade-Relacionamento Diagrama de Fluxo de Dados Dicionário de Dados 5

6 Análise Essencial (Lista de Eventos) Evolução da Análise Estruturada Preocupado com a questão de Controle Formado pelos modelos Ambiental (Contexto + Lista de Eventos) Comportamental (DFD + Dicionário) Informação (DER + Dicionário) Análise Orientada a Objetos (Bottom-up) Enfoque nos dados Maior detalhe na modelagem Mais próximo da realidade Comunicação mais fácil com o usuário Análise Orientada a Objetos O mundo real é composto por objetos. Cada objeto tem propriedades e comportamentos. Então porquê não desenvolver programas que simulem no computador os objetos do mundo real com suas propriedades e comportamentos? 6

7 Sistemas Orientados a Objetos Um sistema construído usando um método Orientado a Objetos é aquele cujos componentes são partes encapsuladas de dados e funções, que podem herdar atributos e comportamentos de outros componentes da mesma natureza, e cujos componentes comunicam-se entre si por meio de mensagens. (YOURDON) Portanto... Vantagens e Desvantagens Vantagens Dependência menor entre os módulos de um sistema Combinação de estrutura (dados) e comportamento (funções) em um único objeto Compartilha comportamentos com objetos de níveis inferiores (herança) Ferramentas poderosas Reuso pode chegar a aumentar a produtividade Desvantagens Usuário se preocupa com funcionalidades Bancos de dados permanecem estruturados 7

8 O que vem a ser um objeto? Qualquer coisa visível ou tangível para qual a ação, pensamento ou sentimento é direcionado, ou seja, o mundo real é formado por coisas e para a Orientação a Objetos estas coisas são denominadas de OBJETOS. Os objetos são caracterizados por: Identidade Comportamento Estado Sendo a comunicação entre os objetos feita através de MENSAGENS. O que vem a ser uma classe? Representação de um conjunto de objetos que possuem os atributos (propriedades) e comportamento (métodos) semelhantes. Cada objeto criado a partir desta classe, pode ser chamado de instância da classe. Classe professor instanciada para o Professor Gabriel Identidade RG: XX.XXX.XXX-X Comportamentos Lançar Nota Lançar Falta Estado Idade: 31 Nome: Gabriel Disciplina que leciona: Análise e Projeto Orientado a Objetos Matrícula: XXXX As informações referentes ao professor Gabriel são os dados do objeto 8

9 Obrigado! Análise e Projeto Orientado a Objetos Aula 2 (Versão ) Conceitos de Orientação a Objetos e Introdução à UML Professor Gabriel Baptista ( gabriel.baptista@uninove.br ) ( ) Conteúdo adaptado do Material do Prof. Marcos Roberto e Silva Revisando O que significa modelar um sistema? O que é a Engenharia de Software? Quais os desafios enfrentados pela Engenharia de Software? O que trata a Crise do Software? Quais são as atividades essenciais para o desenvolvimento de um software? Quais foram as metodologias para Análise e Projeto de Sistemas que foram apresentadas? No que elas se diferem? 9

10 Princípios da Orientação a Objetos A análise orientada a objetos baseia-se em alguns princípios que são utilizados para administrar a complexidade e facilitar a Análise e Projeto Orientado a Objetos Estes princípios são: Abstração Herança Encapsulamento Polimorfismo Vocês sabem dizer o que significa cada um destes princípios? Abstração Princípio de ignorar os aspectos de um assunto não relevantes para o propósito em questão, tornando possível uma concentração maior nos assuntos principais. (Dictionary of Computing. Oxford University Press, 1986) Quais serão os objetos relevantes para desenvolver um sistema de sala de aula? Herança O conceito de HERANÇA representa GENERALIZAÇÃO e ESPECIALIZAÇÃO, tornando explícitos os atributos e métodos comuns em uma hierarquia de classe. Existem dois tipos de herança Simples Múltipla 10

11 Ainda dentro da sala de aula Tanto professor como aluno são pessoas, que tem nome, RG e idade. Sobre a Herança Generalização (Superclasse) Especialização (Subclasse) É possível adicionar novos métodos e/ou reescrever métodos existentes em uma subclasse. Encapsulamento Ocultação de características e comportamentos Proteção de dados Com isso temos: Propriedades Privadas Propriedades Públicas Métodos Privados Métodos Públicos As mensagens entre os objetos serão trafegadas somente entre métodos e propriedades públicos 11

12 Polimorfismo É o princípio em que classes derivadas (subclasses) de uma mesma superclasse podem invocar operações que têm a mesma assinatura (nome), mas comportamentos diferentes em cada subclasse, produzindo resultados diferentes, dependendo de como cada objeto implementa a operação. (Marcos Roberto e Silva) Polimorfismo Obrigado! 12

13 Análise e Projeto Orientado a Objetos Aula 3 (Versão ) Introdução à UML Professor Gabriel Baptista ( gabriel.baptista@uninove.br ) ( ) Conteúdo adaptado do Material do Prof. Marcos Roberto e Silva Obrigado! Análise e Projeto Orientado a Objetos Aula 2 (Versão ) Conceitos de Orientação a Objetos e Introdução à UML Professor Gabriel Baptista ( gabriel.baptista@uninove.br ) ( ) Conteúdo adaptado do Material do Prof. Marcos Roberto e Silva 13

14 Revisando O que significa modelar um sistema? O que é a Engenharia de Software? Quais os desafios enfrentados pela Engenharia de Software? O que trata a Crise do Software? Quais são as atividades essenciais para o desenvolvimento de um software? Quais foram as metodologias para Análise e Projeto de Sistemas que foram apresentadas? No que elas se diferem? Revisando Qual o conceito de objeto? Qual o conceito de classe? Qual o conceito de instância? Qual o conceito de abstração? Qual o conceito de herança? Qual o conceito de encapsulamento? Qual o conceito de polimorfismo? Histórico Orientação a objetos é um paradigma abordado desde a década de 80! Inúmeras metodologias OMT, Rumbaugh COAD/YOURDON, Coad-Yourdon, OOSE, Jacobson, SHLAER/MELLOR, Shlaer-Mellor, BOOCH, Grady Booch 14

15 Histórico UML Unified Modeling Language Padronizada pela OMG: Object Management Group Os três amigos: Rumbaugh, Jacobson e Booch Versão 2.0 Sobre a UML (UML ) helps you specify, visualize, and document models of software systems, including their structure and design, in a way that meets all of these requirements UML Linguagem Linguagem para visualização Linguagem para especificação Linguagem para construção Linguagem para documentação: Requisitos, arquitetura, desenho, código fonte, planos de projeto, testes, protótipos, releases. 15

16 UML Diagramas: Estrutura: Classe, Objetos, Componente, Estrutura Composta, Pacote e Distribuição (Implantação). Comportamento: Caso de Uso, Atividade, Máquina de Estado. Interação: Seqüência, Comunicação, Temporização e Interação. Diagrama de Classes Conjunto de classes, interfaces e colaborações, apresentando seus relacionamentos. Diagrama mais comum da OO. Visão estática da arquitetura do sistema. Diagrama de Classes 16

17 Diagrama de Objetos Conjunto de componentes e seus relacionamentos. Apresenta uma visão dos valores armazenados pelos objetos de um diagrama de classes em um determinado momento de execução de um processo do software. Diagrama de Objetos Diagrama de Componentes Partes internas, conectores e portas que implementam um componente. Ao instanciar um componente, suas partes internas também são instanciadas. Está associado à linguagem de programação que será utilizada no desenvolvimento do sistema. 17

18 Diagrama de Componentes Diagrama de Estrutura Composta Estrutura interna de uma classe ou colaboração. Segundo os três amigos, a diferença entre este diagrama e o diagrama de componentes é muito pequena. Diagrama de Pacotes Decomposição do modelo dentro da organização e suas dependências. Um pacote pode ter qualquer diagrama da UML. 18

19 Diagrama de Pacotes Diagrama de Distribuição Configuração dos nós e os componentes que vivem em cada um destes pontos. Visão estática da arquitetura. Diagrama de Distribuição 19

20 Diagrama de Caso de Uso Conjunto de casos de uso e atores (tipo especial de classe) e seu relacionamento. Visão de uso estática do sistema. Modelagem do comportamento do sistema. Diagrama de Caso de Uso Diagrama de Atividade Estrutura do processo. Passo a passo da execução. Visão dinâmica do sistema. 20

21 Diagrama de Atividade Diagrama de Máquina de Estado Estado, transições, eventos e atividades. Visão dinâmica de um objeto. Modelagem do comportamento de uma interface, classe ou colaboração. Diagrama de Máquina de Estado 21

22 Diagrama de Seqüência Diagrama de Interação Enfatiza a cronologia de troca de mensagens entre classes. Diagrama de Seqüência Diagrama de Comunicação Diagrama de Interação Enfatiza a organização estrutural dos objetos e papéis que enviam e recebem mensagens. 22

23 Diagrama de Comunicação Diagrama de Temporização Apresenta momento atual em relação a diferentes objetos e papéis, em contrapartida a somente seqüências de mensagem relativas. Diagrama de Temporização 23

24 Diagrama de Interação Diagrama híbrido composto pelos diagramas de atividade e seqüência. Diagrama de Interação Hierarquia dos diagramas 24

25 Obrigado! Análise e Projeto Orientado a Objetos Aula 4 (Versão ) Requisitos Professor Gabriel Baptista ( gabriel.baptista@uninove.br ) ( ) Um pouco de reflexão: 25

26 Acabou aí? Tem mais? Mas na verdade... 26

27 Isto é comum? SIM!!! Em 1995, um relatório elaborado pelo Grupo Standish*, chamado CHAOS, alertou que apenas 16,2% dos projetos eram encerrados com sucesso. O mesmo estudo em 2009 apresentou uma melhoria no índice, passando para 32%. Na verdade, fala-se em crise do software desde 1968! * Acessado através de Relatório do Grupo Standish CHAOS % dos projetos de software com sucesso; - 42% atrasados, acima do custo, e/ou com menos funcionalidades; - 21% cancelados ou nunca usados. Isto é comum? Segundo Capers Jones and Bill Curtis: - 25% dos projetos de software falham ou são abandonados; - 15% dos defeitos permanecem no produto entregue ao cliente; - 30% a 44% do tempo está sendo utilizado para retrabalho nas companhias (tempo não produtivo); - 50% dos prazos são atendidos pelas companhias. Segundo Professor Dr. Ivanir Costa: - 65% dos erros ocorrem na fase de requisitos - 8% dos erros ocorrem na fase da codificação* * Testes caixas pretas só conseguem verificar estes erros 27

28 A questão é... Por quê? Para Jack Ganssle: Let's face it: any idiot can write code. Estudo do Grupo Standish: Falta de Envolvimento do Usuário Falta de Gerenciamento Falta de necessidades claras A questão é... Por quê? Segundo Humphrey*: - Cronogramas fora da realidade - Equipe inapropriada - Mudanças de Necessidades - Trabalho com baixa qualidade - Crenças em mágica * Maio de Acessado através de Agora imaginem... Um idiota programando + Lista de necessidades confusas ou inexistentes + Necessidades sendo modificadas a toda hora CAOS 28

29 Existe algo a ser feito? Engenharia de Requisitos A Engenharia de Requisitos ajuda os engenheiros de software a compreender melhor o problema que eles vão trabalhar para resolver. Ela inclui o conjunto de tarefas que elevam a um entendimento de qual será o impacto do software sobre o negócio, do que o cliente quer e de como os usuários finais vão interagir com o software * Pressman, 2006 Engenharia de Requisitos O que é um requisito? Os requisitos para um sistema de software estabelecem o que o sistema deve fazer e definem restrições sobre sua operação e implementação * Sommerville,

30 Engenharia de Requisitos Tipos de requisitos - Requisitos do usuário - Funções que o sistema deve ter, visualizados de uma maneira simples - Requisitos do sistema - Domínio: Leis, normas ou até mesmo uma restrição funcional obtidos a partir das necessidades específicas do sistema. - Funcionais: Funcionalidades ou os serviços que se espera que o sistema forneça. - Não-funcionais: Não dizem respeito diretamente às funções específicas do sistema. Definem atributos como confiabilidade e restrições. * Sommerville, 2005 Engenharia de Requisitos Engenharia de Requisitos Desenvolvimento de Requisitos Gerenciamento de Requisitos Elicitação Análise Especificação Validação * Costa, 2007: Sub-Componentes do domínio da Engenharia de Requisitos Desenvolvimento de Requisitos Elicitação Vamos tentar extrair as necessidades do cliente... - Introspecção (Imaginação) - Questionários - Entrevistas - Etnografia (Observação) - JAD (Joint Application Development) 30

31 Desenvolvimento de Requisitos Análise Vamos pensar sobre tudo que foi levantado e, de alguma maneira, vamos documentar estas necessidades na forma de sistema... - JAD (Joint Application Development) - Use cases - Prototipação Desenvolvimento de Requisitos Especificação Vamos criar um contrato com o nosso cliente... - O objetivo é gerar um documento que possa ser lido por diversos stakeholders: - Clientes - Gerentes - Engenheiros de Desenvolvimento - Engenheiros de Teste - Engenheiros de Implantação Desenvolvimento de Requisitos Especificação * Sommerville,

32 Desenvolvimento de Requisitos Validação Vamos confirmar o que o foi pedido pelo cliente... - Prototipação - Revisões formais Desenvolvimento de Requisitos * Costa, 2007: Desenvolvimento de requisitos em um processo iterativo Obrigado! 32

33 Análise e Projeto Orientado a Objetos Aula 5 (Versão ) Modelo de Caso de Uso Professor Gabriel Baptista ( gabriel.baptista@uninove.br ) ( ) Revisando O que significa UML? Qual o objetivo da UML? Quantos diagramas compõe a UML? Que tipo de representação pode ser feita através dos diagramas da UML? Quais são as etapas básicas para o desenvolvimento de requisitos? Como começar? Detectando as necessidades do sistema! 33

34 Modelo de Caso de Uso Uma das maneiras utilizadas para desenvolvimento dos requisitos funcionais. Composto por: Diagrama Especificação Para que serve? Entender o comportamento do sistema Identificar as funcionalidades de arquitetura Localizar as classes Identificar casos de teste Planejamento Criação de manuais Caso de Uso O modelo de casos de uso é um modelo das funções pretendidas do sistema e seu ambiente, e serve como um contrato estabelecido entre o cliente e os desenvolvedores. O modelo de casos de uso é usado como fonte de informações essencial para atividades de análise, design e teste. 34

35 Diagrama de Caso de Uso Exemplo de diagrama de Caso de Uso Ator Um ator define um conjunto coerente de papéis que os usuários do sistema podem desempenhar ao interagir com ele. Uma instância de ator pode ser desempenhada tanto por um indivíduo quanto por um sistema externo. 35

36 Caso de Uso Um caso de uso define um conjunto de instâncias de casos de uso, no qual cada instância é uma seqüência de ações realizadas por um sistema que produz um resultado de valor observável para determinado ator. Relacionamentos existentes Associação Generalização (Herança) Inclusão Extensão Generalização Conceito de Herança Pode ser aplicado no caso de uso e no ator 36

37 Inclusão Ação do sistema que será executada por mais de um caso de uso. A seta é direcionada para o caso de uso que será incluído. Inclusão Extensão Ação do sistema que pode ser executada por mais de um caso de uso. A seta é direcionada para o caso de uso que poderá executar o caso de uso opcional. 37

38 Extensão Especificação do Caso de Uso Número: Número identificador do UC Nome: Nome dado ao UC no diagrama Breve descrição: Descrição em um parágrafo falando sobre o UC Pré-condições: O que deve acontecer antes do caso de uso ser executado. Fluxo de eventos: Fluxo básico (principal ou happy day), Fluxos alternativos, Fluxos de exceção) Requisitos Especiais: Alguma informação adicional que deva ser comentada Pós-condições: O que deve acontece após o caso de uso executar. Inclusões: Pontos de inclusão Extensões: Pontos de extensão Relacionamentos: Atores relacionados, UC s de especialização ou generalização. Como fazer? 1.Identificar possíveis atores. 2.Identificar possíveis ações do sistema. 3.Criar diagrama apontando relacionamento dos elementos. 4.Criar especificação de cada um dos casos de uso levantados. 38

39 Obrigado! Análise e Projeto Orientado a Objetos Aula 6 (Versão ) Diagrama de Classes Professor Gabriel Baptista ( gabriel.baptista@uninove.br ) ( ) Revisando Qual o objetivo do Modelo de Caso de Uso? O que o ator representa em um diagrama de caso de uso? O que o caso de uso representa em um diagrama de caso de uso? Qual o objetivo do relacionamento de herança? Qual o objetivo do relacionamento de inclusão? Qual o objetivo do relacionamento de extensão? 39

40 Diagrama de Classes Representação estática / estrutural do sistema. Entidades essenciais. Principal e mais usado diagrama da UML. Classe Representação de um conjunto de objetos que possuem os atributos (propriedades) e comportamento (métodos) semelhantes. Cada objeto criado a partir desta classe, pode ser chamado de instância da classe. O que representamos em uma classe? Atributos Métodos Visibilidade Privada (-) Pública (+) Protegida (#) Pacote (~) 40

41 Relacionamento entre classes Associação Nome e direção Multiplicidade Navegabilidade Papéis Restrições Prof. Marcos Roberto e Silva Tipos de associação Unária Binária Agregação Composição Generalização Dependência Associação Unária Auto-relacionamento 41

42 Associação Binária Relacionamento simples Agregação Funcionam como uma entidade única Possui um objeto controlador (todo) que cuida dos objetos agregados (partes) Os objetos partes podem existir sem o objeto todo Agregação 42

43 Composição Um objeto parte pertence somente a UM objeto todo Os objetos partes não podem existir sem o objeto todo Composição Generalização Aplicação do conceito de herança É possível representar uma herança múltipla Representa relacionamentos do tipo É UM. 43

44 Generalização Dependência Indica grau de dependência entre classes Relacionamentos de dependência podem expressar também ordem de precedência, onde um elemento deve preceder a outro. Dependência 44

45 Passos para modelar um diagrama de classes 1. Identificar as classes baseada nos casos de uso. 2. Identificar os atributos das classes. (sem levar em conta suas visibilidades ou tipos) 3. Analisar os atributos, identificando se alguns deles são na realidade relacionamentos. 4. Algumas operações podem ser identificadas neste ponto, mas com certeza, não todas. As operações em geral são descobertas com o auxílio de outros diagramas. 5. Analisar classes semelhantes, remodelando as com relacionamentos de Herança. 6. Lançar detalhes dos atributos. Obrigado! Análise e Projeto Orientado a Objetos Aula 7 (Versão ) Diagrama de Sequência Professor Gabriel Baptista ( gabriel.baptista@uninove.br ) ( ) 45

46 Para que serve? Utilizado para determinar a ordem das mensagens trocadas entre papéis e objetos, com base no tempo. Quais são os componentes deste diagrama? Estereótipos de Objetos 46

47 Exemplo Portanto A sequência é dada desde a interação do ator com o sistema. ATOR -> INTERFACE -> CONTROLE -> CLASSES Não se faz necessário apontar o retorno das mensagens A condicional existe através de um bloco do tipo OPT. É possível enviar mensagens de criação e destruição de objetos durante a sequência do diagrama. Obrigado! 47

48 Análise e Projeto Orientado a Objetos Aula 08 (Versão ) Diagrama de Atividades Professor Gabriel Baptista ( gabriel.baptista@uninove.br ) ( ) Para que serve? Determinação de fluxo Atividades em um processamento Trabalho entre as unidades organizacionais em um modelo de negócio. Cenários dos casos de uso Quais são os componentes deste diagrama? Áreas organizacionais Transição Início Atividade Bifurcação Fim Decisão Junção 48

49 Exemplo Obrigado! Análise e Projeto Orientado a Objetos Aula 09 (Versão ) Diagrama de Máquina de Estados Professor Gabriel Baptista ( gabriel.baptista@uninove.br ) ( ) 49

50 Para que serve? Modelar o comportamento de um objeto individualmente. Descrever a seqüência de estados que um objeto possui durante o seu ciclo de vida. Modelar aspectos dinâmicos do sistema. O que significa estado? Período de tempo em que o objeto atenda a uma condição, realize alguma atividade ou espere algum evento. Quando usar? Comportamentos que respondam à mensagens assíncronas Comportamentos que dependam do comportamento anterior para funcionar. 50

51 Quais são os componentes deste diagrama? Exemplo Caixa eletrônico Obrigado! 51

52 Análise e Projeto Orientado a Objetos Aula 10 (Versão ) Diagrama de Componentes Professor Gabriel Baptista ( gabriel.baptista@uninove.br ) ( ) Projeto com reuso O processo de projeto, na maioria das disciplinas de engenharia, baseia-se no reuso de sistemas existentes ou componentes (SOMMERVILLE, 2008) Projeto com reuso Preocupação desde os requisitos com os pontos do projeto que podem ou serão potenciais itens de reuso. Dependente de um processo de desenvolvimento voltado para tal tarefa. Custo inicial pode ser mais alto, entretanto, o retorno do investimento vai acontecer à medida que o componente for reutilizado. 52

53 Projeto com reuso Desenvolvimento sem reuso Desenvolvimento com reuso 53

54 Vantagens do reuso Confiança aumentada Risco de processo reduzido Uso eficiente de especialistas Conformidade com padrões Desenvolvimento acelerado Desvantagens do reuso Falta de apoio de ferramenta Síndrome do não-inventado-aqui Criação e manutenção de uma biblioteca de componentes Abordagens que apoiam o reuso Bibliotecas Frameworks Softwares de prateleira Desenvolvimento orientado a objetos Desenvolvimento orientado a serviços Desenvolvimento orientado a aspectos Design patterns Em resumo: Componentização 54

55 O que significa componente? Parte lógica e substituível de um sistema que atende e provém a realização de um conjunto de interfaces. UML Diagrama de Componentes Para que serve? Modelar os componentes existentes no sistema, bem como o relacionamento entre eles através de interfaces. O que significa interface? Coleção de operações que especificam um serviço que é provido ou é requerido por uma classe ou componente. 55

56 Quando usar o diagrama de componentes? Descrição de componentes do sistema. Representação explícita de uma biblioteca comum entre diversas aplicações Quais são os componentes deste diagrama? Exemplo Caixa eletrônico 56

57 Exemplo Caixa eletrônico Obrigado! Análise e Projeto Orientado a Objetos Aula 11 (Versão ) Diagrama de Implantação Professor Gabriel Baptista ( gabriel.baptista@uninove.br ) ( ) 57

58 Quando usar o diagrama de implantação? Representar a relação entre diferentes hardwares existentes no sistema. Organizar distribuição de arquivos entregáveis (executáveis, bibliotecas, bases de dados). Componentes do diagrama Exemplo Caixa eletrônico 58

59 Obrigado! 59