capítulo 7 conceção e implementação - ubisebastiao/ensino/ubi/2017-2018/es/teoricas... ·...

Capítulo 7 – Conceção e Implementação

Capítulo 7 Conceção e Implementação 12017/2018

Assuntos abordados

Design orientado a objetos com recurso ao UML

Padrões de design

Questões de implementação

Desenvolvimento de código aberto

Capítulo 7 Concepção e Implementação 22017/2018

Design e implementação

Design e implementação de software é a fase do

processo de engenharia de software em que um sistema

de software executável é desenvolvido.

Atividades de design e implementação de software são

invariavelmente intercaladas.

Design de software é uma atividade criativa em que você

identifica os componentes de software e suas relações, com

base nos requisitos do cliente.

A implementação é o processo de realização do projeto como

um programa executável.


Construir ou comprar

Em vários domínios, é agora possível comprar software

que pode ser parameterizado e adaptado às

necessidades dos utilizadores.

Por exemplo, para se implementar um sistema de registos

médicos, pode-se comprar um pacote que já é usado em

hospitais. Pode ser mais barato e mais rápido usar essa

abordagem em vez de desenvolver um sistema numa linguagem

de programação convencional.

Quando se desenvolve uma aplicação, o processo de

design preocupa-se com a forma de utilizar os recursos

de configuração desse sistema para entregar os

requisitos do sistema.


Design orientado a objetos com recurso ao UML


Processo de design orientado ao objeto

Os processos de design orientado a objetos envolvem odesenvolvimento de vários modelos de sistemas.

Exigem um grande esforço para o desenvolvimento emanutenção destes modelos e, para pequenossistemas, isso pode não ser rentável.

No entanto, para grandes sistemas, desenvolvidos pordiferentes grupos, modelos de design são ummecanismos importante de comunicação.


Etapas do processo

Há uma variedade de diferentes processos de design

orientados a objetos.

Atividades comuns nestes processos incluem:

Definir o contexto e modos de utilização do sistema;

Projetar a arquitetura do sistema;

Identificar os principais objetos do sistema;

Desenvolver modelos de design;

Especificar interfaces de objetos.


Contexto do sistema e as interações

Compreender as relações entre o software que está a

ser projetado e o seu ambiente externo é essencial para

decidir como fornecer as funcionalidades necessárias do

sistema e como estruturar o sistema para se comunicar

com o seu ambiente.

Compreensão do contexto permite também estabelecer

os limites do sistema. Definir os limites do sistema ajuda

a decidir quais os recursos que são implementados no

sistema que está a ser desenhado e que recursos estão

em outros sistemas associados.


Modelos de contexto e interação

Um modelo de contexto do sistema é um modelo

estrutural que demonstra os outros sistemas no

ambiente do sistema que está a ser desenvolvido.

Um modelo de interação é um modelo dinâmico que

mostra como o sistema interage com o seu ambiente,

como ele é usado.


Sistema contexto para a estação de

metereologia


Casos de uso da estação meteorológica


Descrição do caso de uso Weather Report

Sistema Estação meteorológica

Caso de uso Boletim meteorológico

Atores Sistema de informação metereológica, Estação meteorológica

Descrição A estação meteorológica envia um resumo dos dados meteorológicos que foram recolhidos, para o sistema de informações meteorológicas. Os dados enviados são a temperatura, a pressão do ar, a velocidade do vento, a precipitação e a direcção do vento com intervalos de cinco minutos.

Estímulo O sistema de informação metereológica estabelece um link de comunicação via satélite com a estação meteorológica e solicita a transmissão dos dados.

Resposta Os dados resumidos são enviados para o sistema de informações meteorológicas.

Comentários Estações meteorológicas são normalmente solicitados a relatar uma vez por hora, mas essa freqüência pode diferir de uma estação para outra e pode ser modificado no futuro.


Projeto arquitetónico

Uma vez que as interações entre o sistema e o seu

ambiente ter sido compreendido, pode-se usar esta

informação para projetar a arquitetura do sistema.

Identificar os principais componentes que compõem o

sistema e as suas interações, e, em seguida, pode

organizar os componentes usando um padrão de

arquitetura, tais como um modelo em camadas ou

cliente-servidor.

A estação meteorológica é composto por subsistemas

independentes que se comunicam pela transmissão de

mensagens numa infra-estrutura comum.


Arquitetura alto-nível da estação meteorológica


Arquitetura do sistema de recolha de dados


Identificação da classe de objeto

Identificar classes de objetos é muitas vezes uma tarefa

difícil, parte do projeto orientado a objetos.

Não há 'fórmula mágica' para a identificação de objetos.

Baseia-se na habilidade, experiência

e conhecimento de domínio dos projetistas de sistemas.

Identificação de objetos é um processo iterativo. É

improvável que se obtenha correto na primeira vez.


Abordagens para a identificação

Usar uma abordagem gramatical baseada numa

descrição do sistema em linguagem natural.

Basear a identificação em coisas tangíveis no domínio

do aplicativo.

Usar uma abordagem comportamental e identificar

objetos com base no que participa o comportamento.

Usar uma análise baseada em cenários. Os objetos,

atributos e métodos em cada cenário são identificados.


Classes de objeto da estação meteorológica

Identificação das classe de objeto no sistema da

estação meteorológica, pode ser baseada no hardware

tangível e nos dados do sistema:

Termómetro, anemómetro, entre outros

• Objetos de domínio da aplicação que são objetos 'hardware'

relacionados com os instrumentos do sistema.

Estação meteorológica

• A interface básica da estação meteorológica com seu ambiente.

Reflete as interações identificadas no modelo de caso de uso.

Dados meteorológicos

• Encapsula os dados recolhidos pelos instrumentos.


Modelos de design

Modelos de design mostram os objetos, classes de

objetos e relações entre estas entidades.

Existem dois tipos de modelo de design:

Os modelos estruturais descrever a estrutura estática do

sistema em termos de classes de objetos e as suas relações.

Modelos dinâmicos descrevem as interações dinâmicas entre

objetos.


Exemplos de modelos de design

Modelos de subsistemas que mostram os agrupamentos

lógicos de objetos em subsistemas coerentes.

Modelos de sequência que mostram a sequência de

interações dos objetos.

Modelos de máquina de estado que mostram como

objetos individuais mudam o seu estado em resposta a

eventos.

Outros modelos incluem modelos de caso de uso,

modelos de agregação, modelos de generalização, etc.


Modelos de subsistema

Mostra como o projeto está organizado em grupos de

objetos logicamente relacionados.

Em UML, estes são mostrados usando pacotes. Este é

um modelo lógico. A organização real dos objetos no

sistema podem ser diferentes.


Modelos de sequência

Modelos de sequência mostram a sequência deinterações dos objetos

Os objetos são dispostas horizontalmente na parte superior;

O tempo é representado verticalmente para e são lidos de cimapara baixo;

Interações estão representadas por setas, diferentes estilos deseta representam diferentes tipos de interação;

Um retângulo representa o momento em que o objeto é o objetode controlo no sistema.


Diagram de sequência que descreve a recolha

de dados


Diagramas de estado

Diagramas de estado são usados para saber como osobjetos respondem a diferentes solicitações de serviço eàs transições de estado desencadeadas por estassolicitações.

Diagramas de estado são modelos de alto nível de umsistema ou o comportamento de tempo de execução deum objeto.

Normalmente não precisa de um diagrama de estadopara todos os objetos no sistema. Muitos dos objetosnum sistema são relativamente simples e um modelo deestado acrescenta detalhes desnecessários ao design.


Diagrama de estados da estação metereológica


Especificação de interface

Interfaces de objetos precisam ser especificados para

que os objetos e outros componentes possam ser

projetados em paralelo.

Designers devem evitar projetar a representação da

interface, deve-se esconder isso no próprio objeto.

Os objetos podem ter diversas interfaces que são

pontos de vista sobre os métodos fornecidos.

Em UML usa-se o diagrama de classes para a

especificação da interface.


Interfaces da estação metereológica


Padrões de design


Padrões de design

Um padrão de design é uma maneira de reutilizar o

conhecimento abstrato sobre um problema e a sua

solução.

Um padrão é uma descrição do problema e a essência

da sua solução.

Deve ser suficientemente abstrato para ser reutilizado

em diferentes contextos.

Descrições padrão costumam fazer uso de

características orientadas a objetos, tais como herança

e polimorfismo.


Patterns

Padrões e linguagens de padrões são formas de

descrever as melhores práticas, bons projetos e

experiência de captura de uma forma que é possível

para os outros reutilizar essa experiência.


Elementos do padrão teste

Nome

Um identificador padrão significativo.

Descrição do Problema.

Descrição da solução.

Não é um projeto concreto, mas um modelo para uma solução

de design que pode ser instanciado em maneiras diferentes.

Consequências

Os resultados e as compensações de aplicação do padrão.


O padrão observador

Nome

Observador.

Descrição

Separa a exibição de estado do objeto a partir do próprio objeto.

Descrição do Problema

Usado quando são necessários vários monitores de estado.

Descrição da solução

Veja slide com descrição UML.

Consequências

Otimizações para melhorar o desempenho de exibição sãoimpraticáveis.


Vários monitores usando o padrão Observer


Problemas de design

Para usar padrões num projeto, precisa-se reconhecer

que qualquer problema de design pode ter um padrão

associado que pode ser aplicado.

Vários objetos que o estado de algum outro objeto foi alterado.

Arrumar as interfaces para uma série de objetos relacionados

que foram muitas vezes desenvolvidas de forma incrementa.

Fornecer uma maneira padrão de acessar os elementos em

uma coleção, independentemente de como essa coleção é

implementada.

Permitir a possibilidade de estender a funcionalidade de uma

classe existente no tempo de execução.


Problemas de implementação


Problemas de implementação

Foco aqui não é sobre a programação, embora este é, obviamente,

importante, mas em outras questões de implementação que muitas

vezes não são abordados em programação:

Reuso A maioria do software moderno é construído através da

reutilização de componentes ou sistemas existentes. Quando se está a

desenvolver um software, deve-se fazer o máximo uso possível de

código existente.

Gestão de configurações Durante o processo de desenvolvimento, tem

que se manter a par das muitas versões diferentes de cada

componente de software num sistema de gestão de configuração.

Desenvolvimento O software de produção não costuma executar no

mesmo computador como o ambiente de desenvolvimento de software.

Em vez disso, desenvolve-se num computador (o sistema host) e

executa-se num computador separado (sistema de destino).


Reuso

A partir dos anos 1960 aos anos 1990, a maioria dos novos

software foi desenvolvido a partir do zero, escrito todo o

código em uma linguagem de programação de alto nível.

A única reutilização significativa foi a reutilização de funções e

objetos em bibliotecas de linguagem de programação.

Custos e pressão de cronograma, significa que esta

abordagem tornou-se cada vez mais inviável, especialmente

para sistemas comerciais e baseados na Internet.

Uma abordagem ao desenvolvimento baseada em torno da

reutilização de software existente é geralmente usado para

software de negócios e software científico.


Níveis de reutilização

O nível de abstração

Neste nível, não se reutiliza software diretamente, mas usar o

conhecimento de abstrações na concepção do software.

O nível do objecto

Neste nível, reutiliza-se diretamente objetos de uma biblioteca,

em vez de escrever o código.

O nível de componente

Os componentes são coleções de objetos e classes de objetos

que se reutiliza em sistemas de aplicação.

O nível de sistema

Neste nível, reutiliza-se sistemas de aplicação inteiros.


Reuso de software


Custos de reutilização

Os custos do tempo gasto na procura de software para

reutilizar e avaliar se é viável ou não às necessidades.

Quando aplicável, os custos de aquisição do software

reutilizáveis. Para grandes sistemas off-the-shelf, estes

custos podem ser muito elevados.

Os custos de adaptação e configuração dos componentes ou

sistemas de software reutilizáveis para refletir os requisitos do

sistema que se está a desenvolver.

Os custos de integração de elementos de software

reutilizáveis uns com os outros (se estiver s usar software de

diferentes fontes) e com o novo código que se desenvolveu.


Gestão de configurações

Gestão de configuração é o nome dado ao processo

geral de gestão das mudanças de um sistema de

software.

O objetivo da gestão de configuração é apoiar o

processo de integração do sistema de modo a que todos

os programadores possam acessar ao código e

documentos do projeto de uma forma controlada,

descobrir que mudanças foram feitas, e compilar

componentes de ligação para criar um sistema.


Atividades de gestão de configuração

Gestão de versões, onde se acompanha as diferentes

versões de componentes de software. Sistemas de gestão de

versões incluem instalações para coordenar o

desenvolvimento de vários programadores.

Integração de sistemas, onde os programadores a definem as

versões de componentes que vão usar para criar cada versão

do sistema.

Acompanhamento de problemas, onde permite aos

utilizadores reportar bugs e outros problemas, para permitir

que os programadores os resolvam.


Interação ferramenta de gestão de configuração


Desenvolvimento Host-Target

A maioria dos softwares é desenvolvido num computador

(host), mas é executado numa máquina separada (o alvo).

De modo mais geral, podemos falar de uma plataforma de

desenvolvimento e uma plataforma de execução.

A plataforma é mais do que apenas hardware.

Inclui o sistema operacional instalado além de outros softwares

de suporte, como um sistema de gestão de base de dados ou,

para plataformas de desenvolvimento, um ambiente de

desenvolvimento interativo.

Plataforma de desenvolvimento tem geralmente software

instalado diferente da plataforma de execução; essas

plataformas podem ter diferentes arquiteturas.


Desenvolvimento Host-Target


Ferramentas para a plataforma de

desenvolvimento

Um compilador integrado e sistema de edição dirigida pela

sintaxe que permite criar, editar e compilar o código.

Um sistema de linguagem de depuração.

Ferramentas de edição de gráficos, como ferramentas para

editar modelos UML.

Ferramentas de teste, tais como jUnit que pode executar

automaticamente uma série de testes numa nova versão

de um programa.

Ferramentas de apoio ao projeto que ajudam a organizar o

código para diferentes projectos de desenvolvimento.


Ambientes de desenvolvimento integrado (IDEs)

Ferramentas de desenvolvimento de software muitas

vezes são agrupados para criar um ambiente de

desenvolvimento integrado (IDE).

Um IDE é um conjunto de ferramentas de software que

suporta diferentes aspectos do desenvolvimento de

software, dentro de algum quadro comum e interface de

utilizador.

IDEs são criados para apoiar o desenvolvimento de uma

linguagem de programação específica, como Java.


Componentes de implantação do sistema

Se um componente é projetado para uma arquitetura de hardware

específico, ou se baseia em algum outro sistema de software, deve,

obviamente, ser implantado numa plataforma que fornece o suporte

de hardware e software necessários.

Sistemas de alta disponibilidade podem exigir componentes para

ser implantado em mais do que uma plataforma. Isto significa que,

em caso de falha da plataforma, uma implementação alternativa do

componente está disponível.

Se houver um alto nível de tráfego de comunicações entre os

componentes, normalmente faz sentido implantá-los na mesma

plataforma ou em plataformas que estão fisicamente próximos uma

das outras. Isso reduz o atraso entre o tempo que uma mensagem

é enviada por um componente e recebida por outra.



Desenvolvimento de código aberto é uma abordagem para o

desenvolvimento de software no qual o código fonte de um sistema

de software é publicado e os voluntários são convidados a participar

no processo de desenvolvimento

Suas raízes estão na Free Software Foundation (www.fsf.org), Que

defende que o código fonte não deve ser proprietário, mas sim deve

estar sempre disponível para os utilizadores o examinarem e

modificarem como desejarem.

Software de código aberto estendeu essa ideia usando a Internet

para recrutar uma população muito maior de programadores

voluntários. Muitos deles também são utilizadores do código.


Sistemas de código aberto

O produto de código aberto mais conhecido é, claro, o

sistema operacional Linux, que é amplamente usado

como um sistema de servidor e, cada vez mais, como

um ambiente desktop.

Outros produtos open source importantes são o Java, o

servidor web Apache e o mySQL Sistema de Gestão de

Base de Dados.


Negócios de fonte aberta

Mais e mais empresas de produtos estão a usar uma

abordagem de código aberto para o desenvolvimento.

O seu modelo de negócio não é dependente da venda

de um produto de software, mas na venda de suporte

para esse produto.

Elas acreditam que o envolvimento da comunidade de

código aberto irá permitir que o software seja

desenvolvido de forma mais barata, mais rápida e vai

criar uma comunidade de utilizadores para o software.


Licenciamento de fonte aberta

Um princípio fundamental do desenvolvimento de código aberto é

que o código fonte deve ser livremente disponíveis, isso não

significa que qualquer um pode fazer o que quiserem com esse

código.

Legalmente, o programador do código (seja uma empresa ou um

indivíduo) ainda possui o código. Eles podem colocar restrições em

como ele é usado, incluindo condições juridicamente vinculativos em

uma licença de software de código aberto.

Alguns programadores de código aberto acreditam que, se um

componente de código aberto é usado para desenvolver um novo

Sistema em seguida, que o sistema também deve ser de código aberto.

Outros estão dispostos a permitir que o seu código seja usado sem

essa restrição. Os sistemas desenvolvidos podem ser proprietários e

vendidos como sistemas de código fechado.


Modelos de licença

O GNU General Public License (GPL). Esta é uma chamada

de licença 'recíproco' que significa que se usar o software de

código aberto que está licenciado sob a licença GPL, então

deve fazer esse software fonte aberta.

O GNU Lesser General Public License (LGPL) é uma variante

da licença GPL, onde se pode escrever componentes que

apontam para abrir o código-fonte sem ter que publicar a

origem desses componentes.

Distribuição Berkley Padrão (BSD) License. Esta é uma

licença não recíproca, o que significa que não são obrigados

a voltar a publicar quaisquer alterações ou modificações

feitas para abrir o código-fonte. Você pode incluir o código em

sistemas proprietários que são vendidos.


Gestão de licenças

Estabelecer um sistema para manter as informações sobre os

componentes de código aberto que são baixados e usados.

Estar ciente dos diferentes tipos de licenças e compreender

como um componente é licenciado antes de ser usado.

Estar ciente dos caminhos de evolução para os

componentes.

Educar as pessoas sobre código aberto.

Têm sistemas de auditoria no local.

Participar da comunidade open source.


Pontos chave

O processo de concepção orientada para o objecto inclui

actividades como conceber a arquitectura do sistema, identificar

objectos no sistema, descrever a concepção utilizando diferentes

modelos de objecto e documentar as interfaces de componentes.

Uma gama de diferentes modelos podem ser produzidos durante

um processo de concepção orientada por objectos. Estes incluem

modelos estáticos (modelos de classe, modelos de generalização,

modelos de associação) e modelos dinâmicos (modelos de

sequência, modelos de máquinas de estado).

Interfaces de componentes deve ser definido com precisão para

que outros objetos possam usá-los.


Pontos chave

Ao desenvolver software, deve-se sempre considerar a

possibilidade de reutilizar software existente, quer como

componentes, serviços ou sistemas completos.

Gestão de configuração é o processo de gerir mudanças para um

sistema de software em evolução. É essencial quando uma equipa

de pessoas estão a cooperar para desenvolver software.

A maioria de desenvolvimento de software é o desenvolvimento

host-target. Usa-se um IDE em uma máquina host para desenvolver

o software, que é transferida para uma máquina de destino para

execução.

Desenvolvimento de código aberto envolve fazer o código fonte de

um sistema acessível ao público. Isso significa que muitas pessoas

podem propor alterações e melhorias no software.


capítulo 7 conceção e implementação - ubisebastiao/ensino/ubi/2017-2018/es/teoricas... ·...

Documents