1 ARQUITETURA E DESIGN DE SOFTWARE O que é Arquitetura? do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; do dicionário: Arte de projetar e construir prédios, edifícios ou outras estruturas; arquitetônica. 2 Constituição do edifício. 3 Contextura de um todo. 4 Intenção, projeto. O que é Arquitetura de Software? O conceito de Arquitetura de Software surgiu nos anos 60 (com Dijkstra), mas se tornou popular nos anos 90. Perry e Wolf (92) Arquitetura = {Elementos, Organização, Decisões} É um conjunto de elementos arquiteturais (de dados, de processamento, de conexão) que possuem alguma organização. Os elementos e sua organização são definidos por decisões tomadas para satisfazer objetivos e restrições. Shaw e Garlan (96) A arquitetura define o que é o sistema em termos de componentes computacionais e, os relacionamentos entre estes componentes, os padrões que guiam a sua composição e restrições. Bass (98) 2003: Shaw e Garlan (96) É a estrutura (ou estruturas) do sistema, a qual é composta de elementos de software, das propriedades externamente visíveis desses elementos, e dos relacionamentos entre eles; é a abstração do sistema. A arquitetura define o que é o sistema em termos de componentes computacionais e, os relacionamentos entre estes componentes, os padrões que guiam a sua composição e restrições. Bass (98) 2003: É a estrutura (ou estruturas) do sistema, a qual é composta de elementos de software, das propriedades externamente visíveis desses elementos, e dos relacionamentos entre eles; é a abstração do sistema. Por que a arquitetura é importante? Bass (98):
2 1. Representações da arquitetura de software constituem um facilitador da comunicação entre todas as partes interessadas no desenvolvimento de um sistema baseado em computador 2. A arquitetura destaca decições iniciais de projeto. Tem impacto profundo em todo o trabalho de engenharia Tão importante como uma entidade operacional. 3. A arquitetura constitui um modelo relativamente pequeno, intelectualmente inteligível de como o sistema é estruturado e como seus componentes trabalham em conjunto. Importância da Arquitetura Como construir uma casa sem a planta? Atua como uma estrutura a fim de checar o atendimento aos requisitos do sistema Suporte na estimação de custos e gerência da complexidade do sistema Suporte ao reuso Reduz o intervalo entre especificação e implementação Permite considerar alternativas arquitetônicas em estágios iniciais do desenvolvimento Reduz riscos associados à construção do software Sua representação serve como guia para o projeto de sua implementação, teste e implantação do sistema. Arquitetura X Design Design Arquitetura Objetiva a realização do sistema como uma entidade funcional Faz parte do ciclo de vida do software Resulta dos requisitos técnicos que o sistema deve satisfazer. Considera um maior escopo de requisitos confiabilidade, baixo custo, modificabilidade, segurança, dentre outros horizonte de tempo que extrapola a vida de um sistema em particular Representa a organização que a co-produz
3 Arquitetura de Software Abstração que ajuda a gerenciar complexidade Projeto Arquitetural do Software Estrutura modular do software Componentes Relacionamento entre componentes Linguagem de Descrição Arquitetural (ADL) Descreve a arquitetura do sistema Decisão e Organização Comunicação dos componentes Organização dos componentes e ideias Estrutura do sistema e dos subsistemas Raciocínio Motivação Investigação Motivação da Arquitetura de Software Representação de sistemas informalmente através de caixas e linhas Gerenciamento da complexidade de sistemas Dinamismo Redução do gap entre especificação e implementação O termo arquitetura de software é usado para designar: Produto Processo Processo; Produto. Representação da estrutura de software Área da engenharia de software que trata de produzir as estruturas de software, visando a reduzir complexidade.
4 Processo Arquiteto de Software Elaboração do modelo de negócio: envolve analisar custo, tempo de desenvolvimento, restrições de mercado, interfaces com outros sistemas, etc; Entendimento dos requisitos: levantamento de requisitos e modelo do domínio Criação ou seleção de uma arquitetura: identificação dos componentes e suas interações, das dependências de construção e tecnologias que apoiam a implementação. Representação da arquitetura e divulgação: para permitir aos desenvolvedores e testadores o entendimento da arquitetura Implementação da arquitetura, seguindo seus protocolos e estruturas. Análise e avaliação: verificar a adequação da arquitetura, registrando impactos, riscos e dificuldades, o que servirá para evolução da arquitetura. Participantes (stakeholders) Analista de requisitos: identifica os requisitos Arquiteto de software: cria a arquitetura pode ser um time com um arquiteto líder. Projetista ou Desenvolvedor: implementa os componentes Outros: cliente/usuário, testador, gerente de projeto, programador, secretários, etc. Lidera e coordena as atividades e os artefatos técnicos no decorrer do projeto; Estabelece estrutura de cada visão do documento de arquitetura; Deve possuir grande conhecimento geral; Visão profunda; Possuir maturidade; Emitir opiniões sensatas e criteriosas rapidamente; Experiência Conhecer totalmente os requisitos, o domínio do problema e engenharia de software; Liderança
5 Conduzir o esforço técnico, fazer com que as decisões sejam cumpridas à risca; Trabalhar junto com o coordenador do projeto; Comunicação Conquistar a confiança e o respeito dos membros do projeto, persuadir, motivar, servir como mentor; Pró-atividade Enfoque inexorável nos resultados em um ambiente cheio de incertezas e sob pressão; Expectativa do papel de Arquiteto de Software Definir uma sugestão de arquitetura para o sistema com base na experiência obtida com sistemas ou domínios de problema semelhantes; Definir os padrões de arquitetura, os principais mecanismos e as convenções de modelagem para o sistema; Definir a estratégia de reutilização; Fornecer dados para o processo de planejamento; Trocar experiências com outros analistas, arquitetos e programadores de outros projetos; Propor pontos de melhoria nas soluções dos analistas/projetistas; Poder de persuadir com argumentos técnicos válidos, até mesmo o cliente; Estar em contato direto com o Líder do Projeto para que o mesmo apoie e reforce as decisões; Assumir a responsabilidade de toda parte técnica do projeto; Ser capaz de reconhecer estruturas comuns em sistemas já desenvolvidos; Usar o conhecimento sobre arquiteturas existentes para tomar decisões de projeto em novos sistemas; Ser capaz de realizar uma descrição formal da arquitetura de um sistema a fim de analisar as propriedades do sistema; Apresentar a arquitetura para outras pessoas. Atividades do Arquiteto de Software Priorizar casos de uso ou funcionalidades; Realizar análise de tendências tecnológicas;
6 Realizar a análise arquitetural; Construir a prova de conceito arquitetural; Prototipação, simulação e realização de experimentos Desenvolver o guia de implementação; Descrever a distribuição de componentes; Criar o modelo da estrutura da implementação; Identificar elementos do projeto; Desenvolver o guia de projeto; Modelagem de Sistemas O que é um modelo? Simplificação da realidade. Características de um bom modelo: Omite componentes irrelevantes em alto nível de abstração Clara representação do sistema a ser construído; Exemplos de Modelo: maquetes de edifícios; plantas de circuitos eletrônicos.
7 Porque modelar sistemas de informação? Auxilia os usuários e os analistas de sistema a compreenderem melhor o problema; e o sistema que está sendo desenvolvido. Facilita a comunicação entre todas as pessoas envolvidas no projeto de desenvolvimento do software. Facilita a gerência da complexidade do domínio; permitindo exibir várias visões dos elementos do sistema. Permite definir a arquitetura lógica; independente das possíveis implementações. Ajuda a visualizar um sistema como ele é ou como se deseja que ele seja. Permite especificar tanto o comportamento quanto a estrutura de um sistema; Oferece uma representação que serve de guia para a construção do sistema. Documenta as decisões tomadas após a avaliação das alternativas propostas. A linguagem UML (Unified Modeling Language) Linguagem de Modelagem Unificada É uma linguagem de modelagem (visual), não uma linguagem de programação É uma linguagem de modelagem não proprietária Permite a utilização de diagramas padronizados para especificação e visualização de um sistema Surgiu da união de três metodologias de modelagem: Método de Booch, de Grady Booch; Método OMT (Object Modeling Technique) de Ivar Jacobson; Método OOSE (Object Oriented Software Engineering) de James Rumbaugh. A primeira versão foi lançada em 1996 Em 1997 a UML foi adotada pela a OMG (Object Management Group Grupo de gerenciamento de Objetos) como linguagem padrão de modelagem. Por que usar UML? Desenvolver o modelo de uma aplicação antes de construí-la, é tão essencial quanto ter uma planta para a construção de uma casa.
8 Analisar o projeto sobre vários aspectos; Diminui a possibilidade de erros. Bons modelos são essenciais para a comunicação entre os times de projetos e para assegurar a beleza arquitetural. Facilita a programação; Todo o time entende a modelagem, facilitando assim a manutenção. Ter um rigoroso padrão de linguagem de modelagem; Fator essencial para o sucesso de um projeto; Sistemas são dinâmicos. Diagramas UML Representação Gráfica de um Conjunto de Elementos Estrutural (Estática) Diagrama de Classes Diagramas de Objetos Diagrama de Caso de Uso Diagrama de Componentes Comportamental (Dinâmica) Diagrama de Estados Diagrama de Atividades Diagrama de Colaboração Diagrama de Sequência Exemplos de Representação UML Interações da aplicação com o mundo exterior; Diagrama de Caso de Uso; Comportamento da aplicação; Interações dos objetos (Sequência e Colaboração); Estrutura do sistema; Diagrama de Classes;
9 Estrutura utilizada na empresa; Organização e distribuição de pacotes e classes; Os componentes do sistema; Diagrama de componentes; Ferramentas CASE Auxiliam na construção e gerenciamento de diagramas UML Exemplos: Rational Rose, MS Visio, PowerDesign, ArgoUML, Astah, Poseidon, StarUML Exemplos dos diagramas da UML Diagrama de Caso de Uso Diagrama mais geral da UML; Usado geralmente nas fases de Levantamento e Análise de Requisito do Sistema; Mostra como o sistema irá se comportar. Diagrama de Classes Diagrama mais utilizado da UML; Serve de apoio para a maioria dos outros diagramas; Define a estrutura de classes do sistema; Estabelece como as classes se relacionam.
10 Diagrama de Objetos Complemento do Diagrama de Classes; Exibe os valores armazenados pelos objetos de um Diagrama de Classes. Diagrama de Sequência Preocupa-se com a ordem temporal em que as mensagens são trocadas; Baseia-se em um Caso de Uso; Costuma identificar o Evento gerador do processo modelado, bem como, o Ator responsável por este evento.
11 Diagrama de Colaboração Amplamente associado ao diagrama de sequência, um complementa o outro; Não se preocupa com a temporalidade, mas sim, em como os objetos estão vinculados e quais mensagens trocam entre si. Diagrama de Estados Procura acompanhar as mudanças sofridas por um Objeto dentro de um determinado processo; O Diagrama de Estados é utilizado normalmente para acompanhar os estados por que passa uma instância de uma classe.
12 Diagrama de Atividades Preocupa-se em descrever os passos a serem percorridos para a conclusão de uma atividade específica; O Diagrama de Atividades concentra-se na representação do fluxo de controle de uma atividade
13 Diagrama de Componentes Amplamente associado a linguagem de programação que será utilizada para desenvolver o sistema modelado; Este diagrama representa os componentes do sistema quando este for implementado em termos de módulos de código-fonte, bibliotecas, arquivos de ajuda, módulos executáveis, etc. Diagrama de Implantação Determina as necessidades de hardware do sistema, as características físicas como servidores, estações, topologias e protocolos de comunicação, ou seja, todo o aparato físico sobre o qual o sistema deverá ser executado.
14 Diagrama de Pacotes Tem por objetivo representar os subsistemas englobados por um sistema de forma a determinar as partes que o compões. Outros diagramas Diagrama de Interação Geral Fornece uma visão geral dentro de um sistema ou processo de negócios; Diagrama de Tempo Descreve a mudança no estado ou na condição de uma instância de uma classe ou seu papel durante o tempo.