• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Arquitetura de Software - Uma visão gerencial
 

Arquitetura de Software - Uma visão gerencial

on

  • 11,315 views

Visão gerencial da disciplina "Arquitetura de Software".

Visão gerencial da disciplina "Arquitetura de Software".

Statistics

Views

Total Views
11,315
Views on SlideShare
11,258
Embed Views
57

Actions

Likes
26
Downloads
0
Comments
1

5 Embeds 57

http://www.slideshare.net 49
http://static.slidesharecdn.com 3
http://www.linkedin.com 2
https://www.linkedin.com 2
http://twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Jogando.net/mu - 27

    Olá, venho divulgar o melhor servidor de MU on-line do
    Brasil.
    -Season 6 Ep. 3 em todos os Servers. Sendo 7 servers diferenciados proporcionando sua diversão,
    VEJA ALGUMAS NOVIDADES :
    - NOVOS KITS : DEVASTATOR e SUPREMO DIAMOND V2 com Rings e Pendat Mysthical ;
    - Novos Shields Power v3 18 opts;
    - Novas Asas, Rings e Shields JDiamonds;
    - Novas compras com troca de asas e shields para asas e shields JDiamond.
    - Conheça também o site de Animes Cloud: http://www.animescloud.com, mais de 20.000 videos online.
    E NÃO PERCA ~> 1ª Mega Maratona Jogando.net ~> MAIS DE 30 DIAS DE EVENTOS .
    ENTRE JÁ NO SITE : http://www.jogando.net/mu/ >> CADASTRE-SE E GANHE 5 DIAS DE VIP
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Arquitetura de Software - Uma visão gerencial
  • Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Ago de 2009 Arquitetura de Software - Uma visão gerencial
  • Arquitetura de Software - Uma visão gerencial

Arquitetura de Software - Uma visão gerencial Arquitetura de Software - Uma visão gerencial Presentation Transcript

  • Arquitetura de Software Alexandre Leão [email_address] Uma visão gerencial
  • Alexandre Leão
    • Graduação em Engenharia Eletrônica e especialização em Planejamento e Gestão Organizacional, ambos pela Universidade de Pernambuco.
    • Profissional de TI com larga experiência em serviços de consultoria e terceirização de tecnologia da informação, atuando como coordenador técnico de projetos e arquiteto de software.
      • LinkedIn: http://br.linkedin.com/in/alexandreleao
    • Certificações profissionais:
      • PMI Certified Project Management Professional (PMP)
      • Sun Certified Enterprise Architect (SCEA)
      • IBM Certified Solution Designer - Rational Unified Process (RUP)
      • Exin Certified - ITIL Foundation
    ITIL Foundation
  • Agenda
    • Governança e Arquitetura
    • Arquitetura de Software
    • Arquitetura de Software no RUP
    • Arquitetura de Software no OpenUP
    • O Arquiteto de Software
  • Governança Corporativa Em blocos Governança Corporativa Transparência, efetividade, responsabilidade, prestação de contas Governança de TI Normas, Frameworks de TI
    • Governo
    • Mercado
    • Acionistas
    Frameworks de Gestão Corporativa BSC, Six Sigma Leis
  • Governança de TI Em blocos Governança de TI Normas ISO, BSI Frameworks de TI Controle COBIT Gestão de Serviços ITIL, ASL Gestão de Projetos PMBOK, Prince2 Engenharia de Software CMMI, MPS.BR, SWEBOK, RUP Arquitetura Corporativa TOGAF, Zachman, 3D Blueprinting
  • Arquitetura Definição
    • Publicada na norma 1471do IEEE no ano 2000.
    • Adotada como padrão pela ISO no ano 2007.
    “ É a organização fundamental de um sistema, expressa nos seus componentes, nos relacionamentos entre eles e com o ambiente, e nos princípios que governam seu projeto e sua evolução.” ISO/IEC 42010:2007 - Systems and Software Engineering - Recommended practice for architectural description of software-intensive systems
  • Arquitetura Conceitos chaves
    • Organização
    • Sistema
      • Uma aplicação > Arquitetura de software ou de aplicação
      • Um conjunto de aplicações > Arquitetura de aplicações
      • Uma infra-estrutura de TI > Arquitetura técnica ou de tecnologia
      • Uma empresa > Arquitetura corporativa ou empresarial
    • Componentes
      • Partes do sistema, com responsabilidades definidas.
  • Arquitetura Conceitos chaves
    • Relacionamentos
      • Visão estática: estrutura dos componentes.
      • Visão dinâmica: comportamento/interações entre os componentes.
    • Princípios
      • Restrições.
      • Suposições.
      • Requisitos.
      • Padrões, etc.
  • Arquitetura Corporativa Definição
    • Utilizando a definição da ISO:
      • Sistema
        • Uma empresa.
      • Componentes
        • Negócio: objetivos estratégicos e processos de negócio.
        • TI: aplicações, dados e infra-estrutura.
    É a organização fundamental de uma empresa , expressa nos seus componentes, nos relacionamentos entre eles e com o ambiente, e nos princípios que governam seu projeto e sua evolução.
  • Arquitetura Corporativa Em blocos Arquitetura Corporativa Arquitetura Técnica Arquitetura de Dados Arquitetura de Aplicações Arquitetura de Negócio
  • Arquitetura Corporativa Frameworks
    • O pen
      • The Open Group Architecture Framework (TOGAF)
        • Suportado por Capgemini, HP, IBM, Oracle e SAP, entre outras.
    • Comerciais
      • Zachman Framework
        • Zachman International
      • 3D Blueprinting
        • Unisys
  • Arquitetura de Aplicações Definição
    • Utilizando a definição da ISO:
    • O que está no escopo?
      • As aplicações, os dados de entrada e saída, e as integrações necessárias para suportar funções e processos de negócio (definidos na Arquitetura de Negócio).
    • O que está fora do escopo?
      • A organização interna das aplicações.
      • As tecnologias utilizadas nas aplicações.
    É a organização fundamental de um conjunto de aplicações , expressa nos seus componentes, nos relacionamentos entre eles e com o ambiente, e nos princípios que governam seu projeto e sua evolução. Arquitetura de Software
  • Progresso
    • Governança e Arquitetura 
    • Arquitetura de Software
    • Arquitetura de Software no RUP v7
    • Arquitetura de Software no OpenUP v1.5
    • O Arquiteto de Software
  • Arquitetura de Software História
    • Final da década de 60 e início da década de 70
      • O conceito surgiu através dos trabalhos de Edsger Dijkstra e David Parnas:
        • Estrutura de software.
        • Encapsulamento de informação.
        • Separação de interface e implementação.
    • Década de 90
      • Evoluiu e ganhou força, pela utilização em massa de novas tecnologias:
        • Orientação a objetos.
        • Componentes.
        • Internet.
      • Publicado o livro “ Software Architecture: Perspectives on an Emerging Discipline ” em 1996, por Mary Shaw and David Garlan da Universidade Carnegie Mellon.
  • Arquitetura de Software História
    • Hoje
      • Fator crítico de sucesso no desenvolvimento de software
      • Especialização, profissionalização e programas de certificação
        • International Association of Software Architects (IASA)
        • Association of Open Group Enterprise Architects (AOGEA)
      • Pesquisas
      • Publicações
    • Utilizando a definição da ISO:
      • Sistema
        • Um software.
      • Componentes
        • Elementos de software:
          • Módulos/Subsistemas/Camadas/Componentes.
          • Processos (instâncias de programas em execução).
    Arquitetura de Software Definição É a organização fundamental de um software , expressa nos seus componentes, nos relacionamentos entre eles e com o ambiente, e nos princípios que governam seu projeto e sua evolução.
  • Arquitetura de Software É estratégico
    • Envolve uma série de decisões estratégicas, regras e padrões que estabelecem a base para o projeto e a construção de um software.
    Arquitetura Projeto Construção Mudanças nas definições arquiteturais tem um impacto bastante significativo em um software. Quanto maior e mais complexo for o software, mais relevante se torna a definição de sua arquitetura.
  • Arquitetura de Software Benefícios
    • Equaliza as necessidades de todos os interessados ( stakeholders ).
    Riscos, qualidade, distribuição de atividades, ... Estrutura, interações, extensibilidade, manutenibilidade, ... Funcionalidades, desempenho, disponibilidade, segurança, ... Orçamento, prazo, ... Gerenciamento, suportabilidade, ... Cliente Usuários Desenvolvedores e Mantenedores Gerente do projeto Operadores
  • Arquitetura de Software Benefícios
    • Endereça os atributos de qualidade de software.
    • Suporta o processo de planejamento.
    • Guia as atividades de projeto e implementação.
    • Ajuda a gerenciar os riscos técnicos e a complexidade.
    • Reduz os custos de manutenção.
    • Suporta a análise de impacto de mudanças.
    • Serve como um ponto de partida para o treinamento de analistas, desenvolvedores e operadores.
  • Arquitetura de Software e Engenharia de Software
    • Duas visões:
      • 1ª Visão:
      • Arquitetura de Software é um tópico dentro da área da Engenharia de Software.
      • 2ª Visão:
      • Arquitetura de Software é uma área independente da Engenharia de Software.
  • Arquitetura de Software e Engenharia de Software
    • 1ª Visão
    Engenharia de Software Áreas do Conhecimento (AC) Computing Essentials Mathematical and Engineering Fundamentals Professional Practice Software Modeling and Analysis Software Design Software Validation and Verification Software Evolution Software Process Software Quality Software Management Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering - IEEE - 2004
  • Arquitetura de Software e Engenharia de Software
    • 1ª Visão (cont.)
    AC Software Design Unidades do Conhecimento (UC) Design concepts Design strategies Architectural design Human computer interface design Detailed design Design support tools and evaluation Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering - IEEE - 2004
  • Arquitetura de Software e Engenharia de Software
    • 2ª Visão
    Domínio da construção de software Domínio da construção civil Engenharia de Software Arquitetura de Software Engenharia Civil Arquitetura International Association of Software Architects (IASA) Association of Open Group Enterprise Architects (AOGEA)
  • Arquitetura de Software Interessados ( Stakeholders )
    • Qualquer pessoa, equipe ou organização que:
      • Esteja ativamente envolvida no desenvolvimento e manutenção do software.
        • Gerente do projeto
        • Analistas do sistema
        • Programadores
        • Integradores
      • Seja afetada pelo software.
        • Usuários
        • Analistas de suporte técnico
        • Operadores
      • Exerça influência sobre o software.
        • Cliente
        • Gestor do sistema
  • Arquitetura de Software Em blocos Arquitetura de Software Mecanismos arquiteturais Requisitos arquiteturais Restrições e suposições arquiteturais Visões arquiteturais Padrões arquiteturais
  • Restrições Arquiteturais
    • São fatores que impõem restrição na definição da arquitetura de um software.
    Tipo de restrição Exemplos Técnica Infra-estrutura (hardware, software e rede) existente Normas (padrões e mecanismos arquiteturais, padrões de projeto) existentes Organizacional Perfil da equipe de desenvolvimento Financeira Orçamento disponível Mercadológica Tecnologias disponíveis Recomendações de fornecedores Legal Política de licenciamento de software
  • Suposições Arquiteturais
    • São premissas que influem na definição da arquitetura de um software.
    • Exemplos:
      • A WAN que interliga as diversas instalações tem desempenho, disponibilidade e confiabilidade suficientes para suportar a utilização da aplicação nos horários de pico, não havendo a necessidade de se implantar bancos de dados distribuídos.
      • O servidor de banco de dados selecionado é capaz de gerenciar adequadamente o volume de dados exigido pela aplicação, mantendo os níveis de desempenho e confiabilidade nos horários de pico.
    • A validade e a precisão das suposições arquiteturais devem ser continuamente avaliadas ao longo do ciclo de vida do desenvolvimento.
  • Requisitos Arquiteturais
    • São requisitos de um software que tem uma forte influência na definição da sua arquitetura.
      • Funcionais (arquiteturalmente significativos)
        • Definem o que o software deve fazer.
      • Não-Funcionais
        • Definem como o software deve ser.
  • Requisitos Arquiteturais Funcionais
    • Critério: risco.
      • Alta complexidade
      • Integração com outros sistemas
      • Integração com bibliotecas e ferramentas de terceiros
      • Desempenho
    • Exemplos:
      • Caso de Uso “Calcular saldo devedor”
        • O sistema calcula o saldo devedor aplicando a taxa de juros vigente em cada exercício.
      • Caso de Uso “Cadastrar fornecedor”
        • O sistema valida a situação cadastral do fornecedor no SERASA.
      • Caso de Uso “Emitir relatório sintético de saldos contábeis”
        • O sistema gera um relatório em formato pdf, rtf ou html, conforme opção do usuário.
  • Requisitos Arquiteturais Não-Funcionais
    • Cada requisito não-funcional de um software está relacionado a um atributo de qualidade de software.
    • Exemplos:
      • O tempo de resposta máximo no horário de pico não deve ultrapassar 5 segundos.
        • Atributo de qualidade relacionado: desempenho.
      • O software deve disponibilizar ajuda online no nível de tela.
        • Atributo de qualidade relacionado: usabilidade.
    • Classificação dos atributos de qualidade de software:
      • Visíveis em tempo de execução
      • Visíveis em tempo de desenvolvimento
  • Atributos de Qualidade Visíveis em tempo de execução
    • Auditabilidade
    • Confiabilidade
    • Desempenho
    • Disponibilidade
    • Escalabilidade
    • Gerenciabilidade
    • Interoperabilidade
    • Segurança
    • Usabilidade
  • Atributos de Qualidade Visíveis em tempo de desenvolvimento
    • Extensibilidade
    • Manutenibilidade
    • Portabilidade
    • Reusabilidade
    • Testabilidade
  • Atributos de Qualidade Considerações
    • Devem ser priorizados, pois podem interferir negativamente entre si.
      • Escalabilidade normalmente prejudica a gerenciabilidade.
      • Auditabilidade normalmente prejudica o desempenho.
    • Não podem ser esquecidos nas atividades de projeto e implementação.
      • Uma tela mal projetada e implementada não vai proporcionar usabilidade.
      • Um algoritmo mal projetado e implementado não vai proporcionar manutenibilidade, extensibilidade e desempenho.
  • FURPS+
    • Classificação de requisitos arquiteturais criada por Robert Grady.
      • Practical Software Metrics for Project Management and Process Improvement . Prentice-Hall, 1992.
    • Acrônimo:
      • F unctionality (funcionalidade)
      • U sability (usabilidade)
      • R eliability (confiabilidade)
      • P erformance (desempenho)
      • S upportability (suportabilidade)
      • + = Restrições (de projeto, de implementação, de integração, físicas)
  • Padrões Arquiteturais
    • São modelos reutilizáveis de organização de elementos de software, que resolvem problemas recorrentes e satisfazem requisitos arquiteturais.
      • Elementos de software:
        • Partes constituintes de um software.
        • Exemplos:
          • Módulos/Subsistemas/Camadas/Componentes.
          • Processos.
    • Definem responsabilidades e relacionamentos.
    • São independentes de domínio.
    • São também chamados estilos arquiteturais.
  • Padrões Arquiteturais
    • Exemplos:
      • Arquitetura em camadas
        • Arquitetura cliente-servidor
        • Arquitetura em 3 camadas (apresentação, negócio e acesso a dados)
      • Arquitetura baseada em componentes
      • Arquitetura baseada em mensagens
        • Ponto-a-ponto
        • Publicador-assinante
      • Arquitetura orientada a serviço (SOA)
    • Um software pode utilizar um ou mais padrões arquiteturais.
  • Padrões Arquiteturais Exemplo: Arquitetura em 3 Camadas
    • Elementos de software:
      • Camada de apresentação
        • Responsável pela apresentação de dados para o usuário.
        • Tem um relacionamento de dependência com a camada de negócio.
      • Camada de negócio
        • Responsável pelo processamento dos dados submetidos pela camada de apresentação, aplicando as regras de negócio necessárias.
        • Tem um relacionamento de dependência com a camada de acesso a dados.
      • Camada de acesso a dados
        • Responsável pelas operações de persistência e consulta de dados solicitadas pela camada de negócio.
  • Visões Arquiteturais
    • São representações de um software modeladas a partir da perspectiva de diferentes grupos de interessados ( stakeholders) .
      • Semelhantes às diversas plantas utilizadas na construção civil: planta baixa, hidráulica, elétrica, etc...
    • Conjunto típico de visões arquiteturais baseadas na UML:
      • Visão de Caso de Uso
      • Visão Lógica
      • Visão de Dados
      • Visão de Implementação
      • Visão de Processo
      • Visão de Implantação
  • Visões Arquiteturais
    • Visão de Caso de Uso
      • Conteúdo: funcionalidades do software arquiteturalmente significativas, suas interfaces externas e seus principais usuários.
      • Diagramas: de caso de uso
      • Interessados: usuários, analistas de sistema, desenvolvedores.
  • Visões Arquiteturais
    • Visão Lógica
      • Conteúdo: organização dos elementos de análise e projeto de software, e realizações de casos de uso.
      • Diagramas: de classe, de sequência, de comunicação, de estado.
      • Interessados: analistas de sistema, desenvolvedores.
  • Visões Arquiteturais
    • Visão de Implementação
      • Conteúdo: alocação dos elementos de projeto de software em componentes, e organização dos componentes em camadas e subsistemas.
      • Diagramas: de componentes.
      • Interessados: desenvolvedores, integradores.
  • Visões Arquiteturais
    • Visão de Implantação
      • Conteúdo: alocação de componentes em artefatos, alocação de artefatos na infra-estrutura de hardware e software, e organização da infra-estrutura de hardware e software.
      • Diagramas: de implantação.
      • Interessados: integradores, analistas de suporte, operadores.
  • Mecanismos Arquiteturais
    • Soluções reutilizáveis para problemas técnicos recorrentes, que são consistentemente aplicadas em um software e satisfazem requisitos arquiteturais.
    • Exemplos:
      • Problema: como salvar o estado de um software em execução?
        • Mecanismo utilizado: persistência.
      • Problema: como permitir a distribuição do processamento?
        • Mecanismo utilizado: comunicação entre processos.
    • São independentes de domínio.
  • Mecanismos Arquiteturais Estados
    • Podem assumir três estados, conforme o nível de abstração:
      • Análise
      • Projeto
      • Implementação
    Análise Projeto Implementação Persistência Banco de dados relacional Oracle 11g Framework objeto-relacional Java Persistence API (JPA) Comunicação entre processos Contêiner EJB IBM WebSphere Application Server Padrão de projeto Session Façade EJB SessionFacade
  • Mecanismos de Análise Exemplos
    • Que satisfazem requisitos funcionais ( F unctionality ):
      • Tratamento de erros, exceções e mensagens aos usuários
      • Geração de relatórios
      • Paginação de dados em telas de consulta
      • Geração de trilhas de auditoria
      • Comunicação entre processos
      • Processamento batch
      • Gerenciamento de transações
      • Integração
        • Entre subsistemas e com sistemas externos
        • Via camadas de apresentação e de negócio
      • Persistência
      • Controle de numeração sequencial
      • Autenticação
      • Autorização
  • Mecanismos de Análise Exemplos
    • Que satisfazem requisitos de usabilidade ( U sability )
      • Internacionalização e localização
      • Ajuda online
      • Execução simultânea de funcionalidades
    • Que satisfazem requisitos de confiabilidade ( R eliability )
      • Replicação de dados
      • Replicação de sessões de usuário
  • Mecanismos de Análise Exemplos
    • Que satisfazem requisitos de desempenho ( P erformance )
      • Cache de dados
      • Gerenciamento e pools de recursos
      • Gerenciamento de sessões de usuário
    • Que satisfazem requisitos de suportabilidade ( S upportability )
      • Instrumentação ( log e trace)
      • Geração de eventos de alerta aos operadores
  • Mecanismos de Implementação
    • Estão espalhados pelo sistema.
      • No código do software.
      • Nos frameworks utilizados.
        • Spring
        • Hibernate/NHibernate
      • Nos componentes e bibliotecas de classes utilizados.
        • Jasper Reports & iReport/Crystal Reports
        • Log4J/NLog
      • Na plataforma de execução do software.
        • Servidor de banco de dados
        • Servidor de aplicação (Java EE/.Net)
        • Sistema operacional
  • Padrões de Projeto Design Patterns
    • Durante a definição das visões e dos mecanismos arquiteturais, faz-se necessário adotar padrões de projeto.
    • São modelos reutilizáveis de organização de elementos de projeto de software, que resolvem problemas recorrentes e satisfazem requisitos arquiteturais.
      • Elementos de projeto de software:
        • Partes constituintes de um projeto de software.
        • Exemplos:
          • Software procedural: funções e procedimentos
          • Software orientado a objetos: classes, interfaces, objetos, eventos e sinais
          • Software baseado em serviços: serviços
    • Definem responsabilidades e relacionamentos.
    • São independentes de domínio.
  • Padrões de Projeto
    • Exemplos:
      • Padrões de projeto GoF ( Gang of Four - Gamma, Helm, Johnson e Vlissides)
        • Criacionais: Abstratct Factory, Builder, Singleton
        • Estruturais: Adapter, Bridge, Façade
        • Comportamentais: Command, Observer, Strategy
      • Padrões de projeto para aplicações corporativas de Martin Fowler
        • Camada web: Model-View-Controller, Front Controller, Page Controller
        • Camada de negócio: Transaction Script, Domain Model
        • Camada de acesso a dados: Row Data Gateway, Query Object
        • Distribuição: Data Transfer Object
        • Básicos: Gateway, Service Stub
      • Padrões de projeto J2EE
        • Session Façade, Service Locator, Service Activator, Data Acces Object
  • Padrões de Projeto Front Controller
    • Problema
      • Você quer um ponto de acesso centralizado na camada web para tratar as requisições.
    • Solução
      • Utilizar uma classe Front Controller.
        • Possibilita a aplicação de regras comuns a todas as requisições: validações de segurança, validações de dados, gravação de trace de navegação, etc...
  • Progresso
    • Governança e Arquitetura 
    • Arquitetura de Software 
    • Arquitetura de Software no RUP
    • Arquitetura de Software no OpenUP
    • O Arquiteto de Software
  • Arquitetura de Software no RUP
    • RUP ( Rational Unified Process ) é um processo de desenvolvimento proprietário, pertencente à IBM.
  • Arquitetura de Software no RUP
    • Fases e Marcos de um Projeto
      • O marco da fase “Elaboração” é a liberação de uma arquitetura de software robusta e estável.
  • Arquitetura de Software no RUP
    • Disciplinas
      • Modelagem de negócio
      • Requisitos
      • Análise e Projeto
      • Implementação
      • Teste
      • Implantação
      • Gerenciamento de configuração e mudança
      • Gerenciamento de projeto
      • Ambiente
    As tarefas de arquitetura de software estão distribuídas nessas disciplinas.
  • Arquitetura de Software no RUP
    • Tarefas e Artefatos de Arquitetura de Software
  • Arquitetura de Software no RUP
    • Tarefa “Priorizar Casos de Uso”
      • Executada durante a fase “Concepção”.
  • Arquitetura de Software no RUP
    • Tarefa “Análise Arquitetural”
      • Executada durante a fase “Elaboração”.
  • Arquitetura de Software no RUP
    • Tarefa “Identificar Elementos de Projeto”
      • Executada durante a fase “Elaboração”.
  • Arquitetura de Software no RUP
    • Tarefa “Identificar Mecanismos de Projeto”
      • Executada durante a fase “Elaboração”.
  • Arquitetura de Software no RUP
    • Tarefa “Descrever Distribuição”
      • Executada durante a fase “Elaboração”.
  • Arquitetura de Software no OpenUP
    • OpenUP ( Open Unified Process ) é um processo de desenvolvimento aberto, cedido pela IBM para a Fundação Eclipse.
      • Versão ágil do RUP.
      • Mínimo, completo e extensível.
      • Como no RUP, o marco da fase “Elaboração” é a liberação de uma arquitetura de software robusta e estável.
  • Arquitetura de Software no OpenUP
    • Disciplinas do OpenUP
      • Requisitos
      • Arquitetura
      • Desenvolvimento
      • Teste
      • Gerenciamento de projeto
    Tarefas e Artefatos de Arquitetura de Software
  • Arquitetura de Software no OpenUP
    • Tarefa “Esboçar a Arquitetura”
      • Executada durante a fase “Concepção”.
  • Arquitetura de Software no OpenUP
    • Tarefa “Refinar a Arquitetura”
      • Executada durante a fase “Elaboração”.
  • Progresso
    • Governança e Arquitetura 
    • Arquitetura de Software 
    • Arquitetura de Software no RUP 
    • Arquitetura de Software no OpenUP 
    • O Arquiteto de Software
  • O Arquiteto de Software
    • Profissional ou equipe de profissionais em um projeto de software com as seguintes responsabilidades:
      • Gerenciamento dos requisitos não-funcionais.
      • Definição, validação e evolução da arquitetura.
      • Definição, validação e evolução de padrões e regras de desenvolvimento.
      • Seleção e validação de ferramentas, tecnologias e frameworks .
      • Controle de qualidade do código fonte.
      • Capacitação de analistas e desenvolvedores na utilização da arquitetura.
  • O Arquiteto de Software
    • Importante:
      • Deve ter competências técnicas e habilidades interpessoais, adquiridas e desenvolvidas através de treinamentos e certificações.
      • Deve estar alocado ao projeto do início ao fim.
      • Deve ter autoridade para tomar as decisões técnicas no projeto.
      • Deve trabalhar lado a lado do gerente do projeto no planejamento das atividades e na seleção de profissionais.
      • Deve trabalhar lado a lado de analistas e desenvolvedores na análise, projeto e construção do software, garantindo a aderência dos artefatos à arquitetura.
  • Obrigado! Alexandre Leão [email_address]