Analise Projeto Sistemas Mail

e-Tec Brasil/CEMF/UnimontesEscola Técnica Aberta do Brasil

Informática

Análise e Projeto de Sistemas

Nilton Alves MaiaSônia Beatriz de Oliveira e Silva Maia

Ministério daEducação


Informática

Análise e Projeto de Sistemas

Nilton Alves Maia Sônia Beatriz de Oliveira e Silva Maia

Montes Claros - MG2011

Ministro da EducaçãoFernando Haddad

Secretário de Educação a DistânciaCarlos Eduardo Bielschowsky

Coordenadora Geral do e-Tec Brasil Iracy de Almeida Gallo Ritzmann

Governador do Estado de Minas GeraisAntônio Augusto Junho Anastasia

Secretário de Estado de Ciência, Tecnologia e Ensino SuperiorAlberto Duque Portugal

ReitorJoão dos Reis Canela

Vice-ReitoraMaria Ivete Soares de Almeida

Pró-Reitora de EnsinoAnette Marília Pereira

Diretor de Documentação e InformaçõesHuagner Cardoso da Silva

Coordenador do Ensino ProfissionalizanteEdson Crisóstomo dos Santos

Diretor do Centro de Educação Profissonal e Tecnólogica - CEPTMaísa Tavares de Souza Leite

Diretor do Centro de Educação à Distância - CEADJânio Marques Dias

Coordenadora do e-Tec Brasil/UnimontesRita Tavares de Mello

Coordenadora Adjunta do e-Tec Brasil/CEMF/UnimontesEliana Soares Barbosa Santos

Coordenadores de Cursos:

Coordenador do Curso Técnico em AgronegócioAugusto Guilherme Dias Coordenador do Curso Técnico em ComércioCarlos Alberto Meira Coordenador do Curso Técnico em Meio AmbienteEdna Helenice Almeida

Coordenador do Curso Técnico em InformáticaFrederico Bida de Oliveira

Coordenadora do Curso Técnico em Vigilância em SaúdeSimária de Jesus Soares

Coordenadora do Curso Técnico em Gestão em SaúdeZaida Ângela Marinho de Paiva Crispim

ANÁLISE E PROJETO DE SISTEMASe-Tec Brasil/CEMF/Unimontes

ElaboraçãoNilton Alves Maia Sônia Beatriz de Oliveira e Silva Maia

Projeto Gráficoe-Tec/MEC

Supervisão Wendell Brito Mineiro

DiagramaçãoHugo Daniel Duarte SilvaMarcos Aurélio de Almeida e Maia

Impressão e AcabamentoGráfica RB Digital

Designer InstrucionalAngélica de Souza Coimbra FrancoKátia Vanelli Leonardo Guedes Oliveira

RevisãoMaria Ieda Almeida MunizPatrícia Goulart TondineliRita de Cássia Silva Dionísio

Presidência da República Federativa do BrasilMinistério da EducaçãoSecretaria de Educação a Distância

e-Tec Brasil/CEMF/UnimontesAnálise e Projetos de Sistemas

AULA 1

Alfabetização Digital

3

Prezado estudante,

Bem-vindo ao e-Tec Brasil/Unimontes!

Você faz parte de uma rede nacional pública de ensino, a Escola Técnica Aberta do Brasil, instituída pelo Decreto nº 6.301, de 12 de dezem-bro 2007, com o objetivo de democratizar o acesso ao ensino técnico público, na modalidade a distância. O programa é resultado de uma parceria entre o Ministério da Educação, por meio das Secretarias de Educação a Distancia (SEED) e de Educação Profissional e Tecnológica (SETEC), as universidades e escola técnicas estaduais e federais.

A educação a distância no nosso país, de dimensões continentais e grande diversidade regional e cultural, longe de distanciar, aproxima as pes-soas ao garantir acesso à educação de qualidade, e promover o fortalecimen-to da formação de jovens moradores de regiões distantes, geograficamente ou economicamente, dos grandes centros.

O e-Tec Brasil/Unimontes leva os cursos técnicos a locais distantes das instituições de ensino e para a periferia das grandes cidades, incenti-vando os jovens a concluir o ensino médio. Os cursos são ofertados pelas instituições públicas de ensino e o atendimento ao estudante é realizado em escolas-polo integrantes das redes públicas municipais e estaduais.

O Ministério da Educação, as instituições públicas de ensino téc-nico, seus servidores técnicos e professores acreditam que uma educação profissional qualificada – integradora do ensino médio e educação técnica, – não só é capaz de promover o cidadão com capacidades para produzir, mas também com autonomia diante das diferentes dimensões da realidade: cul-tural, social, familiar, esportiva, política e ética.

Nós acreditamos em você!

Desejamos sucesso na sua formação profissional!

Ministério da EducaçãoJaneiro de 2010

Apresentação e-Tec Brasil/CEMF/Unimontes


AULA 1


5

Indicação de ícones

Os ícones são elementos gráficos utilizados para ampliar as formas de linguagem e facilitar a organização e a leitura hipertextual.

Atenção: indica pontos de maior relevância no texto.

Saiba mais: oferece novas informações que enriquecem o assunto ou “curiosidades” e notícias recentes relacionadas ao tema estudado.

Glossário: indica a definição de um termo, palavra ou expressão utilizada no texto.

Mídias integradas: possibilita que os estudantes desenvolvam atividades empregando diferentes mídias: vídeos, filmes, jornais, ambiente AVEA e outras.

Atividades de aprendizagem: apresenta atividades em diferentes níveis de aprendizagem para que o estudante possa realizá-las e conferir o seu domínio do tema estudado.


AULA 1

Alfabetização DigitalSumário

7

Palavra do professor conteudista .............................................9Projeto instrucional ........................................................... 11Aula 1 – Sistema de informações ............................................ 13 1.1 Introdução ............................................................ 13 1.2 Conceito de sistema de informações ............................. 13 Resumo ................................................................... 14 Atividades de aprendizagem ........................................... 14Aula 2 – Modelagem de sistemas de software ............................. 15 2.1 Introdução ........................................................... 15 2.2 Construção de sistemas de software ............................. 15 Resumo ................................................................... 17 Atividades de aprendizagem ........................................... 17Aula 3 – O paradigma da orientação a objetos ............................ 19 3.1 Introdução ........................................................... 19 3.2 Classes e objetos .................................................... 21 3.3 Mensagens ........................................................... 21 3.4 Visão geral dos princípios da orientação a objetos ............ 22 Resumo ................................................................... 25 Atividades de aprendizagem ........................................... 25Aula 4 – Evolução histórica da modelagem de sistemas .................. 27 4.1 Introdução ........................................................... 27 4.2 Resumo histórico .................................................... 27 Resumo ................................................................... 28 Atividades de aprendizagem ........................................... 28Aula 5 – A linguagem de modelagem unificada (UML) .................... 29 5.1 Introdução ........................................................... 29 5.2 Em que a UML pode me ajudar? .................................. 30 5.3 Por que a UML é uma linguagem?................................. 30 5.4 Que caminho deve ser seguido para aprendê-la? ............... 31 5.5 UML e o desenvolvimento de software .......................... 31 Resumo ................................................................... 31 Atividades de aprendizagem ........................................... 31Aula 6 – O processo de desenvolvimento de software ................... 33 6.1 Introdução ........................................................... 33 6.2 Atividades típicas de um processo de desenvolvimento ....... 34 Resumo ................................................................... 39 Atividades de aprendizagem ........................................... 40Aula 7 – Modelagem Baseada em UML ...................................... 41 7.1 Introdução ............................................................ 41 7.2 Um breve histórico .................................................. 42

e-Tec Brasil/CEMF/Unimontes Informática8

7.3 Diagramas da UML .................................................. 43 7.4 Processo adotado neste caderno .................................. 45 7.5 Casos de uso ......................................................... 46 7.6 Classes ................................................................ 53 7.7 Interações ............................................................ 65 7.8 Componentes de software ........................................ 77 Resumo ................................................................... 84 Atividades de aprendizagem ........................................... 84Aula 8 – Estudo de caso ...................................................... 85 8.1 Introdução ........................................................... 85Referências ..................................................................... 86Currículos dos professores conteudistas ................................... 87


AULA 1


9

Bem-vindos caros alunos!A partir do conteúdo trabalhado neste caderno, que trata-se da

disciplina Análise e Projeto de Sistemas, você aprenderá a utilizar diversos recursos para modelagem de sistemas.

Você aprenderá sobre a análise e projeto de sistemas, entenderá sobre a caracterização e aplicação de metodologias e ferramentas de mo-delagem de sistemas orientados a objetos, aprenderá sobre aplicações de metodologias de desenvolvimento de sistemas de software, terá uma revisão dos métodos de desenvolvimento de software, aprenderá sobre aplicação de metodologia através de experiência prática de desenvolvimento de softwa-re, também aprenderá a empregar aspectos fundamentais no processo de desenvolvimento visando maior qualidade do produto de software.

Ao longo deste material, você encontrará diversas atividades a se-rem desenvolvidas durante o decorrer da disciplina. Assim, ao resolvê-las, é possível realizar uma revisão do que foi apresentado e refletir sobre a impor-tância do conteúdo trabalhado e como ele poderá ajudá-lo em seu cotidiano, principalmente como aluno de um curso técnico e futuro profissional.

Este caderno está dividido em oito aulas e seu conteúdo será apre-sentado no encontro presencial deste curso. Como complementação de estu-do, algumas atividades serão propostas, além de apresentação de curiosida-des, destaques para conceitos importantes.

Vamos nos empenhar para aproveitar ao máximo o conteúdo dessa disciplina?

Bom trabalho!

Palavra do professor conteudista


AULA 1


11

Disciplina: Análise e Projeto de Sistemas (carga horária: 60h).

Ementa: Introdução à análise e projeto de sistemas. Caracterização e aplicação de metodologias e ferramentas de modelagem de sistemas orien-tados a objetos. Apresentação e aplicação de uma metodologia de desenvol-vimento de sistemas de software. Revisão dos métodos de desenvolvimento de software. Aplicação de metodologia através de experiência prática de desenvolvimento de software. Empregar aspectos fundamentais no processo de desenvolvimento visando maior qualidade do produto de software.

AULA OBJETIVOS DE APRENDIZAGEM

MATERIAIS CARGA HORÁRIA

Aula 1. Sistemas de informações

- Conhecer conceitos sobre infor-mação, sistemas de informação e

sistemas de software.

4h

Aula 2. Modelagem de

sistemas de software

- Conhecer as características de sistemas de software;

- Entender o conceito de modelo no desenvolvimento de sistemas;

- Compreender o conceito do prin-cípio da abstração;

- Entender a importância da comu-nicação entre as pessoas envolvidas no processo de desenvolvimento de

sistemas.

4h

Aula 3. O paradigma

da orientação a objetos

- Conhecer o conceito de paradig-ma;

- Compreender o conceito de para-digma da orientação a objetos;

- Conhecer os princípios da orienta-ção a objetos;

- Conhecer o conceito de classes, objetos, mensagens;

- Conhecer os princípios do paradig-ma da orientação a objetos.

8h

Aula 4. Evolução histó-rica da modela-gem de sistemas

- Conhecer o histórico da evolução das técnicas de desenvolvimento de

sistemas.

2h

Projeto instrucional


Aula 5. A linguagem de modelagem uni-

ficada – UML

- Saber em que a UML pode nos ajudar;

- Saber por que a UML é uma lin-guagem;

- Conhecer os caminhos que deve-mos seguir para aprender a UML; e- Conhecer a UML e o processo de

desenvolvimento de software.

6h

Aula 6. O processo de

desenvolvimen-to de software

- Conhecer as atividades típicas de um processo de desenvolvimento

de software;- Compreender a importância de cada atividade no decorrer de um processo de desenvolvimento de

software.

4h

Aula 7. Modelagem Ba-seada em UML

- Conhecer um breve histórico da UML;

- Conhecer os principais diagramas da UML;

- Saber a identificar um caso de uso;

- Aprender a identificar atores;- Aprender a desenhar um diagrama

de caso de uso;- Conhecer os cuidados necessários

ao se criar diagramas de caso de uso;

- Aprender a identificar classes;- Aprender a identificar relaciona-

mentos;- Conhecer extensões e mecanis-

mos;- Aprender a desenhar diagramas

de classes;- Conhecer os tipos de diagramas

de interação;- Conhecer o diagrama de colabo-

ração;- Conhecer diagramas de sequência;- Aprender a desenhar diagramas

de sequência;- Aprender sobre os diagramas de

estados e sua função;- Aprender a desenhar diagramas

de estados;- Aprender sobre diagramas de

atividades;- Aprender a desenhar diagramas

de atividades;- Conhecer componentes de software;- Aprender a desenhar diagramas

de componentes;- Aprender a desenhar diagramas

de implantação.

24h

Aula 8. Estudo de caso

- Criar um projeto de software utilizando conhecimentos de orien-tação a objetos e da linguagem de

modelagem unificada.

8h


AULA 1


13

Aula 1 – Sistema de informações

Objetivos

- Conhecer conceitos sobre informação, sistemas de informação e sistemas de software.

1.1 Introdução

No decorrer da história, diversos tipos de bens serviram de base para o desenvolvimento da economia. Propriedade, mão de obra, máquinas e capital são exemplos desses bens. Atualmente, está surgindo um novo tipo de bem econômico: a informação. Dessa forma, a empresa que dispõe de mais informações sobre seus processos de negócio está em vantagem em relação a suas competidoras (BEZERRA, 2002).

Em consequuência do crescimento da importância da informação, surgiu a necessidade de gerenciar informações de uma forma adequada e eficiente e, dessa necessidade, surgiram os denominados sistemas de infor-mações (BEZERRA, 2002).

1.2 Conceito de sistema de informações

Um sistema de informações é uma combinação de pessoas, dados, processos, interfaces, redes de comunicação e tecnologia que interagem com o objetivo de dar suporte e melhorar o processo de negócio de uma organização empresarial com relação às informações que nela fluem. Consi-derando o caráter estratégico da informação nos dias de hoje, pode-se dizer também que os sistemas de informações têm o objetivo de prover vantagens para uma organização do ponto de vista competitivo (BEZERRA, 2002).

O objetivo principal e final da construção de um sistema de infor-mações é a adição de valor à empresa ou organização na qual esse sistema será utilizado. O termo “adição de valor” implica que a produtividade nos processos da empresa na qual o sistema de informações será utilizado deve aumentar de uma forma significativa, de tal forma a compensar os recursos utilizados na construção do sistema. Para que um sistema de informações adicione valor a uma organização, tal sistema deve ser economicamente jus-tificável (BEZERRA, 2002).

O desenvolvimento de um sistema de informações é uma tarefa das mais complexas. Um dos seus componentes é denominado sistema de


software. Esse componente compreende os módulos funcionais computado-rizados que interagem entre si para proporcionar ao(s) usuário(s) do sistema a automatização de diversas tarefas (BEZERRA, 2002).

Resumo

Nesta aula, você aprendeu:• conceitos sobre informação, sistemas de informação e sistemas

de software.

Atividades de aprendizagem1) Conceitue informação?

2) Qual é o conceito de sistemas de informação?

3) Qual é o objetivo dos sistemas de informação?

4) Conceitue sistemas de software?


AULA 1


15

Aula 2 – Modelagem de sistemas de software

Objetivos

- Conhecer as características de sistemas de software;- Entender o conceito de modelo no desenvolvimento de sistemas;- Compreender o conceito do princípio da abstração; - Entender a importância da comunicação entre as pessoas envolvi-

das no processo de desenvolvimento de sistemas.

2.1 Introdução

Uma característica importante dos sistemas de software é a com-plexidade de seu desenvolvimento. Esta complexidade cresce à medida que cresce o tamanho do sistema. Para se ter uma ideia da complexidade en-volvida na construção de alguns sistemas, considere o tempo e os recur-sos materiais necessários para se construir uma casa de um cachorro. Para construir essa casa, provavelmente tudo de que se precisa é de algumas ripas de madeira, alguns pregos, uma caixa de ferramentas e certa dose de amor por seu cachorro. Depois de alguns dias, a casa estaria pronta. O que dizer da construção de uma casa para sua família? Certamente tal emprei-tada não seria realizada tão facilmente. O tempo e os recursos necessários seriam uma ou duas ordens de grandeza maiores do que o necessário para a construção da casa de cachorro. O que dizer, então, da construção de um edifício? Certamente, para se construir habitações mais complexas (casas e edifícios), algum planejamento adicional é necessário. Engenheiros e arqui-tetos constroem plantas dos diversos elementos da habitação antes do início da construção propriamente dita. Na terminologia da construção civil, plan-tas hidráulicas, elétricas, de fundação, entre outras são projetadas e devem manter consistência entre si. Provavelmente, uma equipe de profissionais es-taria envolvida na construção e aos membros dessa equipe seriam delegadas diversas tarefas, no tempo adequado para cada uma delas (BEZERRA, 2002).

2.2 Construção de sistemas de software

Na construção de sistemas de software, assim como na construção de sistemas habitacionais, também há um aumento de complexidade. Para a construção de sistemas de software mais complexos, também é necessário um planejamento inicial anterior. O equivalente ao projeto das plantas da engenharia civil também deve ser realizado. Essa necessidade leva ao con-ceito de modelo, tão importante no desenvolvimento de sistemas. De uma


perspectiva mais ampla, um modelo pode ser visto como uma representação idealizada de um sistema a ser construído. Maquetes de edifícios, de aviões e plantas de circuitos eletrônicos são apenas alguns exemplos de modelos. São várias as razões para a utilização de modelos durante a construção de sistemas (BEZERRA, 2002).

Portanto, a utilização de modelos durante o processo de construção de sistemas ocorre em função dos seguintes motivos:

Gerenciamento da complexidade: uma das principais razões pelas quais modelos são utilizados é que há limitações no ser humano em lidar com a complexidade. Pode haver diversos modelos de um mesmo sistema, cada modelo descrevendo uma perspectiva do sistema a ser construído. Por exemplo, um avião pode ter um modelo para representar sua parte elétri-ca, outro modelo para representar sua parte aerodinâmica, etc. Através de modelos de um sistema, os indivíduos envolvidos no seu desenvolvimento podem fazer estudos e predizer comportamentos do sistema em desenvolvi-mento. Como cada modelo representa uma perspectiva do sistema, detalhes irrelevantes que podem dificultar o entendimento do sistema podem ser ig-norados por um momento estudando-se separadamente cada um dos mode-los. Além disso, modelos se baseiam no denominado Princípio da Abstração, o qual advoga que só as características relevantes à resolução de um problema devem ser consideradas. Modelos revelam as características essenciais de um sistema; detalhes não-relevantes e que só aumentariam a complexidade do problema podem ser ignorados (BEZERRA, 2002).

Comunicação entre as pessoas envolvidas: certamente, o desenvolvi-mento de um sistema envolve a execução de uma quantidade significativa de atividades. Essas atividades se traduzem em informações sobre o sistema em desenvolvimento. Grande parte dessas informações corresponde aos mo-delos criados para representar o sistema. Nesse sentido, os modelos de um sistema servem também para promover a difusão de informações relativas ao sistema entre os indivíduos envolvidos em sua construção. Além disso, diferentes expectativas em relação ao sistema geralmente aparecem quando da construção dos seus modelos, já que estes servem como um ponto de referência comum (BEZERRA, 2002).

Redução dos custos no desenvolvimento: no desenvolvimento de sis-temas, seres humanos estão invariavelmente sujeitos a cometerem erros, que podem ser tanto erros individuais,quanto erros de comunicação entre os membros da equipe. Certamente, a correção desses erros é menos custosa quando detectada e realizada ainda no(s) modelo(s) do sistema (por exem-plo, é muito mais fácil corrigir uma maquete do que pôr abaixo uma parte de um edifício). Lembre-se: modelos de sistemas são mais baratos de construir do que sistemas. Consequuentemente, erros identificados sobre modelos têm um impacto menos desastroso (BEZERRA, 2002).

Predição do comportamento futuro do sistema: o comportamento do sis-tema pode ser discutido através da análise dos seus modelos. Os modelos ser-vem como um “laboratório”, onde diferentes soluções para um problema rela-cionado à construção do sistema podem ser experimentadas (BEZERRA, 2002).

e-Tec Brasil/CEMF/UnimontesAnálise e Projetos de Sistemas 17

Uma outra questão importante é sobre como são construídos os modelos de sistemas de software. Em construções civis, frequuentemente há profissionais analisando as plantas da construção sendo realizadas. A partir dessas, que podem ser vistas como modelos, os homens tomam decisões sobre o andamento da obra. Modelos de sistemas de software não são muito diferentes dos modelos de sistemas da construção civil. Nas próximas aulas, apresentaremos diversos modelos cujos componentes são desenhos gráficos que seguem algum padrão lógico. Esses desenhos são normalmente deno-minados diagramas. Um diagrama é uma apresentação de uma coleção de elementos gráficos que possuem um significado predefinido (BEZERRA, 2002).

Através de desenhos gráficos que modelam o sistema os desenvol-vedores têm uma representação concisa do sistema. No entanto, modelos de sistemas de software também são compostos de informações textuais. Em-bora um diagrama consiga expressar diversas informações de forma gráfica, em diversos momentos há a necessidade de adicionar informações na forma de texto, com o objetivo de explicar ou definir certas partes desse diagrama. Dado um modelo de uma das perspectivas de um sistema, diz-se que os seus diagramas, juntamente com a informação textual associada, formam a docu-mentação desse modelo (BEZERRA, 2002).

Resumo

Nesta aula, você aprendeu:• sobre as características de sistemas de software;• sobre o conceito de modelo no processo de desenvolvimento de

sistemas;• sobre o conceito do princípio da abstração; e• sobre a importância da comunicação entre as pessoas envolvidas

no processo de desenvolvimento de sistemas.

Atividades de aprendizagem

1) Cite uma característica de sistemas de software?

2) Dê o conceito de modelo no processo de desenvolvimento de sistemas de informação?

3) Dê o conceito do princípio da abstração?

4) Quais são as razões da utilização de modelos para a construção de siste-mas de informações?

A modelagem de sistemas de software consiste na utilização de notações gráficas e textuais com o objetivo de construir modelos que representam as partes essenciais de um sistema, considerando-se diversas perspectivas diferentes e complementares.


AULA 1


19

Aula 3 – O paradigma da orientação a objetos

Objetivos

- Conhecer o conceito de paradigma;- Compreender o conceito de paradigma da orientação a objetos;- Conhecer os princípios da orientação a objetos; - Conhecer o conceito de classes, objetos, mensagens;- Conhecer os princípios do paradigma da orientação a objetos.

3.1 Introdução

Um conceito essencial para o desenvolvimento atual de sistemas de software é o paradigma da orientação a objetos. Esta aula descreve o significa-do desse termo e justifica por que a orientação a objetos é importante para a modelagem de sistemas.

Pode-se começar pela definição da palavra paradigma. Essa palavra possui diversos significados distintos, mas o que mais se aproxima do signi-ficado aqui utilizado pode ser encontrado no dicionário Aurélio Século XXI (BEZERRA, 2002):

Paradigma. [ Do gr. parádeigma, pelo lat. tard. paradigma.] S.m. Termo com o qual Thomas Kuhn designou as realiza-ções científicas (p. ex., a dinâmica de Newton ou a química de Lavoisier) que geram modelos que, por período mais ou menos longo e de modo mais ou menos explícito, orientam o desenvolvimento posterior das pesquisas exclusivamente na busca da solução para os problemas por elas suscitados.

Outra definição, mais restrita e mais apropriada ao contexto desta aula: um paradigma é uma forma de abordar um problema. Como exemplo, considere a famosa história da maçã caindo sobre a cabeça de Isaac Newton, citado na definição anterior. Em vez de pensar que somente a maçã estava caindo sobre a Terra, Newton também considerou a hipótese de o próprio planeta também estar caindo sobre a maçã! Essa outra maneira de abordar o problema pode ser vista como um paradigma (BEZERRA, 2002).

Pode-se dizer, então, que o termo “paradigma da orientação a ob-jetos” é uma forma de abordar um problema. Há alguns anos, Alan Kay, um dos pais do paradigma da orientação a objetos, formulou a chamada “analogia biológica”. Nessa analogia, ele imaginou como seria um sistema de software que funcionasse como um ser vivo. Nesse sistema, cada “célula”


interagiria com outras células através do envio de mensagens para realizar um objetivo comum. Adicionalmente, cada célula se comportaria como uma unidade autônoma (BEZERRA, 2002).

De uma forma mais geral, Kay pensou em como construir um siste-ma de software a partir de agentes autônomos que interagem entre si. Ele, então, estabeleceu os seguintes princípios da orientação a objetos (BEZER-RA, 2002):

• Qualquer coisa é um objeto. • Objetos realizam tarefas através da requisição de serviços a ou-

tros objetos. • Cada objeto pertence a uma determinada classe. Uma classe

agrupa objetos similares. • A classe é um repositório para comportamento associado ao ob-

jeto. • Classes são organizadas em hierarquias.

Vamos ilustrar esses princípios com a seguinte história proposta por BEZERRA (2002): “suponha que alguém queira comprar uma pizza. Chame este alguém de João. João está muito ocupado em casa e resolve pedir a sua pizza por telefone. João liga para a pizzaria e realiza o seu pedido. João informa ao atendente (digamos, o José) seu nome, as características da pizza desejada e o seu endereço. José, que só realiza a função de atendente, então comunica à Maria, funcionária da pizzaria responsável por fazer as pizzas, qual pizza deve ser feita. Quando Maria termina de fazer a pizza, José cha-ma Antônio, o entregador. Finalmente, João recebe a pizza desejada das mãos de Antônio meia hora depois de tê-la pedido”.

Pode-se observar, que o objetivo de João foi atingido através da colaboração de diversos agentes, que são denominados objetos. Há diversos objetos na história (1° princípio): João, Maria, José, Antônio. Todos cola-boram com uma parte, e o objetivo é alcançado quando todos trabalham juntos (2º princípio). Além disso, o comportamento esperado de Antônio é o mesmo esperado de qualquer entregador. Diz-se que Antônio é um objeto da classe Entregador (3° princípio). Um comportamento comum a todo entregador, não somente ao Antônio, é o de entregar a mercadoria no endereço especificado (4° princípio). Finalmente José, o atendente, é também um ser humano, também mamífero, também um animal etc (5° princípio) (BEZERRA, 2002).

Mas o que o paradigma da orientação a objetos tem a ver com a modelagem de sistemas? Antes da orientação a objetos, um outro para-digma era utilizado na modelagem de sistemas: o paradigma estrutura-do. Nesse paradigma, os elementos são dados, e processos. Processos agem sobre dados para que um objetivo seja alcançado (BEZERRA, 2002). Por outro lado, no paradigma da orientação a objetos, há um elemento, o objeto, uma unidade autônoma que contém seus próprios dados que são manipulados pelos processos definidos para o objeto e que interage com outros objetos para alcançar um objetivo. É o paradigma da orientação a


objetos que os seres humanos utilizam no cotidiano para a resolução de problemas. Uma pessoa atende a mensagens (requisições) para realizar um serviço; essa mesma pessoa envia mensagens a outras para que estas realizem serviços (BEZERRA, 2002).

3.2 Classes e objetos

O mundo real é formado de coisas. Como exemplos de coisas po-dem-se citar um cliente, uma loja, uma venda, um pedido de compra, um fornecedor, etc. No paradigma de orientação a objetos, essas coisas do mun-do real são denominadas objetos (BEZERRA, 2002).

Por outro lado, seres humanos costumam agrupar os objetos. Prova-velmente, os seres humanos realizam esse processo mental de agrupamento para tentar gerenciar a complexidade de entender as coisas do mundo real. Realmente, é bem mais fácil entender a ideia cavalo do que entender todos os cavalos que existem. Na terminologia da orientação a objetos, cada ideia é denominada classe de objetos, ou simplesmente classe. Uma classe é uma descrição dos atributos e serviços comuns a um grupo de objetos. Sendo assim, pode-se entender uma classe como sendo um molde a partir do qual objetos são construídos. Ainda sobre terminologia, diz-se que um objeto é uma instância de uma classe (BEZERRA, 2002).

Por exemplo, quando se pensa em um cavalo, logo vem à mente um animal de quatro patas, cauda, crina etc. Pode ser que algum dia você veja dois cavalos, um mais baixo que o outro, um com cauda maior que o outro, ou mesmo, por um infeliz acaso, um cavalo com menos patas que o outro. No entanto, você ainda terá certeza de estar diante de dois cavalos. Isso porque a ideia (classe) cavalo está formada na mente dos seres humanos, indepen-dentemente das pequenas diferenças que possa haver entre os exemplares (objetos) da ideia cavalo (BEZERRA, 2002).

É importante notar que uma classe é uma abstração das caracterís-ticas de um grupo de coisas do mundo real. Na maioria das vezes, as coisas do mundo real são muito complexas para que todas as suas características sejam representadas em uma classe. Além disso, para fins de modelagem de um sistema, somente um subconjunto de características pode ser relevante. Portanto, uma classe representa uma abstração das características relevantes do mundo real (BEZERRA, 2002). Finalmente, é preciso atentar para o fato de que alguns textos sobre orientação a objetos utilizam os termos classe e ob-jeto equivalentemente para denotar uma classe de objetos (BEZERRA, 2002).

3.3 Mensagens

Os objetos não executam suas operações aleatoriamente. Para que uma operação em um objeto seja executada, deve haver um estímulo envia-do a esse objeto. Se um objeto for visto como uma entidade ativa que repre-senta uma abstração de algo do mundo real, então faz sentido dizer que tal

O paradigma da orientação a objetos visualiza um sistema de software como uma coleção de agentes interconectados chamados objetos. Cada objeto é responsável por realizar tarefas específicas. É através da interação entre objetos que uma tarefa computacional é realizada.

Tanto o paradigma estruturado quanto o paradigma orientado a objetos surgiram nas linguagens de programação, para depois serem aplicados à modelagem de sistemas. De fato, as ideias de Alan Kay foram aplicadas na construção de uma das primeiras linguagens de programação orientadas a objetos: o Small Talk.

Um sistema de software orientado a objetos consiste de objetos em colaboração com o objetivo de realizar as funcionalidades desse sistema. Cada objeto é responsável por tarefas específicas. É através da cooperação entre objetos que a computação do sistema se desenvolve.


objeto pode responder a estímulos a ele enviados (assim como faz sentido dizer que seres vivos reagem a estímulos que eles recebem). Independen-temente da origem do estímulo, quando ele ocorre, diz-se que o objeto em questão está recebendo uma mensagem requisitando que ele realize alguma operação (BEZERRA, 2002).

Quando se diz que objetos de um sistema estão trocando mensa-gens significa que esses objetos estão enviando mensagens uns aos outros com o objetivo de realizar alguma tarefa dentro do sistema no qual eles estão inseridos (BEZERRA, 2002).

Figura 1: Objetos interagem através do envio de mensagens.Fonte: Bezerra (2002).

3.4 Visão geral dos princípios da orientação a objetos

Nesta aula, vamos apresentar os princípios do paradigma da orien-tação a objetos. A Figura XX mostra uma visão geral dos princípios utilizados em Orientação a Objetos.

Figura 2: Visão geral dos princípios da orientação a objetos.Fonte: Bezerra (2002).

A descrição dos princípios de Encapsulamento, de Abstração, de Polimorfismo e de Herança é realizada nos itens seguintes.


3.4.1 Abstração

Uma abstração é qualquer modelo que inclui os aspectos mais im-portantes, essenciais de alguma coisa, ao mesmo tempo em que ignora os detalhes menos importantes. Abstrações permitem gerenciar a complexida-de e concentrar a atenção nas características essenciais de um objeto. Note que uma abstração é dependente da perspectiva: o que é importante em um contexto pode não ser importante em outro (BEZERRA, 2002).

3.4.2 Encapsulamento

Os Objetos possuem comportamento. O termo comportamento diz respeito a operações realizadas por um objeto e também ao modo pelo qual essas operações são executadas. O mecanismo de encapsulamento é uma forma de restringir o acesso ao comportamento interno de um objeto. Um objeto que precise da colaboração de outro objeto para realizar alguma ta-refa simplesmente envia uma mensagem a este último. O método que o objeto requisitado usa para realizar a tarefa não é conhecido dos objetos requisitantes (BEZERRA, 2002).

Certamente, o objeto requisitante precisa conhecer quais as tarefas que um outro objeto sabe fazer ou que informação ele conhece. Para tanto, a classe de um objeto descreve o seu comportamento. Na terminologia da orientação a objetos, diz-se que um objeto possui uma interface. Em termos bastante simples, a interface de um objeto é o que ele conhece e o que ele sabe fazer, sem descrever como o objeto conhece o faz. A interface de um objeto define os serviços que ele pode realizar e consequuentemente as mensagens que ele recebe. Uma interface pode ter várias formas de im-plementação. Mas, pelo Princípio do Encapsulamento, a implementação de um objeto requisitado não importa para um objeto requisitante (BEZERRA, 2002).

Através do encapsulamento, a única coisa que um objeto precisa saber para pedir a colaboração de outro objeto é conhecer a sua interface. Isso contribui para a autonomia dos objetos. Cada objeto envia mensagens a outros objetos para realizar certas tarefas, sem se preocupar em como as tarefas são realizadas. A aplicação da abstração, neste caso, está em escon-der os detalhes de funcionamento interno de um objeto (BEZERRA, 2002).


Figura 3: Princípio do encapsulamento: visto externamente, o objeto é a sua interface.Fonte: Bezerra (2002).

3.4.3 Polimorfismo

O polimorfismo indica a capacidade de abstrair várias implementa-ções diferentes em uma única interface. Há algum tempo atrás, o controle remoto de meu televisor quebrou. (Era realmente cansativo ter de levantar para desligar o aparelho ou para trocar de canal). Um tempo depois, comprei um videocassete do mesmo fabricante de meu televisor. Para minha surpre-sa, o controle remoto do videocassete também funcionava para o televisor!

Esse é um exemplo de aplicação do Princípio do Polimorfismo. Note mais uma vez que a abstração também é aplicada aqui: um objeto pode en-viar a mesma mensagem para objetos semelhantes, mas que implementam a sua interface de formas diferentes (BEZERRA, 2002).

3.4.4 Herança

A herança é outra forma de abstração utilizada na orientação a objetos. As características e o comportamento comuns a um conjunto de objetos podem ser abstraídos em uma classe. A herança pode ser vista como um nível de abstração acima da encontrada entre classes e objetos (BEZER-RA, 2002).

Na herança, classes semelhantes são agrupadas em hierarquias (ver Figura 1-4). Cada nível de uma hierarquia pode ser visto como um nível de abstração. Cada classe em um nível da hierarquia herda as características


das classes nos níveis acima. Esse mecanismo facilita o compartilhamento de comportamento comum entre um conjunto de classes semelhantes. Além disso, as diferenças ou variações de uma classe em particular podem ser organizadas de forma mais clara (BEZERRA, 2002).

Figura 4: Princípio da herança: classes podem ser organizadas em hierarquias.Fonte: Bezerra (2002).

Resumo

Nesta aula, você aprendeu:• sobre o conceito de paradigma;• sobre o conceito de paradigma da orientação a objetos;• sobre o conceito dos princípios da orientação a objetos; • sobre o conceito de classes, objetos, mensagens; e• sobre os princípios do paradigma da orientação a objetos.


1) Dê o conceito de paradigma?

2) Qual é o conceito de paradigma da orientação a objetos?

3) Dê o conceito dos princípios da orientação a objetos?

4) Dê o conceito de classes, objetos e mensagens?

5) Explique os princípios do paradigma da orientação a objetos.


AULA 1


27

Aula 4 – Evolução histórica da modela-gem de sistemas

Objetivos

- Conhecer o histórico da evolução das técnicas de desenvolvi-mento de sistemas.

4.1 Introdução

O rápido crescimento da capacidade computacional das máquinas resultou na demanda por sistemas de software cada vez mais complexos, que tirassem proveito de tal capacidade. O surgimento desses sistemas com-plexos resultou na necessidade de reavaliação da forma de se desenvolver sistemas. Em função disso, desde o aparecimento do primeiro computador até os dias de hoje, as técnicas utilizadas para a construção de sistemas computacionais têm evoluído de forma impressionante, principalmente no que tange à modelagem de sistemas (BEZERRA, 2002).

4.2 Resumo histórico

A seguir, é apresentado um breve resumo histórico da evolução das técnicas de desenvolvimento de acordo com BEZERRA (2002). O objetivo da apresentação do resumo histórico é esclarecer como se chegou às técnicas atualmente utilizadas.

• Décadas de 1950/60: os sistemas de software eram bastante sim-ples. O desenvolvimento desses sistemas era feito de forma “ad-hoc”. Os sistemas eram significativamente mais simples e, consequentemente, as técnicas de modelagem também eram mais simples: era a época dos fluxogramas e dos diagramas de módulos.

• Década de 1970: nesta época, computadores mais avançados e acessíveis começaram a surgir. Houve uma grande expansão do mercado computacional. Sistemas mais complexos começavam a surgir. Por conseguinte, modelos mais robustos foram propostos. Neste período, surgem à programação estruturada e o projeto estruturado. Os autores Larry Constantine e Edward Yourdon são grandes colaboradores nessas técnicas.

• Década de 1980: nesta fase, os computadores se tornaram ainda mais avançados e baratos. Surge à necessidade por interfaces mais sofisticadas, o que originou a produção de sistemas de sof-twares mais complexos. A Análise Estruturada surgiu no início deste período com os trabalhos de Edward Yourdon, Peter Coad, Tom DeMarco, James Martin e Chris Gane.

O termo ad-hoc significa “direto ao assunto” ou “direto ao que interessa”. Talvez o uso deste termo denote a abordagem desta primeira fase do desenvolvimento de sistemas, na qual não havia um planejamento inicial. O código-fonte do programa a ser construído era ele próprio, o modelo.


• Início da Década de 1990: este é o período em que surge um novo paradigma de modelagem, a Análise Orientada a Objetos. Gran-des colaboradores deste paradigma são Sally Shlaer, Stephen Mellor, Rebecca Wirfs-Brock, James Rumbaugh, Grady Booch e Ivar jacobson.

• Fim da Década de 1990: o paradigma da orientação a objetos atin-ge sua maturidade. Os conceitos de padrões de projeto, fra-meworks, componentes e qualidade começam a ganhar espaço. Surge a Linguagem de Modelagem Unificada (UML).

Resumo

Nesta aula, você aprendeu:• sobre o histórico da evolução das técnicas de desenvolvimento

de sistemas.


1) Explique com suas palavras o histórico da evolução das técnicas de desen-volvimento de sistemas.


AULA 1


29

Aula 5 – A linguagem de modelagem uni-ficada (UML)

Objetivos

- Saber em que a UML pode nos ajudar;- Saber por que a UML é uma linguagem;- Conhecer os caminhos que devemos seguir para aprender a UML; - Conhecer a UML e o processo de desenvolvimento de software.

5.1 Introdução

Todo profissional ligado à informática reconhece a importância da criação de modelos para que sistemas de qualidade sejam obtidos. Há uma série de justificativas que envolvem a criação de modelos, no entanto a mais forte recai sobre o teste. Analogamente ao trabalho do engenheiro, é óbvio que é preferível verificar os erros de construção de uma casa baseando-se em um modelo, que construí-Ia e colocar pessoas morando para depois espe-rar que apareçam os erros (MATOS, 2002).

Na verdade, os modelos são uma importante ferramenta que en-volve muitos outros aspectos úteis na condução do desenvolvimento de um sistema computacional, tais como:

• diminuição da complexidade do sistema, já que é difícil enten-der a complexidade do todo;

• simplificação da realidade por meio de uma abstração que pode ser facilmente entendida;

• possibilidade de enxergar os problemas do sistema antes mesmo que aconteçam;

• possibilidade de simular situações que seriam perigosas ou até danosas caso fossem executadas no sistema em ação.

Embora a concepção da UML tenha sido influenciada por vários mé-todos de análise e projeto orientados a objeto, há particularmente três no-tações das quais a UML é derivada:

• 000 (Projeto Orientado a Objetos) - Grady Booch;• OMT (Técnica de Modelagem de Objetos) - James Rumbaugh. • OOSE (Engenharia de Software Orientada por Objetos) - Ivar Ja-

cobson. Em 1997, a OMG (Object Management Group) tornou a UML uma

linguagem de modelagem padrão para aplicações orientadas a objeto. A im-portância dessa padronização está no fato de que a OMG possui mais de 800 filiados, incluindo empresas como IBM, HP, Borland, etc. Ou seja, os princi-pais softwares que utilizamos são modelados e idealizados por meio da UML (MATOS, 2002).


5.2 Em que a UML pode me ajudar?

Esta é uma inquietação óbvia de qualquer pessoa que nunca ouviu falar em UML. Particularmente, é a inquietação da maioria dos estudantes de Engenharia de Software que questiona (pública ou individualmente): “... para que estou aprendendo isso?”.

A Orientação a Objetos era, até então, um termo obscuro e até certo ponto místico. A Programação Estruturada e, consequentemente, todos os conceitos relacionados à Análise Estruturada já haviam tomado conta do modus operandi de qualquer analista ou projetista. Então surge a questão: esta é a única forma de criar sistemas?

A UML é uma composição das boas características de outras nota-ções de ferramentas direcionadas à orientação a objetos. Ou seja, a UML é a ferramenta ideal para criar, compreender, testar, validar, arquitetar (lógica e fisicamente) e ainda identificar todos os possíveis comportamentos do sis-tema, especialmente os sistemas orientados e objeto (MATOS, 2002).

Convém salientar que a orientação a objetos é o cerne da maioria dos sistemas construídos atualmente: desde os sistemas comerciais (basea-dos em componentes, eventos e hierarquias de formulários) até os comple-xos sistemas para Web. Em suma, o porquê de conhecer a UML está simples-mente relacionado à realidade do processo de desenvolvimento de software (MATOS, 2002).

5.3 Por que a UML é uma linguagem?

Realmente soa estranho dizer que a UML é uma linguagem, sabendo que sua função é bem parecida com a de outras ferramentas de modelagem, tais como o Diagrama de Fluxo de Dados (DFD), o Diagrama de Entidades e Relacionamentos (DER), o Diagrama de Transição de Estados (DTE), etc. Obviamente que se questiona: “... quer dizer que esses outros diagramas também são uma linguagem?”

Uma linguagem (mesmo as do mundo da informática) deve se-guir uma gramática (em que todos os elementos básicos de representa-ção sejam indicados) e também a um conjunto de regras sintáticas, tal qual o nosso português. Talvez faltasse aos outros diagramas essa rigidez sintática em que um outro diagrama (mesmo que no seu nível de abstra-ção), devesse obedecer à sua sintática mantendo a semântica trazida de outro diagrama, ou seja, um diagrama, efetivamente, não se encaixava no outro, a não ser que se fizesse um grande esforço para enxergar, por exemplo, o que um DFD tem a ver com o seu respectivo DER (MATOS, 2002).

O esforço da UML é permitir que desde a representação das funções básicas do sistema (e seus respectivos responsáveis) até o pla-nejamento da arquitetura de implementação, todo o processo aconteça de maneira coerente e com uma estreita ligação com o plano anterior (MATOS, 2002).


5.4 Que caminho deve ser seguido para apren-dê-la?

O ponto de partida é conhecer o Paradigma de Orientação a Objetos. Mesmo aqueles que já programam usando a orientação a ob-jetos precisam conhecer detalhes que, às vezes, passam despercebidos aos programadores. E aqueles que não conhecem a orientação a objetos farão um grande exercício de abstração; no entanto, não se pode con-siderar que o não-conhecimento prévio da Programação Orientação a Objetos seja um empecilho para utilizar a UML (MATOS, 2002).

O uso de um software de apoio à modelagem é muito importan-te por dois motivos: primeiro porque os modelos começarão a ficar tão longos que o papel ficará pequeno, segundo porque é uma ótima maneira de checar se as associações entre os modelos estão corretas (MATOS, 2002).

5.5 UML e o desenvolvimento de software

Outra questão muito importante é como o software, enfim, vai ser produzido. Que caminho é aconselhável para chegar a esse ponto? Quais são os requisitos mínimos para que o software produzido tenha qualidade?

Há cinco etapas bem distintas em qualquer processo de desen-volvimento de software: levantamento de requisitos, análise de requi-sitos, projeto, implementação, testes e implantação. Independente de qual forma foi escolhida, de qual tática será adotada, é imprescindível que essas seis fases surjam de alguma forma (MATOS, 2002).

Na verdade, a UML não prescreve nenhum roteiro, apenas per-mite que a criatividade e o bom senso permeiem um desenvolvimento com qualidade. A qualidade surge obviamente de qualquer processo em que o produto final foi testado e verificado se foi desenvolvido conforme as necessidades do cliente (MATOS, 2002).

Resumo

Nesta aula, você aprendeu:• sobre a UML e em que ela pode nos ajudar, e também porque ela

é considerada uma linguagem;• sobre os caminhos que devemos seguir para aprender a UML; e• sobre a UML e os processos de desenvolvimento de software.


1) Leia com atenção todos os itens relacionados à aula 5, para gravar seus conceitos.


AULA 1


33

Aula 6 – O processo de desenvolvimento de software

Objetivos

- Conhecer as atividades típicas de um processo de desenvolvi--mento de software;

- Compreender a importância de cada atividade no decorrer de um processo de desenvolvimento de software.

6.1 Introdução

O desenvolvimento de software é uma atividade complexa. Essa complexidade corresponde à sobreposição das complexidades relativas ao desenvolvimento dos seus diversos componentes: software, hardware, pro-cedimentos etc. Isso se reflete no alto número de projetos de software que não chegam ao fim, ou que extrapolam recursos de tempo e de dinheiro alocados (BEZERRA, 2002).

Para dar uma idéia da complexidade no desenvolvimento de sis-temas de software, são listados a seguir alguns dados levantados no Chaos Report, um estudo feito pelo Standish Group sobre projetos de desenvolvi-mento.

• Porcentagem de projetos que terminam dentro do prazo estima-do: 10%;

• Porcentagem de projetos que são descontinuados antes de che-garem ao fim: 25%;

• Porcentagem de projetos acima do custo esperado: 60%;• Atraso médio nos projetos: um ano.Tentativas de lidar com essa complexidade e de minimizar os pro-

blemas envolvidos no desenvolvimento de software envolvem a definição de processos de desenvolvimento de software. Um processo de desenvolvimento de software (ou simplesmente processo de desenvolvimento) compreende todas as atividades necessárias para definir, desenvolver, testar e manter um produto de software (BEZERRA, 2002).

Alguns objetivos de um processo de desenvolvimento são: definir quais as atividades a serem executadas ao longo do projeto; quando, como e por quem tais atividades serão executadas; prover pontos de controle para verificar o andamento do desenvolvimento; padronizar a forma de desenvol-ver software em uma organização (BEZERRA, 2002).


6.2 Atividades típicas de um processo de de-senvolvimento

Um processo de desenvolvimento classifica em atividades as tare-fas realizadas durante a construção de um sistema de software. Há vários processos de desenvolvimento propostos. Além disso, não existe o melhor processo de desenvolvimento. Cada processo tem suas particularidades em relação ao modo de arranjar e encadear as atividades de desenvolvimento. Entretanto, podem-se distinguir atividades que, com uma ou outra modifica-ção, são comuns à maioria dos processos existentes. Abaixo, descreveremos essas atividades (BEZERRA, 2002).

6.2.1 Levantamento de requisitos

A atividade de levantamento de requisitos corresponde à etapa de com-preensão do problema aplicada ao desenvolvimento de software. O principal objetivo do levantamento de requisitos é que usuários e desenvolvedores te-nham a mesma visão do problema a ser resolvido. Nessa etapa, os desenvol-vedores, juntamente com os clientes, tentam levantar e definir as necessi-dades dos futuros usuários do sistema a ser desenvolvido. Essas necessidades são geralmente denominadas requisitos (BEZERRA, 2002).

Formalmente, um requisito é uma condição ou capacidade que deve ser alcançada ou possuída por um sistema ou componente deste para satisfazer um contrato, padrão, especificação ou outros documentos formal-mente impostos. Normalmente os requisitos de um sistema são identificados a partir do domínio do negócio. Denomina-se domínio do negócio a área de conhecimento específica na qual um determinado sistema de software será desenvolvido. Ou seja, o domínio do negócio corresponde à parte do mundo real que é relevante ao desenvolvimento de um sistema, no sentido de que algumas informações e processos desse domínio precisam ser incluídos no sistema. O domínio do negócio também é chamado de domínio do problema ou domínio da aplicação (BEZERRA, 2002).

Durante o levantamento de requisitos, a equipe de desenvolvimen-to tenta entender o domínio do negócio que deve ser automatizado pelo sistema de software. O levantamento de requisitos compreende também um estudo exploratório das necessidades dos usuários e da situação do siste-ma atual (se este existir). Há várias técnicas utilizadas para isso, como por exemplo: leitura de obras de referência e livros-texto, observação do am-biente do usuário, entrevistas com os usuários, entrevistas com especialistas do domínio, reutilização de análises anteriores, comparação com sistemas preexistentes do mesmo domínio do negócio (BEZERRA, 2002).

O produto do levantamento de requisitos é o documento de requi-sitos, que declara os diversos tipos de requisitos do sistema. Normalmente esse documento é escrito em uma notação informal (em linguagem natural). As principais seções de um documento de requisitos são listadas a seguir (BEZERRA, 2002).


Requisitos funcionais: definem as funcionalidades do sistema. Al-guns exemplos de requisitos funcionais são listados a seguir.

• “O sistema deve permitir que cada professor realize o lançamen-to de notas das turmas nas quais lecionou”;

• “O sistema deve permitir que um aluno realize a sua matrícula nas disciplinas oferecidas em um semestre”;

• “Os coordenadores de escola devem poder obter o número de aprovações, reprovações e trancamentos em todas as turmas em um determinado período”.

Requisitos não-funcionais: declaram as características de quali-dade que o sistema deve possuir e que estão relacionadas às suas funciona-lidades. Alguns tipos de requisitos não-funcionais são enumerados a seguir.

• Confiabilidade: corresponde a medidas quantitativas da confia-bilidade do sistema, tais como tempo médio entre falhas, recu-peração de falhas ou quantidade de erros por milhares de linhas de código-fonte.

• Desempenho: requisitos que definem tempos de resposta espe-rados para as funcionalidades do sistema.

• Portabilidade: restrições sobre as plataformas de hardware e de software nas quais o sistema será implantado e sobre o grau de facilidade para transportar o sistema para outras plataformas.

• Segurança: limitações sobre a segurança do sistema em relação a acessos não-autorizados.

• Usabilidade: requisitos que se relacionam ou afetam a usabilida-de do sistema. Exemplos incluem requisitos sobre a facilidade de uso e a necessidade ou não de treinamento dos usuários.

Restrições: declaração de restrições impostas sobre o desenvolvi-mento do sistema. Restrições definem, por exemplo, a adequação a custos e prazos, a plataforma tecnológica, aspectos legais (licenciamento), limitações sobre a interface com o usuário, componentes de hardware e software a serem adquiridos etc.

Uma das formas de se medir a qualidade de um sistema de softwa-re é através de sua utilidade. E um sistema será útil para seus usuários se atender aos requisitos definidos. Portanto, os requisitos devem ser expressos de uma maneira tal que eles possam ser verificados e comunicados a leitores técnicos e não-técnicos. A equipe técnica (leitores técnicos) deve entender o documento de requisitos de tal forma a poder obter soluções técnicas apropriadas. Clientes (leitores não-técnicos) devem entender esse documen-to para que possam priorizar o desenvolvimento dos requisitos, conforme as necessidades da organização (BEZERRA, 2002).

Um ponto importante sobre o documento de requisitos é que ele não deve conter informações sobre as soluções técnicas que serão adotadas para desenvolver o sistema. O enfoque prioritário do levantamento de re-quisitos é responder claramente à questão “O que o usuário necessita do novo sistema?”. Lembre-se sempre: novos sistemas serão avaliados pelo seu grau de conformidade aos requisitos, não importa quão complexa a solução tecnológica tenha sido. Requisitos definem o problema a ser resolvido pelo sistema de software; eles não descrevem o software que resolve o problema (BEZERRA, 2002).


O levantamento de requisitos é a etapa mais importante em termos de retorno em investimentos feitos para O projeto de desenvolvimento. Mui-tos sistemas foram abandonados ou nem chegaram a uso porque os membros da equipe não dispensaram tempo suficiente para compreender as necessi-dades do cliente em relação ao novo sistema. Por outro lado, um sistema de informações é normalmente utilizado para automatizar processos de negócio de uma organização: Portanto, esses processos devem ser compreendidos antes da construção do sistema de informações (BEZERRA, 2002).

O documento de requisitos serve como um termo de consenso entre a equipe técnica (desenvolvedores) e o cliente. Esse documento constitui a base para as atividades subsequentes do desenvolvimento do sistema e fornece um ponto de referência para qualquer validação futura do software construído. O envolvimento do cliente desde o início do processo de desen-volvimento ajuda a assegurar que o produto desenvolvido realmente atenda às necessidades identificadas (BEZERRA, 2002).

Além disso, o documento de requisitos estabelece o escopo do sistema (isto é, o que faz parte e o que não faz parte do sistema). O escopo de um sistema muitas vezes muda durante o seu desenvolvimento. Desta forma, se o escopo muda, tanto clientes quanto desenvolvedores têm um parâmetro para decidirem o quanto dos recursos de tempo e financeiros devem mudar. Contudo, o planejamento inicial do projeto deve se basear no escopo inicial (BEZERRA, 2002).

Um outro ponto importante sobre os requisitos é a sua característi-ca de volatilidade. Um requisito volátil é aquele que pode sofrer modificações durante o desenvolvimento do sistema. Nos primórdios da modelagem de sis-temas, era comum a prática de “congelar” os requisitos levantados antes de se iniciar a construção do sistema. Isto é, os requisitos considerados eram os mesmos do início ao fim do projeto de desenvolvimento. Atualmente, a vola-tilidade dos requisitos é um fato com o qual a equipe de desenvolvimento de sistemas tem de conviver e consequentemente o congelamento de requisitos é impraticável. Isso porque, nos dias atuais, as organizações precisam se adaptar a mudanças cada vez mais rapidamente. Durante o período em que o sistema está em desenvolvimento, as tecnologias utilizadas, as expectativas dos usuários, e as regras do negócio mudam. E isso para mencionar apenas algumas possíveis mudanças (BEZERRA, 2002).

Isso parece se contrapor ao fato de que o documento de requisitos deve definir de forma clara quais são os requisitos do sistema. Na realidade, o documento de requisitos serve como um consenso inicial. O ponto principal do levantamento de requisitos é compreender o sistema o máximo possível antes de começar a ser construído. A regra é definir completamente qual-quer requisito já conhecido, mesmo os mais simples. À medida que novos requisitos sejam detectados (ou que requisitos preexistentes mudem), os desenvolvedores devem verificar cuidadosamente o impacto das mudanças resultantes no escopo do sistema. Dessa forma, os clientes podem decidir se tais mudanças devem ser consideradas no desenvolvimento, uma vez que influenciam o cronograma de desenvolvimento e os recursos financeiros alo-cados (BEZERRA, 2002).


A menos que o sistema a ser desenvolvido seja bastante simples e estático (características raras nos sistemas atuais), é praticamente impossí-vel pensar em todos os detalhes a princípio. Além disso, quando o sistema entrar em produção e os usuários começarem a utilizá-lo, eles próprios des-cobrirão requisitos nos quais não tinham pensado inicialmente. Em resumo, os requisitos de um sistema complexo inevitavelmente mudarão durante o seu desenvolvimento (BEZERRA, 2002).

Uma característica desejável a um documento de requisitos é ter os seus requisitos ordenados pelos usuários em função do seu grau de prio-ridade. O grau de prioridade de um requisito para os usuários normalmente é estabelecido em função da adição de valor que o desenvolvimento desse requisito no sistema trouxer aos usuários. Saber o grau de prioridade de um requisito permite que a equipe de desenvolvimento (mais particularmente o gerente do projeto) decida em que momento cada requisito deve ser consi-derado durante o desenvolvimento. As prioridades atribuídas aos requisitos permitirão ao gerente de projeto tomar decisões acerca do momento no qual cada requisito deve ser considerado durante o desenvolvimento do sistema (BEZERRA, 2002).

6.2.2 Análise de requisitos

Formalmente, o termo análise corresponde a “quebrar” um sistema em seus componentes e estudar como tais componentes interagem com o objetivo de entender como esse sistema funciona. No contexto dos sistemas de software, esta é a etapa na qual os analistas realizam um estudo detalha-do dos requisitos levantados na atividade anterior. A partir desse estudo, são construídos modelos para representar o sistema a ser construído. A análise de requisitos é também chamada de especificação de requisitos.

Assim como no levantamento de requisitos, a análise de requisitos não leva em conta o ambiente tecnológico a ser utilizado. Nesta atividade, o foco de interesse é tentar construir uma estratégia de solução sem se preocupar com a maneira como essa estratégia será realizada. A razão desta prática é tentar obter a melhor solução para o problema sem se preocupar com os detalhes da tecnologia a ser utilizada. É necessário saber o que o sis-tema proposto deve fazer para, então, definir como esse sistema irá fazê-Io (BEZERRA, 2002).

O termo “paralisia da análise” é conhecido no desenvolvimento de sistemas de software. Esse termo denota a situação em que há uma es-tagnação da fase de análise: os analistas passam muito tempo construindo o modelo do sistema. Embora essa situação certamente exista, na prática raramente poderíamos encontrá-Ia. O que ocorre frequentemente na prática é exatamente o contrário: equipes de desenvolvimento que passam para a construção da solução sem antes terem definido completamente o problema. Portanto, os modelos construídos na fase de análise devem ser cuidadosa-mente validados e verificados, através da validação e verificação dos modelos, respectivamente (BEZERRA, 2002).


O objetivo da validação é assegurar que as necessidades do cliente estão sendo atendidas pelo sistema: será que o software correto está sendo construído? Já a verificação tem o objetivo de verificar se os modelos constru-ídos estão em conformidade com os requisitos definidos: será que o software está sendo construído corretamente? Na verificação dos modelos da análise, é analisada a exatidão de cada modelo em separado e a consistência entre os modelos (BEZERRA, 2002).

Em um processo de desenvolvimento orientado a objetos, o resul-tado da análise são modelos que representam as estruturas das classes de objetos componentes do sistema. Além disso, a análise também resulta em modelos que especificam as funcionalidades do sistema de software (BEZER-RA, 2002).

6.2.3 Projeto

O foco principal da análise são os aspectos lógicos e independen-tes de implementação de um sistema (os requisitos). Na fase de projeto, determina-se “como” o sistema funcionará para atender aos requisitos, de acordo com os recursos tecnológicos existentes (a fase de projeto considera os aspectos físicos e dependentes de implementação). Aos modelos construí-dos na fase de análise são adicionadas as denominadas “restrições de tecno-logia” (BEZERRA, 2002). Exemplos de aspectos a serem considerados na fase de projeto: arquitetura do sistema, padrão de interface gráfica, a linguagem de programação, o gerenciador de banco de dados etc.

Esta fase produz uma descrição computacional do que o software deve fazer e deve ser coerente com a descrição feita na análise. Em alguns casos, algumas restrições da tecnologia a ser utilizada já foram amarradas no levantamento de requisitos. Em outros casos, essas restrições devem ser especificadas. Mas, em todos os casos, a fase de projeto do sistema é dire-cionada pelos modelos construídos na fase de análise e pelo planejamento do sistema (BEZERRA, 2002).

O projeto consiste de duas atividades principais: projeto da arqui-tetura (também conhecido como projeto de alto nível) e projeto detalhado (também conhecido como projeto de baixo nível). .

Em um processo de desenvolvimento orientado a objetos, o projeto da arquitetura consiste em distribuir as classes de objetos relacionadas do sistema e subsistemas e seus componentes. Consiste também em distribuir esses componentes fisicamente pelos recursos de hardware disponíveis. Os diagramas da UML normalmente utilizados nesta fase do projeto são os dia-gramas de implementação. O projeto da arquitetura é normalmente realiza-do por um arquiteto de software (BEZERRA, 2002).

No projeto detalhado, são modeladas as colaborações entre os ob-jetos de cada módulo com o objetivo de realizar as funcionalidades do módu-lo. Também são realizados o projeto da interface com o usuário e o projeto de dados. Os diagramas da UML utilizados nesta fase do projeto são: diagra-


ma de classes, diagrama de casos de uso, diagrama de interação, diagrama de estados e diagrama de atividades.

Embora a análise e o projeto sejam descritos em seções separadas neste caderno, é importante notar que não há uma distinção assim tão cla-ra entre essas duas fases. Principalmente no desenvolvimento de sistemas orientados a objetos, as atividades dessas duas fases frequentemente se misturam (BEZERRA, 2002).

6.2.4 Implementação

Na implementação, o sistema é codificado, ou seja, ocorre a tradu-ção da descrição computacional da fase de projeto em código executável através do uso de uma ou mais linguagens de programação.

Em um processo de desenvolvimento orientado a objetos, a imple-mentação envolve a definição das classes de objetos do sistema utilizando linguagens de programação como C++,Java etc. Além da codificação desde o início, a implementação pode também utilizar componentes de software e bibliotecas de classes preexistentes para agilizar a atividade (BEZERRA, 2002).

6.2.5 Testes

Diversas atividades de teste são realizadas para verificação do siste-ma construído, levando-se em conta a especificação feita na fase de projeto. O principal produto dessa fase é o relatório de testes, contendo informações sobre erros detectados no software. Após a atividade de testes, os diversos módulos do sistema são integrados, resultando finalmente no produto de software (BEZERRA, 2002).

6.2.6 Implantação

O sistema é empacotado, distribuído e instalado no ambiente do usuário. Os manuais do sistema são escritos, os arquivos são carregados, os dados são importados para o sistema e os usuários são treinados para utilizar o sistema corretamente. Em alguns casos, aqui também ocorre à migração de sistemas de software e de dados preexistentes (BEZERRA, 2002).

Resumo

Nesta aula, você aprendeu:• sobre as atividades típicas de um processo de desenvolvimento

de software;• sobre a importância de cada atividade no decorrer de um pro-

cesso de desenvolvimento de software.


Atividades de aprendizagem1) Qual é o conceito do processo de desenvolvimento de software?

2) Quais são os objetivos de um processo de desenvolvimento de software?

3) Quais são as atividades típicas de um processo de desenvolvimento de software? Descreva de forma sucinta cada atividade.

4) Qual é o conceito de requisitos?

5) Como é chamado o produto do levantamento de requisitos?

6) Dê o conceito de requisitos funcionais e requisitos não-funcionais? Cite exemplos dos dois tipos de requisitos.

7) Qual é o objetivo da validação e da verificação dos modelos construídos na fase de análise?


AULA 1


41

Aula 7 – Modelagem Baseada em UML

Objetivos

- Conhecer um breve histórico da UML;- Conhecer os principais diagramas da UML;- Saber a identificar um caso de uso;- Aprender a identificar atores;- Aprender a desenhar um diagrama de caso de uso;- Conhecer os cuidados necessários ao se criar diagramas de caso de uso;- Aprender a identificar classes;- Aprender a identificar relacionamentos;- Conhecer extensões e mecanismos;- Aprender a desenhar um diagrama de classes;- Conhecer os tipos de diagramas de interação;- Conhecer diagramas de colaboração;- Conhecer diagramas de sequência;- Aprender a desenhar diagramas de sequência;- Aprender sobre diagramas de estados e sua função;- Aprender a desenhar diagramas de estados;- Aprender sobre diagramas de atividades;- Aprender a desenhar diagramas de atividades;- Conhecer componentes de software;- Aprender a desenhar diagramas de componentes;- Aprender a desenhar diagramas de implantação.

7.1 Introdução

Finalmente vamos conhecer a UML. O importante é que alguns lem-bretes permaneçam até a última aula:

• UML é baseada em um conjunto de diagramas, portanto o mo-delo não termina no primeiro diagrama, a não ser que se deseje um aspecto bem reduzido do problema;

• Cada diagrama da UML enfoca um aspecto distinto do problema, ou seja, é necessário, a cada diagrama, um exercício de abstra-ção diferente;

• UML não é uma linguagem de programação, mas de modelagem, ou seja, aqui os testes não são sob os erros de execução, mas os de consistência;

• Por último, todos os diagramas estão de alguma forma ligados, portanto, o desenho de um diagrama tem que obrigatoriamente ser coerente com o que já foi proposto (MATOS, 2002).


7.2 Um breve histórico

A UML é uma linguagem criada com o propósito de permitir espe-cificações, visualizações e documentação de artefatos de sistemas. Ou seja, é permitido usar a UML para entender e manipular todos os elementos que direta ou indiretamente influenciam na construção do software (artefatos). Dessa forma, é possível, também, a avaliação da modelagem do negócio ou de quaisquer outros aspectos não necessariamente computacionais (MATOS, 2002).

No entanto, para chegar a essa especificação, alguns detalhes his-tóricos foram importantes.

O primeiro foi a constatação de que o software possui valor estra-tégico nos negócios de uma empresa. Ou seja, são necessárias técnicas que automatizem a produção do software, mas não perdendo de vista a arquite-tura do sistema e do negócio.

Nesse contexto, o segundo detalhe histórico ocorria no final da década de 80. O panorama do desenvolvimento de software, nesta época, vislumbrava a utilização de várias técnicas e ferramentas baseadas na orien-tação a objetos. Por causa dessa “confusão”, em 1994, dois importantes au-tores imaginaram a fusão dos conceitos de seus métodos com vistas à criação de um método unificado (Grady Booch e James Rumbaugh). Com a fusão de seus métodos (Booch e OMT - Object Modeling Technology de Booch e Rum-baugh respectivamente), uma semente para a criação de um padrão havia, enfim, sido plantada (MATOS, 2002).

Um questionamento perdurava: “o que fazer, então, com os méto-dos que ainda existiam?”. Neste caso, o grande trunfo da idéia de Booch e Rumbaugh era que, criando um padrão, a indústria participaria, opinaria e iniciaria a construção de recomendações. Este pensamento nos remete ao terceiro importante detalhe histórico - a versão draft 0.8 da UML, idealizada em outubro de 1995 (MATOS, 2002).

Muitas empresas ligadas à informática perceberam nessa nova pro-posta uma importante alavanca para a melhoria da qualidade dos proces-sos de software orientado a objetos. Dessa forma, um grupo importante de empresas reunidas sob a OMG (Object Management Group) destacou pontos importantes para essa nova recomendação e idealizou a primeira proposta completa da linguagem – a versão 0.9 da UML. Nesta versão, características de outro método foram incluídas (OOSE - Object Oriented Software Enginee-ring de Ivar Jacobson) (MATOS, 2002).

Sob a proteção da OMG (a UML é marca registrada da OMG), ficou estabelecido (desde sua origem já estava definido) que se trataria de uma proposta não proprietária e aberta, ou seja, as empresas membro da OMG teriam a liberdade de propor recomendações e adendos à especificação ori-ginal, permitindo que novas funcionalidades fossem assumidas. Neste con-texto, a UML já está na sua versão 2.3 e suas modificações têm sido ampla-mente discutidas em eventos e listas de discussão (MATOS, 2002).


7.3 Diagramas da UML

A proposta básica (efetuada pela OMG) indica cinco níveis de abs-tração:

• Identificar as funções do sistema e seus respectivos responsáveis por meio de um Diagrama de Caso de Uso:

Figura 5: Representação de um diagrama de caso de uso.Fonte: Matos (2002).

• Identificar as estruturas mínimas de informação por meio de um Diagrama de Classes:

Figura 6: Representação de um diagrama de classes.Fonte: Matos (2002).

• Modelar e compreender o comportamento e o dinamismo das classes por meio de Diagramas de Interação (Sequência ou Co-laboração).


Figura 7: Representação de um diagrama de sequência.Fonte: Matos (2002).

• Compreender os estados das execuções, permitindo identifi-car o comportamento das classes por meio de Diagramas de Estado e de Atividade.

Figura 8: Representação de um diagrama de estado.Fonte: Matos (2002).


• Esquematizar o processo de implementação e o de implan-tação, por meio dos componentes (hardware ou software) previstos para o sistema, por intermédio de Diagramas de Componentes e de Implantação.

Figura 9: Representação de um diagrama de componentes e de implantação.Fonte: Matos (2002).

7.4 Processo adotado neste caderno

A abordagem que será apresentada neste caderno não é nenhum processo formal de software. Apenas por uma questão de melhor entendi-mento e de percepção da relação existente entre os diagramas foi organiza-da a distribuição (MATOS, 2002).

Os Casos de Uso são o primeiro tópico, haja vista a sua importância no princípio de qualquer processo de software - determinar o que é o siste-ma?

As classes atuam não apenas como complementações aos casos de uso, mas também podem ser desenhadas para que os diagramas de interação possam validar suas estruturas (MATOS, 2002).

As interações, representadas pelas sequências e colaborações, são a melhor visão do funcionamento das operações, ou os métodos que serão parte das classes (MATOS, 2002).

Estados e atividades permitem que eventos possam ser identifica-dos e estudados, ou seja, pode-se ter uma noção completa dos estados ines-perados ou até mesmo os esperados na execução das operações (MATOS, 2002).

Por fim, estudaremos formas de estruturar os programas e também de arquitetar a organização do hardware envolvido no sistema.


7.5 Casos de uso

Geralmente quando nos deparamos com a necessidade de iniciar o modelo de um sistema, vem-nos à mente o desejo de criar uma lista das fun-ções que o sistema precisa implementar. Existem técnicas e ferramentas que apóiam essa iniciativa, no entanto do ponto de vista da orientação a objetos essa não é uma boa idéia (MATOS, 2002). As funções têm o seu local bem determinado - são parte de uma classe e são diretamente executadas pelos objetos dessas classes. Se este não é o ponto de partida, então qual seria?

Na verdade, construímos sistemas computacionais para que usuá-rios pessoas possam utilizá-los ou para que eles sejam entrada ou saída de outros sistemas. Portanto, o ponto de partida é saber quem ou o que intera-ge com o sistema (MATOS, 2002).

Os Casos de uso (do inglês Use Case) são utilizados para identificar as regras do negócio e são uma excelente forma de entender o ponto de vista do usuário simplesmente pelo fato de que modela o que ele precisa executar (MATOS, 2002).

Internamente, um caso de uso é uma sequência de ações que per-meiam a execução completa de um comportamento esperado para o sistema.

Este é o ponto de partida de todo o processo, por isso é necessário ter muito cuidado e não incluir detalhes demais. Um Diagrama de Caso de Uso deve ser simples, porém não pode ser incompleto (MATOS, 2002).

7.5.1 Identificando um caso de uso

A primeira coisa que precisa ficar clara é a distinção que existe entre um processo de um Diagrama de Fluxo de Dados e um Caso de Uso. Enquanto processos representam fluxos de dados e precisam, portanto, de dados de entrada e geram dados de saída, um caso de uso é apenas a representação de uma função, manipulada por uma entidade do sistema, conhecida como Ator, ou seja, não nos interessa o fluxo dos dados, pois essa transformação cabe aos métodos da classe (e serão tratados no Dia-grama de Interação). Nosso enfoque nesse momento não são as classes ou as interações (MATOS, 2002).

Figura 10: Representação de um diagrama de fluxo de dados e de um diagrama de caso de uso.Fonte: Matos (2002).


Um caso de uso não deve se preocupar com o “como” das funções, mesmo que este “como” seja apenas conhecer o fluxo de entrada e saída de dados. É importante encapsular ações que em conjunto sejam relevantes e que de alguma forma influenciam algo ou alguém no sistema (MATOS, 2002).

Identificar um caso de uso, portanto, é um esforço que envolve: • descobrir um ator (alguém que influencia ou é influenciado pelo

sistema; • verificar para esse ator ações das quais ele participaria; • agrupar tais ações de forma que possuam um nome em comum

(geralmente um. verbo no infinitivo).

7.5.2 Identificando atores

O ator está relacionado a um papel. No contexto do sistema, papel diz respeito à visão dada ao sistema. Por exemplo, em um hospi-tal teríamos pelo menos quatro papéis distintos: paciente, enfermeira, médico e o setor administrativo, haja vista que o tipo de informação que um manipula jamais seria manipulado por outro (por exemplo, uma en-fermeira não pode receitar nada a um paciente) (MATOS, 2002).

O que se pretende concluir com esta idéia é o seguinte: os dados que uma enfermeira veria em seu formulário do sistema seriam diferen-tes dos dados que o médico veria, ou seja, há o ator médico e também há o ator enfermeira, cujos casos de uso seriam distintos (MATOS, 2002).

7.5.3 Desenho de um diagrama de caso de uso

Um lembrete importante antes de iniciar qualquer modelo (diagra-ma) é entender o PORQUÊ de estar desenhando aquilo. Como já conhecemos o objetivo do Diagrama de Caso de Uso, é imprescindível que se tenha em mente, desde já, a necessidade de identificação de atores e suas respectivas visões. No entanto, para que fique simples e tenhamos um roteiro que facili-te, abaixo seguem alguns passos que devem ser observados na criação de um Diagrama de Caso de Uso (MATOS, 2002).

Figura 11: Passos para a criação de um diagrama de caso de uso.Fonte: Matos (2002).


Um exemplo clássico está ligado às tarefas cotidianas de uma clíni-ca médica.

Seguindo os passos indicados anteriormente, teríamos:

Figura 12: Identificação dos atores.Fonte: Matos (2002).

Este é um passo relativamente simples. Às vezes, é bom fazer a se-guinte comparação: “enfim, quem vai ficar à frente do computador operando o sistema?”. Esta pergunta não resolve por completo a identificação de todos os atores, no entanto permite que se deixe uma certa vazão para aquelas responsabilidades que não foram cobertas (MATOS, 2002).

Figura 13: Identificação dos atores e seus casos de uso.Fonte: Matos (2002).

Ao identificar um ator, obviamente, percebe-se no que especifica-mente ele atuará. Os passos 2 e 3 são úteis para rotular o que cada ator fará ou responsabilizar-se-á no sistema (MATOS, 2002).

Diagramas de Caso de Uso também são úteis para a identificação de duas situações relacionadas a qualquer sistema computacional.


SITUAÇÃO 1: é muito comum que mais de uma função do sistema execute tarefas parecidas. Na figura apresentada em seguida, espera-se que em três momentos distintos seja feita uma identificação antecipada do pa-ciente. Essa identificação é importante em todas essas situações, pois, caso contrário, não se sabe quem está sendo atendido (MATOS, 2002). Os momen-tos citados são os seguintes:

• quando o paciente chega à clínica e é atendido pela enfermeira;

• quando o paciente decide, enfim, marcar uma consulta;

• quando o médico avalia as condições do paciente mediante seus

sintomas e decide aplicar um tratamento (diagnóstico).Esta situação indica a existência de uma típica relação uses entre

casos de uso. O termo uses é bem elucidativo: o caso de uso em questão usa o caso de uso indicado (MATOS, 2002).

É necessário ressaltar que o caso de uso “usado” somente é rele-vante para ser representado se for compartilhado entre outros casos de uso. Caso contrário, estaríamos apenas detalhando o comportamento esperado de um único caso de uso. Esse detalhamento, na verdade, vai ser analisado apenas nos diagramas de interação e de classe (MATOS, 2002).

Figura 14: Identificação de relações entre casos de uso do tipo uses.Fonte: Matos (2002).

SITUAÇÃO 2: quando alguma recorrência surge. Por exemplo, no próximo diagrama percebe-se que pode existir a situação em que o paciente nunca foi atendido nessa clínica (MATOS, 2002). Situações inesperadas como estas indicam a existência de relações do tipo extends.


Figura 15: Identificação de relações entre casos de uso do tipo extends.Fonte: Matos (2002).

7.5.4 Cuidados com os diagramas de caso de uso

A primeira ação que NÃO deve ser representada é a inclusão de aspectos de implementação. Conforme já citado anteriormente, o “como” deve ser deixado para outros níveis de abstração, ou seja, para os diagramas de classes e de interação (MATOS, 2002).

No entanto, o aspecto mais perigoso nesse momento seria o abuso de uses e extends. A relação uses somente deve ser empregada quando houver realmente um compartilhamento da função indicada; caso contrário, estaremos abusando do detalhamento e produzindo um diagrama exagerada-mente pormenorizado (MATOS, 2002).

Na Figura seguinte, a intenção do caso de uso Verificar Histórico de Tratamento é uma ação que pode até ser óbvia em qualquer consultório médico, todavia, não se trata de algo que seria compartilhado por outros casos de uso, ou seja, na verdade, é uma parte do caso de uso Diagnosticar Paciente (MATOS, 2002).


Figura 16: Cuidados na criação dos diagramas dos casos de uso.Fonte: Matos (2002).

O que convém ser salientado, portanto, é que um Diagrama de Caso de Uso deve ser o mais simples possível. Detalhes devem ser deixa-dos para outros diagramas, pois eles foram idealizados justamente com este objetivo (MATOS, 2002).

No entanto, problemas complexos necessitam obviamente ser sim-plificados. Nesse caso, o importante é permitir que a complexidade seja gerenciada desde o início. No caso específico de Diagramas de Caso de Uso, isso significaria produzir diagramas que ressaltem quais são as fronteiras do negócio, tal como o diagrama seguinte:

Figura 17: Pacotes representando os subsistemas de um sistema para controle de clínicas.Fonte: Matos (2002).

Nesse caso, cada subsistema poderia ser modelado por um dia-grama de caso de uso particular. Por exemplo, o setor relacionado à enfermeira poderia ser visto como:


Figura 18: Diagrama de casos de uso do subsistema enfermeira.Fonte: Matos (2002).

E o subsistema do médico seria modelado como:

Figura 19: Diagrama de casos de uso do subsistema médico.Fonte: Matos (2002).

Em suma, Diagramas de Caso de Uso são ferramentas que nos ajudam a enxergar o todo do sistema por intermédio da constatação das responsabilidades que os usuários diretos do sistema têm (MATOS, 2002).

Outros aspectos, tais como: como cada caso de uso é efetiva-mente utilizado ou onde ficarão armazenados os dados que são utilizados para fazer os casos de uso funcionarem. Esses são assuntos para discus-são em próximos diagramas (MATOS, 2002).


7.6 Classes

A UML é adequada para a modelagem de sistemas, cuja abrangên-cia pode incluir sistemas de informação corporativos a serem distribuídos para aplicações baseadas em Web e até sistemas complexos embutidos de tempo real (MATOS, 2002).

Em qualquer aplicação orientada a objetos, classes são importantes por quatro motivos:

• Na verdade, são a real estrutura de dados, ou seja, são o objeti-vo final para o início da etapa de programação;

• Dar ao programador a noção do domínio do problema; • Projetar uma solução de implementação ao problema; • Traçar perspectivas de escalabilidade ao sistema (onde e como o

sistema pode crescer em termos funcionais).

A princípio, para quem apenas possui experiência com a modela-gem de dados, o Diagrama de Classes pode parecer uma simples coleção de entidades mais complexas, no entanto esta é uma idéia errada, pois o mo-delo de classes especializa-se na representação do COMPORTAMENTO e não apenas dos dados (MATOS, 2002).

A construção de um Diagrama de Classes está, obviamente, base-ada no conceito de Classe. Desse fato, pode-se concluir que Diagramas de Classes são estáticos, ou seja, devem apenas esboçar o que interage e não o que acontece quando as classes interagem. Portanto, para que se crie um Diagrama de Classes, é imprescindível conhecer todos os conceitos do Pa-radigma de Orientação a Objetos relacionados à noção de classes (MATOS, 2002).

7.6.1 Identificando classes

Uma classe é uma abstração de um conjunto de coisas que possuem características e operações em comum. Ou seja, uma classe é um conjunto de objetos (MATOS, 2002). No Paradigma de Objetos, um objeto é uma uni-dade fundamental. Somos forçados a pensar nos nossos programas não como um conjunto de registradores da memória, mas como realmente é o mundo real - um conjunto de coisas (que possuem atributos e operações).

Partindo desse fato, há alguns aspectos que facilitam a identifica-ção de classes. O primeiro aspecto é o fato de que uma classe surge da união de vários objetos que possuem coisas em comum. Por exemplo, se em um hospital percebe-se a importância de que várias pessoas pertençam a um mesmo convênio e essas pessoas começam a se tornar comuns e em grande quantidade, alguma operação pode uni-Ias e mais, alguma funcionalidade do sistema poderá ser importante para esse conjunto de pessoas. Talvez esse seja o caso de criar uma classe para pessoas conveniadas, em vez de apenas ter um atributo diferenciador (MATOS, 2002).


As Classes são uma síntese de um conjunto de coisas. Essas coisas podem ser facilmente identificadas no contexto do problema, tais como: Eventos, Papéis, Recursos, Equipamentos, Sociedades, Responsabilidades, etc.

É bom salientar que uma classe não é, efetivamente, uma entidade (do modelo Entidade-Relacionamento). Uma entidade existe como um repo-sitório de dados e uma classe como um ENCAPSULAMENTO de atributos e métodos (MATOS, 2002).

Em UML, uma classe é esquematicamente representada por:

Figura 20: Representação de uma classe.Fonte: Matos (2002).

A UML é apenas uma linguagem, ou seja, apesar de existir uma noção padronizada de que linguagens em informática relacionam-se apenas a Linguagens de Programação, a UML é uma espécie de linguagem cuja in-tenção não é passar por um processo de compilação e geração de código da maneira como se conhece, mas servir de padrão para facilitar a condução do processo de desenvolvimento do software (MATOS, 2002).

Os componentes da linguagem de modelagem unificada (UML) são importantes para a representação tanto conceitual quanto física do sistema. Nessa aula, serão discutidos todos os recursos relacionados com o Diagrama de Classes, porém muitos desses recursos também são aplicáveis a outros diagramas da UML (MATOS, 2002).

7.6.2 Relacionamentos

Uma classe não é um ponto isolado e totalmente autônomo dentro de um sistema de software. Para que uma classe obtenha sucesso e real-mente execute suas tarefas, invariavelmente, ações vindas de outras classes serão necessárias (MATOS, 2002).

Para os programadores de Java, C++, SmallTalk, Eifel e outras lin-guagens orientadas ou baseadas em objetos (até mesmo Delphi ou Object Pascal poderiam ser citados), a afirmação do parágrafo anterior não soaria estranho.

Por exemplo:


Há quatro tipos de relacionamento possíveis em um modelo de UML:

Dependências

Relacionamentos no qual a modificação em um item superior (uma superclasse, por exemplo) ocasiona modificações em itens inferiores. Por exemplo, uma ação que passa a ser executada de uma forma diferenciada em um item superior seria também executada de maneira diferenciada em um item inferior (MATOS, 2002).

A representação para esse relacionamento é indicada em seguida:

Figura 21: Representação de um relacionamento de dependência.Fonte: Matos (2002).

Há duas observações relacionadas à representação em seguida: • Todo método, em qualquer classe, convencionalmente é repre-

sentado por dois parênteses para indicar a presença ou não de parâmetros. Por exemplo, regular();

• A adição de uma pessoa à lista ou sua retirada indica a neces-sidade de um objeto da classe Pessoa, ou seja, esses métodos dependem de como um objeto Pessoa está organizado.

A princípio, representar uma dependência pode parecer desneces-sário, mas é extremamente importante conhecer o limite de classes uti-lizadas na implementação, além de dar um limite ao escopo do problema (MATOS, 2002).

Herança

Uma forma de criar hierarquias entre classes e entender o esquema de herança inerente a qualquer aplicação orientada a objetos é entender as ge-neralizações. Uma generalização é um relacionamento do tipo “é um tipo de”. Ou seja, a classe inferior é uma classificação da classe superior (MATOS, 2002).


Uma classe generalizada (especializada) herda operações e atribu-tos da classe superior, ou seja, não é necessário refazer métodos ou identi-ficar atributos de classes generalizadas, pois eles já foram definidos em um nível superior (MATOS, 2002).

No entanto, há situações em que métodos ou atributos podem ser redefinidos. Esse caso, conhecido como polimorfismo, permite que métodos ou atributos com a mesma assinatura tenham corpo distinto.

Em UML muitos aspectos do sistema podem ser representados: des-de o software do sistema em si até aspectos de implementação e implanta-ção. Dessa forma, pode-se utilizar esse relacionamento para também repre-sentar a generalização entre componentes físicos, tais como: pontos de uma rede de computadores (MATOS, 2002).

Esquematicamente a herança é representada da seguinte forma:

Figura 22: Representação de relacionamento de herança.Fonte: Matos (2002).

Associação/Agregação

A associação é um relacionamento em que é representada a cone-xão de um objeto a outro. No entanto, existem duas facetas para essa cone-xão. O primeiro aspecto diz respeito à conexão entre um objeto e outro de onde possa surgir um vínculo com ela (MATOS, 2002).

Essa associação é representada por:

O termo assinatura é utilizado em UML (ou na

orientação a objetos) para indicar como é a declaração/definição da interface de uma

classe (seus métodos e atributos). Por exemplo,

adicionar (Pessoa p) é a assinatura do método

adicionar que indica que sua execução exige

este formato.


Figura 23: Representação de relacionamento de associação.Fonte: Matos (2002).

O termo “Trabalha para” com a respectiva direção representa o vínculo criado entre os objetos das classes e permite imprimir um sentido de “navegação” na leitura do diagrama (MATOS, 2002).

Este, no entanto, não é o único tipo de associação. O outro tipo, e talvez o mais comum, é a agregação que representa uma relação do tipo todo/parte e tem propósitos diferenciados de uma associação como a representada anteriormente. Enquanto em uma associação pura podem ser identificados os papéis (que em determinados casos podem mudar), por exemplo, entre pessoa e empresa podem existir os papéis (emprega-do e empregador). Em uma agregação, o que fica mais nítido é o todo e a parte. Além desse fato, em uma agregação, ambas as classes estão no mesmo nível, não havendo distinção entre o papel mais importante e o papel coadjuvante (MATOS, 2002).

É importante ressaltar que esse tipo de agregação é conhecido como agregação fraca ou agregação simples, pelo fato de esse relaciona-mento não interferir no tempo de vida de suas “partes”, nem de haver um significado de navegação importante, como havia no exemplo ante-rior (MATOS, 2002).

O exemplo seguinte pode soar estranho, mas o intuito é identifi-car a Escola como sendo um todo, formado não de tijolos, mas de partes quais sejam os alunos e os professores. Esta não é uma visão “poética” do problema, mas é possível que a realidade do sistema modelado indique essa situação (MATOS, 2002).

Figura 24: Representação de relacionamento de agregação.Fonte: Matos (2002).


Relacionamentos como as agregações tornam-se complexos, caso informações adicionais não sejam identificadas, por exemplo, será que existe alguma restrição quantitativa para o relacionamento? Este tipo de questionamento, na verdade, pode ser adequadamente comple-mentado pela multiplicidade (MATOS, 2002). Por exemplo:

Figura 25: Representação de multiplicidade entre relacionamento.Fonte: Matos (2002).

Onde se lê: cada pessoa reside em um município e apenas nes-te, no entanto em cada município podem residir várias pessoas.

Há uma variante mais forte da agregação, em que cada classe que é uma parte do todo também se torna um componente físico do todo. Esses tipos de agregação são representados por um losango cheio (MATOS, 2002).

Por exemplo:

Figura 26: Representação de relacionamento de agregação forte.Fonte: Matos (2002).

Uma instância da classe Endereço torna-se, na verdade, parte de alguma instância da classe Pessoa, pois o endereço é também uma caracte-rística de qualquer pessoa (MATOS, 2002).

7.6.3 Extensões e mecanismos

É possível representar, em diagramas da UML, informações que auxiliam no processo de modelagem. Enquanto existem recursos que são apenas extensões aos recursos que já existem, outros são mecanismos cuja função é dar maior clareza ao modelo (MATOS, 2002).

Nesta aula estudaremos os seguintes recursos: estereótipos, inter-faces, pacotes, restrições e notas.

Estereótipos

Estereótipo é o típico recurso que se parece com a expressão “carta embaixo da manga” ou o famoso “plano B”. Ou seja, estereótipos podem ser utilizados para indicar um comportamento que se espera para determinado componente. Poderíamos dizer que um estereótipo é um metatipo, ou seja, aquele tipo que seria usado para ajudar na definição de outro tipo (MATOS, 2002).

Agregação forte é uma prática muito perigosa

- se endereço é um atributo de Pessoa,

então deveria ter sido modelado como atributo e não como

outra classe, a não ser que o Endereço seja importante, no

contexto, como uma classe à parte.


Existem alguns estereótipos predefinidos, tais como: use (em relacionamentos de casos de uso) e abstract (para indicar classes abstra-tas). E além desses, estereótipos podem ser criados e incorporados ao modelo em desenvolvimento. Todas as ferramentas CASE de desenho de UML incorporam tanto os estereótipos prontos como permitem a defini-ção de novos estereótipos (MATOS, 2002).

Em suma, estereótipos são recursos que agilizam a definição de algum componente, permitindo que comportamentos sejam incorpo-rados. Ou seja, se a palavra extends aparece, um conjunto de comporta-mentos já fica subentendido (MATOS, 2002).

A presença de um estereótipo sempre é acompanhada dos símbo-los << extends >>, como em << uses >>.

Estereótipos são recursos utilizados em todos os diagramas da UML, não estando restritos apenas às definições de classe (MATOS, 2002).

Interfaces

Existem classes cuja existência é puramente virtual, ou seja, exis-tem apenas para indicar que a interface de determinado objeto deve seguir. Em UML, a representação dessas interfaces é feita pela indicação de um es-tereótipo <<type>>. A inserção do estereótipo é importante, pois fica claro que a interface não possuirá atributos e os métodos definidos são apenas as-sinaturas, cuja implementação dar-se-á em outras instâncias (MATOS, 2002).

Figura 27: Representação de estereótipo <<type>>.Fonte: Matos (2002).

Parece simplório demais, mas uma interface exime o programador da chata tarefa de ter que pesquisar tudo o que um determinado objeto deveria fazer. Obviamente que nem todas as situações podem ser aplicadas, por exemplo, no caso mostrado anteriormente, espera-se que toda máquina de lavar roupas faça as tarefas indicadas, com o perigo de haver máquinas muito distintas (MATOS, 2002).


Pacotes

Uma analogia que soa estranho, mas que é eficaz para compreen-der este conceito é entender o que fazem os empacotadores em supermer-cados. Todos os produtos que são similares vão para os mesmos pacotes (ou sacolas). O objetivo é simples: organizar, facilitar o transporte dos produtos (MATOS, 2002).

Em um Diagrama de Classes, pacotes podem ser criados para dimi-nuir a complexidade do problema: classes que possuam características em comum podem ser incluídas em pacotes separados, tornando a manutenção e até mesmo as implementações menos complexas (MATOS, 2002).

Figura 28: Representação de pacotes.Fonte: Matos (2002).

O que se propõe neste exemplo é a distribuição da complexidade do problema em dois pacotes. Cada pacote implementa uma visão diferen-ciada do problema (MATOS, 2002).

Restrições

Dentro de um modelo, as restrições são regras que permitem expli-citar o comportamento esperado de alguns relacionamentos. As restrições podem ser descritas utilizando descrições informais ou por meio de uma linguagem específica para a descrição de restrições - OCL (Object Constraint Language) (MATOS, 2002).

Exemplo em que à representação da restrição não utiliza formalismos.

Figura 29: Representação de restrições.Fonte: Matos (2002).

O próximo exemplo mostra a utilização de OCL que complemen-ta a indicação de que há funcionários que são chefes e são objetos cujo atributo tipo possuirá o valor chefe (MATOS, 2002).


Figura 30: Representação de restrições com utilização de OCL.Fonte: Matos (2002).

Notas

Assim como em qualquer linguagem de programação, é possível fazer comentários que facilitem o entendimento do código. Em UML, este recurso também existe em todos os diagramas (MATOS, 2002).

Por exemplo:

Figura 31: Representação de notas.Fonte: Matos (2002).

Além de ser um simples comentário, notas podem conter estereó-tipos que no caso do exemplo já determinam que tipo de comportamento a nota possuirá. No exemplo, trata-se da identificação dos requisitos que o atributo possui para que possa ser manipulado (MATOS, 2002).

7.6.4 Desenho de um diagrama de classes

Não basta sabermos identificar o que é uma classe ou como elas se relacionam. Atributos e métodos são, na verdade, a parte mais importante na criação de uma classe (MATOS, 2002).

Outros diagramas, tais como: o Diagrama de Interação e o de Esta-do, facilitam a identificação dos atributos e dos métodos; no entanto, nesta aula vamos iniciar o trabalho de filtrar essas características que devem exis-tir em uma classe. Para tanto, continuaremos nos reportando à Clínica Médi-ca que vem sendo discutida nos exemplos, agora por meio de uma descrição textual (MATOS, 2002).

Suponha que os trabalhos da Clínica Médica iniciem com a chegada de um Paciente. O provável paciente dirige-se à Enfermeira que está na por-taria e se identifica lhe dizendo seu Nome e o número de algum Documento. A Enfermeira verifica se o Paciente já foi atendido em alguma Data anterior. Caso seja constatado que o Paciente nunca foi atendido na Clínica, ele for-


nece Informações Pessoais à Enfermeira que efetua o seu cadastramento. Após esse passo, o Paciente está apto a marcar uma Consulta, caso seja do seu interesse. A Enfermeira precisa se organizar e identificar uma Data e um Horário em que a Consulta possa ser marcada. O Paciente, então, está apto a entrar na sala do Médico, que previamente muniu-se de Informações do Paciente. Neste momento, o Paciente precisa esboçar ao Médico todos os Sintomas, Problemas e Restrições que o levaram à Clínica. O Médico, então, avalia essas Informações da Saúde do Paciente e efetua um Diagnóstico que pode ser seguido de um Pedido de Exames, além de um Receituário de Me-dicamentos, além da indicação de um Retorno. Ao sair da sala do Médico, o Paciente precisa informar à Enfermeira os Dados do Pagamento que podem ser feitos em dinheiro ou por algum Convênio Médico (MATOS, 2002).

Analisando os nomes que aparecem em maiúsculo neste texto, po-demos identificar classes e atributos peculiares de algumas classes. Dessa forma, um primeiro modelo de classes poderia ser feito da seguinte maneira:

Figura 32: Representação das classes identificadas.Fonte: Matos (2002).


Este Modelo de Classes inicial proposto apresenta algumas falhas que, quase sempre, passam despercebidas. Esse trabalho inicial de avaliar as classes potenciais e seus atributos é essencialmente semântico, ou seja, é necessário avaliar se cada item foi colocado no seu devido lugar. Após chegar a uma conclusão, passaremos a discutir os relacionamentos entre as classes (MATOS, 2002).

Um problema que pode ser identificado neste modelo trata dos atributos. Alguns atributos são imprescindíveis, mas estão prejudicando a modelagem (MATOS, 2002). Por exemplo:

Figura 33: Representação dos problemas e soluções no contexto dos atributos.Fonte: Matos (2002).

Para complementar o modelo proposto, os atributos em questão serão direcionados para os locais corretos e os relacionamentos serão criados da seguinte maneira (MATOS, 2002):


Figura 34: Representação do diagrama de classes proposto.Fonte: Matos (2002).

Ainda não possuímos o modelo definitivo, mas podem ser discu-tidas duas dúvidas (MATOS, 2002):

1) Como tratar a inclusão de métodos? 2) Exame e doença parecem ter uma existência dependente da

classe Diagnóstico. Não seriam os relacionamentos entre essas classes do tipo dependência ou de agregação?

As respostas a essas dúvidas complementam o modelo que exi-bimos como exemplo (MATOS, 2002). As respostas são:

1) Métodos podem até ser incluídos nesse momento, mas pre-cisam ser validados (confirmados). A validação ocorre nos Diagramas de Sequência e de Estados que serão discutidos posteriormente; no entan-to, é conveniente ressaltar que dois métodos são comumente sugeridos. Métodos get (obter) e set (configurar) são sugeridos por se tratar de uma ação muito comum aos atributos. Obter o valor de um atributo (get) é saber qual o seu valor atual, e configurar o valor de um atributo (set) é atribuir-lhe algo.


2) Não há necessidade de representar agregação ou dependência. Basta confrontar com situações que ocorrem em outros contextos, por exem-plo, um hospital ou até mesmo se tratar-se de um diagnóstico em clínicas de várias especialidades (psicologia, odontologia e até medicina alternativa). Diagnósticos não precisam ter, necessariamente, pedidos de exames ou o paciente pode não ter tido doenças no passado e além desse fato, a maneira como o diagnóstico é tratado não influencia nos exames (um exame de raio X continuará sendo o mesmo, apesar de um médico mudar sua rotina de diag-nosticar um paciente). Associar um exame e um histórico de doenças a um diagnóstico médico não significa construir um todo.

7.7 Interações

Objetos são entidades dinâmicas, ou seja, não é possível nós ima-ginarmos os objetos como depósitos estáticos de dados, mas sim como um ponto de referência do processo de execução das tarefas. Neste sentido, é necessária uma forma de modelar como esse comportamento dinâmico é conduzido (MATOS, 2002).

Programas orientados a objeto são, na verdade, constantes tro-cas de mensagens. Em conjunto, essas mensagens colaboram na obtenção de um determinado propósito. Os diagramas de interações são, portanto, a representação do comportamento dinâmico que uma sociedade de objetos necessita ter para que a execução de alguma tarefa possa ser acompanhada (MATOS, 2002).

Estudaremos nesta aula duas formas de representar interações, e como essas representações podem ser úteis no entendimento do processo de desenvolvimento de um software.

7.7.1 Por que devemos representar as interações

Representar interações é permitir que saibamos como um deter-minado conjunto de operações permitirá que o que se deseja do sistema seja realmente executado. É muito improvável que apenas a constatação empírica de que haja estruturas de dados suficientes seja razoável para se confirmar à exatidão na execução de tais operações (MATOS, 2002).

De certa forma, os diagramas de interação são, na verdade, ferra-mentas de constatação. É possível validar um Diagrama de Classes, ou até mesmo complementá-Io pela análise de um Diagrama de Interação. O resul-tado é um processo de software menos sofrido e menos empírico (MATOS, 2002).

Percebemos então que representar interações é um misto de vali-dação e complementação. Validação, porque é possível constatar-se que a construção de outros diagramas está realmente de acordo com o modelo que vem sendo proposto, e complementação, pois cada possível falha visualizada pode ser corrigida conforme sua validação (MATOS, 2002).


Interações indicam que um conjunto de objetos esteja se comuni-cando. Essa comunicação ocorre por meio da troca de mensagens. Mensa-gens são, na verdade, uma invocação a alguma tarefa previamente definida para ocorrer em algum objeto (MATOS, 2002). Esquematicamente, uma men-sagem pode ser identificada como:

Figura 35: Representação de interação através de mensagens.Fonte: Matos (2002).

A figura 35 representa a vontade que um objeto da classe Cliente chamado cl001 possui de se comunicar com um objeto da classe Conta, espe-cificamente o ct001. Nesse momento, o objetivo de cl001 é mudar o ESTADO de ct001, ou seja, da conta em questão é retirado o valor de R$1.560,00. A mensagem surgiu porque o cliente, representado pelo objeto cl001, decidiu retirar essa quantia dá conta em questão, ou seja, esse foi um momento de ocorrência de uma interação entre dois objetos (MATOS, 2002).

Podemos dizer então, que sem a representação de interações, a modelagem dos sistemas torna-se incompleta, haja vista que não se conhece como uma tarefa está sendo executada, e também não se conhece como um objeto dispara e finaliza uma tarefa. Essa representação é feita através dos Diagramas de Interação e conforme identificaremos, através de dois tipos de diagramas: Diagramas de Colaboração e Diagramas de Sequência (MATOS, 2002).

7.7.2 Tipos de diagramas de interações

Por meio de diagramas de interação podemos observar como os objetos estão relacionados. Questões como o entendimento das associações entre as classes de um diagrama de classes ficam mais nítidas ao identificar como um objeto realmente se comunica com outro (MATOS, 2002). Por exem-plo, analisemos a situação exposta no diagrama de classes da figura 36.

Figura 36: Representação de interação através da associação entre as classes.Fonte: Matos (2002).

Mensagens são, na grande maioria das vezes, executadas entre objetos. Não

faz sentido, a priori, que classes troquem

mensagens. Neste caso, há uma lembrança que

deve ser feita: a sintaxe usada na representação

para indicar que se trata de um objeto

que está indicado pelo sublinhado e pelas

inicias em minúsculo, por exemplo:

cliente:Cliente indica que cliente (com c

minúsculo) é objeto da classe Cliente (com C

maiúsculo).


É possível que em algum instante da vida de um objeto da classe Paciente ocorra o seguinte:

Figura 37: Representação de interação através de mensagens.Fonte: Matos (2002).

O que ocorre nesta representação, que se trata de um trecho de um diagrama de sequência, é que um objeto da classe Paciente, denomina-do pac, teve a necessidade de marcar uma consulta. Essa ação foi traduzida em uma mensagem, ou seja, o pedido de execução de um método em outra classe, neste caso, no objeto cons, da classe Consulta. Isso constata a neces-sidade de uma associação entre as classes Paciente e Consulta no diagrama de classes (MATOS, 2002).

Na verdade, este não é o único tipo de mensagem que objetos tro-cam. Quando se trata de uma interação, podemos ter as seguintes mensa-gens:

Automensagens: quando as mensagens são enviadas para o pró-prio objeto que originou o pedido (MATOS, 2002). Como exemplo tem a figura 38, que retrata uma mensagem que necessita ser executada no mesmo local de onde se originou a requisição.

Figura 38: Representação de interação através de automensagens.Fonte: Matos (2002).


Mensagens de destruição (destroy): quando se trata de efeti-vamente desativar a sequência de ações de um objeto. Essa destruição pode ser ativada por um objeto distinto ou pelo mesmo objeto. Esse tipo de mensagem pode ser acompanhado do estereótipo destroy (MATOS, 2002).

Figura 39: Representação de interação através de mensagens <<destroy>>.Fonte: Matos, 2002.

O uso do estereótipo <<destroy>> pode ser substituído pela repre-sentação da flecha com o acompanhamento de um símbolo de x, conforme visualizado na figura 40.

Figura 40: Outra forma de representação de interação através de mensagens <<destroy>>.Fonte: Matos (2002, p.).

Mensagens de criação (create): de outro lado, mensagens podem exigir a criação de um objeto. Por exemplo:

Figura 41: Outra forma de representação de interação através de mensagens <<create>>.Fonte: Matos (2002, p.)

Esta situação apresentada pode parecer estranha, mas é muito simples de interpretar: um objeto, para dar continuação a alguma tarefa


iniciada, precisou criar um objeto. Esse objeto em questão, no instante, não possuía identificação, mas, bastava ser indicado que se tratava de uma instância da classe Diagnóstico. A leitura que pode ser feita da figura é, portanto, que o médico (objeto med) precisou fazer um novo diagnós-tico de paciente (MATOS, 2002).

O conhecimento do comportamento das mensagens é importan-te para o entendimento dos diagramas de interação (MATOS, 2002). Os diagramas discutidos nesta aula podem seguir dois enfoques distintos:

• baseando-se na ordem temporal das mensagens; • baseando-se no contexto e na familiaridade de um conjunto de

objetos. Em particular, a ordem temporal é representada pelo Diagrama

de Sequência e o outro enfoque é representado pelo Diagrama de Cola-boração (MATOS, 2002).

7.7.3 Diagrama de colaboração

A primeira visão de interação que teremos é a colaboração. O dia-grama de colaboração fixa a atenção em como os objetos estão se organizan-do para realizar uma tarefa (MATOS, 2002). É como se uma cadeia de ajuda fosse realizada com a intenção de que um desejo fosse alcançado.

Na troca de mensagens, em um diagrama de colaboração, cada ob-jeto possui uma identificação esperada pelos outros objetos (MATOS, 2002). Na verdade, o que se usa é o nome que os outros utilizam para identificá-Io. Visualizamos esta afirmação da seguinte maneira:

Figura 42: Representação de diagrama de colaboração.Fonte: Matos, 2002.

Estudaremos agora os tipos de mensagens em diagramas de interação:Mensagens síncronas: aquelas em que o objeto remetente espera

o destino para finalizar sua tarefa para continuar a execução. Essa espera deve-se ao fato de que o destino possui uma resposta sem a qual o remeten-te não pode continuar. O desenho de uma seta, seja no diagrama de cola-boração, seja no diagrama de sequência, indica que há sincronismo (MATOS, 2002).

Mensagens assíncronas: nesse tipo de mensagem, o objeto reme-tente não precisa esperar pelo destino. A linha de execução pode continuar sem que haja uma resposta ao remetente. Mensagens assíncronas estão, na grande maioria dos casos, relacionadas a problemas de tempo real, em que pode ocorrer paralelismo de execução (MATOS, 2002).


As mensagens podem ser representadas da seguinte forma:

Figura 43: Representação de mensagens.Fonte: própria.

7.7.4 Diagrama de sequência

Os diagramas de sequência descrevem o comportamento dos obje-tos do sistema, que se relacionam pela troca de mensagens em interações sequenciais no tempo, enfatizando, portanto, o ordenamento temporal das ações. Cada diagrama mostra um cenário, isto é, um conjunto de mensagens, ordenadas no tempo, com um determinado objetivo. Assim, para a elabora-ção de um diagrama de sequência, é importante que os objetivos do sistema já tenham sido descritos nos cenários dos casos de uso (SBROCCO, 2011). Os diagramas de sequência devem ser construídos conforme determinadas con-venções, descritas a seguir:

• Linhas verticais: utilizadas para representar e separar os obje-tos envolvidos. Elas devem apresentar uma informação comple-mentar representada por um retângulo, utilizada para indicar o tempo de vida dos objetos.

• Setas horizontais: para representar as mensagens passadas en-tre os objetos. As setas também podem receber rótulos, que correspondem aos nomes das operações.

• Anotações: as representações dos elementos de um diagrama de sequência pode ser complementadas e esclareci das por meio de anotações.

Os casos de uso são a base para o desenvolvimento dos diagramas de sequência, pois é pelo estudo da lógica dos casos de uso que podemos organizar roteiros que representam seu desdobramento. Quando observamos que existem diferentes caminhos lógicos que podem ser seguidos, convêm criar diagramas de sequência separados para cada um dos caminhos (SBROC-CO, 2011).

7.7.5 Desenho de um diagrama de sequência

O ponto de partida é uma análise dos casos de uso que foram cria-dos. Os diagramas de sequência são facilmente criados a partir dessa análise.


Este seria o primeiro e mais importante passo. Para facilitar, um resumo de passos que podem ser seguidos é apresentado (MATOS, 2002).

Passo 1: transforme um caso de uso em uma descrição algorítmica. O objetivo é identificar todos os passos envolvidos nesse caso de uso;

Passo 2: avalie quais classes podem fazer parte desse caso de uso. Esta é uma análise que pode se basear tanto na observação dos nomes que apareçam na descrição, como na observação dos atores;

Passo 3: para cada passo que foi incluído na descrição do passo 1, escolha uma classe que seja responsável por fazer a tarefa indicada;

Passo 4: se a tarefa for muito complexa para apenas um objeto da classe executar, divida-a. O objetivo é tanto perceber se haverá outras clas-ses no modelo, como se o caso de uso não está complexo demais.

Para facilitar, continuaremos utilizando o exemplo da clínica médi-ca. Em especial, o diagrama de casos de uso, apresentado na figura 16. O caso de uso eleito para ser avaliado nos passos de 1 a 4 propostos anterior-mente foi Marcar Consulta. Esse caso de uso tem como ator responsável a Enfermeira, mas, obviamente, o estímulo que permite o início de tudo é a chegada do paciente e seu respectivo interesse em ser atendido. Então, vamos iniciar, descrevendo os passos desse caso de uso (MATOS, 2002).

Passo 1: descrição do caso de uso em linguagem algorítmica.1. Paciente relata interesse em marcar uma consulta (este é o estímulo en-dereçado à enfermeira). 2. A enfermeira precisa verificar se o paciente já está cadastrado na clínica. Para isso, são pedidos os seus dados pessoais. Caso ainda não seja cadastra-do, seu cadastro é requisitado. 3. Verificadas as informações do paciente, a enfermeira verifica se há vagas para a consulta. Essa verificação consiste da constatação de data e horário. 4. Caso haja vagas, a consulta enfim é marcada. Caso contrário, o paciente recebe uma negativa.

Passo 2 e 3: avaliação das classes participantes. 1. A melhor estratégia é tomar cada passo da descrição anterior e eleger classes (MATOS, 2002). 2. Enfermeira - neste ponto, apenas a Enfermeira estaria participando, pois é a receptora do estímulo inicial.3. Enfermeira e Paciente - a classe Enfermeira participa, pois é a estimula-dora de uma verificação na classe Paciente que, por sua vez, também deve participar, pois é a classe que possui as informações que estão sendo verifi-cadas e/ou cadastradas. 4. Enfermeira e Consulta - a classe Enfermeira recebe, da classe Paciente, uma resposta que dá início às atividades de marcação da consulta, portanto a classe Consulta também participa dessa etapa.

Paciente e Consulta - as informações para a consulta são checadas. Caso haja espaço na agenda da clínica, a classe Consulta recebe um estímu-lo para agendar a consulta; caso contrário, a classe Paciente é informada.


Nesse momento, o processo de marcação de consulta termina, com ou sem sucesso. Se não houve sucesso, todo o processo pode se repetir com um novo estímulo para a Enfermeira (MATOS, 2002).

Passo 4: avaliação da complexidade. A complexidade não é facilmente medida apenas com a consta-

tação textual. Nesse instante, é necessário que se construa um primeiro modelo. Conforme o comportamento esperado nos passos 2 e 3, um modelo inicial seria o representado na figura 44.

Figura 44: Representação de diagrama de sequência proposto.Fonte: Matos (2002).

7.7.6 Diagrama de estados

Normalmente, um sistema aberto reage a estímulos provenientes de fora dele ou ainda estímulos temporais por ele mesmo desencadeado. Essa reação pode originar respostas externas ao sistema. Essa dinâmica exis-tente nos sistemas é fruto da colaboração entre objetos, os quais estarão em determinado estado em um certo momento no tempo (TONSIG. 2003).

O Diagrama de Estados é usado para mostrar os possíveis estados dos objetos de uma classe. A mudança de um estado para outro é chamada de transição de estados. Os eventos do diagramas de estados causam uma transição de um estado para outro e as ações resultam na mudança de esta-do. Cada diagrama de transição de estados está associado a uma classe ou a um diagrama de transição de estados de um nível mais alto (TONSIG, 2003).

O início de um diagrama de estados é indicado pelo chamado esta-do inicial, cuja representação gráfica é um círculo preenchido. Na verdade, ele não expressa um estado específico do objeto da classe, indica apenas o início do diagrama. Na sequência, se conecta o primeiro estado real com uma transição, rotulado ou não. Em cada diagrama de estado há somente um estado inicial (TONSIG, 2003).


A notação gráfica de um estado inicial é mostrada na figura 45.

Figura 45: Representação do estado inicial de um diagrama de estado.Fonte: Tonsig, 2003.

Um estado demonstra uma situação no tempo de algum aspecto do sistema sobre o qual existe interesse de controle. Durante a vida de um objeto, pode vir a existir controle sobre várias situações, cada qual podendo assumir diversos estados possíveis no tempo. Um objeto permanece em um estado por um tempo finito (TONSIG, 2003).

A notação gráfica e um exemplo de estado são mostrados na Figura 46.

Figura 46: Representação de um diagrama de estado.Fonte: Tonsig (2003).

O estado final representa o término do ciclo previsto de controle para mudanças de um dos aspectos do sistema (TONSIG. 2003). Na Figura 47 verifica-se a representação gráfica do estado final, mediante dois círculos, sendo o interno totalmente preenchido.

A mudança de um estado para outro é chamado de transição de estados. Trata-se de relacionamento entre dois estados (TONSIG. 2003). Para o objeto passar de um estado para outro, é necessário dois me-canismos: condição e ação. A condição, se existir, deverá ser satisfeita para que a ação seja executada.. Essa ação é a responsável pela transi-ção dos estados.


Figura 47: Representação de transição de estados.Fonte: Tonsig (2003).

7.7.7 Diagrama de atividades

Do ponto de vista da representação de aspectos dinâmicos do sis-tema, dois diagramas possuem características muito comuns: o diagrama de atividades e o diagrama de estados.

Através deste diagrama vamos ter uma visão da representação do fluxo de operações (MATOS, 2002).

Antes de mais nada é necessário diferenciar atividade de estado. Atividade: trata-se de algo que está em execução, portanto não

finalizado. Quando uma atividade termina, alguma ação ocorre (MATOS, 2002).

Pelo conceito exposto, podemos traçar algumas diferenças entre estado e atividade:

• em uma atividade a ação é a finalização, ou seja, não há ações internas, assim como ocorre em um estado;

• quando se fala em um estado, representamos algo que já foi atingido e cujo interesse é questionar o que ocorre quando ele é alcançado;

• uma atividade é, na verdade, uma operação obviamente relacio-nada a um objeto. Enquanto um diagrama de estados enfatiza os fluxos das operações em uma classe, um diagrama de atividades relaciona as atividades entre classes.

A última diferença é a mais importante. Aqueles que vêem o diagra-ma de atividades pela primeira vez, em não conhecendo essa diferença, vão imaginar que é a mesma coisa que o diagrama de estados. Na verdade, pode--se considerar que os recursos são semelhantes, mas não são efetivamente os mesmos (MATOS, 2002).

Desenhamos um diagrama de atividades com a intenção de deixar claro o que acontece na cooperação entre os objetos de classes distintas,


mas não com o enfoque de um diagrama de sequência, cujo foco são as men-sagens trocadas e as respostas a esse estímulo. Grady Booch e outros autores costumam salientar que o diagrama de estados ressalta o aspecto interno do que ocorre em um diagrama de interação (MATOS, 2002).

Outra observação útil aos modelistas é o fato de que um diagrama de atividades pode ser visto como um verdadeiro fluxograma estendido - uma visão do fluxo das operações, decisões e finalizações (MATOS, 2002).

Para estudarmos a criação de um diagrama de atividades e seus respectivos conceitos, apresentamos o seguinte problema: a marcação de uma consulta (MATOS, 2002).

Figura 48: Representação de um diagrama de atividades.Fonte: Matos (2002).

Apesar de este diagrama conter as mesmas operações do diagrama de sequências do capítulo 7.7.4, sua semântica é diferente. Sua representa-ção indica como as atividades são conduzidas até que se chegue ao objetivo final - agendar uma consulta (MATOS, 2002).


Algumas representações na figura 48 podem ter causado estranhe-za, mas vamos explicá-las:

A presença de estados

Os estados inicial e final ainda são importantes, pois um diagrama de atividades representa um fluxo de operações, ou seja, é necessário indi-car o início e o fim delas (MATOS, 2002).

A presença de uma reta escura ( ___________ )Trata-se de uma barra de sincronização. A função dessa barra é

representar momentos em que ocorre uma bifurcação ou união do fluxo. Por exemplo, Cadastrar Paciente e Verificar Paciente são atividades que levam à mesma atividade - Checar Agenda. É conveniente ressaltar que se trata de um fluxograma estendido, portanto há momentos em que o fluxo é bifurcado e unido (MATOS, 2002).

A presença de um símbolo de decisão

Mais um motivo para considerar o diagrama de atividades distinto do diagrama de estados. Em um diagrama de estados o foco não está na identificação de caminhos alternativos e nem na união de caminhos. Devido a essa preocupação, diagramas de atividade são considerados extensões a fluxogramas, daí a importância de um símbolo como o de decisão (MATOS, 2002).

Na verdade, essas não são as únicas representações importantes em um diagrama de atividades. É possível indicar as classes envolvidas no fluxo. Essa representação dá-se por meio de raias (ou swinlanes).


Figura 49: Representação de um diagrama de atividades e suas raias.Fonte: Matos, 2002.

Conforme se observa, as raias são, na verdade, uma divisão de ta-refas, facilitando assim o entendimento de como as atividades estão distri-buídas em um modelo de classes (MATOS, 2002).

Enfim, o que se observa é que a construção de um diagrama de atividades parte de duas fontes: ou da avaliação dos casos de uso e/ou da avaliação dos atores que participam do sistema (MATOS, 2002).

7.8 Componentes de software

Muitos programadores já devem ter percebido a seguinte consta-tação: muitas tarefas pequenas constantemente reaparecem no desenvol-vimento de um novo software, mas geralmente em pontos e situações di-ferentes. Um componente de software seria o elemento que surgiria com a implementação da interface esperada para esse objeto “novo”, diminuindo a sensação de que o mesmo trabalho seria feito novamente (MATOS, 2002).


Apesar de um componente assemelhar-se muito a um objeto de uma classe, pode-se diferenciar um componente de um objeto por suas ca-racterísticas adicionais quanto ao reuso de código (e de projeto) (MATOS, 2002).

Componentes são desenvolvidos baseando-se na junção de classes. Na verdade, são a solução para um determinado problema, cujas interfaces são conhecidas, no entanto, ainda não haviam sido implementadas (MATOS, 2002).

Componentes podem atuar em conjunto. Neste caso, precisam ser empacotados, pois a implementação de várias interfaces individuais implica no esqueleto e um sistema completo (MATOS, 2002).

Modelar um componente em UML é prover recursos de gerencia-mento da configuração e versão do software. Ou seja, como cada componen-te e software possuem uma relação intrínseca com outros, é bem provável que se criem dependências entre componentes. Dessa forma, qualquer mo-dificação pode ser previamente avaliada. Obviamente que o impacto dessas modificações pode ser simulado e o resultado final validado (MATOS, 2002).

Além dessa visão de projeto, um componente, enfim, pode ser vis-to como um elemento cuja interface (a visão do seu conjunto de operações e dados) é mutável. Essa mutabilidade é gerenciada pelos elementos que compõem o componente e permitem que ele seja reutilizado (MATOS, 2002).

7.8.1 Diagrama de componentes

Escrever código-fonte é um trabalho artesanal. E não é difícil cons-tatar-se esse fato. Um programador é um indivíduo criativo; suas idéias fluem no escopo de um mundo - o mundo dos bits e bytes. A idealização de uma solução é um caminho similar ao de um pintor, até que se chegue à arte final, não se distanciando, obviamente, da realidade em que a solução do proble-ma vai repousar (MATOS, 2002).

Construir um diagrama de componentes é criar um roteiro para essa “tempestade de criatividade” (MATOS, 2002). Obviamente que poderíamos ser questionados pelo menos de três formas:

• Como criar um roteiro de criatividade para alguém sendo que este é um trabalho individual?

• Como alguém externo pode gerar um roteiro criativo para outra pessoa?

• Por que criar um roteiro criativo se isso pode limitar a inventivi-dade de uma pessoa?

Diante dessas dúvidas, vamos esclarecer no que realmente se tra-duz um diagrama de componentes.

Um diagrama de componentes é a relação de todos os itens de software que colaboram na confecção do produto final (MATOS, 2002). Nes-te diagrama, as maneiras como os elementos se relacionam e dependem permitem que o reuso de código e empacotamento de componentes sejam avaliados.


O exemplo representado através da figura 50 pode ajudar a enten-der a função de um diagrama de componentes.

Figura 50: Representação de um diagrama de componentes.Fonte: Matos, 2002.

Observando este exemplo, as funções de um diagrama de compo-nentes ficam mais claras:

• componentes são elementos de alto nível. Não se trata de um pacote, mas de um elemento que permite o agrupamento de várias interfaces. Por exemplo, o Gerenciador de Senhas não necessariamente precisa implementar os métodos indicados a partir de uma única classe;

• conforme será melhor discutido no diagrama de implantação, o sistema pode ser visto como uma divisão de nós, e cada nó agrupa um conjunto de componentes similares.

Na verdade, o desenho de um diagrama de componentes deve ser guiado pela conjunção da visão dos seguintes elementos de software:

• Código-fonte • Bibliotecas e interfaces • Documentação e arquivos complementares Ou seja, um diagrama de componentes permite que se conheça a

dependência que existe entre os diferentes elementos de software (MATOS, 2002).


Na figura 51, vamos esboçar a organização de um software verifica-dor de senhas e usuários para um terminal de um banco.

Figura 51: Representação de um diagrama de componentes para um terminal de banco.Fonte: Matos, 2002.

Obviamente que essa organização é dependente da solução adota-da - esse conjunto de código é peculiar a um ambiente de programação em Java. Neste sentido, é conveniente ressaltar que um diagrama de compo-nentes reflete o que se espera da linguagem de programação usada (MATOS, 2002).

Podemos incluir outros recursos de programação importantes em diagramas de componentes, tais como, tabelas de banco de dados e docu-mentações. Estaremos visualizando estes recursos na figura 52.


Figura 52: Representação de um diagrama de componentes com tabelas de banco de dados.Fonte: Matos, 2002.

7.8.2 Diagrama de implantação

Devemos visualizar que em qualquer processo ou ciclo de vida de software, um sistema computacional não apresenta apenas uma parte lógica. Analistas, projetistas e tomadores de decisão precisam preocu-par-se com o hardware - afinal de contas é onde o software desenvolvido será executado (MATOS, 2002).

Os sistemas distribuídos exigem muito mais dos projetistas de sistemas, pois um componente de software passa a ser muito mais do que um simples trecho de código estático, passando a ter uma responsabilida-de e mobilidade imprescindível (MATOS, 2002).

Se adaptar uma plataforma de hardware para um software dis-tribuído não é uma tarefa simplória e de decisão meramente baseada em análises de configurações, devemos estudar um meio de modelar essa situação (MATOS, 2002).

Em UML, diagramas de implantação são o recurso ideal para a discussão da adequação do hardware (MATOS, 2002). A partir do conceito de nó podemos vislumbrar a distribuição do hardware e dos respectivos componentes de software necessários. Devemos então entender o conceito de nó. Nó é qualquer elemento de hardware em que um componente de sof-tware possa ser executado, ou seja, entende-se como nó um elemento que possua capacidade de processamento (MATOS, 2002).


A modelagem de nós facilita a tomada de decisões e diminui a distância de vocabulário e entendimento que geralmente existe entre pro-gramadores e analistas de sistemas (MATOS, 2002). Obviamente que não se espera que gestores e analistas tornem-se excelentes analistas de hardware, mas a discussão pela plataforma ideal torna-se mais simples (MATOS, 2002).

Devemos salientar que a criação de diagramas de implantação é um recurso da UML que melhor exemplifica a necessidade de extensabilidade (prevista pela linguagem). Nesse caso, o uso de estereótipos é plenamente aconselhável e podem indicar muito mais do uma simples relação de depen-dência (MATOS, 2002).

Componentes e nós possuem estreita relação e podem ser repre-sentados como na figura 53. No entanto, diagramas de implantação não se restringem a apenas indicar essa relação existente entre componentes e seus respectivos nós de implementação (MATOS, 2002). É importante ar-quitetar a organização lógica do hardware participante de um ambiente.

Figura 53: Representação de um diagrama de componentes com nó.Fonte: Matos, 2002.

É comum o uso do diagrama de implantação para a confecção de uma visão simplificada de uma organização de hardware (MATOS, 2002). Na verdade, o que se vê na figura 54 é uma relação de ligação que permite, inclusive, que se infira como estão distribuídas as funções de um ambiente de gerenciamento de uma rede Internet, porém esse mesmo esquema pode ser estendido para uma situação mais real conforme podemos visualizar na figura 55.


Figura 54: Representação de um diagrama de componentes mostrando funções de ambiente de gerenciamento de uma rede internet.Fonte: Matos, 2002.

Figura 55: Representação completa de um diagrama de componentes mostrando funções de ambiente de gerenciamento de uma rede internet.Fonte: Matos, 2002.


Resumo

Nesta aula, você aprendeu:• sobre o histórico da UML;• sobre os principais diagramas da UML; • como identificar um caso de uso;• como desenhar um diagrama de caso de uso;• como os principais diagramas da UML; • sobre os cuidados necessários ao se criar diagramas de caso de uso;• como identificar classes;• como identificar relacionamentos;• sobre extensões e mecanismos;• como desenhar um diagrama de classes;• sobre os tipos de diagramas de interação;• sobre diagramas de colaboração;• sobre diagramas de sequência;• como desenhar diagramas de sequência;• sobre os diagramas de estados e sua função;• como desenhar diagramas de estados;• sobre diagramas de atividades;• como desenhar diagramas de atividades;• sobre componentes de software;• como desenhar diagramas de componentes; e• como desenhar diagramas de implantação.


As atividades referentes à aula 7 – Modelagem Baseada em UML estarão disponíveis na plataforma moodle.


AULA 1


85

Aula 8 – Estudo de caso

Objetivos

- Criar um projeto de software utilizando conhecimentos de orien-tação a objetos e da linguagem de modelagem unificada.

8.1 Introdução

Através do estudo de caso, o aluno estará colocando em prática os conhecimentos obtidos neste caderno.

O estudo de caso será disponibilizado na plataforma moodle.


Referências

BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. 8 ed. Rio de Janeiro: Editora Elsevier, 2002.

MATOS, Alexandre Veloso de. UML: Prático e Descomplicado. 2 ed. São Paulo: Editora Érica, 2002.

SBROCCO, José Henrique Teixeira de Carvalho. UML 2.3: teoria e prática. São Paulo: Editora Érica, 2011.

TONSIG, Sérgio Luiz. Engenharia de software. São Paulo: Editora Futura, 2003.


Currículos dos professores conteudistas

Nilton Alves Maia

Doutor em Engenharia Elétrica - área de concentração Engenharia de Com-putação e Telecomunicações pela UFMG (2006), mestre em Administração - área de concentração produção e sistemas pela UFRGS (1999), especialista em Análise de Sistemas Área de Concentração em Computação pela UFMS (1997), especialista em Tópicos Avançados em Telecomunicações pela UFMS (1996), especialista em Administração de Sistemas e de Informações Geren-ciais pela UCDB (1994) e graduado em Engenharia Elétrica - Opção Eletrônica pelo INATEL (1979). Atualmente é professor adjunto da Universidade Estadual de Montes Claros e das Faculdades Santo Agostinho. Possui experiência nas áreas de Engenharia Elétrica e Sistemas de Informação, atuando principal-mente nos seguintes temas: sistemas de telecomunicações, engenharia de tráfego, computação autonômica, inteligência computacional, análise e pro-gramação de sistemas de informação orientados à objetos.

Sônia Beatriz de Oliveira e Silva Maia

Mestranda em Administração com Ênfase em Gestão Pública, especialista em Análise de Sistemas Área de Concentração em Computação pela UFMS (1997) é formada em Tecnologia de Processamento de Dados pelo CESUP (1994). Atualmente é professora da Universidade Estadual de Montes Claros. Possui experiência em Sistemas de Informação, atuando principalmente nos seguintes temas: Engenharia de Software, Análise Estruturada e Gerência de Projetos.


Documents

Analise Projeto Sistemas Mail