Implementação de software

Frameworks

É com a experiência dos programadores que foram surgindo os frameworks

Construir um software do zero é muito custoso, por isso se usa uma base já implementada

Benefícios de se usar um framework

• O benefício básico de se usar um framework é a produtividade
• Melhora da qualidade através da reutilização do framework, já que ele é mais usado e se detecta mais falhas

Com restrições de prazo e custo, os desenvolvedores devem-se utilizar de componentes, frameworks e padrões de projeto para realização do projeto

Definições

Framework é uma técnica que se beneficia de três características das linguagens de programação orientadas a objeto: abstração de dados, poliformismo e herança;

 O framework é uma arquitetura semi-acabada e passível de reutilização para um domínio de aplicação;

Framework é uma aplicação genérica que permite a criação de diferentes aplicações em um determinado domínio;

Um framework define uma arquitetura para uma família de sistemas, fornecendo partes predefinidas para sua construção;

Conceitos de Frozen Spots e Hot Spots

Frozen Spots: definem uma arquitetura global de um sistema que permanece inalterado em qualquer instanciação do framework;

Hot Spots: são pontos do framework onde ocorrem a especialização (definir classes adicionais para sobrepor métodos, etc.) e adaptação.

Esquema de HotSopts

• Uma classe abstrata de base, que vai definir a interface
• Classes concretas derivadas, representando cada uma das diferentes alternativas para os aspectos variáveis
• Parte opcional com relacionamentos e classes adicionais

Benefícios

• Modulariação
• Reutilização
• Extensão de interfaces
• Framework controla estrutura e abordagem do programa

UML-F 

Usada para fazer modelagem de frameworks e utiliza conceitos comuns e mecanismos de extensão (como estereótipos) da própria UML.

• Estereótipos
• São mecanismos para permitir adicionar novos blocos de construção semelhantes aos existentes
• É representado graficamente por << e >>
• Tag values
• São meios para proporcionar a criação de novas propriedades. É apresentado como uma sequencia de caracteres entre chaves, colocado abaixo de outro elemento.
• Restrições
• São mecanismos para especificar uma nova semântica de algum elemento UML. É representada como uma sequencia de caracteres colocada próxima ao elemento associado.

Hot Spots

Há três tipos de hot spots em um framework orientado a objetos:

• Métodos variáveis: possuem uma interface bem definida, mas que podem variar sua implementação de acordo com a instanciação do framework;
• Classes estendidas: podem ser estendidas durante a instanciação do framework, recebendo novos métodos;
• Interfaces estendidas ou classes abstratas: permitem a criação de subclasses concretas na instanciação do framework. Essas classes são chamadas de classes de aplicação.

Os três tipos podem ser estáticos (instanciação não é requerida em tempo de execução) ou dinâmicos (é requerida em tempo de execução)

Tags utilizadas em UML-F

• Variable: é aplicado aos métodos de uma classe e representa o hot spot Métodos Variáveis;
• Extensible: é aplicada a uma classe e indica o hot spot Classes Estendidas. 
• Incomplete: representa o hot spot Interfaces Estendidas. Colocada ao lado do simbolo de generalização;
• Tag appl-class: Complementa a definição de classes estendidas. Indica um aditivo na estrutura de um framework;
• static e dynamic: complementam a notação dos hot spots, indicando se o mesmo requer instanciação ou não.

Conceitos de Programação Orientada a Objetos

Conceitos Básicos de OO (cap. 1)

• Classes consistem na descrição de atributos e métodos para um conjunto de objetos. Possuem uma visão interna e externa (funções publicas).
• Interface pública são os serviços da classe que poderão ser utilizados por outras partes do programa, ocultando como os serviços são implementados. Essa ocultação é chamada encapsulamento.
• Objetos são entidades unicamente identificados. Eles são uma instancia concreta e dinâmica de uma classe. Possuem dados, comportamento e identidade da classe. Pode-se dizer que um objeto é "uma variável do tipo de dados definido pela classe".
• Os métodos de uma classe podem ser chamados de funções membros ou serviços.
• O estado de um objeto é determinado pelo valor de seus atributos
• Modificadores de acesso
• Público - visíveis em toda aplicação
• Privado - visíveis apenas internamente a classe que foram programados
• Protegido - visibilidade intermediária, visíveis apenas em uma hierarquia de classes (subclasses)
• Herança
• Criar classe mãe e classes filhas que especializam um determinado comportamento
• Herança múltipla: duas ou mais classes que possuem subclasses (java e c# não implementa esse conceito)

Linguagem Java - (cap. 3)

• Em java, um objeto é interpretado como uma referência e não o objeto propriamente dito.
• NomeClasse nomeObjeto -> cria-se referência mas não objeto; uma vez criado objeto com "new" a referência não pode ser manipulada numericamente.
• Construtor: iniciam o objeto
• Modificador "friendly" - visíveis apenas no mesmo pacote
• Membros estáticos: os atributos declarados como estáticos, possuem o mesmo valor durante a execução.
• Destrutores: são utilizados para finalizar um objeto.

Herança de Classe (cap. 4)

• Extends
• Atributos protegidos podem ser explicados depois que o conceito de herança de classe foi introduzido
• Membros protegidos podem ser acessados por classes do mesmo pacote mesmo que não sejam da mesma hierarquia de classes
• Podem ser acessados por classes que estendem dessa classe, mesmo que esta subclasse seja de outro pacote
• Membros protegidos se limitam a uma hierarquia de classes, uma vez que java não permite herança múltipla de classes
• Membros protegidos e estáticos podem ser acessados em qualquer classe estendida
• Construtores em classes estendidas
• Quando uma subclasse é construída, uma superclasse também é.
• A nova classe (derivada) deverá escolher qual construtor da superclasse deseja chamar
• Subclasse chama o construtor da superclasse através do super() com a mesma assinatura da superclasse

Polimorfismo (cap 5)

• Reescrever métodos com mesmo nome, parâmetros diferentes, etc.
• Palavra chave super, pode-se usar super.metodo()
• Palavra chave final, serve para definir atributos ou métodos que não podem ser modificados após sua primeira inicialização. 

Projeto nos Modelos de Qualidade

Projeto e construção do produto MPS.br

O objetivo do processo é definir atividades que permitam a elaboração do projeto e que possibilitem a implementação dos requisitos.

Processos de projeto de software

No MPS.br

• Projeto e Construção do Produto (PCP) -> Nível D

No CMMI

• Technical Solutions (TS) -> Nível 3

Na ISO 12207

• Development Processes

Propósito

• Projetar (design)
• Processo criativo de transformar o problema em uma solução.
• Representação significativa de algo a ser construído
• Desenvolver
• Implementar requisitos

Resultados esperados

• PCP1 - Definição da arquitetura e documentação da arquitetura
• Necessário fazer a definição da arquitetura do software
• Criar alternativas para solucionar o problema 
• Exemplos de alternativas
• Desenvolver ou comprar?
• Linguagens, frameworks
• Ambiente desktop, move
• Banco de dados
• Escolher uma das alternativas com base nos critérios estabelecidos inicialmente
• Exemplos de critérios
• Risco
• Custo
• Capacitação da equipe
• PCP2 - Soluções
• Soluções são selecionadas com base no cenário que são definidos e em critérios que são identificados
• Necessário identificar os critérios de seleção e avaliar as alternativas 
• Pode ser necessário repetir o processo todo de tomada de decisão para um componente específico
• PCP3 - Produto e componentes do produto
• Projetar o produto de acordo com os requisitos
• Projeto é constituído da arquitetura do sistema (hardware, software e op. manual) e do software
• Para evidenciar este resultado pode ser usado documentos técnicos como documento de arquitetura, desenho, análise ou modelo de banco de dados
• PCP4 - Interfaces
• Interfaces entre os componentes do produto
• Componente precisa expor as interfaces que ele fornece e que ele consome.
• Projeto deve conter a definição das interfaces
• A escolha da interface leva em conta os requisitos definidos no processo DRE
• O processo ITP (integração do produto) utilizará as interfaces projetadas
• PCP5 - Análise dos componentes do produto
• Análise é necessário para decidir sobre a construção, compra ou reutilização dos componentes
• Considerar custo-benefício, deve incluir custo direto e indireto.
• PCP6 - Componentes do produto implementado e verificação
• Verificar se os componentes estão implementados de acordo com o projeto e a sua documentação desenvolvida
• MPS.br fornece várias alternativas para fazer a verificação
• Revisão por pares
• Testes de unidade
• Verificação em relação aos requisitos do projeto
• Como evitar este resultado?
• Código fonte
• Lista de verificação
• Padrões de codificação
• Relatórios de inspeção
• Relatórios da execução dos testes
• PCP7 - Documentação
• Desenvolvida de acordo com os padrões estabelecidos
• Doc. deve dar apoio para o desenvolvimento
• Deve conter
• O projeto de arquitetura do projeto
• Justificativa das decisões tomadas
• Projeto dos componentes
• Projeto das interfaces
• Rastreabilidade entre os requisitos e interfaces
• PCP8 - Documentação é mantida
• Doc. precisa ser mantida e revisada
• Pode-se utilizar padrões na documentação, ex:
• Fontes a serem utilizadas
• uso de abreviações
• índice
• tamanho da fonte

Introdução ao framework SEMAT Essence

SEMAT é a comunidade que trabalha definindo o framework Essence

Framework Essence

O framework inclui uma linguagem e um kernel e oferece:

• Monitoramento do progresso do projeto de software
• Direcionamento do progresso dirigido por objetivos

Framework consiste

• Métodos
• Práticas
• Kernel Essence
• Linguagem Essence

O framework se baseia em três aspectos: Cliente, Solução e Esforço, dentro de cada aspecto tem os:

• Alphas: itens com os quais trabalhamos
• Possuem diversos estados
• Cada estado possui uma lista de verificação
• Organiza os estados através de cartões
• Espaços de atividades: itens a fazer
• Competências: quais as competências para trabalhar dentro da situação

Portanto, a estrutura ficaria assim:

• Cliente
• Alphas
• Oportunidade, Stakeholders
• Espaços de atividades
• Competências
• Solução
• Alphas
• Requisitos e Sistemas de Software
• Espaços de atividades
• Competências
• Esforço
• Alphas
• Trabalho, Forma de Trabalho e Equipe
• Espaços de atividades
• Competências

Kernel do Essence

1. Olhar o projeto holisticamente
• Dar atenção de forma holística é observar todos os aspectos do projeto (todos os alpha)
2. Monitorar o progresso
• Definir qual o estado atual de um determinado alpha
• Precisa ter a lista de verificação feita para completar um estado no alpha
3. Definir a direção e os objetivos do projeto
• Uma vez definido o estado atual
• Definir o estado alvo, qual a direção que vou dar para o projeto
4. Decidir como alcançar os objetivos (itens a trabalhar)
• Preciso demonstrar as características chave
5. Agir para concluir os itens a trabalhar
• Produzir os itens levantados para atingir o objetivo

Alphas relevantes dentro da disciplina

• Requisitos delimitados
• Sem eles não é possível elaborar a arquitetura definitiva
• Requisitos coerentes
• Não há conflitos entre os requisitos funcionais e não funcionais
• Sistema de Software
• o primeiro item é certificar que a arquitetura deve ser selecionada
• ser capaz de demonstrar a arquitetura selecionada

Kernel provê a estrutura e o mecanismo para:

• Monitoramento do progresso do projeto
• Reflexão da equipe
• Gerenciamento de riscos
• Direcionamento do projeto

Fundamento do SEMAT Essence é o kernel. Utilizando as práticas e o kernel é possível criar um método personalizado.

Projeto Arquitetural

Fundamentos da Análise Arquitetural

Trata de modelos que ajuda o implementador a construir o software.

Questões Principais

• Como decompor um sistema em diversos pacotes e subsistemas?
• Quais classes devem estar em cada subsistema de forma a permitir mais reutilização de subsistemas?
• Quais dependências entre os subsistemas?
• Quais os conectores devem ser usados entre os subsistemas?
• Como distribuir cada um dos subsistemas em diferentes nós de processamento?
• Apenas um subsistema em cada maquina ou mais de um?
• Qual o impacto no resto do sistema se agruparmos ou separarmos subsistemas em diferentes nós?

 Propriedades do sistema

• Escala: número de usuários 
• Capacidade: de atender ao um certo número de requisições
• Degradação: como o sistema se comporta (degrada) se a capacidade for ultrapassada
• Desempenho
• Portabilidade

Projeto arquitetural identifica:

• Componentes: definem onde ocorre o processamento;
• Conectores: mediam as interações entre os componentes;
• Propriedades: informações para a construção e análise;

Modelo "4+1" visões arquiteturais

• Visão de projeto ou lógica: estamos interessados em definir a funcionalidade do sistema, vocabulário dos objetos de negócio do sistema
• Visão de implementação ou componentes: definir o gerenciamento da configuração, quais os elementos que vão fazer parte da configuração do sistema. Aqui definimos como fazer o build do sistema.
• Visão de processo: interessados na visão de execução do sistema, nessa etapa que nos preocupamos com as propriedades do sistema (acima). 
• Visão de implantação: mostra como os componentes de software estão mapeados pelos componentes de hardware. (Topologia, distribuição, fornecimento, instalação, etc)
• Visão de caso de uso: diagrama de casos de uso.

A visões são como as diferentes visões de uma casa, como a planta baixa, projeto elétrico, projeto hidráulico, maquete 3D, etc.

Pontos de Variação e Evolução 

• Pontos de Variação: variações previstas nos requisitos do sistema.
• Ponto de evolução: pontos especulativos de variação que podem surgir no futuro mas que não estão presentes nos requisitos existentes.

Passos para fazer análise arquitetural:

• Identificar e analisar os requisitos não-funcionais e funcionais
• Analisar alternativas e criar soluções que resolvam o impacto, documentando as decisões arquiteturais

Fatores arquiteturais

• Segurança
• Como o controle de segurança afeta o projeto do sistema para evitar uso indevido do sistema?
• Confiabilidade, tolerância a falhas
• Como os requisitos de confiabilidade e tolerância a falhas afetam o projeto?
• Custo
• Custo de software de terceiros adquiridos vai afetar os lucros, etc.
• Adaptabilidade, configurabilidade
• Como afetam o projeto?
• Desempenho, capacidade e degradação
• Como afetam o projeto?
• Usabilidade
• Como impacta no projeto?
• Restrições de projeto
• Como as interfaces externas com outros sistemas, o ambiente de desenvolvimento e execução impactarão na solução?
• Restrições de Processo
• Como a documentação exigida, normas e processos a serem seguidos no desenvolvimento vão impactar a arquitetura?

Padrões Arquiteturais

São formas conhecidas para se estruturar um sistema. Se diferem um dos outros nos componentes, nas formas de conexão e formas de se conectar.

Categorias de padrões arquiteturais

• Sistemas de fluxo de dados;
• Disponibilidade dos dados controla a computação;
• Estrutura baseia-se na transferência ordenada de dados entre componentes;
• Não há outra forma de interação entre componentes;
• Variações: Batch sequencial, pipe-e-filtro e padrão de camadas;
• Exemplo: comunicação entre camadas de redes (ISO/OSI)
• Sistemas de chamada-e-retorno;
• Sistema em rede;
• Cliente-servidor: 
• Em geral, clientes iniciam as computações e interagem com usuários. Servidores: executam as computações e provêm recursos.
• P2P
• Componentes executam em máquinas distintas;
• Cada componente age como ambos, cliente e servidor.
• Em geral, existe um servidor centralizado onde os componentes se registram.
• É um padrão resiliente. Tolera a remoção de componentes.

• Sistemas interativos;
• Repositórios;
• Sistemas orientados a serviços;
• Componentes são serviços de organizações possivelmente diferentes (provedores).
• Conectores são XML
• Aplicações que requisitam os serviços, são os consumidores
• Existe um diretório de serviços (banco de dados) onde eles podem ser descobertos
• Requisitante pode ser uma aplicação, web service, mobile, etc.
• Computação nas nuvens
• Funcionalidade é toda através de serviços
• Está fora da empresa que necessita do serviço
• As maquinas são virtualizadas. Configuradas de acordo com a necessidade, como o S.O.
• Os recursos são escaláveis
• Gerenciamento
• Serviços são providos no modelo de pilha
• IaaS: Infra Ex: EC2 (Amazon)
• PaaS: Plataforma Ex: Google AppEngine, MS Azure
• SaaS: Software (Aplicação) Ex: SalesForce

Arquitetura na UML

Voltar no modelo 4+1

• Visão de casos de uso
• É um resumo dos casos de uso mais significativos
• Ilustra a cobertura arquitetural mais significativa
• O caso de uso "Processar Venda" exercita vários elementos arquiteturais, por isso, é interessante detalhar. Podemos incluir realizações, contratos de operação, diagramas de interação.
• Visão lógica ou de projeto
• Mostra a organização conceitual do software, em termos de camadas, subsistemas, pacotes, frameworks, classes importantes.
• É uma visão para o modelo de projeto do RUP
• Visão de implementação ou de componentes
• Inclui os componentes utilizados para montar e entregar o sistema físico
• Um componente de software é uma unidade indivisível de um sistema. Ex: Banco de dados, navegador web.
• Podem ser substituídos por outros componentes que fazem a mesma coisa
• Caixa preta com interface bem definida
• Fornece ou requisita serviços a outros componentes
• Visão de implantação
• Representa a topologia física do sistema e componentes que são executados nessa topologia. Mostra um mapeamento entre elementos de hardware e software.
• Elementos do diagrama são os nós de processamento e conexões.
• Nós: processadores, sensores, etc. (executam software)
• Conexões: meio físicos de comunicação (cabos), ou protocolos (tcp, etc)

Arquitetura na UML

Como representar arquitetura na UML, utiliza os conceitos de:

• Pacotes
• É um mecanismo para agrupar vários artefatos de um modelo
• Podem conter outros pacotes
• Podem existir relacionamentos entre pacotes

• Interfaces 
• É um conjunto de especificações de serviço
• Não contém estrutura interna (diferente de uma classe abstrata)
• Quando uma classe implementa as operações de uma interface, a classe realiza essa interface
• Subsistemas

Projeto Comportamental

Contrato de Operações

• Ajudam a definir o comportamento do sistema, descrevendo o resultado das execuções das operações do sistema
• Objetos de domínio: as classes dão origem aos objetos do sistema, os objetos mudam de estado.

Seções de um contrato

• Operação: nome e parâmetros da operação
• Referências cruzadas: casos de uso nos quais esta operação deve ocorrer
• Pré-condição: hipóteses dignas de nota sobre o estado do sistema. Essas hipóteses não serão testadas na lógica da operação.
• Pós-condição: o estado dos objetos no modelo de domínio, concluída a operação. É importante descrever na mudança de estado: criação ou remoção de instância, criação ou exclusão de associação, alteração de atributo.

Descrever o resultado sem se importar "como".

Quando usar contratos

• É importante utilizar contratos quando existem muitos objetos de domínio que estão sendo criados, modificados, etc. num único passo do caso de uso. 
• É útil usar contratos também quando não é claro quais objetos serão atualizados pela descrição dos casos de uso.
• Não é necessário fazer contratos para toda operação do sistema, em geral, só o caso de uso basta.

Para fazer contratos

• Identifique operações de sistema a partir dos diagramas de sequência de sistema.
• Para operações do sistema que são complexas
• Para descrever as pós condições, use as seguintes categorias:
• Criação e remoção de instância
• Modificação de atributo
• Associação formadas e desfeitas

Responsabilidades, princípios e padrões de projeto

Responsabilidade é um contrato que uma classe tem. Existem dois tipos de responsabilidade:

1. Conhecer dados privados. São derivadas dos atributos dos objetos 
2. Fazer: criar objetos, realizar cálculo, etc. São derivadas dos métodos.

Responsabilidade pode envolver um ou mais métodos de um ou mais objetos.

Interações são trocas de mensagem entre objetos no sistema, e quando se troca mensagens estamos atribuindo responsabilidades a um objeto, já que ocorre a interação de um objeto com outro.

Padrões de Projeto

Padrões de desenvolvimento: expressam uma solução para um determinado problema em um determinado contexto.

Padrões arquiteturais: expressam uma solução num nível mais alto de abstração.

Exemplos de padrão arquitetural:

• Modelo visão-controle: MVC
• Camadas: só se comunica com as camadas adjacentes
• Padrões GRASP
• Controlador
• Coesão alta
• Acoplamento baixo
• Polimorfismo
• Padrões de domínio: o principal foco deve ser o domínio, a logica do domínio.
• Entidades
• Objetos de valor
• Serviços
• Fábricas

Princípios de projeto

Representam um conjunto de diretrizes que ajudam a evitar que um projeto fiquei ruim ou de baixa qualidade. Deve ser evitado nos projetos:

• Rigidez: sistema muito acoplado
• Fragilidade: uma parte para de funcionar quando se faz alteração em outra parte não relacionada.
• Imobilidade: muito difícil ou arriscado separar uma parte da aplicação para ser usada em outro projeto.
• Viscosidade: fazer coisas corretas é mais difícil do que fazer coisas erradas.
• Complexidade desnecessária
• Repetição desnecessária: projeto possui estruturas repetidas que não podem ser unificadas.
• Opacidade: intenção do projeto não está bem expressada.

Deve-se procurar praticar:

• Única responsabilidade
• Manter o controller simples e a lógica deve ficar no domínio 
• Restringir as associações ao máximo, torna o projeto mais claro

Responsabilidades, interações e realizações de casos de uso

Mensagens são utilizadas com objetivo de cumprir as responsabilidades. Uma mensagem indica uma operação existente no objeto receptor.

Construindo diagramas de interação

A maioria dos objetos envolvidos nesse diagrama já foram identificados no diagrama de classe de domínio. Diagrama de interação vai estar consistente com os casos de uso e as classes de domínio.

No ciclo de vida iterativo/incremental os modelos vão evoluindo, então:

Modelo de classes serve como base para o modelo de interações
Mod. Interações ajuda o refinamento do modelo de casos de uso
Mod. Interações ajuda gerar operações para o modelo de classes
Mod. Interações gera novos atributos para o modelo de classes


Exemplo de diagramas de interação de um PDV

Diagrama de Classes de Projeto

Classes de projeto ilustram as especificações para as classes de software e interfaces.
Acontece em paralelo ao diagrama de interação

Criando classes de projeto

• Identificar as classes que fazem parte do diagrama;
• Acrescentar atributos identificados no modelo de domínio;
• Acrescentar operações (analisando o diagrama de interação);

Visibilidade entre objetos

É a habilidade de um objeto ver ou ter referência a outro objeto.

• Visibilidade por atributo
• Existe de A pra B quando B é um atributo de A
• Visibilidade por parâmetro
• Existe de A pra B quando B é passado como parâmetro para um método de A
• Visibilidade local
• Existe quando B é declarado como um objeto local dentro de um método de A
• Visibilidade global
• Existe quando B é declarado como um objeto global em A

Navegabilidade é a propriedade do papel que indica que é possível navegar unidirecionalmente por meio da associação de objetos da classe de origem para objetos da classe alvo. (Seta nos diagramas de classe para ligar duas classes)

Diagrama de transição de estados 

Esses diagramas são uma complementação para modelagem comportamental.

Estado

• Estado é uma situação na vida de um objeto em determinado momento no tempo em que ele satisfaz a alguma condição ou realiza alguma atividade.
• Cada estado é determinado pelos valores dos atributos ou pela ligações com outros objetos.
• Em geral, possui um único estado inicial pode ou não possuir estados finais.

Evento

• Uma transição possui um evento associado
• Um evento é algo que acontece em algum ponto do tempo e que pode modificar o estado de um objeto. Ex. Pedido Realizado, Fatura paga, Cheque devolvido, etc.
• Condição de Guarda é uma espécie de "If" que valida se a transição vai ocorrer quando for disparada por um evento.

Ações

• Ações são tudo que um objeto realiza quando transita de um estado para outro.
• É expressa em termos de atributos, operações, associações da classe, etc. 
• Está associada sempre a uma transição. E é executada somente se uma transição for disparada.

Objetos dependentes de estado

Os diagramas de estado devem ser criados para objetos dependentes de estados, ou seja, objetos que reagem diferente dependendo de seu estado.

Tipos

Existem dois tipos de objetos dependentes de estado:

• Objetos Reativos: 
• Complexos: telefone, carro, microondas, elevador
• Transações ou objetos de negócio: venda, pedido, pagamento reagem a eventos como cancelar, adiar, faturar, etc.
• Protocolos de comunicação
• Fluxos de navegação de pagina, janela, menu, interface com usuário
• Controlador de sessão de um fluxo de interface em páginas web, guarda o estado da sessão no cliente web e dependendo desse estado ele reage diferente.

• Sequências de operações: as operações que chegam ao sistema tem que chegar numa determinada ordem de estados. Para definir essa ordem, usamos o diagrama de estados. Ex. Estados: EsperandoPorVenda -> EntrandoItens -> EsperandoPagamento -> AutorizandoPagamento.

Projeto de Sistemas: Introdução e Contextualização

Objetivos do projeto de software:

• Definir um modelo implementável que atenda aos requisitos
• Garantir que todos os requisitos sejam satisfeitos

Atividades de projeto

• Projeto da arquitetura do sistema
• Decomposição em componentes
• Definição da interface entre eles
• Projeto das interfaces do sistema
• com usuário
• com outros sistemas
• Projeto detalhado comportamental
• Projeto dos objetos e suas interações
• Projeto da persistência de dados
• Documentação do projeto

Avaliação do projeto (considerar a qualidade do projeto)

• Determina se o projeto satisfaz os requisitos do sistema
• Importante verificar se todos os requisitos foram considerados
• Como o projeto atende/satisfaz um requisito
• Determina se o projeto pode ser entendido pelos implementadores e testadores do sistema

Diagramas que contemplam a etapa de projeto 

• Casos de uso
• Diagrama
• Especificação do caso de uso
• Diagrama de Classes
• Diagrama de Sequencia
• Superficial (ainda na analise)
• Detalhado
• Diagrama de Componentes (projeto arquitetural)
• Diagrama de Implantação

Princípios de Projeto

• Considerar diversas abordagens (soluções candidatas) que atenda um requisito e outro
• Precisa ser rastreável entre os elementos de análise e os elementos de projeto
• Utilizar padrões ao invés de reinventar a roda
• Projeto precisa minimizar a distância entre o software e o mundo real (projeto que conecta os dois mundos)
• Precisa ser estruturado para acomodar mudanças. É certo que o software vai mudar!
• Precisa ser avaliado quanto a sua qualidade em cada etapa

Conceitos de Projeto

1. Abstração: sistema nasce num nível alto e desce até o código
2. Refinamento: elaboração maior do nível de detalhes (complementar da abstração)
3. Modularização: sistemas divididos em componentes
4. Ocultação de Informações: sugere que cada módulo deve conter decisões de projeto. Modulo publica na interface só o que importa. Deve conter um segredo.

Projetos de Software no RUP

Princípios essenciais do RUP

• -> Atacar os riscos de forma rápida e contínua
• Garantir que se está provendo algo de valor ao cliente
• -> Concentrar-se em produzir software executável
• -> Acomodar mudanças no projeto
• -> Definir a arquitetura o mais cedo possível
• -> Construir o sistema com componentes
• Trabalhar em equipe
• Fazer da qualidade uma forma de vida

-> Impactam na etapa de projeto do sistema

• Atacar os riscos: RUP prega que devemos atacar primeiro os problemas que apresentam o maior risco para o sucesso do projeto. É diferente do modelo em cascata nesse ponto. É preciso testar a arquitetura logo no inicio do projeto através de protótipos arquiteturais.
• Construir o sistema com componentes: Componentes separam a interface da implementação. Possibilita a reutilização de partes. Reduz o impacto de mudanças.
• Desenvolvimento iterativo e incremental
• Fases e atividades do RUP
• Concepção: entender o escopo e construir o caso de negócio
• Objetivos:
• Compreender o que construir
• Identificar funcionalidades chave
• Determinar ao menos uma solução possível 
• Custos, prazos, riscos, qual processo, qual ferramentas
• Decidir se deve continuar ou cancelar
• Elaboração: reduzir os riscos técnicos, criar a arquitetura do sistema
• Tem uma ou mais iterações, na primeira: Identificar cenários críticos, criar protótipos para testar esses cenários, fazer o projeto inicial do BD, detalhar os casos de uso de maior prioridade, validar arquitetura. Na segunda iteração, consertar problemas da primeira iteração, fechar projeto do BD, detalhar os casos de uso restantes, garantir que a arquitetura está estável.
• Objetivos:
• Detalhar os requisitos
• Projetar, implementar e validar arquitetura
• Mitigar os riscos principais
• Revisar estimativas de prazo e custo
• Refinar o processo
• Implantar ferramentas
• Construção: construir versão operacional do sistema
• Transição: construir versão final do produto e entregar o cliente
• Marcos: ao final de cada fase há marcos. 

Arquitetura

Para projetar a arquitetura:

• Componentes do sistema e suas interfaces
• Decidir se cada componente será desenvolvido, reutilizado, comprado
• Definir como os componentes vão interagir

Implementação

• Criar protótipo arquitetural para validar a arquitetura
• Projetar casos de uso críticos 
• Consolidar e empacotar classes
• Garantir uma cobertura arquitetural
• Projetar BD
• Identificar padrões
• Delinear aspectos de concorrência e distribuição
• Implementar cenários críticos
• Integrar componentes
• Testar cenários mais críticos

Protótipo arquitetural

A arquitetura é definida com base nos casos de uso mais significativos. Para se fazer um protótipo que represente bem a arquitetura do sistema, deve-se selecionar os casos de uso mais significativos pro sistema e desenvolver o protótipo em cima desses casos de uso.

Cobertura arquitetural

Garante que todos os elementos arquiteturais sejam cobertos através de um caso de uso.

Validação arquitetura

Protótipo arquitetural tem que exibir as características adequadas.

Diagramas de Interação

Diagrama de Sequencia do Sistema - DSS

• Ilustram as interações dos atores com o sistema
• As operações iniciadas por eles
• As respostas do sistema
• É uma figura que mostra os eventos que os atores geram e a ordem que eles acontecem.
• Deve ser feito um diagrama para a sequencia de sucesso e para cenários alternativos

Modelagem Estrutural: Diz respeitos de componentes que vão compor o sistema.

Modelagem Comportamental: Ajuda projetar a lógica, comportamento do código, corpo dos métodos.

Dois tipos de diagramas de interação:

• Diagrama de sequência: foi visto no vídeo
• Diagrama de comunicação: apresentam as mensagens enfatizando relacionamentos.

Ambos são equivalentes.