engenharia de software -...

Engenharia de Software

Engenharia de Software 2012/3Aula 5 – Modelagem de Sistemas

Thiago P. da [email protected]

06/05/13 2

Agenda

● Modelagem de Sistemas

● Modelos de contexto

– Diagramas de Atividades● Modelos de interação

– Diagramas de Casos de uso

– Diagramas de Sequência● Modelos estruturais

– Diagramas de Classe● Modelos comportamentais

– Diagramas de Estado

06/05/13 3

Objetivos da Aula

● Compreender como modelos gráficos podem ser usados para representar sistemas de software;

● Compreender por que diferentes tipos de modelos são necessários para representar um sistema de software;

● Entender os principais diagramas da UML;

● Compreender por que diferentes modelos apresentam visões diferentes sobre o sistema, que são úteis para diferentes stakeholders.

06/05/13 4

Modelagem de Sistemas

● É o processo de desenvolvimento de modelos abstratos de um sistema

● Cada modelo representa uma visão ou perspectiva diferente do sistema

● Modelos podem usar notações gráficas, tal como UML, ou modelos formais com especificação formal

● Modelos são usados amplamente em outras disciplinas

– Engenharia civil – modelos hidráulicos

– Matemática - Modelos matemáticos

– Física, Química, etc

06/05/13 5


● Os modelos são abstrações do sistema, e não uma representação alternativa dele

– Uma Representação mantém todas as informações a respeito da entidade apresentada

– Uma Abstração simplifica e seleciona características mais salientes

– Exemplo:● Um livro traduzido em outra língua é uma representação

alternativa da entidade livro● Um resumo pode ser considerado uma abstração da

entidade livro

06/05/13 6


● Modelos podem ser usados em todas as etapas da engenharia de software

– Engenharia de requisitos – extrair requisitos do sistema, esclarecer o que o sistema faz, tirar dúvidas, explicar os requisitos para outros stakeholders

– Processo de Projeto – Descrever o sistema

– Outras etapas - Documentar a estrutura e operação do sistema, estimular a discussão entre os engenheiros de software, descrever detalhadamente o sistema em uma abordagem MDD

06/05/13 7


● Diferentes modelos proporcionam perspectivas (ou pontos de vista) diferentes

– Perspectiva externa modela o contexto ou o ambiente do sistema

– Perspectiva de interação modela as interações entre um sistema e seu ambiente, ou entre os componentes de um sistema

– Perspectiva estrutural modela a organização de um sistema ou a estrutura dos dados processados pelo sistema

– Perspectiva comportamental modela o comportamento dinâmico do sistema e como ele reage aos eventos

06/05/13 8


● A UML (Unified Modeling Language) é uma linguagem de modelagem amplamente utilizada

– Conjunto de notações que visam apoiar a modelagem de sistemas orientados a objetos

– Não explicita como a modelagem deve ser conduzida

– Pode ser usada para modelar sistemas não-OO● Modelos de domínio● Modelos de contexto

06/05/13 9


● [3] sugerem que cinco tipos de diagramas podem representar a essência de um sistema

– Diagramas de Atividade – atividades envolvidas em um processo ou no processamento de dados

– Diagramas de Caso de Uso – interações entre um sistema e seu ambiente

– Diagramas de Sequência – interação entre os atores e o sistema, e entre os componente ou objetos do sistema

– Diagramas de Classe – mostram as classes de objetos do sistema e as associações entre elas

– Diagramas de Estado – mostram como o sistema reage a eventos internos e externos

06/05/13 10

Agenda








06/05/13 11

Modelos de Contexto

● Definem os limites do sistema

● Normalmente usados em um estágio inicial da especificação de um sistema

– Trabalhar com os stakeholders para descobrir funcionalidades do sistema e o que são fornecidos pelo ambiente

● Mostram quais outros sistemas fazem parte do ambiente, mas não mostram os tipos de relacionamentos entre sistemas

● Os sistema externos podem:

– produzir dados para o sistema consumir dados deste

– compartilhar dados

– ser conectados diretamente por meio de uma rede

– estar fisicamente no mesmo local ou em locais separados

06/05/13 12

Modelos de Contexto

Exemplo – Contexto de um Sistema Operacional

S.O.S.O.

Sistemade Arquivos

Sistema de Ger.de Memória

Sistema Ger.ProcessadorSistema de E/S

06/05/13 13

Modelos de Contexto

Diagrama de Atividades da UML

– Modelam atividades, a ordem em que são realizadas e dependências entre elas

● Podem também indicar entradas e saídas das atividades

– Úteis para modelar fluxos de trabalho

– Exemplos:● Sequência de passos da descrição de um requisito● Processos dentro de uma empresa

06/05/13 14

Modelos de Contexto

Diagrama de Atividades da UML – Exemplo 1

06/05/13 15

Modelos de Contexto

Diagramas de Atividades da UML

– O início de um processo é indicado por um círculo preenchido

– O fim do processo é indicado por um circulo preenchido dentro de outro círculo

– Os retângulos com cantos arredondados representam atividades (ou subprocessos)

– Objetos são presentados por retângulos (podem representar outros sistemas)

– As setas representam o fluxo de trabalho de uma atividade para outra

– A barra sólida é usada para indicar coordenação de atividades

– Atividades podem ser executas em paralelo

– Guardas (anotações) podem ser incluídas nas setas

06/05/13 16

Modelos de ContextoDiagrama de Atividades da UML - Exemplo 2

06/05/13 17

Modelos de Contexto

● Na modelagem de processos de negócio é comum a realização de atividades por várias entidades, participantes no dito processo.

● A UML propõe o conceito de pistas (swimlanes) ou rais como elemento que permite agrupar as várias atividades da responsabilidade de cada entidade participante.

● Um diagrama de atividades ilustra o fluxo de controle entre atividades, enquanto que um diagrama de estados ilustra o fluxo de controle entre estados

06/05/13 18

Modelos de Contexto

Diagrama de Atividades da UML - Exemplo 3

06/05/13 19

Agenda








06/05/13 20

Modelos de Interação

● Mostram interação do usuário, que podem ter entradas e saídas, com o sistema

– Ajudam a descobrir requisitos do usuário● Mostram interações entre sistemas

● Ou interações entre os componentes do sistema

● Pode-se usar dois abordagens para modelar a interação

– Casos de uso que mostram, principalmente, interações com atores externos(sistemas ou usuários)

– Diagramas de Sequência que mostram interações entre os componentes do sistema

● Diagramas de Casos de uso e sequência apresentam interações em diferentes níveis de detalhamento

– Detalhes de alto nível do Caso de uso podem ser detalhados no diagrama de sequência

06/05/13 21


Caso de Uso

– Amplamente usado para apoiar a elicitação de requisitos

– Representa uma tarefa discreta que envolve a interação externa com um sistema, que pode ser hardware/software/pessoa

– Oferece uma visão simples de uma interação● Necessário mais detalhes para entender o que está

envolvido

06/05/13 22


Caso de Uso – Exemplo 1

06/05/13 23



06/05/13 24


Caso de uso

● Um diagrama de casos de uso permite dar uma visão global e de alto nível do sistema, sendo fundamental a definição correta da sua fronteira

● Um cenário é uma determinada sequência de ações que ilustra um comportamento do sistema

● Uma designação alternativa para cenário, por vezes utilizada, é “fluxo de ações”

06/05/13 25


Caso de uso

● Deve-se especificar o comportamento de um caso de uso descrevendo textualmente um ou mais fluxos de ações, de modo que um usuário não técnico o possa entender sem dificuldade.

● Tal especificação deve incluir:

– Como e quando o caso de uso começa e termina;

– Quando é que o caso de uso interage com os atores;

– Que objetos são trocados;

– Cenário principal, e

– Cenários alternativos (Ex., situações de exceção)

06/05/13 26



06/05/13 27



Nome: Validar Usuário

Cenário Principal

O caso de uso inicia-se quando o sistema apresenta uma tela que pede ao cliente o seu cartão eletrônico. O cliente introduz o seu cartão magnético e, através de um pequeno teclado, a sua senha. Note-se que o cliente pode limpar a introdução da sua senha inúmeras vezes e re-introduzir um novo número antes de pressionar o botão “Entrar”. O cliente ativa o botão “Entrar” para confirmar. O sistema lê a senha e a respectiva identificação do cartão, e verifica se é válido. Se a senha for válida o sistema aceita a entrada e o caso de uso termina.

Cenário Alternativo 1 (Cliente cancela operação)

O cliente pode cancelar a transação em qualquer momento ativando o botão “Cancelar”, implicando a re-inicialização do caso de uso. Não é realizada qualquer alteração à conta do cliente.

Cenário Alternativo 2 (senha inválida)

Se o cliente introduz uma senha inválida o cartão MB é ejetado e o caso de uso reinicializado. Se tal ocorrer 3 vezes consecutivas, o sistema aciona medidas de segurança e “recolhe” o cartão e cancela a transação; não permitindo qualquer interação nos 2 minutos seguintes.

06/05/13 28


Caso de Uso – Exemplo Generalização

“Testar Senha” e “Leitura com Smartcard” são especializam o caso de uso “Validar usuário”

06/05/13 29


Caso de Uso – Exemplo <<include>>

Relação de delegação, significando que o caso base incorpora o comportamento do outro caso

06/05/13 30


Diagramas de Sequência

– Modelam as interações entre os atores e os objetos em um sistema, e as interações entre os próprios objetos

– Mostra as interações que ocorrem durante um caso de uso, segundo uma visão temporal

– Um diagrama de sequência é representado através de duas dimensões:● a dimensão horizontal, que representa o conjunto de objetos; e● a dimensão vertical que representa o tempo

– Os objetos e atores envolvidos são listados no topo do diagrama

– Interações entre objetos são indicadas por setas anotadas

06/05/13 31


Diagramas de Sequência – Exemplo 1

06/05/13 32


Diagramas de Sequência – Exemplo 2

06/05/13 33

Agenda








06/05/13 34

Modelos Estruturais

● Exibem a organização de um sistema em termos de seus componentes e seus relacionamentos

● Podem ser:

– Estáticos, que mostram a estrutura do projeto do sistema ou;

– Dinâmicos, que mostram a organização do sistema em execução

● Conjunto de threads que interagem entre si● Pode-se criar modelos estruturais quando se discute e

projeta a arquitetura do sistema

06/05/13 35

Modelos Estruturais

Diagrama de classe

● São usados para modelar um sistema orientado a objetos

● Mostra as classes de objetos de sistema e suas associações

– Dependência

– Herança e realização

– Associação

● Uma classe é uma abstração de um conjunto de objetos com atributos comuns e os serviços fornecidos por cada objeto

● Perspectiva inerentemente estática

06/05/13 36

Modelos Estruturais

Diagrama de classe

● Os modelos podem ter níveis de abstração diferentes em etapas da Engenharia de software

– Na engenharia de requisitos podemos pensar em objetos do contexto e criar classes para eles

– Depois pode-se refinar estas classes● As classes são retângulos com três divisões

– o nome na parte superior,

– atributos na intermediária e

– operações na inferior● Classes podem também aparecer apenas como retângulos

● Relacionamentos entre classes são linhas

06/05/13 37

Modelos Estruturais

Diagrama de classe - Exemplo

06/05/13 38

Modelos Estruturais

Diagrama de classe – Exemplo 2

● Um objeto (o todo) é composto de outros objetos (as partes)

– Na Agregação, a existência do Objeto-Parte faz sentido, mesmo não existindo o Objeto-Todo

06/05/13 39

Modelos Estruturais

Diagrama de classe – Exemplo 2

● Um objeto (o todo) é composto de outros objetos (as partes)

– Composição é uma agregação mais forte; nela, a existência do Objeto-Parte NÃO faz sentido se o Objeto-Todo não existir

06/05/13 40

Agenda








06/05/13 41

Modelos Comportamentais

● Mostram o comportamento dinâmico do sistema quando está em execução

● O que o sistema faz em resposta a estímulos de seu ambiente

– Estímulos = dados ou eventos● Dados - dados que chegam precisam ser processados

pelo sistema● Eventos – eventos disparam o processamento do sistema.

● Dois principais tipos

– Modelagem Orientada a Dados

– Modelagem Dirigida a Eventos

06/05/13 42


Modelagem Orientada a Dados

● Mostram a sequência de ações envolvidas no processamento de dados de entrada e a geração de uma saída correspondente

● São úteis durante a análise de requisitos, pois podem ser usados para mostrar, do início ao fim, o processamento de um sistema

● A UML não tem diagramas orientado a dados. Entretanto pode-se usar diagramas de sequência

– Diagramas de sequência destacam os objetos de um sistema, enquanto os diagramas orientados a dados destacam as funções e os dados

06/05/13 43


Modelagem Orientada a Dados

● Diagramas de fluxo de dados (DFD)

– Mostram as etapas de processamento em sistema.

– Não reconhecem objetos

06/05/13 44


Modelagem Orientada a Eventos

● Mostram como o sistema reage a eventos internos e externos

● Sistemas têm número finito de estados e eventos podem causa uma transição de um estado para outro

● O diagrama de estados da UML (StateCharts) mostra os estados como nós e eventos como arcos entre nós. Quando ocorre um evento, o sistema move de um estado para outro

● Não mostra o fluxo de dados, mas pode incluir informações adicionais sobre o processamento realizado em cada estado.

● É importante fornecer mais detalhes sobre os estímulos e estados, utilizando texto e tabelas

06/05/13 45


Modelagem Orientada a Eventos

● Mostram como o sistema reage a eventos internos e externos

● Sistemas têm número finito de estados e eventos podem causa uma transição de um estado para outro

● O diagrama de estados da UML (StateCharts) mostra os estados como nós e eventos como arcos entre nós. Quando ocorre um evento, o sistema move de um estado para outro

● Não mostra o fluxo de dados, mas pode incluir informações adicionais sobre o processamento realizado em cada estado.

● É importante fornecer mais detalhes sobre os estímulos e estados, utilizando texto e tabelas

06/05/13 46


Diagrama de estados da UML – Forno de Microondas

06/05/13 47


Diagrama de estados da UML

06/05/13 48



06/05/13 49


06/05/13 50

Referências

[1] - SOMMERVILLE, Ian. Engenharia de Software, 9. ed., 2003.

[2] - PRESSMAN, R.S. Engenharia de Software: Uma abordagem Profissional, 7 ed., McGraw Hill, 2011.

[3] - IEEE Guide to the Software Engineering Body of Knowledge – 2004 Version. Disponível em http://www.swebok.org/.

engenharia de software -...

Documents