Visão geral2

Prévia do material em texto

ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
 
Unidade 2 – Introdução à Análise de Sistemas
WEBAULA 1
 
2.1 Visão Geral da Unified Modeling Language (UML)
A UML foi criada a partir da fusão de três métodos dos autores - Booch, Rumbaugh (OMT- Object Modeling Technique) e Jacobson (OOSE – Object-Oriented Software Engineering). A concretização da UML aconteceu em 1997. Atualmente, a última versão da UML é 2.5 e a OMG é a organização responsável em manter e administrar a UML. A Figura 2.1 ilustra o nome de vários métodos orientados a objetos.
Conforme Booch; Jacobson e Rumbaugh (2006, p. 13), a UML é “uma linguagem padrão para a elaboração da estrutura de projetos de software. A UML é uma linguagem para visualização, especificação, construção e documentação de artefatos que façam uso de sistemas complexos de software”.
Figura 2.1 – Métodos Orientados a Objetos
Fonte: < http://arquivo.devmedia.com.br/artigos/Renato_Groffe/Modelagem_UML/Modelagem_UML1.jpg >. Acesso em: 30 out. 2015.
A UML apresenta um conjunto de técnicas de modelagem gráficas, integrando vários elementos (objetos, classes, atributos, etc.) do paradigma orientado a objetos. A UML não se aplica, exclusivamente, a uma etapa (fase ou atividade) do processo de desenvolvimento de software e nem a um Modelo de Engenharia de Software, mas se apoia no desenvolvimento incremental e iterativo, através de modelos (um conjunto de diagramas) que podem evoluir com a inclusão de novos detalhes.
Importante!
Um modelo é uma descrição simplificada da realidade, apresentado a partir de uma perspectiva específica e criado para proporcionar uma melhor compreensão do sistema. Cada modelo pode ser expresso em diferentes níveis de precisão, constituindo um conjunto de diagramas consistentes entre si e acompanhados de técnicas de modelagem textuais. Um diagrama é uma visão sobre um modelo, o qual proporciona uma representação parcial do sistema (Booch, Jacobson e Rumbaugh 2006).
Booch, Jacobson e Rumbaugh (2006) consideram as principais características da UML:
a) Centrado na arquitetura: a arquitetura do sistema é utilizada como principal artefato para a conceituação, construção, gerenciamento e evolução do sistema em desenvolvimento, representando uma visão do projeto como um todo;
b) Orientado a Use Cases (Casos de Uso): os use cases são utilizados como o principal artefato para o estabelecimento do comportamento desejado do sistema;
c) Processo iterativo: refere-se ao gerenciamento de sequências de versões executáveis e incrementais, sendo que cada nova versão incorpora os artefatos incrementais em relação às demais, conforme mostra a Figura 02, a seguir.
Figura 2.2 – Métodos Orientados a Objetos
Fonte: < http://www.ceara.pro.br/introducao/VII-abordagem/imagens/interacao.jpg >. Acesso em: 01 dez. 2015.
A UML 2.0 abrange quatorze técnicas de modelagem, classificadas em estruturais e comportamentais. As técnicas estruturais enfatizam a estrutura dos elementos estáticos, a partir da identificação dos objetos. As técnicas de modelagem comportamentais enfatizam o comportamento dinâmico e a interação entre os elementos do sistema.
Quadro 2.1 - Relação das técnicas de modelagem da UML 2.0
Fonte: BEZERRA (2007)
As técnicas de modelagem propostas pela UML não estão vinculadas, diretamente, a uma atividade (Análise, Projeto, Implementação e Testes) do processo de desenvolvimento de software e não dizem quem deve fazer o que, quando e como. Bezerra (2009) e demais autores, sugerem a adoção do Diagrama e Documentação de Casos de Uso, do Diagrama de Classes, do Diagrama de Objetos e do Diagrama de Estruturas Compostas para modelar a atividade de análise e, posteriormente, fazer um refinamento dessas técnicas e complementar com os diagramas de iteração para modelar a atividade de projeto, representando uma visão física de desenvolvimento.
	
	Conheça o material oficial da UML 2.5.: .
Vamos, agora, refletir sobre a Unified Modeling Language (UML):
A UML consiste da fusão de três métodos, abrangendo atualmente quatorze técnicas de modelagem. Qual foi a contribuição de cada método (Booch, Jacobson e Rumbaugh) na criação da UML?
2.1  Diagrama de Use Cases (Casos de Uso) e Documentação 
Vamos iniciar o estudo das técnicas de modelagem da UML, começando com o Diagrama de Casos de Uso e o Diagrama de Classes.
O Diagrama de Casos de Uso representa as funcionalidades do sistema (requisitos funcionais do sistema) e os elementos externos ao sistema que interagem com ele. É um diagrama abstrato e flexível com poucos elementos de notação, que representa a interação entre os elementos Ator e Casos de Uso, indicando os serviços ou funcionalidades que o sistema disponibiliza para os usuários. Posteriormente, deve ser feita a documentação de cada Caso de Uso e ainda a sua especificação através dos diagramas de Atividades, Sequência ou Comunicação, consistindo e validando os casos de usos com os objetos que são manipulados durante a execução de um Caso de Uso. Segundo Bezerra (2007), o Modelo de Casos de Uso (MCU) é uma representação das funcionalidades do sistema e dos elementos externos ao sistema que interagem com ele. Um Diagrama de Casos de Uso é representado pelos elementos Atores, Casos de Uso e Relacionamentos.  A Figura 2.3 ilustra um Diagrama de Casos de Uso:
Figura 2.3 – Exemplo de um Diagrama de Casos de Uso
Fonte: A autora (2016).
Os Casos de Uso (use cases) representam qualquer interação de serviços (funcionalidades) entre um Ator e o sistema, sem revelar a estrutura e o comportamento interno do sistema. Cada serviço deve ser representado, individualmente, como um Caso de Uso. Eles são representados por uma elipse, contendo uma breve descrição dentro do seu símbolo que identifica qual serviço o Caso de Uso assume. Recomenda-se nomeá-lo com o verbo no infinitivo mais o substantivo(s). Exemplo: Cadastrar Curso ou Manter Curso, Realizar Avaliação, Lançar Nota de Avaliação. Os Atores representam os papéis desempenhados por pessoas, hardware ou outro sistema que pode utilizar ou interagir com as funcionalidades do sistema. Um ator primário é responsável em fornecer os dados para que ocorra a execução do serviço.
Os Atores são representados por símbolos de “bonecos magros”, identificados com um nome que representa qual o papel assumido no contexto do sistema. Cada Ator deve representar um único papel. A interação entre um Ator e um Caso de Uso é representada por um relacionamento, os quais são possíveis: associação, generalização, extensão e inclusão.
Vídeo
Assista ao vídeo para fixar os conceitos abordados!
Disponível em: < https://www.youtube.com/watch?v=fx0mBsgS4Uw >. Acesso em: 16 nov. 2015
A Associação é um tipo de relacionamento entre os Atores que interagem com o sistema. Ela pode ser estabelecida entre o Ator e Caso de Uso ou entre um Caso de Uso e outros Casos de Uso. Uma associação estabelecida entre um Ator e Casos de Uso representa que o Ator utiliza-se, de alguma maneira, da função representada pelo Caso de Uso. A Generalização é um tipo de relacionamento entre Casos de Uso ou entre Atores. A Generalização de Atores é uma representação abstrata de papéis e a Generalização de Casos de Uso representa dois ou mais Casos de Uso que apresentam características semelhantes. A Figura 2.4 ilustra um exemplo de Generalização de Atores e Casos de Uso.
Figura 2.4 – Notação de Generalização
Fonte: A autora (2016).
	
	Faça a leitura dos materiais para conhecer mais sobre o Diagrama de Casos de Uso! .
O relacionamento de Extensão representa um relacionamento de dependência entre Casos de Uso, indicado pelo estereótipo <<extend>>. A Extensão é utilizada para descrever cenários opcionais de um Caso de Uso, que somente ocorrerão se uma determinada condição for satisfeita (GUEDES, 2008). O relacionamento de dependência <<extend>> é representado por uma seta que parte do Caso de Uso “estendido” para o Caso de Uso “base”. A Figura 2.5 ilustra um exemplo de Extensão entre os Casos de Uso.
Figura 2.5 – Exemplo do Relacionamento de Extensão
Fonte: A autora (2016).
O relacionamento de Inclusãorepresenta um relacionamento de dependência entre Casos de Uso, indicado pelo estereótipo <<include>>. Esse relacionamento é utilizado quando existe uma situação ou rotina comum a mais de um Caso de Uso. A inclusão indica uma obrigatoriedade com outro Caso de Uso, sendo que a execução do primeiro obriga também a execução do segundo. O relacionamento de dependência <<include>> é representado por uma seta que parte do Caso de Uso “base” para o Caso de Uso “incluído”. A Figura 2.6 ilustra um exemplo de Inclusão entre os Casos de Uso:
Figura 2.6 – Exemplo do Relacionamento de Inclusão
Fonte: A autora (2016).
	
	Saiba mais sobre Modelar Sistemas em UML - Casos de Uso no link: .
Após a criação do Diagrama de Casos de Uso, eles são complementados com uma documentação. Não existe um formato específico de documentação para Casos de Uso definido pela UML. O formato de documentação de um Caso de Uso é flexível, permitindo que se documente o Caso de Uso da forma que se considerar melhor, até mesmo através do uso de pseudocódigo ou de código de uma linguagem de programação. A seguir, é exemplificada a documentação do Caso de Uso “Cadastrar Curso” no formato descritivo em cenários, especificando-os em Cenário Principal e Cenário(s) Alternativo(s). O cenário principal apresenta uma descrição de uma tarefa que represente o mundo perfeito, sem exceções, e o cenário alternativo relata qualquer situação que represente uma exceção (condição) do cenário principal.
Exemplo de Formato Descritivo Numerado:
Número: 001
Caso de Uso: Cadastrar Curso
Descrição: Autor informa os dados para realizar o cadastro de um curso.
Ator: Autor
 
Cenário Principal:
1. Autor solicita cadastro de curso.
2. Sistema exibe o cadastro de cursos.
3. Autor informa código do curso.
4. Sistema verifica que não existe código do curso cadastrado.
5. Autor informa demais dados.
6. Sistema verifica que categoria de curso está cadastrada.
7. Sistema recupera dados da categoria de curso.
8. Autor confirma o cadastro.
9. Sistema registra curso.
10. Sistema emite Msg 1, informando que o curso foi cadastrado com sucesso.
11. Sistema encerra o caso de uso.
Cenário Alternativo 4:
4. Sistema verifica que existe código do curso cadastrado.
4.1 Sistema recupera dados do curso associado ao código.
4.2 Sistema permite alteração ou exclusão do curso.
4.3 Autor escolhe a opção de alteração.
4. 4 Autor informa dados (nome, descrição, objetivo e carga horária) a serem alterados.
4.5 Autor confirma alteração dos dados.
4.6 Sistema atualiza dados do curso.
4.7 Sistema encerra o caso de uso.
Cenário Alternativo 4.3:
4.3.     Autor escolhe a opção de exclusão.
4.3.1   Sistema verifica que o curso não está associado a outro objeto.
4.3.2.  Sistema emite Msg 04, confirmando a exclusão do curso.
4.3.3.  Autor confirma a exclusão do curso.
4.3.4.  Sistema exclui o curso.
4.3.5.  Sistema encerra o caso de uso.
Vamos, agora, refletir sobre o Diagrama de Casos de Uso:
O Diagrama de Casos de Uso, conforme a classificação das técnicas de modelagem da UML é uma técnica comportamental. Assim, qual é a aplicabilidade do Diagrama de Casos de Uso?
2.1 Diagrama de Classes
O Diagrama de Classes é a principal técnica de modelagem da UML, assim, vamos explorar nesta seção os seus principais componentes, tratando-o como um diagrama da fase de análise.  O Diagrama de Classes representa a modelagem da parte estática do sistema, representando um conjunto de classes com seus atributos, operações e relacionamentos. O objetivo do Diagrama de Classes é permitir a visualização das classes utilizadas pelo sistema e como estas se relacionam. Ele apresenta uma visão estática de como as classes estão organizadas, preocupando-se em definir sua estrutura lógica (GUEDES, 2008).
Considerando que o Diagrama de Casos de Uso está concluído, a próxima etapa é analisá-los para iniciar o trabalho de identificação das classes de objetos. A partir da elaboração de um primeiro estágio do Diagrama de Classes, o mesmo evoluirá à medida que o sistema é desenvolvido, o qual o diagrama deve ser incrementado com novos detalhes. A seguir, apresentamos os principais elementos do Diagrama de Classes.
Classe:
Uma Classe é representada por um retângulo com, no máximo, três partes. Na primeira parte (de cima para baixo) é exibido o nome da Classe. Por convenção, o nome é apresentado no singular e com as palavras compostas começando por letra maiúscula. Na segunda parte, são declarados os atributos e na terceira parte, são declaradas as operações.
O nome de um atributo é declarado por um substantivo, tipicamente, em letra minúscula e para palavras compostas usa-se concatená-las, sendo que a partir da segunda palavra inicia-se com letra maiúscula, por exemplo, dataNascimento. O nome de uma operação é declarado por um verbo, usando a mesma convenção de letras minúsculas e maiúsculas dos atributos. A Figura 2.7 ilustra alguns exemplos de representação de Classes:
Figura 2.7 – Notação de Classe
Fonte: A autora (2016).
Relacionamentos:
Na UML, os modos pelos quais os itens podem estar conectados a outros, isto é, logicamente ou fisicamente, são modelados como relacionamentos, que permitem compartilhar informações e colaboram para a execução dos processos pelo sistema (GUEDES, 2008).
Existem quatro tipos de relacionamentos:
a)    Associações: são relacionamentos estruturais entre instâncias. Tipos de associações: Unária (autoassociação ou reflexiva), binária, ternária, classe associativa e agregação.
b)    Generalizações: conectam classes generalizadas a outras mais especializadas, o que é conhecido como relacionamento Generalização e Especialização;
c)    Dependências: são relacionamentos de utilização entre casos de uso, classes, pacotes e anotações;
d)    Realizações: são relacionamentos que especificam um contrato de execução entre classes e interfaces.
O relacionamento do tipo Associação é representado por uma reta, ligando as classes envolvidas. Pode-se indicar um nome na associação e a navegabilidade na extremidade das associações que indicará o sentido em que as informações são transmitidas entre os objetos das classes associadas. As Associações podem, também, possuir nomes (títulos). A Figura 2.8 ilustra a notação de Associação:
Figura 2.8 – Notação de Associação
Fonte: A autora (2016).
O atributo a ser transmitido na Associação é implícito, não sendo apresentado na classe para a qual foi transmitido. Em cada extremidade da associação deve ser definida a sua multiplicidade, a qual depende de pressupostos e de como são definidas as fronteiras de um problema, conforme as regras de negócio. O quadro a seguir ilustra os tipos de multiplicidade:
 Quadro 2.3 – Tipos de Multiplicidades
	Multiplicidade
	Significado
	0..1
	Nenhum e no máximo um. Representa que os objetos associados não precisam obrigatoriamente estar relacionados, mas se houver relacionamento indica que apenas uma instância da classe se relaciona com as instâncias da classe associada.
	1..1
	Um e exatamente um. Representa que apenas uma instância da classe se relaciona com as instâncias da classe associada.
	0..*
	Nenhum e no máximo muitos. Representa que pode ou não haver instâncias da classe participando do relacionamento e que muitas instâncias da classe participam da classe associada.
	*
	Muitos. Representa que multas instâncias da classe estão envolvidas no relacionamento.
	1..*
	No mínimo 1 e no máximo muitos. Representa que há pelo menos uma instância da classe envolvida no relacionamento, podendo haver muitos objetos envolvidos.
	Intervalo específico
	Representa um intervalo inicial e final, indicando que existe pelo menos um número específico de instâncias iniciais envolvidas no relacionamento com um número limite de instâncias, exemplo 1-5.
Fonte: Booch; Jacobson e Rumbaugh (2006)
A Associação Unária ou Reflexiva ocorre quando existe um relacionamento de um objeto com objetos da mesma classe, em que cada um tem um papel distinto nessa associação. A Figura 2.9 ilustra a notação e um exemplo de Associação Unária.
Figura 2.9 – Notação e Exemplode Associação Unária
Fonte: A autora (2016).
A Associação Binária ocorre quando são definidos relacionamentos entre objetos de duas classes. A existência de uma associação entre dois objetos possibilita a troca de mensagens entre eles. A Figura 2.10 ilustra a notação e um exemplo de Associação Binária:
Figura 2.10 – Notação e Exemplo de Associação Binária
Fonte: A autora (2016).
Vídeo
Assista ao vídeo para fixar os conceitos abordados!
Disponível em: < https://www.youtube.com/watch?v=9Wdjuds5vPQ >. Acesso em: 16 nov. 2015
A Classe Associativa também é chamada de classe de associação. Em vez de estar ligada a outras classes, ela está ligada à associação, a qual, normalmente, aparece quando duas ou mais classes estão associadas e é necessário manter características (atributos) específicas da Associação, sendo que uma classe associativa pode participar de outros relacionamentos. A Figura 2.11 ilustra a notação e um exemplo de Classe Associativa.
Figura 2.11 – Notação e Exemplo de Classe Associativa
Fonte: A Autora (2016)
A Agregação demonstra que um objeto (chamado objeto-todo) precisa ser complementado com um ou mais objetos de outra classe (chamados objeto-parte), sendo essa associação conhecida como “Todo-Parte”. Ambas as classes podem “viver” de forma independente, ou seja, não existe uma ligação forte entre as duas.  O símbolo de Agregação difere do de Associação por conter um losango na extremidade da classe que contém os objetos-todo. Essa análise dependerá do domínio do problema em estudo. A Figura 2.12 ilustra a notação e um exemplo de Agregação.
Figura 2.12 – Notação e Exemplo de Agregação
Fonte: A autora (2016)
Outro tipo de Agregação é a Composição. Essa Associação é uma variação da Agregação, na qual é estabelecido um vínculo mais forte entre o objeto-todo e os objetos-parte, demonstrando que os objetos-parte devem se associar a um único objeto-todo. Utiliza-se um losango preenchido para indicar a Composição.  A Figura 2.13 ilustra a notação e um exemplo de Associação Composição. Ambas as classes “vivem” unidas de forma dependente, ou seja, existe uma ligação forte entre as duas. Os objetos da classe parte são dependentes, em termos de existência, da classe todo, ambas são partes de um único todo. Os objetos da classe parte não podem viver quando o todo é destruído. Utiliza-se um losango preenchido para indicar a Composição.
 Figura 2.13 – Notação e Exemplo de Composição
Fonte: A autora (2016)
	
	Faça a leitura dos materiais para conhecer mais sobre o Diagrama de Classes!
O relacionamento do tipo Generalização representa uma classe genérica com características e comportamentos comuns a outras classes especializadas, demonstrando a ocorrência de herança e possivelmente de métodos polimórficos nas classes especializadas. A herança é a possibilidade de uma classe utilizar os atributos e métodos de outra como se fossem seus.  Na representação desse relacionamento, a classe generalizada é chamada de “superclasse” e as especializadas são chamadas de “subclasses”. Ainda na representação desse relacionamento, pode ocorrer que uma subclasse herde atributos e operações de duas ou mais superclasses, o qual indica uma herança múltipla. A Figura 2.14 ilustra a notação e um exemplo de Herança e Herança Múltipla, o qual a subclasse Extensão herda características das superclasses Curso e Evento.
 Figura 2.14 – Notação e Exemplo de Herança e Herança Múltipla
 
Fonte: A autora (2016)
	
	Saiba mais sobre a UML no link:
Vamos, agora, refletir sobre o Diagrama de Classes:
O Diagrama de Classes, conforme a classificação das técnicas de modelagem da UML é uma técnica estrutural. Assim, qual é a aplicabilidade do Diagrama de Classes? Como é possível consistir o Diagrama de Casos de Uso com o Diagrama de Classes?
RESUMO DA UNIDADE DE ENSINO:
Esta unidade apresentou uma contextualização UML e suas técnicas de modelagem, classificadas em estruturais e comportamentais, que integram vários elementos (objetos, classes, atributos, etc.) do paradigma orientado a objetos. Iniciou o estudo das técnicas de modelagem da UML com o Diagrama de Casos de Uso, que é constituído dos elementos gráficos Atores, Casos de Uso (Use Cases) e relacionamentos, para representar as funcionalidades do sistema e suas interações. Após a especificação do Diagrama de Casos de Uso, se faz a documentação de cada um, sendo o formato descritivo o mais recomendado. Posteriormente, inicia-se uma primeira versão do Diagrama de Classes, que é constituído dos elementos gráficos Classes e relacionamentos, conforme a abstração das regras de negócio do sistema, para depois refiná-los em outras versões e visões até atender completamente a solução proposta.
PRATIQUE!
Execute a ferramenta CASE que você instalou, conforme sugerimos na Unidade de Ensino 1, e desenhe todos os diagramas que foram exemplificados nesta Unidade.
Bom trabalho!