Pensamento: Se você esta achando que está no nada... Lembre-se... Que é do nada que se inicia tudo

Transcrição

1 Pensamento: Se você esta achando que está no nada... Lembre-se... Que é do nada que se inicia tudo Prof. Sergio Akio Tanaka

2 Mensagem

3 Análise e Design Orientado a Objetos com Modelagem WEB utilizando UML (Unified Modeling Language) Parte Ia Introdução a Orientação a Objetos Carga Horária: 60 horas Professor Sergio Akio Tanaka

4 Apresentação Qual o seu nome? Formação acadêmica? Nome da sua empresa e cargo que desempenha? Qual a sua expectativa com a Disciplina do UML? e a pós como um todo? Tem interesse em estar fazendo a certificação oficial de UML? e/ ou outras disciplinas? Experiência prática e acadêmica com UML? OO? Rose? RSM? Outras Ferramentas CASE s?

5 Cronograma 05 e 06/04/13 APOO Sergio Tanaka 19 e 20/04/13 APOO Sergio Tanaka 26 e 27/04/13 APOO Sergio Tanaka 24 e 25/05/13 - APOO Sergio Tanaka

6 Avaliação 24/05 => Apresentação dos Trabalhos pelas Equipes 1, 2, 3, 4 e 5 respectivamente. O que será apresentado? Site do Projeto (IRUP) Caso de Desenvolvimento Modelagem de Negócios (Modelo de UC Negócios e Diagrama de Objetos de Negócios) Gerência de Requisitos (Diagrama de Casos de Usos, Protótipo do Projeto(Interfaces Gráficas), Visão, STR, Especificação dos Casos de Usos, Especificação Suplementar, Glossário e Plano de Gerenciamento de Requisitos) Arquitetura do Projeto e Artefato de OOAD (Documento de Arquitetura de Software) - Facultativo Diagramas da UML (UC, Atividade, Estado, Sequência, Comunicação, Implantação, Componentes e Classe) e Modelagem UML para a WEB

7 Forma de Avaliação das Disciplinas: Presença em sala de aula Presença durante a apresentação das outras equipes Participação nas apresentações Apresentação individual Apresentação do grupo Organização e estruturação do trabalho Trabalho completo conforme acordado em sala de aula (artefatos)

8 EMENTA Introduzir conceitos de metodologias para o desenvolvimento de software orientado a objetos, utilizando a UML como linguagem de modelagem do sistema. Estudo de uma metodologia de Análise de Sistemas. Ferramentas de auxílio ao desenvolvimento de Sistemas. Abordar as técnicas para a modelagem de aplicações Web com UML, desde a definição da Arquitetura ao seu Projeto.

9 Conteúdo Programático Introdução da Disciplina de OOAD no RUP Rastreabilidade da Gerência de Requisitos e Modelagem de Negócios para a disciplina de OOAD Introdução a Análise de Sistemas Paradigmas da Análise Metodologias de OOAD (Object Oriented Analysis Design) Análise e Projeto Orientado a Objetos Introdução à Orientação a Objetos Operações e Atributos Tipo de Objeto e Classes Agregação e Composição Estado e Eventos Generalização e Especialização (herança) Encapsulamento, Polimorfismo, Comunicação e Estereótipos

10 Conteúdo Programático Modelagem Utilizando a UML O uso de Pacotes na UML Diagramas de Casos de Usos Diagramas de Classes Diagramas de Seqüência Diagramas de Colaboração Diagramas de Estados Diagramas de Atividades Diagramas de Componentes Diagramas de Implantação Diagramas de Visão Geral Diagramas de Estrutura Composta Diagramas de Tempo Diagramas de Pacotes Diagrama de Perfil O uso de uma ferramenta CASE Arquitetura Aplicações Básicas Clientes Dinâmicos Construções de Aplicações Web Arquiteturas Thin Web Client Thick Web Client Web Delivery Extensões de Aplicações Web para a UML

11 Referências 1/2 OMG. OBJECT MANAGEMENT GROUP. UML 2.0. Disponível em: Martin. UML Essencial. 3ª Edição. Porto Alegre: Bookman, LARMAN, Craig. Utilizando UML e Padrões. 3 Edição. Porto Alegre: Bookman, PENDER, Tom. UML A Bíblia. Rio de Janeiro: Editora Campus, BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML Guia do Usuário. 2 ed. Rio de Janeiro: Editora Campus, CONALLEN, Jim. Desenvolvendo Aplicações Web com UML. Tradução da Segunda Edição. Rio de Janeiro: Editora Campus, Pressman, Roger S.; Engenharia de Software; Bookman, Porto Alegre, 7 Edição

12 Referências 2/2 LEFFINGWELL, Dean; WIDRIG, Don. Managing Software Requirements: A Use Case Approach. Boston, MA: Addison- Wesley, ERIKSON, Hans-Erik; PENKER, Magnus. Business Modeling with UML: business patterns at work. ISBN: New York:Wiley, IBM. RUP Rational Unified Process (Software) Versão 7.0. USA: IBM Rational, 2006.

13 Estudos de Casos das Equipes EQUIPE 1: EQUIPE 2: EQUIPE 3: EQUIPE 4:

14 Estudo de Caso padrão - Interface Gráfica Inserir CD s

15 Interface Gráfica Alterar CD s

16 Introdução a Orientação a Objetos

17 Conceitos Básicos } Objeto } Abstração } Classe } Instância } Atributo } Identificador ê Operação ê Método ê Mensagem ê Evento ê Parâmetro ê Estado } Transição de Estado } Associação } Herança } Encapsulamento } Polimorfismo } Colaboração } Estereótipos

18 Orientação a Objetos Histórico/Evolução das Linguagens Surgiu no início da década de 60 Devido a necessidade dos: sistemas de comunicação, fluxo de trânsito, sistemas de produção, sistemas administrativos e sociais. Cronograma das Linguagens OO: 1966 SIMULA (Kristen Nogaard, Noruega); 1980 SMALLTALK (Xerox); 1986 C++ (AT&T), SMALLTALK V, OBJECTIVE-C; 1988 EIFFEL (Meyer, França); 1989 Turbo Pascal 5.5 (Borland); 1995 JAVA; 2001 C#; 2002 VB.NET

19 Definição Orientação a Objetos? É um paradigma para o desenvolvimento de aplicações, ou seja, é uma estratégia de desenvolvimento de software que organiza o software como uma coleção de objetos que contém tanto a estrutura dos dados como o comportamento.

20 Orientação a Objetos } Características Forma natural de enxergar a realidade Forma natural de modelar Forma natural de codificar O mundo é Orientado a Objetos

21 } Mundo Natural Orientação a Objetos Formado por Objetos

22 Orientação a Objetos Propostas da Técnica OO Reusabilidade: de código; de objetos encapsulados; Componentes, Frameworks, etc. Manutenibilidade: Mudanças bem localizadas, não acarretando propagações descontroladas. Confiabilidade: Devido ao encapsulamento, que torna as estruturas de dados privado aos objetos. Extensibilidade Aumento da Produtividade

23 Garantia de Sucesso Garantia Cronograma das fases de Ciclo de Vida Planejamento adequado; Capacitação dos desenvolvedores; Adoção de uma Metodologia e/ou Padrão.

24 Análise OO Técnicas de Análise Apresenta um conjunto de regras e modelos que auxiliam o Engenheiro de Software levantar e modelar os requisitos dos usuários que o sistema deve atender.

25 O que é um objeto? Um objeto é uma entidade com uma fronteira bem definida e identidade que encapsula o estado e o comportamento O Estado é representado por atributos e relacionamentos. O Comportamento é representado por operações e máquinas de estados. Atributos Objeto Operações

26 Princípios Básicos da Orientação a Objetos Orientação a Objetos Abstração Encapsulamento Modularidade Hierarquia

27 Abstração É o ato de definir um objeto conceitual a partir de OBJETOS do mundo real que possuam as mesmas características e comportamento, podendo ser classificados como pertencentes a um mesmo tipo. Dinheiro

28 Abstração Exemplo Avião Esporte

29 Classe Representa a abstração de um conjunto de OBJETOS do Mundo Real que possuem tipos de características e de comportamento em comum. Pessoa

30 Classe Exemplo Classe Funcionário Funcionários Ana, João, Fátima, Pedro, Carlos. possui nome possui endereço possui data de nascimento possui telefone

31 Instância Representa cada ocorrência de um OBJETO formados a partir de uma CLASSE. Funcionário 1 Ana 2 João 3 Fátima 4 Pedro 5 Carlos

32 Instância Classe Funcionário Objeto Funcionário 2 (instância) Ana Maria Av. Curitiba, /02/ possui nome possui endereço Exemplo possui data de nascimento possui telefone Objeto Funcionário 1 Instanciação (instância) Carlos Av. Curitiba, 44 05/03/

33 Atributo É uma característica particular possuída por todos os OBJETOS de uma CLASSE e assume valores específicos para cada OBJETO. Classe Funcionário (possui) CPF (possui) RG (possui) Nome (possui) Endereço

34 Atributo Exemplo Classe Funcionário (possui) nome (possui) endereço (possui) data de nascimento (possui) telefone Valor: nome = João, endereço = rua..., data de nascimento = 05/07/71 telefone =

35 Identificador Único É um ou vários ATRIBUTOS, cuja função é permitir a individualização de cada INSTÂNCIA. IDPessoa

36 Identificador Único Exemplo Classe Funcionário Funcionario-ID RG Nome Endereço Data Nascimento

37 Operação Um serviço que é requisitado a um objeto como parte de seu comportamento em resposta a estímulos. Uma operação tem uma assinatura que pode restringir quais parâmetros reais são possíveis.

38 Operação É o que os Objetos de uma Classe sabem realizar. Cafeteira.esquenta Cafeteira.aumentaTemperatura Cafeteira.diminuiTempo

39 Operação Exemplo Métodos CERA Funcionário Fala Corre Anda Come Lê Funcionário Cria() Elimina() Recupera() Atualiza()

40 Método Exemplo da implementação de um método em JAVA: void remover(actionevent e) { try { deleterow(); savechanges(); } catch (Exception ex) { desabilita(); } }

41 Mensagem Representa o mecanismo de invocação de uma OPERAÇÃO. É o mecanismo utilizado para solicitar uma OPERAÇÃO. É a forma de conseguir executar uma OPERAÇÃO. Evento ao abrir mensagem Operação Abrir

42 Evento Um evento é uma especificação de uma ocorrência significativa que tem uma localização no tempo e no espaço. Evento Ao abrir

43 Evento Exemplo Evento Partida Evento Botão do mouse pressionado

44 Parâmetro Representa um ou mais ATRIBUTOS carregados dentro de uma MENSAGEM. Pessoa.elimina (CPF)

45 Parâmetro Exemplo Evento Partida Avião.Partida (linha área, nº vôo)

46 Estado Um estado é uma condição ou situação na vida de um objeto durante a qual ele satisfaz a alguma condição, realiza alguma atividade ou aguarda algum evento. Evento Ao abrir Estado Fechado Estado Aberto

47 Estado Exemplo Evento Partida Estado Decolando Estado Parado

48 Estado Exemplo Classe Exemplar ISBN Nº Tombo... estado Criado Eliminado Emprestado Em manutenção Reservado Liberado

49 Transição de Estado Uma transição é um relacionamento entre dois estados, indicando que um objeto no primeiro estado realizará certas ações e entrará no segundo estado quando um evento especificado ocorrer e as condições especificadas estão satisfeitas. Estado Fechado Estado Aberto Estado Criado Estado Eliminado

50 Associação Representa a forma como os OBJETOS de uma mesma CLASSE ou de CLASSES diferentes se reconhecem entre si. BANCO 1 Possui * AGÊNCIA

51 Exemplo de Hierarquia Aumento da abstração Asset BankAccount Security RealEstate Diminuição da Abstração Savings Checking Stock Bond Elementos do mesmo nível de hierarquia deveriam estar no mesmo nível de abstração.

52 Herança Representa a propriedade pela qual uma CLASSE pode herdar características e comportamento de uma outra CLASSE. Pessoas

53 Herança Pessoas{abstract} Nome Endereço Telefone Cria() {abstract} Elimina() {abstract} Recupera() {abstract} Atualiza() {abstract} Operações abstratas Cliente CPF Cria() Elimina() Recupera() Atualiza() Operações Concretas Fornecedor CNPJ Cria() Elimina() Recupera() Atualiza()

54 Exemplo de Herança Múltipla Veículo {sobreposição, incompleto} Veículo terrestre Veículo aquático Veículo anfíbio

55 Ilustração de Encapsulamento Professor Kenji necessita estar disponível para ministrar aulas para as quatro turmas no próximo semestre. SetMaxLoad(4) Professor Kenji Name: S. Kenji Employee ID: HireDate: 07/25/1991 Status: Tenured Discipline: Finance MaxLoad: 4 TakeSabbatical() Encapsulamento: significa separar o programa em partes, o mais isoladas possível. A idéia é tornar o software mais flexível, fácil de modificar e de criar novas implementações.

56 Exemplo de Modularidade Por exemplo, quebrar um sistema complexo em pequenos módulos. Sistema de Pagamento Sistema de catálogo de curso Sistema de Registro de Curso Sistema de gerenciamento de estudantes

57 Polimorfismo Representa a propriedade pela qual OBJETOS de CLASSES diferentes possuem tipos de reações particulares a uma mesma operação. Uma mesma operação pode se comportar de diferentes formas sobre diferentes CLASSES.

58 Polimorfismo Mundo Natural Chegada do Verão

59 Mundo Natural Polimorfismo A Mensagem é a mesma. A reação é diferente para cada tipo de Objeto.

60 Polimorfismo Operação Criar Exemplo Funcionário Livro Exemplar Banco Agência... a estrutura (atributos) de cada classe é diferente

61 Exemplo de Polimorfismo

62 Colaboração É a troca de MENSAGENS entre OBJETOS. É uma comunicação entre OBJETOS e Atores.

63 Estereótipos => UML 1.x Palavras Chaves => UML 2.0 } Sugerido por Rebecca Wirfs-Brock em 1990; } } } } Torna a UML extensível pelo usuário do método pela definição de estereótipos adicionais; O uso do estereótipo é omitido quando a semântica predefinida na UML for suficiente; Um estereótipo é escrito textualmente (em guillmets sobre a seqüência de nome); Ex: <<estereótipo>>.

64 FINAL DA PARTE Ia

65 Análise e Design Orientado a Objetos com Modelagem WEB utilizando UML (Unified Modeling Language) Parte Ib Introdução a UML Professor Sergio Akio Tanaka

66 Apresentação da NOTAÇÃO UML (Unified Modeling Language)

67 Apresentação da UML UML, Linguagem formada pela junção das melhores técnicas de modelagem (OMG 2008). UML, Linguagem de Modelagem Unificada, é uma linguagem gráfica para visualização, especificação, construção e documentação de artefatos de sistemas complexos de software (BOOCH 2006).

68 Ciclo de Vida do Desenvolvimento do Software

69 Inputs to the UML Rumbaugh Booch Jacobson Meyer Before and after conditions Harel State charts Fusion Operation descriptions, message numbering Embley Singleton classes, High-level view Gamma, et.al Frameworks, patterns, notes Wirfs-Brock Responsibilities Shlaer- Mellor Object lifecycles Selic, Gullekson, Ward ROOM (Real-Time Object-Oriented Modeling) Odell Classification

70 Breve Histórico (UML) Oficialmente em Out/94 Rumbaugh se junta a Booch na Rational; Foco inicial do projeto era a unificação dos métodos Booch e OMT; Out/95 lançado um esboço da versão 0.8; Jun/96 lançado a versão 0.9 incorporando o método OOSE de Jacobson; Jan/97 v.1.0 oferecida para padronização a OMG (Object Management Group); Versão revisada 1.1, oferecida para padronização a OMG Julho/97; 14 de Novembro de 1997 a UML é aprovada pela OMG (v.1.1); Revisão da UML assumida pela RTF (Revision Task Force) do OMG, lançando a versão 1.2 em junho 1998; Dez/98 a RTF lança a versão 1.3; 15/9/2000, a OMG estendeu o prazo p/ a aprovação da UML 1.4 p/ 22/12/2000; UML 1.5, combinação da UML /09/2000 UML 2.0 definida pelo Working Group Consolidação da UML 2.0, 2.1, 2.2, 2.3 E Continuação da UML 2.x.

71 Histórico UML (Forma gráfica) UML 2.0 (2004) UML 1.5 (March, 03) UML Partners Expertise UML 1.1 (Sept. 97) UML 1.0 (Jan. 97) UML 0.9 (June 96) and UML 0.91 (Oct. 96) Unified Method 0.8 (OOPSLA 95) Public Feedback Booch 93 OMT - 2 OOSE Other Methods Booch 91 OMT - 1

72 E finalmente o histórico real da...uml... Ilustração de como foi extraída a UML no laboratório da Rational

73 Tipos de Modelagem - V. 1.x Modelagem Estrutural 1-Diagrama de Classes Diagramas de Pacotes; => oficializado como diagrama na versão 2.0 Diagramas de Objetos. => oficializado como diagrama na versão 2.0 Modelagem Comportamental 2-Diagramas de Casos de Uso; 3-Diagramas de Seqüência; 4-Diagramas de Colaboração; => diagrama de comunicação na versão Diagramas de Atividades; 6-Diagramas de Estados; Processos e Threads; Eventos e Sinais. Modelagem Arquitetural 7-Diagramas de Componentes; 8-Diagramas de Implantação; Patterns e Frameworks.

74 Tipos de Modelagem - V. 2.4 Na versão 2.4, a UML tem quatorze diagramas divididos em:

75 Visão dos Diagramas Estruturais Usando Mapas Conceituais.

76 Visão dos Diagramas Comportamentais Usando Mapas Conceituais.

77 w Multiplas visões Sequence Diagrams Modelos Dinâmico Use-Case Diagrams Class Diagrams Static Diagrams Object Diagrams Communication Diagrams Models Component Diagrams Dynamic Diagrams State Machine Diagrams Activity Diagrams Deployment Diagrams

78 Iniciando a Modelagem e Rastreabilidade entre os elementos Antes, vamos fazer uma Revisão dos conceitos básicos do RUP. Revisar, também, a Modelagem de Negócios e Gerência de Requisitos em relação a disciplina de Análise e Design

79 Melhores Práticas } Aplicando as 6 melhores práticas: } } } } } } Desenvolvimento Iterativo Gerência de Requisitos Uso da Arquitetura de Componentes Modelo Visual (UML) Verificação Contínua da Qualidade Gerência de Mudanças PROCESSO CONFIGURÁVEL

80 Princípios Chave para o Desenvolvimento Orientado a Negócios Adaptar o Processo Equilíbrio que compete as Prioridades dos Stakeholders Colaboração Entre os Times Demonstrar o Valor Iterativamente Elevar o Nível de Abstração Focar Continuamente na Qualidade

81 Estrutura do Site (IRUP v.2002)

82 Modelagem Utilizando os Casos de Usos de Negócios

83 Modelo de Objetos de Negócio } Define o ponto de vista dos trabalhadores de negócio ponto de vista interno. Modelo de Negócio e Atores de Sistema

84 Revisão MN:

85 REVISÃO Modelagem Utilizando Casos de Uso de Sistemas

86 Breve Revisão - Diagrama de Casos de Uso Representa o estudo e modelagem da interface externa do sistema. Descrição dos requerimentos dos usuários. Elementos e Notação: ATOR Caso de Uso

87 Ator ATOR é qualquer pessoa, departamento, sistema computacional e dispositivos que utilizam funcionalidades do Sistema.

88 Ator Exemplo de Atores: Diretoria Departamento Pessoal Aluno Estoque

89 Caso de Uso Representa qualquer interação de serviços entre um ATOR e o SISTEMA. Cada serviço é representado como um Caso de Uso (Use Case). SISTEMA

90 Diagrama de Casos de Uso OBSERVAÇÕES: Não representar para o mesmo ATOR mais do que uma missão. Departamento e sistema pessoal Sistema pessoal Departamento pessoal

91 Descrição de Caso de Uso Descrita no Artefato: Especificação de Casos de Uso

92 Casos de Uso Nível de Especificação Definir Funcionalidades Genéricas; Regras de Negócios; Visão do Usuário;

93 O Escopo de um Caso de Uso Geralmente, é difícil decidir se um conjunto de interações do usuário do sistema (ATOR COM O SISTEMA), ou uma caixa de diálogo, é um ou são vários casos de uso. Considere o uso de uma máquina de reciclagem. O cliente insere itens de depósito como, por exemplo, latas, garrafas e caixotes na máquina de reciclagem. Ao inserir todos os itens de depósito, basta pressionar um botão e um recibo é impresso. Esse recibo pode ser trocado por dinheiro.

94 Cada Comunicação-Associação é um conjunto de diálogo Estudante faz o login no sistema Sistema aprova o login Estudante solicitação informação do Curso Estudante Registrar Cursos Sistema de Catálogo de Cursos Sistema mostra a lista de cursos Estudante seleciona cursos Sistema confirma curso disponível Sistema mostra aprovação da programação Sistema transmite solicitação Catálogo de Cursos retorna informação do curso

95 Herança entre atores } Pode-se utilizar herança entre atores; } Herança entre atores significa que um ator preenche os mesmos papéis de outro ator, podendo também preencher papéis adicionais; } Na UML herança é indicado pelo relacionamento de generalização.

96 Herança entre atores Ator 1 Caso de Uso 1 Caso de Uso 2 Ator 3 Ator 2 Caso de Uso 3 Created with Visio

97 Relacionamentos Entre Casos de Uso Include Extend <<include>> <<extend>> Generalização

98 O que é um Relacionamento Include? Um relacionamento de um caso de uso base para um caso de uso de inclusão O comportamento definido no caso de uso de inclusão é inserida explicitamente para o caso de uso base Inclusão Base <<include>>

99 Relacionamento Include: Exemplo RU e-st Obter Cota <<include>> Executar Comércio <<include>> <<include>> Identificar Cliente Outros UC Caso de Uso Obter Cota 1. Incluir Identificar Cliente para verificar identidade do cliente 2. Mostrar opções. Cliente seleciona Obter Cota Caso de Uso Identificar Cliente 1. Logon 2. Validar logon 3. Entrar com a senha 4. Verificar a senha A1: Logon inválido A2: Senha errada A3:...

100 Por Que Usar um Relacionamento de Include? Base Inclusão <<include>> Fatorar comportamento comum para dois ou mais casos de uso Evitar descrever qualquer comportamento múltiplas vezes (reutilização). Assegurar comportamento comum consistente com o resto. Fatorar e encapsular comportamento de um caso de uso base Simplificar fluxo de eventos complexos (ver exemplo RU-st) Fatorar comportamento que não faz parte de um propósito primário.

101 O que é um Relacionamento Extend? Conexão de um caso de uso estendido para um caso de uso base Inserir comportamento estendido de um caso de uso num caso de uso base Inserir somente se a condição de extensão for verdadeira Inserir num caso de uso base ao ponto de extensão nomeado Base Extensão <<extend>>

102 Relacionamento Extend: Exemplo RU e-st Obter Cota Cliente do Comércio Sistema News <<extend>> Obter News <<extend>> Obter Prognóstico Sistema Especialista de Cota

103 Relacionamento Extend: Exemplo RU e-st (cont.) Caso de Uso Obter Cota Fluxo Básico 1. Include Identificar Cliente para verificar identidade do cliente. 2. Mostrar opções 3. Cliente seleciona Obter Cota. 4. Cliente obtém cotas 5. Cliente obtém outras cotas 6. Cliente faz logoff A1. Sistema Cota indisponível... Pontos de Extensão: O ponto de extensão Serviço Opcional ocorre no Passo 3 do Fluxo Básico. Caso de Uso Obter News Este caso de uso extend o Caso de Uso Obter Cota, ao ponto de extensão Serviços Opcionais. Fluxo Básico: 1. Se o Cliente selecionar Obter News, o sistema pergunta ao cliente o período de tempo e o número de itens news. 2. Cliente entra com o período de tempo e o número de itens. O sistema envia o símbolo da ação de comércio para o Sistema News, recebe resposta, e mostra os news para o cliente. 3. O Caso de Uso Obter Cota continua. A1: Sistema News Indisponível A2: Não Existe News Sobre Esta Ação

104 Execução de um Extend Executado quando o ponto de extensão é alcançado e a condição de extensão (decisão) for verdadeira Instância do Caso de Uso Caso de Uso Base Ponto de Extensão Caso de Uso Extensão

105 Por Que Usar um Relacionamento Extend? Extensão Base <<extend>> Fatorar um comportamento opcional ou excepcional Executado somente numa certa condição Fatorando a simplificação do fluxo de eventos do caso de uso base Exemplo: ligando um alarme Adicionar comportamento estendido Desenvolver comportamento separadamente, possivelmente numa versão posterior Exemplo: Caso de Uso Obter News

106 Um caso de uso é abstrato ou concreto Casos deuso (Concreto versus Abstrato) A B <<include>> Casos de uso abstrato (A & D): - Não tem que ser completo. - Existe somente por outros casos de uso. - Nunca são instanciados para si mesmo (não é inicializado por um ator). Casos de uso concreto (B & C): - Deve ser completo e significativo - Pode ser instanciado para si mesmo C D <<extend>> É comum o caso de uso de extensão ser abstrato, mas não é necessário que seja.

107 Universidade (from Actors) Firmar Convênio (f rom Firmar Conv ênio) Em pre sa (from Actors) Exemplo de um diagrama de Caso de Uso para um Sistema de Controle de Estágio Definir Empresa para desenvolvimento (f rom Definir Empresa para desenv olv imento) Definir Professor Orientador (f rom Definir Prof essor Orientador) Aluno (from Actors) Re gistrar e ntre ga d a RPOD (f rom Registrar entrega da RPOD) Registrar Plano de Estágio (f rom Registrar Plano de Estagio) Efetuar Controle de Estágio (f rom Ef etuar Controle de Estágio) Professor Orientador (from Actors) Coordenador Estágio (from Act... Definir Aluno (f rom Def inir Aluno) Avaliar Aluno (f rom Av aliar Aluno)

108 Diagramas de Casos de Uso 1. Fazer o levantamento com os usuários para identificar os Atores e os Casos de Uso. 2. Fazer uma lista dos possíveis Atores. 3. Filtrar a lista e definir os Atores. 4. Fazer uma lista dos possíveis Casos de Uso dos Atores. 7. Realizar levantamento junto aos usuários para entender como o sistema deve atender os Casos de Uso. 6. Representar cada Ator com seus Casos de Uso no diagrama. 5. Filtrar e definir os Casos de Uso para cada Ator.

109 FINAL DA PARTE Ib

110 Análise e Design Orientado a Objetos com Modelagem WEB utilizando UML (Unified Modeling Language) Parte Ic Introdução a Arquitetura de Software Professor Sergio Akio Tanaka

111 Representação da Arquitetura de Software através de Pacotes

112 Pacote Um pacote é um mecanismo de propósito geral para a organização de elementos em grupos. Um pacote é representado graficamente como uma pasta com uma guia.

113 Pacote Cada pacote deve ser nomeado; O nome dos pacotes são escritos sobre os pacotes; Ligações entre os pacotes são representadas para indicar a dependência entre os pacotes; u Notação: Pacote1 Nome

114 Dependência de Pacotes u Notação de Dependência: Pacote1 Pacote1 Nome Pacote2 Pacote2 Nome Relacionamento de dependência

115 Contexto em Análise Arquitetural [Early Elaboration Iteration] [Inception Iteration (Optional)] Architecture Analysis Architect Define a Candidate Architecture Perform Architectural Synthesis Analyze Behavior Refine the Architecture (Optional) Design Components Design the Database

116 Visão Geral da Análise Arquitetural Supplementary Specification Glossary Software Architecture Doc Reference Architecture Vision Document Architectural Analysis Project-Specific Guidelines Design Model Use-Case Model Deployment Model

117 Papel: Arquiteto de Software O papel arquiteto de software lidera e coordena as atividades e os artefatos técnicos no decorrer do projeto. O arquiteto de software estabelece a estrutura geral de cada visão de arquitetura: a decomposição da visão, o agrupamento dos elementos e as interfaces entre esses principais agrupamentos. Portanto, comparado aos outros papéis, a visão do arquiteto de software é ampla, e não detalhada.

118

119 Qual o conhecimento de um Arquiteto de Software? "O arquiteto ideal deve ser uma pessoa erudita, um matemático, familiarizado com estudos históricos, um estudioso aplicado de filosofia, conhecedor de música, que não desconheça medicina, detentor de saber jurídico e familiarizado com astronomia e cálculos astronômicos." - Vitruvius, há aproximadamente 25 anos a.c.

120 Arquitetura de Software Segundo Buschmann 1996, a arquitetura de software consiste da descrição dos subsistemas, e dos componentes de um sistema de software e dos relacionamentos entre eles. Subsistemas, Componentes

121 Arquitetura Logical View Implementation View Analista/Projetista Estrutura Usuário-final Funcionalidade Use-Case View Programador Gerência de Software System integrators Performance Escalabilidade Rendimento Process View Deployment View System engineering Topologia do Sistema Entrega, instalação comunicação

122 } } } } Pacotes (Importação e Exportação) Na UML, a modelagem de um relacionamento de importação é feita como uma dependência assinalada pelo estereótipo <<import>> como adorno; As partes públicas de um pacote são chamadas suas exportações; As partes exportadas por um pacote são visíveis somente para o conteúdo dos pacotes que importam aquele pacote explicitamente. As dependências de importação e de acesso não são transitivas.

123 Pacotes (Importação e Exportação)

124 Pacotes } Dois ou três níveis de aninhamento constituem o limite do que será conveniente utilizar. Mais do que o aninhamento, utilize a importação para a organização de seus pacotes.

125 Pacotes A UML define 5 estereótipos-padrão que se aplicam aos pacotes: <<facade>>: especifica um pacote que é apenas uma visualização de algum outro pacote; <<framework>>: especifica um pacote que é formado por padrões; <<stub>>: serve como proxy para o conteúdo público de outro pacote; ou seja, são utilizados quando possuimos ferramentas capazes de dividir um sistema em pacotes que manipulamos em diferentes momentos e potencialmente em diferentes locais. <<subsystem>>: representa uma parte independente de todo o sistema cuja modelagem está sendo feita. <<system>>: representa todo o sistema cuja modelagem está sendo feita.

126 Acoplamento de Pacotes Acoplamento: quanto maior a dependência entre os pacotes maior o acoplamento Pacotes não deveriam ter codependências (circular) Pacotes da camada inferior não deveria ser dependente da camada superior. Isto é uma regra para o estilo arquitetural em camadas Em geral, as dependências não deveriam pular camadas Upper Layer Lower Layer A X A X B C B X X = Violação de acoplamento

127 Exemplo: Arquitetura em Camadas <<layer>> Application <<layer>> Business Services Necessary because the Application Layer must have access to the core distribution mechanisms provided with Java RMI. <<layer>> Middleware Base Reuse global

128 Evitando Dependências Circulares A A B A Hierarquia deveria ser aciclica B A C B A' C Dependências Circulares torna dificil o reuso para reutilizar um pacote sem o outro. Solução no exemplo, acima, criar um novo pacote A que seja comum para A e C.

129 Estilo Arquitetural Um estilo de arquitetura pode ser definido como uma família de sistemas em termos de um modelo de estrutura de organização. Um estilo de arquitetura expressa componentes e o relacionamento entre eles, com restrições de suas aplicações, composições e regras de projeto para suas construções [BUS 96]. Mais especificamente, pode-se dizer que um estilo de arquitetura define um vocabulário de componentes e tipos de conectores, mais um conjunto de restrições sobre a combinação desses (GARLAN 1995).

130 Arquitetura de Software Tipos de estilos arquiteturais: ü Pipes e Filtros ü Camadas ü Objetos ü Invocação Implícita ü Quadro-negro ü Repositório (Passivo) ü Arquiteturas de Aplicações Distribuídas ü Processos Comunicantes ü Cliente-Servidor ü Chamada de Procedimento

131 Exercício 1: Configurar na Ferramenta CASE IBM Rational Rose para a visualização da Arquitetura Multicamadas Elaborar o Estilo Arquitetural proposto para utilização nos estudos de casos utilizando pacotes

132 Arquitetura de Software Proposta do Estilo Arquitetural em Camadas para o desenvolvimento dos estudos de casos

133 FINAL DA PARTE Ic

134 CV Resumido do Professor SERGIO AKIO TANAKA, MSc Área ENGENHARIA DE SOFTWARE, ARQUITETURA CORPORATIVA GERÊNCIA DE PROJETOS E PROCESSOS DE NEGÓCIOS Sergio Akio Tanaka, atua na área de Informática desde 1990 tanto na área acadêmica como empresarial. É Especialista em Gestão Empresarial pelo ISE - Instituto Superior de Ensino em convênio com o IESE de Barcelona. Mestre em Ciência da Computação pela Universidade Federal do Rio Grande do Sul; Pós-graduado pela Universidade Estadual de Londrina nas áreas de Redes de Computadores e Banco de Dados e em Análise de Sistemas pela UniFil; Graduado em Processamento de Dados. Engenheiro de Software certificado pela IBM Rational em diversas áreas. Ao Longo da sua carreira, foi Diretor de Novas Tecnologias da K2Solutions. Atuou como Gerente Geral da PLATIN/ADETEC e Consultor do Agente Softex/ADETEC no mercado Espanhol, Instrutor e Coordenador da área de TI do SENAC por 11 anos e foi Gerente da KAIZEN - DATABASE Marketing por 5 anos. Atualmente, é Diretor Geral, e também, consultor certificado pela IBM Rational na AUDARE Engenharia de Software. Na área acadêmica, desde 1994, atua como professor e coordenador da UNIFIL - Universidade Filadélfia nos cursos de Pós-Graduação da área de Computação e Pesquisa, Professor e Coordenador de Pós-Graduação na área de Engenharia de Software do SENAI/SC e SENAI-PR; Professor Ad-hoc da UNIVEL, UNIVALE, UNOPAR, UNIPAR e UEL em cursos de Pós-graduação. Possui expertise em Gerência de Projetos, Arquitetura de Software, UML, Construção de Frameworks e Componentes, Processo de Desenvolvimento de Software, Gerência de Requisitos, Gerência de Mudanças, Workflow, Modelagem Web e de Negócios. Possui forte experiência no mercado Internacional e Possui mais de 100 artigos publicados (veja plataforma lattes).