ANÁLISE E ORIENTADA A OBJETOS I

Prévia do material em texto

ANÁLISE E ORIENTADA A OBJETOS I
Visão geral
Apresentação da disciplina:
Olá ! Seja bem-vindo a nossa WEBAULA!
Vamos refletir sobre a formação do pedagogo e sua atuação nos espaços não escolares e conhecer um pouquinho sobre qual é a função do pedagogo com a pedagogia social, pedagogia empresarial, pedagogia hospitalar e a educação do campo. Porém, precisamos ter claro que esses não são alguns, mas não os únicos espaços de atuação do pedagogo fora da escola.
 
Objetivos:
Olá, Caro Aluno! Seja bem vindo à disciplina de Análise Orientada a Objetos I. É com imenso prazer que eu, professora Iolanda Cláudia Sanches Catarino, apresento a você a nossa webaula, contemplando uma visão geral da atividade de Análise de Sistemas, conforme o Paradigma Orientado a Objetos e o Processo Unificado, abordando os conceitos básicos do paradigma e as técnicas iniciais de modelagem.
Nessa disciplina, você será levado a compreender a importância da modelagem de um sistema computacional para documentar a atividade de Análise de Sistemas, através das técnicas de modelagem de um método de desenvolvimento de software, bem como estudar, especificar e consistir as técnicas de modelagem textuais e diagramais do software.
Conteúdo Programático:
Unidade de estudo 1: Paradigma Orientado a Objetos e o Processo Unificado:
Fundamentos da Análise de Sistemas.
Paradigma Orientado a Objetos.
Fundamentos do Processo Unificado.
Unidade de estudo 2: Introdução à Análise de Sistemas:
Visão Geral das Técnicas de Modelagem da Unified Modeling Language (UML).
Modelagem de Casos de Uso.
Modelagem de Classes.
Metodologia:
Em cada Unidade de Estudo, você será conduzido à leitura do texto e das figuras, ao acesso aos objetos de aprendizagem e a especificar técnicas de modelagem da atividade de Análise de Sistemas em uma ferramenta CASE, para consolidar o seu processo de aprendizagem.
Os conteúdos programáticos ofertados nessa disciplina serão desenvolvidos por meio das tele aulas de forma expositiva e interativa (chat - tira dúvidas em tempo real), aula atividade por chat para aprofundamento e reflexão e web aulas, que estarão disponíveis no Ambiente Colaborar, compostas de conteúdos de aprofundamento, reflexão e atividades de aplicação dos conteúdos e avaliação. Serão também realizadas atividades de acompanhamento tutorial, participação em Fórum, atividades práticas e estudos independentes (auto estudo), além do material didático da disciplina.
 
Avaliação Prevista:
Em conformidade com o modelo de ensino vigente da UNOPAR.
O sistema de avaliação da disciplina compreende em assistir a teleaula, participação no fórum, produções textuais interdisciplinares (Portfólio), realização das avaliações virtuais e avaliação presencial embasada no material didático, teleaulas, webaulas e material complementar.
 
Critérios para Participação dos Alunos no Fórum:
Quando houver fórum de discussão o aluno será avaliado quanto ao conteúdo de sua postagem, onde deverá comentar o tópico apresentando respostas completas e com nível crítico de avaliação pertinente ao nível de pós-graduação. Textos apenas concordando ou discordando de comentários de outros participantes do fórum sem a devida justificativa ou complementação não acrescentam em nada ao debate da disciplina, sendo assim, devem ser evitados. Os textos devem sempre vir acompanhados das justificativas para a opinião do discente sobre o conteúdo discutido, para que assim, possamos dar continuidade ao debate em nível adequado. Além disso, podem ser utilizados citações de artigos, livros e outros recursos que fundamentem a opinião ou deem sustentação a sua posição crítica sobre o assunto. Deve ser respeitado o tópico principal do fórum, evitando debates que não tem relação com o tema selecionado pelo professor.
Habilidades e competências
Unidade 1
Competências: Conhecer e compreender os fundamentos da atividade de análise e princípios e conceitos do paradigma orientado a objetos. Conhecer e compreender o Processo Unificado.
Habilidades: Raciocinar de forma lógica. Abstrair e especificar requisitos. Analisar e interpretar. Negociar e liderar.
Unidade 2
Competências: Conhecer e compreender os métodos de desenvolvimento de sistemas na atividade de Análise de Sistemas. Conhecer e aplicar as técnicas de modelagem para documentar e especificar a atividade de Análise de Sistemas.
Habilidades: Raciocinar de forma lógica. Abstrair e especificar objetos. Analisar e interpretar. Negociar e liderar.
Unidade 1 – Paradigma Orientado A Objetos e O Processo Unificado
WEBAULA 1
1. Fundamentos da Análise de Sistemas
Com o crescimento da complexidade nos processos de negócio, a modelagem organizacional tem sido amplamente adotada para que a transição entre negócios e Tecnologias de Informação (TI) ocorra de forma tranquila e consistente, para atender os requisitos dos usuários, ou seja, as funcionalidades/serviços que o sistema deverá contemplar. Para desenvolver um Sistema de Informação (SI), o gerente de projetos de TI e sua equipe, entre eles o analista de sistemas, devem definir uma metodologia de desenvolvimento de sistemas que contemple procedimentos, um ou mais métodos com suas técnicas de modelagem e as tecnologias a serem adotadas no desenvolvimento do sistema, visando à qualidade do software. A Figura 1.1 ilustra a interpretação, compreensão e definição dos requisitos de um sistema, atividade comum entre o analista de sistemas e os usuários.
Figura 1.1 – Interpretação e Definição de Requisitos
Fonte: < http://bgnweb.com.br/portal2//wp-content/uploads/2015/06/The-Project-Cartoon-Beta.png >. Acesso em: 30 out. 2015.
A Engenharia de Software é uma parte da Engenharia de Sistemas que se ocupa de todos os aspectos da produção de software (SOMMERVILLE, 2011). Na concepção de Pressman (2011), a Engenharia deSoftware abrange um conjunto de três elementos: métodos, ferramentas e procedimentos. Dessa forma, possibilita ao gerente o controle do processo de desenvolvimento do software e oferece ao profissional uma base para a sua construção com qualidade.
O método proporciona os detalhes de “como fazer” para construir o software. Envolve um amplo conjunto de atividades que inclui: planejamento, análise de requisitos, análise e projeto, implementação e testes, como ilustra a Figura 1.2. Para Sommerville (2011), um método é uma abordagem estruturada para o desenvolvimento de software, facilitando a sua produção com qualidade e uma boa relação custo-benefício.
Figura 1.2 – Integração entre as Atividades de um Ciclo de Vida Básico
Fonte: Acervo da autora (2015).
Importante!
Na literatura, há vários métodos de desenvolvimento de software renomados, como o método de Coad & Yourdon (OOAD), Grady Booch (Booch Method), Ivar Jacobson (OOSE), James Rumbaugh (OMT), etc. Os métodos abrangem as atividades ou fases de desenvolvimento e apresentam para cada atividade as técnicas de modelagem representadas por diagramas ou de forma descritiva. Um conjunto de diagramas constitui um modelo do sistema.
Acesse um exemplo em: .
As ferramentas proporcionam apoio automatizado aos métodos de desenvolvimento de software, como as ferramentas CASE (Computer Assited Software Engineering – Engenharia de SoftwareAssistida por Computador) de modelagem, de banco de dados e de linguagens de programação. Os procedimentos referem-se às decisões que serão tomadas quanto ao planejamento do projeto, à escolha do método com as técnicas de modelagem que serão especificadas e demais padrões adotados, no desenvolvimento do software.
Vídeo
Assista ao vídeo para fixar os conceitos abordados! 
Disponível em: < https://www.youtube.com/watch?v=iRvZw9BQDYw >.
A Figura 1.3 representa um ciclo de vida do processo de desenvolvimento de software chamado Processo Unificado, sendo as principais atividades: Comunicação (Modelagem Organizacional), Planejamento (Levantamento de Dados ou Análise de Requisitos), Modelagem (Análise e Projeto), Construção (Implementação – Programação eTestes) e Implantação (Instalação e Manutenção).
Figura 1.3 – Processo de Desenvolvimento de Software – Processo Unificado
Fonte: < http://jkolb.com.br/wp-content/uploads/2013/12/up.png >. Acesso em: 30 out. 2015.
Na atividade de Comunicação realiza-se a especificação da modelagem organizacional, identificando os processos de negócio. Na atividade de Planejamento realiza-se a identificação dos requisitos do sistema e faz o estudo de sua viabilidade. Na atividade de Modelagem define–se o que e como vai ser desenvolvido o software, adequando o projeto de acordo com as tecnologias que serão adotadas para o seu desenvolvimento. Na atividade de Construção realiza-se a implementação correspondente à programação e testes do software e, por fim, na atividade de Implantação é feita a instalação do sistema para o usuário e, posteriormente, a sua manutenção.
A realização bem executada das três primeiras atividades de um ciclo de vida básico do projeto é essencial para o sucesso e qualidade do software desenvolvido.
	Acesse o link para saber mais a respeito de Visão Geral de Desenvolvimento: 
Um analista de sistemas é um profissional essencial em qualquer projeto de desenvolvimento de sistemas. Ele, na atividade de Análise de Requisitos, deve identificar, definir e especificar os requisitos funcionais e não funcionais do sistema. Na atividade de análise, define-se a solução do sistema, especificando o que será desenvolvido. Posteriormente, os demais profissionais da equipe de desenvolvimento definem como o software será desenvolvido e o implementam com consistência e qualidade técnica.
O profissional analista de sistemas precisa ter habilidades e competências para: analisar, projetar e desenvolver sistemas computacionais, principalmente sistemas de informação; definir o uso adequado de Tecnologias de Informação e Comunicação (TIC), conforme o domínio dos projetos; visualizar o sistema computacional de várias perspectivas, abstraindo soluções lógicas e físicas satisfatoriamente; e trabalhar com pessoas em equipe, mediar conflitos de ideias e gerenciar situações que exigem tomadas de decisão.
Importante!
Um Requisito Funcional (RF): representa um serviço ou uma funcionalidade que o sistema deve fornecer para atender uma necessidade do usuário.
Exemplo: Cadastrar Cliente; Realizar Orçamento; Emitir Nota Fiscal de Venda; Consultar Clientes e Gerar Relatório de Vendas.
Um Requisito Não-Funcional (RNF): representa restrições que o software deve atender ou qualidades específicas que ele deve ter.
Exemplo: O relatório de vendas deve ser gerado automaticamente às 18h, diariamente; Toda nota fiscal de venda será enviada para o endereço eletrônico do cliente, no prazo máximo de 24 horas, após e efetivação de uma venda.
Para Refletir
Vamos, agora, refletir sobre os Fundamentos da Análise de Sistemas: como o analista de sistemas pode garantir que os requisitos funcionais de um sistema sejam implementados com sucesso?
2.  Paradigma Orientado a Objetos
Segundo Bezerra (2007), pode-se dizer que o termo “paradigma da orientação a objetos” é uma forma de abordar um problema, visualizando um sistema de software como uma coleção de agentes interconectados chamados objetos, sendo cada um responsável por realizar tarefas específicas. A programação orientada a objetos teve início na década de 70, com a linguagem SIMULA, parte da linguagem Smalltalk, mas ganhou grande visibilidade na década de 80. Os métodos de modelagem orientados a objetos surgiram no final da década de 80, sendo que na década de 90 uma grande diversidade de autores lançou seus métodos, praticamente com propostas semelhantes.
No início da década de 90, os pesquisadores Grady Booch, Ivar Jacobson e James Rumbaugh uniram as melhores práticas de seus métodos e construíram um padrão de referência para modelagem orientada a objetos, lançando a Unified Modeling Language (UML - Linguagem de Modelagem Unificada).
Vídeo
Assista ao vídeo para conhecer um pouco mais sobre a história das linguagens de programação! 
Disponível em: <https://www.youtube.com/watch?v=81mX6ZdJvw8 >.
	Faça a leitura do artigo para conhecer mais sobre o Paradigma Orientado a Objetos e seus pilares! .
A seguir, apresentamos uma definição dos principais conceitos da abordagem orientada a objetos, suas correlações e exemplos.
Objeto:
Um objeto pode ser definido como qualquer coisa concreta ou abstrata com existência no mundo real, com características e comportamento próprio, sendo possível identificá-lo como único.  Na definição de Booch; Jacobson e Rumbaugh (2006, p. 456), um objeto é “uma entidade com uma fronteira bem-definida e uma identidade que encapsula o estado e comportamento”. Os objetos são descritos por seus atributos e operações. Um atributo é uma característica particular possuída por todos os objetos.  Uma operação é uma ação que um objeto executa ou está sujeito, ou seja, é uma ordem que faz um objeto reagir.  A implementação de uma operação é chamada de método. Um método representa o conjunto de passos (lógica) que um objeto executa para reagir a uma operação. Ele pode receber ou não parâmetros e pode retornar valores ao ser executado. Parâmetros são os valores utilizados durante a execução do método. A Figura 1.4 ilustra alguns exemplos de objetos concretos, como telefones e carro, e o objeto abstrato nota fiscal.
Figura 1.4 - Exemplos de Objetos Concretos e Abstratos
Fontes das imagens: < http://thumbs.dreamstime.com/z/telefones-celulares-modernos-e-velhos-34953118.jpg >. Acesso em: 30 out. 2015.
< http://gtudo.com/index.php?page=search/images&search=carro&type=images >. Acesso em: 30 out. 2015.
< http://www.jmgraficaebrindes.com.br/wp-content/uploads/Nota-Fiscal-Mod3-a.jpg >. Acesso em: 30 out. 2015.
Abstração:
O conceito de abstração consiste na concentração dos aspectos essenciais e relevantes de um objeto, inerentes ao contexto e ao domínio do sistema.  Na definição de Rumbaugh (1994, p. 599), o conceito de abstração representa a “habilidade mental que permite aos seres humanos visualizarem os problemas do mundo real com vários graus de detalhe, dependendo do contexto corrente do problema”. A Figura 1.5 ilustra atletas realizando esportes, abstraindo, assim, as características relevantes desses objetos, define-se a classe Esporte.
Figura 1.5 – Exemplo do Conceito de Abstração
Fontes das imagens: < http://www.portalsaudenoar.com.br/wp-content/uploads/2015/10/atletismo27.jpg >. Acesso em: 30 out. 2015.
<https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcQPXaHLmDwPltzjRTP-FihrlSuVXbKkGminDsQwFCoGUleXQXyB>. Acesso em: 30 out. 2015.
Classe:
Uma classe representa um grupo de objetos do mundo real que possui tipos de características e de comportamento em comum. Cada ocorrência de um objeto representa uma instância da classe. Na definição de Rumbaugh (1994, p. 32), uma classe “descreve um grupo de objetos com propriedades semelhantes (atributos), o mesmo comportamento (operações), os mesmos relacionamentos com outros objetos e a mesma semântica”.
A Figura 1.6 ilustra objetos reais de um domínio, por exemplo, funcionários de uma empresa. Observando as características relevantes para o domínio em questão, abstraímos as características comuns entre eles, definindo os seus atributos: matrícula, nome, data de nascimento, etc; assim, representamos na modelagem do sistema a classe Funcionário.
Figura 1.6 – Exemplo da Classe Funcionário
Fonte: < http://legalstrategy.com.br/?page_id=70 >. Acesso em: 30 out. 2015.
Vídeo
Assista ao vídeo para fixar os conceitos abordados!
Disponível em: <https://www.youtube.com/watch?v=ipC000O3rzU >.
Evento e Estado:
Eventos são os acontecimentos que fazem os objetos mudarem de estado. Na definição de Para Rumbaugh (1994, p. 114-115), um evento é “um estímulo individual de um objeto para outro; é algo que acontece em certo momento. É uma transmissão ou informação unidirecional de um objeto para outro”. Um estado representa a abstração de uma forma de apresentação dos objetosde uma classe em um determinado instante de tempo. Na definição de Booch; Jacobson e Rumbaugh (2006, p. 290), 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. Um objeto permanece em um estado por uma quantidade finita de tempo”. A transição de estado representa a mudança de estado de um objeto como resposta à chegada de um evento. Os eventos, assim como os estados, dependem da abstração aplicada, especificamente, a um contexto. A Figura 1.7 a seguir ilustra um exemplo de um objeto do tipo Livro, que num instante de tempo (t1) encontra-se no estado fechado e a partir de um evento (abrir, uma ação humana) o objeto reage e muda o seu estado para aberto, no instante de tempo seguinte (t2).
Figura 1.7 – Exemplo da Ocorrência e um Evento      
Fonte: < http://2.bp.blogspot.com/IICzHmVWR_4/UtaZAge031I/AAAAAAAAG0M/IqRIYNHnhuY/s1600/Book+Red.png >. Acesso em: 30 out. 2015.
< http://vidalonga.org/wp-content/uploads/2015/02/livros-sobre-saude.jpg >. Acesso em: 30 out. 2015.
Um evento, ao ser disparado, envia uma mensagem a uma operação do objeto, o qual o método correspondente é executado. O mecanismo de invocação de uma operação representa uma mensagem, ou seja, é a forma de conseguir executar um método.
Encapsulamento:
Representa o ato de reunir em uma estrutura chamada classe, as características e o comportamento dos objetos, sendo uma forma de organizá-los, permitindo que um objeto proteja a integridade de suas partes. Na definição de Rumbaugh (1994, p. 10), o conceito de encapsulamento é “também chamado de ocultamento de informações, consiste na separação dos aspectos externos de um objeto, acessíveis por outros, dos detalhes internos da implementação daquele objeto, que ficam ocultos dos demais objetos”. A Figura 1.8 ilustra um objeto real Calculadora. Ela tem internamente seus registradores, sendo que apenas as funções (serviços) de somar, subtrair, multiplicar e outras funções são disponibilizadas ao usuário, através de uma interface, Os detalhes dos processos pelos quais se obtém um resultado não estão diretamente visíveis para o usuário da calculadora.
Figura 1.8 – Exemplo do Conceito de Encapsulamento
Fonte: < http://www.freeshop.com.br/brindes/fotos/produtos/Originais/2352/calculadora-mesa-solar-3-2352-13.jpg >. Acesso em: 30 out. 2015.
Generalização:
O conceito de generalização representa a propriedade pela qual uma classe pode herdar características e comportamento de outra, para obter o reaproveitamento dos atributos e operações. Quando a herança é de uma única superclasse, ela é denominada herança simples e se for de várias superclasses, é denominada herança múltipla. Na definição de Para Rumbaugh (1994, p. 4), o conceito de herança é “o compartilhamento de atributos e operações entre classes com base em um relacionamento hierárquico. Uma classe pode ser definida de forma abrangente e depois refinada em sucessivas subclasses mais definidas”. A Figura 1.9 ilustra um exemplo de herança representado pelo relacionamento de generalização entre as classes Veículo (superclasse) e as classes Carro, Caminhão e Ônibus (subclasses). Fazendo a leitura da figura, carro é um tipo de veículo.
Figura 1.9 – Exemplo de Herança entre Classes
Fonte: A autora.
Polimorfismo:
O conceito de polimorfismo representa uma mesma operação se comportando de diferentes formas, em diferentes classes. Uma operação polimórfica possui o mesmo nome em classes distintas, mas em cada classe o método implementado é diferente. Na definição de Rumbaugh (1994, p. 4), polimorfismo “significa que a mesma operação pode atuar de modos diversos em classes diferentes; a mesma operação pode se aplicar a muitas classes diferentes”. 
Para Refletir
Vamos, agora, refletir sobre o Paradigma Orientado a Objetos: Quais são os principais pilares/características que sustentam o Paradigma Orientado a Objetos?
	
	Visualize o link e leia o Capítulo 1: 
3. Fundamentos do Processo Unificado
O Processo Unificado foi criado para apoiar o desenvolvimento orientado a objetos com a UML, fornecendo uma forma sistemática de especificar sistemas de softwares para diferentes domínios e tamanhos de projetos. O ciclo de vida do Processo Unificado é iterativo e incremental. Segundo Bezerra (2007), o ciclo de vida de processo incremental e iterativo abrange duas dimensões: dimensão temporal e dimensão de atividades (fluxos de trabalho). Na dimensão temporal, o processo é estruturado em fases, sendo que em cada uma delas há uma ou mais iterações. Cada iteração tem uma duração preestabelecida e, ao final de cada iteração, é produzido um incremento – uma parte do sistema. Os ciclos de desenvolvimento são organizados em quatro fases sucessivas - Concepção, Elaboração, Construção e Transição, e cada uma delas integra um conjunto de atividades iterativas - Requisitos, Análise e Projeto, Implementação e Teste, como mostra a Figura 1.10. Em cada uma das fases, diferentes artefatos de software são produzidos e a cada iteração, novos detalhes são adicionados a eles, resultando na geração de uma nova versão de um protótipo a cada fase realizada.
Importante!
No modelo de ciclo de vida incremental e iterativo, um sistema de software é desenvolvido em vários passos similares (iterativo). Em cada passo, o sistema é estendido com mais funcionalidades (incremental), incentivando a participação do usuário nas atividades de desenvolvimento, para validar os requisitos do sistema através da prototipagem (BEZERRA, 2007).
Figura 1.10 – Ciclo de Vida do Processo Unificado
Fonte: Adaptado de MEDEIROS, 2006, p. 16.
Vídeo
Assista ao vídeo para fixar os conceitos abordados!
Disponível em: < https://www.youtube.com/watch?v=q6_Pq5zByME >.
Na fase de Concepção define-se a ideia geral do negócio do sistema e a delimitação do escopo do projeto para obter um desenvolvimento bem fundamentado nos requisitos do usuário. Um planejamento de alto nível do desenvolvimento é realizado para identificar, definir e analisar os requisitos do sistema. Em síntese, a fase de concepção se concentra na delimitação da fronteira e do contexto do sistema, com a identificação e definição dos requisitos. Na fase de Elaboração define-se como o sistema será construído a partir da definição dos requisitos do sistema, estabelecendo a arquitetura e mecanismos para especificar o sistema. Concentra-se na especificação dos requisitos funcionais do sistema nas atividades de Análise e Projeto, principalmente. A atividade de análise consiste em identificar o que o sistema deve fazer em uma visão lógica do negócio, e a atividade de projeto consiste em definir como o software será desenvolvido, ou seja, fazendo uma transição da modelagem lógica da análise para a modelagem física do software, de acordo com a escolha do Sistema Gerenciador de Banco de Dados (SGBD), linguagens de programação, frameworks, etc. Ainda, algum trabalho de projeto e implementação pode ser realizado, desenvolvendo a prototipagem do software, conforme mostra a Figura 1.11 a seguir:
Figura 1.11 – Protótipo da Interface Gráfica de um Caso de Uso
Fonte: < http://images.slideplayer.com.br/5/1608156/slides/slide_7.jpg >. Acesso em: 01 dez. 2015.
Na fase de Construção, concentra-se na implementação e testes das funcionalidades, através do desenvolvimento iterativo e incremental do sistema. A atividade principal concentra-se no projeto e na implementação, visando validar e melhorar a prototipagem inicial, até obter o primeiro produto operacional. Na fase de Transição, o sistema é entregue aos usuários treinados com acompanhamento constante, devido à demanda de novas funcionalidades ou adequações no sistema. A atividade principal é a de testes, visando garantir que o sistema atenda aos requisitos do usuário satisfatoriamente. Em cada fase é realizado um conjunto de iterações, envolvendo as atividades em um ciclo de desenvolvimento. Contudo, de uma iteração para outra e de uma fase para a próxima, a ênfase sobreas várias atividades muda, como mostra a Figura 1.10, a qual ilustra a concentração das atividades em uma determinada fase.
	Faça a leitura dos artigos para conhecer mais sobre o Processo Unificado!  e .
Para Refletir
Vamos, agora, refletir sobre os Fundamentos do Processo Unificado: como funciona a evolução iterativa e incremental do ciclo de vida do Processo Unificado?
Resumo da Unidade de Ensino
Esta unidade apresentou uma contextualização do processo de desenvolvimento de software, especificamente o Processo Unificado, com suas principais fases e atividades. Nas primeiras atividades do processo de desenvolvimento, as atividades de Requisitos (ou Comunicação e Planejamento), Análise e Projeto, o profissional analista de sistemas tem a responsabilidade de abstrair e identificar os processos de negócio e, posteriormente, conceber e elaborar o software, definindo, para isso, um ou mais métodos de desenvolvimento de sistemas com suas técnicas de modelagem para especificar todos os requisitos do sistema. Posteriormente, foram apresentados e exemplificados os principais conceitos do paradigma Orientado a Objetos, que serão utilizados para compreender as técnicas de modelagem da UML e aplicá-los na implementação do software.
Pratique!
Faça um levantamento das ferramentas CASE que contemplam a modelagem das atividades de Requisitos, Análise e Projeto, conforme a UML, e escolha uma ferramenta CASE para você instalar em seu computador e começar a se familiarizar.
Bom trabalho!
REFERÊNCIAS
BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. 2. ed. Rio de Janeiro: Elsevier, 2007.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário. 2. ed. Rio de Janeiro: Elsevier, 2006.
MEDEIROS, Ernani Sales de. Desenvolvendo software com UML 2.0: definitivo. São Paulo: Pearson, 2006.
PRESSMAN, Roger S. Engenharia de software: uma abordagem profissional. 7. ed. Porto Alegre: McGraw-Hill, 2011.
RUMBAUGH, James et al. Modelagem e projetos baseados em objetos. Rio de Janeiro: Campus, 1994.
SOMMERVILLE, Ian. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.
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 desoftware”.
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
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)
	Saiba mais sobre a UML:  e .
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=N6K-vaVunf0 >. 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ão representa 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 Exemplo de 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!
REFERÊNCIAS
BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. 2. ed. Rio de Janeiro: Elsevier, 2007.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário. 2. ed. Rio de Janeiro: Elsevier, 2006.
GUEDES, Gilleanes T. A. UML: uma abordagem prática. 3. ed. São Paulo: Novatec, 2008.
MEDEIROS, Ernani Sales de. Desenvolvendo software com UML 2.0: definitivo. São Paulo: Pearson, 2006.