Download - Processo unificado e notação uml

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.

mailto:[email protected]

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.


Prática 1: Desenvolvimento Iterativo


Cada iteração resulta e m u m r e l e a s e executável

Análise de Riscos


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.


Prática 3: Uso de Arquitetura baseada em Componentes

• Base para reuso

• Reuso de Componentes

• Reuso de Arquitetura


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


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


Testes em cada Iteração


Prática 6: Gerenciar Mudanças

❖ O que você quer controlar? ❖ workspaces seguros para cada desenvolvedor ❖ Gerenciamento de build/integração automatizados ❖ Desenvolvimento paralelo


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;


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


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


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


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.


Conceitos Básicos do RUP


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.


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].


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


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


Trabalhador , Atividade e Artefato


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.


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.


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.


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.


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.


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.


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/


http://www.omg.org/

Rápido Resumo dos Diagramas da UML

❖ Será descrito brevemente cada um dos diagramas oferecidos pela UML, destacando suas principais características.


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.



❖ 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.


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.


Diagrama de Classes


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.


Diagrama de Objetos


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.


Diagrama de Pacotes


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.


Diagrama de Sequência


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.


Diagrama de Comunicação


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.


Diagrama de Máquina de Estados


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.


Diagrama de Atividade


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.


Diagrama de Visão Geral de Interação


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.


Diagrama de Componentes


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.


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.


Síntese Geral dos Diagramas


Próxima Aula

• Ferramentas CASE Orientadas a Objetos; e

• Orientação a Objetos


Dúvidas

• Conteúdo • Moodle • (http://wagnerglorenz.com.br/moodle/)

• Dúvidas

• [email protected]


http://wagnerglorenz.com.br/moodle/

mailto:[email protected]

Referências Bibliográficas

• GUEDES, Gilleanes T. A.. UML: uma abordagem prática. São Paulo: Novatec, 2004.


Download - Processo unificado e notação uml

Top Related