Professor Mário Dantas

Professor Mário DantasSet/2010

ENGENHARIA DE SOFTWARE

2

Aula 04- Agenda Princípios e conceitos de análise e

projeto;

3

Durante as últimas décadas, um grande número de métodos de modelagem de análise foi desenvolvido. Pesquisadores identificaram problemas de análise e suas causas, e desenvolveram uma variedade de notações de modelagem e conjuntos de heuríticas correspondentes para resolve-los. Cada método de análise tem um ponto de vista singular. No entanto, todos os métodos de análise estão relacionados a um conjunto de princípios operacionais (PRESSMAN, 2006).

MODELAGEM DE ANÁLISE

4

O que é?

A modelagem da análise usa uma combinação de formas textuais e diagramáticas para mostrar os requisitos de dados, função e comportamento, de modo que seja relativamente fácil de entender e revisar o sistema.

5

Quem faz?

Um engenheiro de software (ou analista) constrói um modelo usando requisitos extraídos do cliente.

6

Por que é importante?

Por representar os requisitos de várias maneiras, aumentando a chance de serem encontrados erros, inconsistências e que omissões sejam descobertas.

7

Qual é o produto do trabalho?

Uma variedade de formas diagramáticas podem ser escolhidas para o modelo de análise. Cada uma fornece uma visão de um ou mais elementos do modelo.

8

Como tenho certeza de que fiz corretamente?

Revisados quanto à correção, completeza e consistência.

Devem refletir as necessidades dos interessados e estabelecer um fundamento com base na qual o projeto pode ser conduzido.

9

Princípios da Modelagem de Análise

O domínio da informação de um problema deve ser representado e entendido;

As funções a serem desenvolvidas pelo software devem ser definidas;

O comportamento do software (como conseqüência de eventos externos) precisa ser representado.

O modelos que mostram informações, funções e comportamento devem ser particionados de um modo que revele detalhes em forma de camadas (ou hierarquias);

A tarefa de análise deve ir da informação mais essencial até os detalhes de implementação.

10

Conjunto genérico de Tarefas para modelagem de Análise

Revisar os requisitos de negócio, as características/necessidades dos usuários, as saídas visíveis ao usuário, as restrições do negócio e outros requisitos técnicos que foram determinados durante a atividade de comunicação com o cliente e o planejamento.

11

Conjunto genérico de Tarefas para modelagem de Análise

Expandir e refinar os cenários do usuário. Definir todos os atores; Representar como os atores interagem com

o software. Extrair funções e características dos

cenários de usuário. Revisar o cenário do usuário quanto à

completude e precisão.

12

Conjunto genérico de Tarefas para modelagem de Análise

Modelar o domínio da informação. Representar todos os principais objetos de

informação; Definir atributos para cada objeto de

informação; Representar os relacionamentos entre os

objetos de informação.

13

Conjunto genérico de Tarefas para modelagem de Análise

Modelar o domínio funcional. Mostrar como as funções modificam os

objetos de dados; Refinar funções para fornecer detalhes de

elaboração; Escrever um narrativa de processamento

que descreva cada função e subfunção; Revisar os modelos funcionais.

14

Conjunto genérico de Tarefas para modelagem de Análise

Modelar o domínio comportamental. Identificar os eventos externos que causam

mudanças comportamentais no sistema; Identificar os estados que representam

cada modo de comportamento observável externamente;

Mostrar como o evento faz o sistema se mover de um estado para outro;

Revisar os modelos comportamentais.

15

Conjunto genérico de Tarefas para modelagem de Análise

Analisar e modelar a interface do usuário. Conduzir tarefa de análise; Criar protótipos de imagem de tela;

Revisar todo os modelos quanto à completude, consistência e omissões.

16

O modelo de análise deve:

Descrever o que o cliente exige Estabelecer a base para a criação de um

projeto de software Definir um conjunto de requisitos que possam

ser validados quando o software for construído

17

Regras práticas de Análise O nível de abstração deve ser relativamente

alto. Adie a consideração de modelos de infra-

estrutura e outros não funcionais até o projeto. Minimize o acoplamento ao longo de todo o

sistema Certifique-se de que o modelo de análise tem

valor para todos os interessados Mantenha o modelo tão simples quanto puder

18

Análise de Domínio

É a identificação, análise e especificação dos requisitos comuns de um domínio de aplicação específico.

Sua meta é encontrar ou criar classes de análise e/ou as funções e características que são amplamente aplicáveis, de modo que possam ser reutilizadas.

19

Abordagens de Modelagem de Análise

Elementos baseados em cenários Elementos baseados em classes Elementos comportamentais Elementos orientados a fluxos

20

Atividade 002

4 grupos para apresentar as abordagens de modelagem de análise

Data: 15/09/2010

21 Projeto de Software

22

Objetivos

Conhecer os conceitos relacionados ao projeto de software, bem como sua aplicação;

Saber quais decisões devem ser tomadas sobre a arquitetura de sistema durante o processo de projeto de arquitetura.

23

Projeto de Software

Engloba um conjunto de princípios, conceitos e práticas que levam ao desenvolvimento de um sistema ou produto de alta qualidade.

Seu objetivo é produzir um modelo ou representação que exiba firmeza, comodidade e prazer, ou seja, que satisfaça aos requisitos do sistema.

24

O que é?

O projeto cria uma representação ou modelo de software, mas diferente do modelo de análise (que enfoca a descrição dos dados, função e comportamento requeridos).

O modelo de projeto fornece detalhe sobre as estruturas de dados, arquitetura, interfaces e componentes do software necessários para implementar o sistema.

Projeto de Software

25

Quem faz? Engenheiros de software conduzem cada uma das

tarefas de projeto.

Por que é importante? Permite ao engenheiro de software modelar o

sistema ou produto que deve ser construído. Esse modelo pode ser avaliado quanto à qualidade e aperfeiçoado antes que o código seja gerado, testes sejam conduzidos e usuários finais fiquem envolvidos em grande número.

Projeto de Software

26

Atividades de projeto

27

Atividades de projeto Projeto da Arquitetura do Software� :

visa a definir os grandes componentes estruturais do software e seus relacionamentos.

�Projeto de Dados: tem por objetivo projetar a estrutura de armazenamento de

dados necessária para implementar o software. Projeto de Interfaces:

descreve como o software deverá se comunicar dentro dele mesmo (interfaces internas), com outros sistemas (interfaces externas) e com pessoas que o utilizam (interface com o usuário).

Projeto Procedimental Detalhado: tem por objetivo refinar e detalhar a descrição procedimental

dos componentes estruturais da arquitetura do software.

28

Princípios da Modelagem de Projeto

O projeto deve estar relacionado ao modelo de análise;

Sempre considere a arquitetura do sistema a ser construído;

O projeto dos dados é tão importante quanto o projeto de funções de processamento;

As interfaces (tanto externas quanto internas) precisam ser projetadas como cuidado.

O projeto de interface do usuário deve estar sintonizado com as necessidades do usuário final. No entanto, em cada caso, ele deve enfatizar a facilidade de uso.

29

Princípios da Modelagem de Projeto

O projeto a nível de componente deve ser funcionalmente independente;

Os componentes devem ser fracamente acoplados uns aos outros e ao ambiente externo.

Representações de projeto (modelos) devem ser facilmente compreensíveis.

O projeto de ser desenvolvido iterativamente. A cada iteração, o projetista deve lutar por maior simplicidade.

30

Conjunto genérico de tarefas para o Projeto

Usando o modelo de análise, selecionar um estilo (padrão) arquitetural que seja apropriado para o software.

31

Conjunto genérico de tarefas para o Projeto

Particionar o modelo de análise em subsistemas de projeto e alocar esses subsistemas na arquitetura. Certifica-se de que cada subsistema seja

funcionalmente coesivo. Projetar as interfaces dos subsistemas. Alocar classes ou funções de análise a cada

subsistema. Usando o modelo de domínio de

informação, projetar as estruturas de dados adequadas.

32

Conjunto genérico de tarefas para o Projeto

Projetar as interfaces do usuário. Rever os resultados das análises de tarefas. Especificar a seqüência de ações com base

nos cenário dos usuários. Criar o modelo comportamental da

interface. Definir objetos de interface e mecanismos

de controle. Rever o projeto de interface e revisar

conforme a necessidade.

33

Conjunto genérico de tarefas para o Projeto

Conduzir o projeto em nível de componentes. Especificar todos os algoritmos em um nível

de abstração relativamente baixo. Refinar a interface de cada componente. Definir a estrutura de dados em nível de

componente. Rever o projeto em nível de componente

Desenvolver um modelo de implantação.

34

Qual é o produto do trabalho? Um modelo de projeto que inclui representações de

arquitetura, interface, componente e implantação.

Como tenho certeza de que fiz corretamente? O modelo de projeto é avaliado pela equipe de

software em um esforço para determinar se contém erros, inconsistências ou omissões; se existem alternativas melhores e se o modelo pode ser implementado dentro das restrições, cronograma e custo que foram estabelecidos.

Projeto de Software

35

Projeto de SoftwareObjetivo: produzir um modelo que satisfaça ao requisitos.

Evolução contínua à medida que a análise se aperfeiçoa e entendimento amplia.

36

Projeto serve de base para todas as etapas da Engenharia de Software

Projeto é necessário? Sem projeto, como modificar, testar e avaliar a qualidade?

Permite avaliar a qualidade antes de implementar

Projeto de Software

37

Abstração: visão de alto nível dos aspectos fundamentais do

sistema, de maneira que obtenha-se uma ocultação dos detalhes.

Arquitetura: organização dos componentes de programas, suas

interações e as estruturas usadas pelos componentes. Padrões:

descreve uma estrutura para resolver um determinado problema.

Conceitos de Projeto

38

Modularização Módulos são integrados com o objetivo de

atender a um requisito “Dividir e conquistar”

39

Por que modularizar? Planejar mais fácil Manutenção Testes e depuração Ocultação de Informações Módulos devem ser especificados e

projetados de tal modo que informações desnecessárias sejam inacessíveis

Apenas o necessário é fornecido para a realização de funções

Abstração + ocultação (erros não são propagados nas modificações)

40

Independência FuncionalModularidade + abstração + ocultação = Independência

Funcional

“Finalidade única” e menos interação Interfaces simplificadas Manutenção mais fácil Propagação de erros minimizada Reutilização

Dois critérios (qualitativos) para avaliação COESÃO: robustez funcional de um módulo (módulo

realiza uma única tarefa) ACOPLAMENTO: indicação da interdependência

entre módulos

41

Refinamento e Refatoração Refinamento

Processo de elaboração (alto nível -> mais detalhes)

Refinamentos sucessivos (Abstração + refinamentos): conceitos

complementares

Refatoração Reorganizar para simplificar o projeto sem alterar

as funções e os comportamentos. O que pode ser refatorado?

Redundância, elementos não utilizados, algoritmos ineficientes, etc

42

Extract Method Exemplo Sem Variáveis Locais

void imprimeDivida () {Enumerate e = _pedidos.elementos ();double divida = 0.0;// imprime cabeçalhoSystem.out.println (“***************************”);System.out.println (“*** Dívidas do Cliente ****”);System.out.println (“***************************”);// calcula dívidaswhile (e.temMaisElementos ()){Pedido cada = (Pedido) e.proximoElemento ();divida += cada.valor ();

}// imprime detalhesSystem.out.println (“nome: ” + _nome);System.out.println (“divida total: ” + divida);

}

43

Extract MethodExemplo Com Variáveis Locais

void imprimeDivida () {Enumerate e = _pedidos.elementos ();double divida = 0.0;imprimeCabecalho ();// calcula dívidaswhile (e.temMaisElementos ()){Pedido cada = (Pedido) e.proximoElemento ();divida += cada.valor ();

}//imprime detalhesSystem.out.println(“nome: ” + _nome);System.out.println(“divida total: ” + divida);

}void imprimeCabecalho () { System.out.println (“***************************”);

System.out.println (“*** Dívidas do Cliente ****”);System.out.println (“***************************”);

}

44

Extract MethodExemplo COM Variáveis Locais

void imprimeDivida () {Enumerate e = _pedidos.elementos ();double divida = 0.0;imprimeCabecalho ();// calcula dívidaswhile (e.temMaisElementos ()){Pedido cada = (Pedido) e.proximoElemento ();divida += cada.valor ();

}imprimeDetalhes (divida);

}

void imprimeDetalhes (double divida){

System.out.println(“nome: ” + _nome);System.out.println(“divida total: ” + divida);

}

45

Extract Methodcom atribuição

void imprimeDivida () {imprimeCabecalho ();double divida = calculaDivida ();imprimeDetalhes (divida);

}

double calculaDivida (){

Enumerate e = _pedidos.elementos ();double divida = 0.0;while (e.temMaisElementos ()){Pedido cada = (Pedido) e.proximoElemento ();divida += cada.valor ();

}return divida;

}

46

Extract Methoddepois de compilar e testar

void imprimeDivida () {imprimeCabecalho ();double divida = calculaDivida ();imprimeDetalhes (divida);

}

double calculaDivida (){

Enumerate e = _pedidos.elementos ();double resultado = 0.0;while (e.temMaisElementos ()){Pedido cada = (Pedido) e.proximoElemento ();resultado += cada.valor ();

}return resultado;

}

47 Projeto de Arquitetura

48

Objetivos Introduzir projeto arquitetural e discutir

sua importância. Explicar porque vários modelos são �

necessários para documentar uma arquitetura de software.

Descrever os tipos de modelos �arquitetural que podem ser usados.

49

Arquitetura do Software O processo inicial de projeto, que

consiste em identificar os subsistemas é chamado de projeto de arquitetura.

A saída desse processo de projeto é uma descrição da arquitetura do software.

50

Projeto de Arquitetura Sistemas grandes são sempre decompostos em

subsistemas que fornecem algum conjunto de serviços relacionados.

O projeto de arquitetura é o primeiro estágio no processo de projeto e representa uma ligação crítica entre os processos de engenharia de projeto e de requisitos.

O processo de projeto de arquitetura envolve o estabelecimento de um framework básico que identifica os principais componentes de um sistema e as comunicações entre eles.

51 Comunicação com os stakeholders.

A arquitetura é uma apresentação em alto nível do sistema que pode ser usada para enfocar a discussão entre os diferentes stakeholders.

Análise de sistema. Decisões do projeto de arquitetura tem um profundo

efeito sobre se o sistema pode ou não cumprir requisitos não funcionais importantes (desempenho, confiabilidade, facilidade de manutenção)

Reuso em larga escala. A arquitetura pode ser reutilizada em sistemas com

requisitos similares ou para em um sistema pertencente a uma família de aplicações

Projeto de Arquitetura

52

A arquitetura de sistema afeta o desempenho, facilidade de distribuição e de manutenção de um sistema.

O estilo e a estrutura específicos escolhidos para uma aplicação podem, portanto, depender dos requisitos não funcionais do sistema.

1. Desempenho. 2. Proteção. 3. Segurança. 4. Disponibilidade. 5. Facilidade de manutenção.

Projeto de Arquitetura

Conflitantes

53

Atividades de Processos de projeto de arquitetura Estruturação de sistema

O sistema é decomposto em vários subsistemas principais e a comunicação entre esses subsistemas são identificados.

Modelagem de controle� É estabelecido um modelo geral dos relacionamentos

de controle entre as partes do sistema. Decomposição modular�

Os subsistemas identificados são decompostos em módulos. O projetista deve decidir sobre o tipo de módulo e suas interconexões.

54

Subsistemas e módulos Um subsistema é um sistema cuja

operação não depende de serviços fornecidos por outros subsistema.

Um módulo é um componente do sistema que fornece serviços a outros componentes, mas normalmente não é considerado um sistema independente.

55

Modelos de arquitetura Diferentes modelos de arquitetura pode

ser produzidos durante o processo de projeto.

Cada modelo representa diferentes �perspectivas na arquitetura.

56

O modelo de repositório Subsistemas precisam trocar informações. Isso

pode ser feito de duas maneiras: Dados compartilhados são mantidos em um banco de

dados central, que pode ser acessado por todos os subsistemas.

Cada subsistema mantém seu próprio banco de dados e são passados explicitamente para outros subsistemas.

Quando grandes quantidades de dados precisam �ser compartilhados, o modelo de repositório é usado para organizar os sistemas.

Ex. de sistemas: SIG, CAD, CASE, sistema de �comando e controle

57

Arquitetura de um conjunto de ferramentas CASE integrado

58

Características de um modelo de repositório Vantagens

Maneira eficiente de compartilhar grandes quantidades de dados

Subsistemas que produzem dados não precisam se preocupar em como os dados são utilizados.

Gerenciamento centralizado de atividades, tais como backup,

segurança, etc. O modelo de compartilhamento é visível por meio

do esquema do repositório, facilitando a integração de novas ferramentas (desde que compatíveis com o modelo de dados estabelecido).

59

Características de um modelo de repositório Desvantagens

Subsistemas devem concordar com o modelo de dados de repositório. Inevitavelmente um compromisso.

A evolução de dados é difícil e cara.� Diferentes subsistemas podem ter diferentes

requisitos para políticas de proteção, segurança e backup. O modelo de repositório impõe a mesma política.

Dificuldade em distribuir o repositório em uma �série de máquinas. Pode ser feito, porém pode haver problemas de redundância e inconsistência de dados.

60

Modelo cliente-servidor Modelo cliente-servidor: é um modelo em que o

sistema é organizado como um conjunto de serviços e servidores e clientes associados que acessam e usam os serviços.

Seus componentes são: Um conjunto de servidores que oferecem

serviços para outros subsistemas. Um conjunto de clientes que solicita os serviços

oferecidos pelos servidores. Uma rede que permite aos clientes acessarem

esses serviços.

61

Biblioteca de filmes e fotografias

62

Características de cliente-Servidor Vantagens�

É uma arquitetura distribuída, permitindo o uso efetivo de sistemas de rede com muitos processadores distribuídos.

É fácil incluir um novo servidor e integrá-lo com o restante do sistema ou fazer a atualização do servidor de forma transparente.

Normalmente requer hardware mais barato Desvantagens

A falta de um modelo de referência compartilhada para dados pode significar dificuldade em prever problemas na integração de dados.

Gerenciamento redundante em cada servidor (backup e recuperação).

Não existe um registro central de nomes e serviços - pode ser difícil encontrar quais servidores e serviços estão disponíveis

63

Modelo em camadas Modelo em camadas: organiza um sistema em

camadas, cada uma das quais fornecendo um conjunto de serviços. Com cada camada sendo implementada por meio dos recursos da camada base.

64

Sistema de gerenciamento de versões

65

Modelo em camadas Vantagens

Apóia o desenvolvimento incremental de sistemas.

Arquitetura modificável e portável.

Desvantagens Estruturar um sistema dessa maneira pode ser

difícil. Problemas de desempenho.

66

Arquitetura de Sistemas Distribuídos

Sistema distribuído O processamento de informações é

distribuído em vários computadores ao invés de confinado em uma única máquina.

Bastante comum em qualquer organização Estilos de arquitetura comuns

Arquiteturas de múltiplos processadores Arquiteturas cliente-servidor Arquiteturas de objetos distribuídos Computação interorganizacional

67

Características do sistema distribuído

Compartilhamento de recursos Interoperabilidade

Uso de equipamento e software de fabricantes diferentes.

Concorrência Processamento concorrente para aumentar o

desempenho. Escalabilidade

Capacidade ampliada pela adição de novos recursos. Tolerância a falhas

A capacidade de continuar em operação após a ocorrência de uma falha.

68

Características do sistema distribuído

Complexidade Tipicamente, sistemas distribuídos são mais

complexos que sistemas centralizados. Segurança

Mais suscetível a ataques externos. Gerenciamento

Mais esforço é necessário para o gerenciamento do sistema.

Imprevisibilidade Respostas imprevisíveis dependendo da

organização do sistema e da carga de rede.

69

Arquiteturas de Multiprocessadores

Sistema composto de múltiplos processos que podem (mas não precisam) executar em processadores diferentes.

Distribuição de processo para processador pode ser predeterminada ou pode estar sob o controle de um escalonador.

70

Arquiteturas de Multiprocessadores

71

Arquiteturas cliente-servidor A aplicação é modelada como um conjunto de

serviços que são fornecidos pelos servidores e um conjunto de clientes que usam estes serviços.

Os clientes sabem da existência dos servidores mas os servidores não sabem dos clientes.

s1

s2 s3

s4c1

c2 c3 c4

c5

c6c7 c8

c9

c10

c11c12

Client process

Server process

72

Arquitetura C-S em camadas Camada de apresentação

Está relacionada à apresentação dos resultados de um processamento para os usuário do sistema, e à coleta de entradas do usuário.

Camada de processamento de aplicação Está relacionada ao fornecimento de

funcionalidade específica da aplicação, por exemplo, em um sistema de banco, funções bancárias, tais como abrir conta, fechar conta, etc.

Camada de gerenciamento de dados Está relacionada ao gerenciamento do

banco de dados do sistema.

73

Clientes magros e gordos Modelo de cliente-magro (Thin-client)

Em um modelo cliente-magro, todo o processamento de aplicação e o gerenciamento de dados é realizado no servidor. O cliente é responsável, simplesmentes por executar o software de apresentação.

Modelo de cliente-gordo (Fat-client) Nesse modelo, o servidor é responsável somente

pelo gerenciamento de dados. O software do cliente implementa a lógica da aplicação e as interações com o usuário do sistema.

74

Clientes magros e gordos

75

Arquiteturas de três camadas

Camada de Apresentação Trata da apresentação dos resultados de uma

computação para os usuários do sistema e das formas de entrada de dados do usuário no sistema.

Camada de Aplicação Fornece funcionalidades específicas da

aplicação (ex., abertura e fechamento de conta em um sistema bancário)

Camada de dados Gerenciamento dos sistemas de banco de

dados.

76

Arquiteturas de três camadas

77

Arquitetura de Objetos Distribuídos

Não existe distinção entre clientes e servidores em uma arquitetura de objetos distribuídos.

Cada entidade distribuível é um objeto que fornece serviços para outros objetos e recebe serviços de outros objetos.

Os objetos se comunica através de um sistema de middleware chamado requisitor de objetos.

78

Software bus

o1 o2 o3 o4

o5 o6

S (o1) S (o2) S (o3) S (o4)

S (o5) S (o6)

79

Middleware CORBA Middleware

Software que gerencia e apóia os componentes diferentes de um sistema distribuído. Em essência, ele se situa no meio do sistema.

CORBA Padrão internacional para um localizador de

objetos (Object Request Broker) para gerenciar a comunicação entre objetos distribuídos.

80

Middleware CORBA

81

Arquiteturas orientadas a serviços SOA

Serviços “Uma ação ou desempenho oferecido de um grupo

para um outro. Embora o processo possa estar ligado a um produto

físico, o desempenho é essencialmente intangível e não resulta normalmente em propriedade de algum dos fatores de produção”.

O fornecimento dos serviços é, portanto, independente da aplicação que usa o serviço.

Um web service é uma abordagem padronizada para tornar um componente reusável disponível e acessível através da rede

82

Arquiteturas orientadas a serviços SOA

83

Exemplo Um sistema de informações de um automóvel

fornece aos motoristas informações sobre o clima, condições de tráfego, informações locais, etc. O sistema é ligado ao aparelho de rádio do automóvel que apresenta as informações como um sinal de emissora de rádio específica.

O automóvel é equipado com um receptor GPS para informar sua posição e, baseado nessa posição, o sistema acessa uma gama de serviços de informações. A informação pode ser fornecidas no idioma especificado pelo motorista.

84

85

Referências

PRESSMAN, Roger S. Engenharia de Software. 5. ed. São Paulo: Makron Books, 2006.

SOMMERVILLE, Ian. Engenharia de Software. 8. ed. São Paulo: Pearson, 2007.