Upload
wagner-gadea-lorenz
View
78
Download
0
Embed Size (px)
Citation preview
Processo Unificadoe
Notação UML
Professor Wagner Gadêa [email protected]
Disciplina: Engenharia de Software IICurso de Sistemas de Informação
Cachoeira do Sul, 04 de Março de 2015.
Processo Unificado RationalUm dos mais conhecidos processos tradicionais é o Processo Unificado da IBM/Rational;
O Processo Unificado é baseado em componentes, e utiliza a Linguagem de Modelagem Unificada (UML);
O Processo Unificado integra ciclos, fases, disciplinas, suav ização de r iscos, cont ro le de qua l idade, gerenciamento de projetos e controle de configuração;
Engenharia de Software II 2
Solução• Uso das Melhores Práticas de Desenvolvimento: práticas usadas
com sucesso pela indústria de software;
• São elas:
• Desenvolvimento iterativo;
• Gerência de requisitos;
• Uso de arquitetura baseada em componentes;
• Modelagem visual;
• Verificação contínua da qualidade de software ;
• Gerência de mudança.
Engenharia de Software II 3
Prática 1: Desenvolvimento Iterativo
Engenharia de Software II 4
Cada iteração resulta e m u m r e l e a s e executável
Análise de Riscos
Engenharia de Software II 5
Prática 2: Gerência de Requisitos• Tenha certeza que você está
• Resolvendo o problema certo
• Construindo o sistema certo • Por usar uma abordagem sistemática para:
• elicitar
• organizar
• documentar
• gerenciar
• As mudanças dos requisitos de um software.
Engenharia de Software II 6
Prática 3: Uso de Arquitetura baseada em Componentes
• Base para reuso
• Reuso de Componentes
• Reuso de Arquitetura
Engenharia de Software II 7
System- software
Middleware
Business- specific
Application- specific
Arquitetura baseada em componentes com camadas
Prática 4: Modelagem Visual usando a UML
8Engenharia de Software II
Prática 5: Verificação Contínua da Qualidade
9Engenharia de Software II
Dimensões de Teste de Qualidade
Confiabilidade⬥Testar se a aplicação se
comporta consistentemente e previsivelmente.
Performance⬥Testar resposta online com
sobrecarga
Funcionalidade⬥Testar cada cenário de
caso de uso para verificar que se comporta corretamente
Usabilidade⬥Testar a aplicação da
perspectiva do usuário final
Suportabilidade⬥Testar a habilidade de manter e
suportar a aplicação sob uso em ambiente de produção
10Engenharia de Software II
Testes em cada Iteração
11Engenharia de Software II
Prática 6: Gerenciar Mudanças
❖ O que você quer controlar? ❖ workspaces seguros para cada desenvolvedor ❖ Gerenciamento de build/integração automatizados ❖ Desenvolvimento paralelo
Engenharia de Software II 12
Alcançando as melhores práticas por meio de um processo
❖ Abordagem iterativa; ❖ Guia para atividades e artefatos; ❖ Processo focado na arquitetura; ❖ Casos de uso dirigem o projeto e a implementação; ❖ Modelos simplificados do sistemas;
Engenharia de Software II 13
Organização do RUP
conteúdo
Disciplinas agrupam
atividades relacionadas
A iteração percorre
todas as
disciplinas.
tempo
Engenharia de Software II
Organização do RUP por tempo❖ Rational Unified Process é organizado em 4 fases:
❖ Concepção: define o escopo do software ❖ Elaboração: planeja o projeto, especifica features, define e valida a arquitetura ❖ Construção: constrói o produto ❖ Transição: implantação do software
Engenharia de Software II 15
Número de Iterações❖ Rule of thumb: Use 6 ± 3 iterações
Phase Low Medium High
Inception 0 1 1
Elaboration 1 2 3
Construction 1 2 3
Transition 1 1 2
Total 3 6 9
Engenharia de Software II 16
DisciplinasCada disciplina no RUP contém um fluxo de trabalho (workflow). Um workflow é um fluxo de a t i v i d a d e s d e a l t o - n í v e l ( W o r k f l o w D e t a i l s ) q u e produzem um resultado de valor observável
•Workflow Details
Engenharia de Software II 17
Workflows DetailsExemplo: Disciplina Requisitos Exemplo diagrama Workflow Detail:
Analyze the Problem
Workflows details mostram trabalhadores, atividades que estes executam, artefatos de entrada e artefatos de saída.
Engenharia de Software II18
Disciplinas❖ No Processo Unificado Rational existem nove disciplinas,
que são divididas em seis disciplinas de processo e três de suporte: ❖ As disciplinas de processo são:
❖ Modelagem de Negócio; ❖ Requisitos; ❖ Análise e Projeto (desenho); ❖ Implementação; ❖ Teste; ❖ Implantação.
❖ As disciplinas de suporte são: ❖ Gerenciamento de Configuração e Alteração; ❖ Gerenciamento de Projetos ❖ Ambiente.
Engenharia de Software II 19
Conceitos Básicos do RUP
Engenharia de Software II 20
Trabalhador (Worker)
❖ O trabalhador define o comportamento e as responsabilidades de um indivíduo, ou um conjunto de indivíduos trabalhando em uma equipe, dentro do contexto de uma organização de software;
❖ O trabalhador representa um cargo executado por indivíduos em um projeto e define como eles devem realizar o trabalho [RAT 99][RAT 2001];
❖ Exemplos: Analistas de Sistemas, gerentes de projeto, arquitetos de software, testadores, entre outros.
Engenharia de Software II 21
Atividade (Activity)
❖ Uma atividade é uma unidade de trabalho que um indivíduo que representa um trabalhador é encarregado de executá-la;
❖ Uma atividade tem uma finalidade clara, usualmente expressa em termos de criação ou atualização de algum artefato, como um modelo, uma classe, um plano [RAT 99][RAT 2001].
Engenharia de Software II 22
Artefatos (Artifacts)
❖ Atividades têm artefatos como entrada e saída;
❖ Um artefato é um produto de trabalho do processo, trabalhadores usam artefatos para executar suas atividades, e produzem artefatos durante a execução de suas atividades;
❖ Artefatos são de responsabilidade de um único trabalhador, em um processo, cada porção de informação é de responsabilidade de uma pessoa específica
Engenharia de Software II 23
Artefatos (Artifacts)
Iteration Plan
Developer Test
Storyboard
Project Measurements
Business Use Case
Model
Iteration Assessment Analysis
Model
Architectural Proof-of-Concept
Use Case Model
Test Environment Configuration
User-Interface Prototype
Engenharia de Software II 24
Trabalhador , Atividade e Artefato
Engenharia de Software II 25
Referências Bibliográficas❖ [JAC 98] JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James.
The Unified Software Development Process. [S.l.]: Addison Wesley, 1998.
❖ [KRU 2000] KRUCHTEN, Philippe. The Rational Unified Process: An Introduction. Massachusetts: Addison Wesley, 2000.
❖ [RAT 2001] RATIONAL SOFTWARE CORPORATION. Rational Unified Process, Version 2001.03.00. Cupertino, 2001.
❖ [SCO 2004] SCOTT, Kendall. O Processo Unificado (RUP) Explicado – UML. Bookman, 2004.
❖ Material da Profa. Lisandra Manzoni Fontoura, disciplina de Engenharia de Software.
Engenharia de Software II 26
UML
❖ A UML - Unified Modeling Language ou Linguagem de Modelagem Unificada, é uma linguagem visual utilizada para modelar softwares baseados no paradigma de orientação de objetos.
❖ Essa linguagem tornou-se, nos últimos anos, a l i n g u a g e m - p a d r ã o d e m o d e l a g e m a d o t a d a internacionalmente pela indústria de engenharia de software.
Engenharia de Software II 27
UML
❖ Deve ficar bem claro, que a UML não é uma linguagem de programação, e sim uma linguagem de modelagem, uma notação, cujo objetivo é auxiliar os engenheiros de software a definirem as características do software, tais como seus requisitos, seu comportamento, seus estrutura lógica, a dinâmica de seus processos e até mesmo suas necessidades físicas em relação ao equipamento sobre o qual o sistema deverá ser implantado.
❖ Tais características podem ser definidas por meio da UML antes do software começar a ser realmente desenvolvido.
Engenharia de Software II 28
UML
❖ Além disso, cumpre destacar que a UML não é um processo de desenvolvimento de software e tampouco está ligada a um de forma exclusiva, sendo totalmente independente, podendo ser utilizada por muitos processos de desenvolvimento diferentes ou mesmo da forma que o engenheiro considerar mais adequada.
Engenharia de Software II 29
Breve Histórico da UML❖ A UML surgiu da união de três métodos de modelagem:
❖ O método de Booch, o método OMT (Object Modeling Technique), de Jacobson; e
❖ O método OOSE (Object-Oriented Software Engineering) de Rumbaugh.
❖ Estes eram até meados da década de 1990, os métodos de modelagem orientada a objetos mais populares entre os profissionais da área de desenvolvimento de software.
Engenharia de Software II 30
Breve Histórico da UML
❖ A união desses métodos contou com o amplo apoio da Rational Software, que a incentivou e financiou.
❖ O esforço inicial do projeto começou com a união do método de Booch ao OMT de Jacobson, o que resultou no lançamento do Método Unificado, no final de 1995.
❖ Logo em seguida, Rumbaugh juntou-se a Booch e Jacobson na Rational Software, e seu método OOSE começou também a ser incorporado à nova metodologia.
Engenharia de Software II 31
Breve Histórico da UML
❖ O trabalho de Booch, Jacobson e Rumbaugh, conhecidos popularmente como “Os Três Amigos”, resultou no lançamento, em 1996, da primeira versão da UML propriamente dita.
❖ Em 1997, a UML foi adotada pela OMG (Object Management Group ou Grupo de Gerenciamento de Objetos), como uma linguagem-padrão de modelagem.
❖ A versão 2.0 da linguagem foi oficialmente lançada em julho de 2005.
❖ http://www.omg.org/
Engenharia de Software II 32
Rápido Resumo dos Diagramas da UML
❖ Será descrito brevemente cada um dos diagramas oferecidos pela UML, destacando suas principais características.
Engenharia de Software II 33
Diagrama de Caso de Uso
❖ O Diagrama de Caso de Uso é o diagrama mais geral e informal da UML, utilizado normalmente nas fases de levantamento e análise de requisitos do sistema, embora venha a ser consultado durante todo o processo de modelagem e possa servir de base para outros diagramas.
Engenharia de Software II 34
Diagrama de Caso de Uso
❖ Apresenta uma linguagem simples e de fácil compreensão para que os usuários possam ter uma ideia geral de como o sistema irá se comportar.
❖ Procura identificar os atores (usuários, outros sistemas ou até mesmo algum hardware especial) que utilizarão de alguma forma o software, bem como os serviços, ou seja, as funcionalidades que o sistema disponibilizará aos atores, conhecidas nesse diagrama como casos de uso.
Engenharia de Software II 35
Diagrama de Caso de Uso
❖ Apresenta uma linguagem simples e de fácil compreensão para que os usuários possam ter uma ideia geral de como o sistema irá se comportar.
❖ Procura identificar os atores (usuários, outros sistemas ou até mesmo algum hardware especial) que utilizarão de alguma forma o software, bem como os serviços, ou seja, as funcionalidades que o sistema disponibilizará aos atores, conhecidas nesse diagrama como casos de uso.
Engenharia de Software II 36
Diagrama de Caso de Uso
Engenharia de Software II 37
Diagrama de Classes
❖ O Diagrama de Classes é provavelmente o mais utilizado e é um dos mais importantes da UML.
❖ Serve como apoio para a maioria dos demais diagramas.
❖ Como o próprio nome diz, define a estrutura das classes utilizadas pelo sistema, determinando os atributos e métodos que cada classe tem, além de estabelecer como as classes se relacionam e trocam informações entre si.
Engenharia de Software II 38
Diagrama de Classes
Engenharia de Software II 39
Diagrama de Classes
Engenharia de Software II 40
Diagrama de Classes
Engenharia de Software II 41
Diagrama de Objetos*
❖ O Diagrama de Objetos está amplamente associado ao diagrama de Classes.
❖ Na verdade, o diagrama de objetos é praticamente um complemento do diagrama de classes e bastante dependente deste.
❖ O diagrama fornece uma visão dos valores armazenados pelos objetos de um diagrama de classes em um determinado momento de execução de um processo de software.
Engenharia de Software II 42
Diagrama de Objetos
Engenharia de Software II 43
Diagrama de Objetos
Engenharia de Software II 44
Diagrama de Pacotes*❖ O Diagrama de Pacotes é um diagrama estrutural que
tem por objetivo representar os subsistemas ou submódulos englobados por um sistema de forma a determinar as partes que o compõem.
❖ Pode ser utilizado de maneira independente ou associado com outros diagramas.
❖ Este diagrama pode ser utilizado também para auxiliar a demonstrar a arquitetura de uma linguagem, como ocorre com a própria UML ou ainda para definir as camada de um software ou de um processo de desenvolvimento.
Engenharia de Software II 45
Diagrama de Pacotes
Engenharia de Software II 46
Diagrama de Sequência❖ O Diagrama de Sequência é um diagrama comportamental que
preocupa-se com a ordem temporal em que as mensagens são trocadas entre os objetos envolvidos em um determinado processo.
❖ Em geral, baseia-se em um caso de uso definido pelo diagrama de mesmo nome e apoia-se no diagrama de classes para determinar os objetos das classes envolvidas em um processo.
❖ Um diagrama de sequência costuma identificar o evento gerado do processo modelado, bem como o ator responsável por esse evento, e determina como o processos deve se desenrolar e ser concluído por meio da chama de métodos disparados por mensagens enviadas entre os objetos.
Engenharia de Software II 47
Diagrama de Sequência
Engenharia de Software II 48
Diagrama de Sequência
Engenharia de Software II 49
Diagrama de Comunicação❖ O Diagrama de Comunicação era conhecido como de Diagrama
de Colaboração até a versão 1.5 da UML, tendo o seu nome modificado para diagrama de comunicação a partir da versão 2.0.
❖ Está amplamente associado ao diagrama de sequência: na verdade, um complementa o outro.
❖ As informações mostradas no diagrama de comunicação com frequência são praticamente as mesmas apresentadas no de sequência, porém com um enfoque distinto, visto que esse diagrama não se preocupa com a temporalidade do processo, concentrando-se em como os elementos do diagrama estão vinculados e quais mensagens trocam entre si durante o processo.
Engenharia de Software II 50
Diagrama de Comunicação
Engenharia de Software II 51
Diagrama de Comunicação
Engenharia de Software II 52
Diagrama de Máquina de Estados❖ O Diagrama de Máquina de Estados demonst ra o
comportamento de um elemento por meio de um conjunto finito de transições de estado, ou seja, uma máquina de estados.
❖ Além de poder ser utilizado para expressar o comportamento de uma parte do sistema, quando é chamado de máquina de estado comportamental, também pode ser usado para expressar o protocolo de uso de parte de um sistema, quando identifica uma máquina de estados de protocolo.
❖ Como o diagrama de sequência, o de máquina de estados pode basear-se em um caso de uso, mas também pode ser utilizado para acompanhar os estados de outros elementos, como, por exemplo, uma instância de uma classe.
Engenharia de Software II 53
Diagrama de Máquina de Estados
Engenharia de Software II 54
Diagrama de Máquina de Estados
Engenharia de Software II 55
Diagrama de Atividade❖ O Diagrama de Atividade era considerado um caso especial do
antigo diagrama de gráfico de estados, hoje conhecido como diagrama de máquina de estados, conforme descrito anteriormente.
❖ A partir da UML 2.0, foi considerado independente do diagrama de máquina de estados.
❖ O diagrama de atividade preocupa-se em descrever os passos a serem percorridos para a conclusão de uma atividade específica, podendo esta ser representada por um método com certo grau de complexidade ou mesmo por um processo completo.
❖ O diagrama de atividade concentra-se na representação do fluxo de controle de uma atividade.
Engenharia de Software II 56
Diagrama de Atividade
Engenharia de Software II 57
Diagrama de Atividade
Engenharia de Software II 58
Diagrama de Atividade
Engenharia de Software II 59
Diagrama de Visão Geral de Interação
❖ O Diagrama de Visão Geral de Interação é uma variação do diagrama de atividade que fornece uma visão geral dentro de um sistema ou processo de negócio.
❖ Esse diagrama passou a existir apenas a partir da UML 2.
Engenharia de Software II 60
Diagrama de Visão Geral de Interação
Engenharia de Software II 61
Diagrama de Componentes❖ O Diagrama de Componentes está amplamente
associado à linguagem de programação que será utilizada para desenvolver o sistema modelado.
❖ Esse diagrama representa os componentes do sistema quando o mesmo for ser implementado em termos de módulos de código-fonte, bibliotecas, formulários, arquivos de ajuda, módulos executáveis etc. e determina como tais componentes estarão estruturados e irão interagir para que o sistema funcione de maneira adequada.
Engenharia de Software II 62
Diagrama de Componentes
Engenharia de Software II 63
Diagrama de Componentes
Engenharia de Software II 64
Diagrama de Implantação
❖ O Diagrama de Implantação determina as necessidades de hardware do sistema , as características físicas como servidores, estações, topologias e protocolos de comunicação, ou seja, todo o aparato físico sobre o qual o sistema deverá ser executado.
Engenharia de Software II 65
Diagrama de Implantação
Engenharia de Software II 66
Diagrama de Implantação
Engenharia de Software II 67
Síntese Geral dos Diagramas
❖ Os diagramas da UML dividem-se em diagramas estruturais e diagramas comportamentais, sendo que os últimos contêm ainda uma subdivisão representada pelos diagramas de interação.
Engenharia de Software II 68
Síntese Geral dos Diagramas
Engenharia de Software II 69
Próxima Aula
• Ferramentas CASE Orientadas a Objetos; e
• Orientação a Objetos
Engenharia de Software II 70
Dúvidas
• Conteúdo • Moodle • (http://wagnerglorenz.com.br/moodle/)
• Dúvidas
Engenharia de Software II 71
Referências Bibliográficas
• GUEDES, Gilleanes T. A.. UML: uma abordagem prática. São Paulo: Novatec, 2004.
Engenharia de Software II 72