MODELAGEM DE PROCESSOS
Profa. Dra. Alynne Oya Chiromatzo
UNIP- Ribeirão Preto
1.INTRODUÇÃO
Motivação
História da UML
Conceitos básicos
RESUMO DOS DIAGRAMAS DA UML
1.6. Diagrama de Comunicação:
O Diagrama de Comunicação era conhecido como Diagrama de Colaboração até a versão 1.5 da UML, tendo seu nome modificado para Diagrama de Comunicação a partir da versão 2.0. Esse diagrama está amplamente associado ao Diagrama de Seqüência; na verdade, um complementa o outro. As informações mostradas no Diagrama de
Comunicação são, com freqüência, praticamente as mesmas apresentadas no Diagrama de Seqüência, porém com um enfoque diferente, visto que este diagrama não se preocupa com a temporalidade do processo, concentrando-se em
como os objetos estão vinculados e quais mensagens
trocam entre si durante o processo.
RESUMO DOS DIAGRAMAS DA UML
1.6. Diagrama de Comunicação:
Filmes 1. Cadastrar
2. Selecionar filmes 3. Pagar filme
4. D evolv er fi lme
1.1. Realizar cadastro 2.1. Locar filmes
3.1. Receber pagamento
Pessoa Atendente
RESUMO DOS DIAGRAMAS DA UML
1.7. Diagrama de Máquina de Estados
O Diagrama de Máquina de Estados era conhecido nas
versões anteriores da linguagem como Diagrama de Gráfico de Estados ou simplesmente como Diagrama de Estados, tendo assumido nova nomenclatura a partir da versão 2.
Esse diagrama procura acompanhar as mudanças sofridas nos estados de uma instância de uma classe, de um Caso de Uso ou mesmo de um subsistema ou sistema completo.
Como o Diagrama de Seqüência, o Diagrama de Máquina de
Estados muitas vezes se baseia em um Caso de Uso e se
apóia no Diagrama de Classes.
RESUMO DOS DIAGRAMAS DA UML
1.7. Diagrama de Máquina de Estados
Locado Filmes
selecionados
Disponível
Filmes devolvidos
.
RESUMO DOS DIAGRAMAS DA UML
1.8. Diagrama de Atividade
O Diagrama de Atividade era considerado um caso especial do antigo Diagrama de Gráfico de Estados, mas, a partir da UML 2.0, esse diagrama se tornou independente, deixando inclusive de se basear em máquinas de estados e passando a se basear em Redes de Petri. O Diagrama de Atividade se preocupa em descrever os passos a serem percorridos para a conclusão de uma atividade específica, muitas vezes
representada por um método com um certo grau de
complexidade, podendo, no entanto, modelar um processo completo. Concentra-se na representação do fluxo de
controle e no fluxo de objeto de uma atividade.
RESUMO DOS DIAGRAMAS DA UML
1.8. Diagrama de Atividade
Pessoa Totem Locadora
Entra na
Loja Selecion
a filme
Paga filme
Loca filme
Retorna
filme
2. MODELAGEM E ORIENTAÇÃO À OBJETOS
Princípios de Modelagem
Modelagem Orientada à Objetos
2. MODELAGEM DE PROCESSOS
“Um processo de desenvolvimento de software compreende todas as atividades necessárias para definir, desenvolver, testar e manter um produto de
software.”
Objetivos:
Definir quais as atividades a serem executadas ao longo do projeto;
Quando, como e por quem tais atividades serão executadas;
Promover pontos de controle para verificar o andamento do desenvolvimento;
Padronizar a forma de desenvolver software em uma
organização.
2. MODELAGEM DE PROCESSOS
“O processo de desenvolvimento (PD) de um software é uma atividade complexa. Essa complexidade corresponde à sobreposição das complexidades
relativas aos diversos componentes: software, hardware, procedimentos… ”
Efeitos dessa complexidade (Chaos, 1994):
10% dos projetos terminam dentro do prazo esperado;
25% dos projetos são descontinuados antes de chegarem ao fim;
60% dos projetos saem acima do custo esperado
1 ano é o atraso médio
2. MODELAGEM DE PROCESSOS
“Existem diversos modelos de processos, cada um deles tem a sua peculiariedade em relação ao modo de arranjar e
encadear as atividades de desenvolvimento”
2.1 Atividades Típicas de um Processo de Desenvolvimento
Levantamento de Requisitos
Análise de Requisitos
Projeto
Implementação
Testes
Implementação
2.1. ATIVIDADES TÍPICAS DE UM PD
Levantamento de Requisitos:
“ O princípio básico da análise de requisitos é identificar e documentar o que é realmente necessário, desta forma comunicando a todos os envolvidos no projeto da forma mais clara possível, de maneira não-ambígua de modo que
os riscos sejam identificados sem correr riscos de imprevistos. ”
Objetivo: mesma visão entre desenvolvedores e usuários
Desenvolvedores + clientes → Levantar e definir necessidades dos futuros usuários (requisitos)
Pode ser desenvolvida baseada em sistema de
negócios e não apenas de software
2.1. ATIVIDADES TÍPICAS DE UM PD
Levantamento de Requisitos:
Diagramas de casos de uso (Use Cases)
Atores externos → interagem com o sistema juntamente com as funções que elas requerem (casos de uso)
Através dos diagramas de Casos de Uso aos atores externos
(futuros usuários) o que
eles podem esperar do
sistema.
2.1. ATIVIDADES TÍPICAS DE UM PD
Análise:
Objetivo: Construir uma estratégia de solução sem se
preocupar com a maneira como essa estratégia será realizada.
Tenta-se obter a melhor solução para o problema sem se preocupar com o detalhes da tecnologia que será utilizada.
Diagramas de Classes
Primeiras abstrações - Geral (classes e objetos)
- Atributo: propriedade que todos os objetos têm
- Método: ações que
implementam uma operação
2.1. ATIVIDADES TÍPICAS DE UM PD
Projeto :
“Define como o sistema funcionará para atender os requisitos, de acordo com os recursos e tecnologias existentes” (Bezerra)
Projeto de arquitetura: Adicionadas novas classes mais
detalhadas para oferecer uma infra-estrutura técnica tal como:
interface do usuário e periféricos, banco de dados, interação com outros sistemas, etc
Projeto detalhado: são modeladas as colaborações entre os objetos de com o objetivo de realizar suas funcionalidades.
Diagramas de Classes, Diagramas de Interação, Diagramas de Estado e diagramas de Atividades.
“ Projeto cria uma representação do domínio de problema do mundo
real e leva-a a um domínio de solução que é o software ”
(Pressman,1995)
2.1. ATIVIDADES TÍPICAS DE UM PD
Implementação:
“Para que uma fase de programação possa ter um bom desempenho, necessitamos de um projeto bem elaborado,
consequentemente converteremos as classes da fase do projeto para o código da linguagem orientada a objetos escolhida. Se o desenho foi elaborado corretamente e com
detalhes suficientes, a tarefa de codificação é facilitada”
(Furlan, 1998).
2.1. ATIVIDADES TÍPICAS DE UM PD
Testes:
Com o sistema pronto, nesta fase dedica-se a encontrar os
possíveis erros.
Programadores: que conhecem a programação do sistema e
sabe onde encontrar os possíveis pontos críticos que podem
gerar falhas
Usuários: que conhecem como os
procedimentos deve se comportar
2.1. ATIVIDADES TÍPICAS DE UM PD
Implantação:
“Produto é empacotado, distribuído e instalado no ambiente do usuário.”
- Manuais são escritos;
- Dados são importados;
- Usuários treinados;
- Migração de software e/ou dados pré-existentes.
2.2. O COMPONENTE HUMANO
Gerentes de projeto: coordenação das atividades necessárias à construção do sistema
Analistas: tem o domínio do negócio
Projetistas: avalia as alternativas de solução e gera a solução computacional detalhada.
Arquitetos de software: toma decisões sobre quais são os subsistemas que compõe o sistema e quais são as interfaces entre esses subsistemas
Programadores: implementação efetiva do sistema
Clientes: grupo de pessoas para os quais o sistema foi desenvolvido
Avaliadores de qualidade: adequam o software a
padrões de qualidade estabelecidos por organizações
2.2. O COMPONENTE HUMANO
2.2. CICLOS DE VIDA
Para a construção de um sistema, as atividades típicas são encadeadas de forma a formar um modelo de ciclo de vida.
Ciclo de vida em cascata: clássico ou linear, possui uma
tendência na progressão sequencial entre uma atividade e
a seguinte.
2.2. CICLOS DE VIDA
Ciclo de vida iterativo e incremental: seleciona um
subconjunto de requisitos por vez para ser desenvolvido por
completo
3. VISÃO GERAL DA UML
UML é uma linguagem para
Visualização: facilita a comunicação sendo que cada símbolo gráfico possui uma semântica bem definida
Especificação: especifica diversos aspectos arquiteturais e de uso do sistema
Construção:
Geração automática de código a partir modelo visual
Geração do modelo visual a partir do código
Documentação:
Deliverables (entregáveis) → documentos tal como especificação de requisitos, especificações funcionais, planos de teste, etc.
Documentos importantes para controlar, medir e
refletir sobre um sistema durante o desenvovimento e
implantação.
3. VISÃO GERAL DA UML
Oferece um padrão para desenhar a arquitetura do sistema que inclui:
Aspectos abstratos: processos de negócios e funcionalidades do sistema
Aspectos concetros: classes, esquema de banco de dados, etc.
UML não é uma metodologia
UML não é uma linguagem de programação
É uma linguagem de modelagem
3. VISÃO GERAL DA UML
Suporta todo o ciclo de vida do software
modelação do negócio (processos e objetos do negócio)
modelação de requisitos alocados ao software
modelação da solução de software
3.1. ELEMENTOS DE MODELAGEM
“ Os conceitos usados nos diagramas são chamados de modelos de elementos (Barros, 2001). Um modelo de elemento é definido com a semântica, a definição formal do elemento com o exato significado do que ele representa sem
definições duvidosas ou ambíguas e também define sua representação gráfica que é mostrada nos diagramas da UML.”
Classe/Objeto
Estados
Pacotes
Componentes
Relacionamentos
3.1. ELEMENTOS DE MODELAGEM : CLASSE
Uma classe é uma descrição de um conjunto de objetos que compartilham os mesmo atributos,
operações, relacionamentos e semântica
Modelo de classes de domínio:
- representa as classes no domínio do negócio em questão
- construído na fase de análise
- não leva em consideração a tecnologia utilizada
Modelo de classes de especificação:
- extensão da classe anterior
- adição de detalhes específicos da solução de software
Modelo de classes de implementação:
- extensão da classe anterior
- adição de detalhes da linguagem de programação
3.1. ELEMENTOS DE MODELAGEM : CLASSE
É único e identifica a classe
são propriedades que descrevem os valores que as instâncias da propriedade podem apresentar
são os
processos/métodos que a
classe pode realizar
3.1. ELEMENTOS DE MODELAGEM : CLASSE
Objeto:
- É uma instância da classe
- É um elemento que pode-se manipular,
acompanhar seu comportamento, criar, interagir e destruir
- Pode existir no mundo real ou pode ser uma
derivação de estudos da estrutura e comportamento
de outros objetos do mundo real.
3.1. ELEMENTOS DE MODELAGEM : ESTADOS
Nome do Evento: mostra o nome do evento, geralmente este nome descreve o que este estado realiza
Atributos: mostra as variáveis de estado, onde os atributos do objeto em questão pode ser listados e atualizados
Atividades: o compartimento de atividades é onde podemos listar os eventos e ações.
Está dividido em três eventos padrões :
Entrar: usado para definir atividades no momento em que o objeto entra naquele estado;
Sair: usado para definir atividades que o objeto executa antes de passar para o próximo estado;
Fazer: usado para definir atividades que o objeto executa enquanto se encontra
naquele estado.
Um estado é uma condição ou situação na vida de
um objeto durante a qual o objeto satisfaz alguma condição, realiza alguma atividade
ou aguarda um
evento
3.1. ELEMENTOS DE MODELAGEM : PACOTES
Organiza elementos de modelagem em grupos, podendo, inclusive, estar aninhando dentro de outros pacotes(pacotes
subordinados)
Os elementos ligados ou referenciados por um
pacote são chamados de
"Conteúdo do pacote“
Um pacote possui vários modelos de elementos, e isto significa que estes não podem ser incluídos em outros pacotes
Pacotes podem importar
modelos de elementos de
outros pacotes.
3.1. ELEMENTOS DE MODELAGEM : COMPONENTES
Um componente pode ser tanto um código em linguagem de programação como um código executável já compilado.
Math.dll
Pessoa.class
3.1. ELEMENTOS DE MODELAGEM : RELACIONAMENTOS
Dependência:
- É um relacionamento entre elementos, um independente e outro dependente
- Uma modificação é um elemento independente afetará diretamente seus elementos dependentes
Produto Estoque
Local:
ID:
Nome:
Unidade:
Estoque ID:
3.1. ELEMENTOS DE MODELAGEM : RELACIONAMENTOS
Generalização:
- Relacionamento de um elemento mais geral e outro mais específico
- Elemento mais específico pode conter apenas informações adicionais.
Gerência
Administrati
vo Jurídico
3.1. ELEMENTOS DE MODELAGEM : RELACIONAMENTOS
Associação:
- É uma conexão entre as classes e seus respectivos objetos
Recursivas:
Gerência Pessoa Empregado
Empregador
Pessoa Esposa
Marido
É casado com
3.1. ELEMENTOS DE MODELAGEM : RELACIONAMENTOS
Associação:
Ternária:
Gerência Pessoa
RH
1..*
1..1
1..1
3.1. ELEMENTOS DE MODELAGEM : RELACIONAMENTOS
Ornamentos da associação:
Nome
Papel
Multiplicidade
Gerência Pessoa Empregado
Empregador
Gerência Pessoa 1..*
1
Gerência Pessoa Trabalha p/
Gerência
Pessoa Trabalha p/
3.1. ELEMENTOS DE MODELAGEM : RELACIONAMENTOS
