desenvolvimento_de_software_i

Prévia do material em texto

Brazcubas
Mogi das Cruzes - SP
2018
Desenvolvimento de Software I
2ª edição
Robson Paz Vieira
Reitor: Prof. Maurício Chermann
EQUIPE PRODUÇÃO CORPORATIVA
Gerência: Adriane Aparecida Carvalho
Coordenação de Produção: Diego de Castro Alvim
Coordenação Pedagógica: Karen de Campos Shinoda
Equipe Pedagógica: Graziela Franco,
Rúbia Nogueira, Vania Ferreira
Coordenação Material Didático: Michelle Carrete
Revisão de Textos: Adrielly Rodrigues,
Aline Gonçalves, Telma Santos
Diagramação: Amanda Holanda, Douglas Lira,
Nilton Alves, Priscila Noberto
Ilustração: Everton Arcanjo, Noel Gonçalves
Impressão: Grupo VLS / Gráfica Cintra
Imagens: Fotolia / Freepik / Acervo próprio
Os autores dos textos presentes neste material didático assumem total 
responsabilidade sobre os conteúdos e originalidade.
Proibida a reprodução total e/ou parcial.
© Copyright Brazcubas 2014
Av. Francisco Rodrigues Filho, 1233 - Mogilar 
CEP 08773-380 - Mogi das Cruzes - SP
Sumário
Sumário 
Apresentação 5
O Professor 7
Introdução 9
1Unidade I
Criação e evolução do desenvolvimento de software 11
1.1 Desenvolvimento de software 12
1.2 Evolução 13
1.2.1 Crise do software 15
1.2.2 Falhas conhecidas 18
1.2.3 Projetos de software 20
1.2.4 Problemas no desenvolvimento de software 22
1.3 Considerações da unidade I 23
2Unidade II
Processo unificado de desevolvimento (RUP) 25
2.1 Processo unificado 26
2.2 Fase da concepção 27
2.2.1 Visão do sistema 28
2.2.2 Requisitos 29
2.2.3 Caso de uso 30
2.3 Fase da elaboração 31
2.4 Fase da construção 32
2.5 Fase de transição 33
2.6 Considerações da unidade II 34
3Unidade III
Modelos de Workflow 35
3.1 Atividades técnicas 36
3.1.1 Workflow de requisitos 36
3.1.2 Atores e casos de uso 36
3.1.3 Interface do sistema 38
3.2 Workflow de análise e projeto 38
3.2.1 Classes de análise 39
3.2.1.1 Limite 40
3.2.1.2 Controle 41
3.2.1.3 Entidade 41
3.2.2 Diagrama de comunicação 42
3.2.3 Análise arquitetural 45
3.2.3.1 Pacotes de análise 45
3.2.3.2 Pacotes de serviço 46
3.3 Considerações da unidade III 46
Sumário
4Unidade IV
Utilização da modelagem visual, ferramenta case e diagramas 47
4.1 Modelagem visual 48
4.2 Ferramenta case 48
4.3 Diagramas estáticos 52
4.3.1 Diagramas de casos de uso 54
4.4 Considerações da unidade IV 56
Apresentação
5
Apresentação
Prezado(a) Aluno(a), 
Seja bem-vindo(a) à disciplina Desenvolvimento de Software I. Sou o professor 
Robson Paz Vieira e estarei com você durante o desenvolvimento dos conceitos da 
disciplina.
A disciplina que iniciaremos a seguir terá como objetivo apresentar a importân-
cia dos Processos e Desenvolvimento de Software e qual o grande papel da área de 
TI nesse contexto. Assim, você também terá a oportunidade de ver alguns conceitos 
utilizados para a padronização, controle e organização da Informação.
Sua participação em buscar informações extras por meio de leitura ou até mes-
mo dentro do mercado de trabalho acrescentará muito no resultado ao final desta 
disciplina. Lembre-se, vivemos um momento de mercado de trabalho competitivo e 
globalizado, em que a atualização de conhecimentos e experiências passa a ser uma 
grande aliada na atualização profissional. 
Não se esqueça de consultar os materiais disponíveis na plataforma de estu-
dos, assistir às teleaulas e utilizar os fóruns para esclarecer suas dúvidas e ampliar 
seu conhecimento.
O Professor
7
O Professor
Prof. Robson Paz Vieira 
Formado em Ciências da Computação pela 
Universidade Santa Cecília dos Bandeiran-
tes (UNISANTA), Pós-Graduado em Análise 
de Sistemas e MBA em Gestão Empresarial 
pela Fundação Getúlio Vargas (FGV), Do-
cência para o Ensino Superior pela Fun-
dação Getúlio Vargas (FGV), Mestre em 
Liderança pela Universidade Santo Amaro 
(UNISA), Docente nos cursos de Adminis-
tração, Ciências da Computação, Economia 
e Ciências Contábeis (Graduação e Pós-
-Graduação) e Gerente / Consultor de TI, 
Telecom e Gestão da Qualidade.
Introdução
9
Introdução
Espero que nesta disciplina tenhamos a oportunidade de conhecermos, jun-
tos, um pouco mais sobre esse assunto tão comentado, estudado e de fundamental 
importância no mercado de TI nos últimos tempos. 
O desenvolvimento de software mudou o perfil do profissional da área, princi-
palmente com a evolução e uso da Internet. A especialização técnica em alguma fer-
ramenta na área de informática eram suficientes para se obter um papel valorizado 
dentro de uma corporação, mas hoje cada vez mais os profissionais da área vêm se 
tornando grandes especialistas em gestão de informações e assim elementos fun-
damentais na direção dessas empresas. 
O desenvolvimento de software é um dos assuntos mais abordados e discuti-
dos por gestores e profissionais da área de informática, uma vez que as empresas 
estão cada vez mais dependentes dos bons serviços prestados. Não é difícil enten-
dermos o quanto é importante a área de informática dentro de uma empresa, até 
porque sabemos que cada vez mais os computadores e seus periféricos estão exe-
cutando funções com o objetivo de garantir velocidade e organização das tarefas no 
seu dia a dia.
Dessa forma, durante o aprendizado da disciplina, mostraremos e exempli-
ficaremos os principais conceitos e técnicas dos procedimentos que devem ser 
adotados durante o desenvolvimento do software. Lembrando que é importante 
consultar o livro didático, a plataforma e participar dos fóruns, buscando sempre 
aprimorar os conhecimentos adquiridos.
Unidade 1Criação e evolução do desenvolvimento de software
11
1Unidade I
Criação e evolução do desenvolvimento de 
software
Objetivos da Unidade:
• Apresentar os conceitos de desenvolvimento de software;
• Entender a evolução e práticas do desenvolvimento de software;
• Aplicar os conceitos de criação e programação.
Competências e Habilidades da Unidade:
• Conhecimento dos conceitos de desenvolvimento de software;
• Descrição das práticas e do processo de evolução da programação.
Unidade 1 Criação e evolução do desenvolvimento de software 
12
1.1 Desenvolvimento de software
O software a nível mundial começa a se desenvolver 
nessa década. O ato de programar essas máquinas tinha 
pouco de soft e muito de hard, dado que realizava-se pri-
meiro mediante a manipulação da própria fiação e depois 
mediante instruções em cartões perfurados.
Nesse momento, o desafio maior era programar os 
algoritmos para que os computadores fizessem os cálcu-
los, processos e reportes que se exigiam para as diferentes 
funções.
Foi em meados da década de 60 que se gera a crise 
do software. Essa crise se evidencia no estudo do Standish 
Group (“Reporte do Caos”), no qual mostra-se que só 16% 
dos projetos de software são exitosos. Em geral, os proje-
tos de software tiveram alterações nos custos e os tempos 
foram várias vezes mais altos do que os planejados. Adicio-
nalmente, os erros no software levaram a perdas nas em-
presas e inclusive de vidas.
A crise persiste até o ano de 1985, mas nesse mo-
mento, nasce a consciência de que desenvolver é bem mais 
que codificar: faz-se ênfase à qualidade. Dentro do conceito 
de qualidade, cabe a definição intuitiva que o software não 
contenha erros, mas também inclui o fato que os projetos 
cumpram os tempos e os custos planejados.
Unidade 1Criação e evolução do desenvolvimento de software
13
1.2 Evolução 
Desenvolvimento de software é um termo informático 
utilizado em 1968, na primeira conferência organizada pela 
OTAN sobre desenvolvimento de software, da qual nasceu for-
malmente o ramo da engenharia de software. O termo se atri-
bui a F.L. Bauer, ainda que previamente tivesse sido utilizado 
por Edsger Dijkstra em sua obra “The Humble Programmer”.
Em 1984, Richard Stallman deixa o MIT e começa a tra-
balhar em seu projeto GNU, com o objetivo de desenvolver 
um sistema operacional completamente livre, desde o kernel, 
editores, compiladores, debuggers, até utilitários mais comple-
xos como processadores de texto e inclusive jogos. Um dos 
primeiros desenvolvimentos realizados pelo mesmo Stallman 
foi o editor de textos GNU Emacs, no início do ano de 1985. 
Nesse mesmo ano funda-se a Free Software Fundation, entida-
de que financia desde então o projeto GNU, mantendo-se a 
mesma com doações e com o produto da venda de CD-ROMs 
tanto de programas binários como código fonte, manuais e 
distribuições completas (conjunto de software para uma de-
terminada plataforma de hardware).
F. L. Bauer
Edsger Dijkstra
Richard Stallman
Nesse ponto convém esclarecer a distinção entre software livre e software gra-
tuito. Entende-se que o possuidor de software livre tem a liberdade de:
• Executar o programa;
• Modificar o programa (para que este ponto 
faça sentido é necessário que o programa seja 
distribuído com o código fonte);
• Redistribuir cópias do programa (seja grátis ou 
não);
• Distribuir cópias modificadas do programa.
Unidade 1 Criação e evolução do desenvolvimento de software 
14
Com o tempo, os programadores da Free Software Fundation foram completan-
do algumas das tarefas planejadas originalmente pelo projeto GNU, entre outros a 
biblioteca de linguagem “C”, e o shell mais utilizado nos sistemas GNU/Linux: bash. O 
sucesso conseguido por esses programas que não só trabalham em sistemas GNU/
Linux, mas que têm sido portados a outras plataformas, forçaram a seus programa-
dores a dedicar um tempo importante a sua manutenção e melhora. Dessa maneira, 
o desenvolvimento completo de um sistema operacional baseado em software livre 
viu-se demorado por alguns anos.
Por outro lado, além dos produtos da FSF existem outros desenvolvimentos de 
software livre que foram aproveitados pelo projeto GNU, entre os mais importantes 
estão o TeX como processador de textos e o X Windows System como sistema gráfico 
de interface com o usuário.
Perto do ano 1990, o único componente básico do sistema que estava faltando 
era o kernel. A decisão que se tomou naquele momento foi utilizar o microkernel Mach 
(desenvolvido pelas Universidades Carnegie Mellon e a de Utah), adicionando uma 
série de processos servidores desenvolvidos pela FSF. 
A essa combinação de um microkernel com processos 
servidores independentes chamou-se de HURD. A partir dos 
últimos meses de 1999, HURD começa a ser utilizado de for-
ma confiável. Muito antes disso ocorrer, um estudante finlan-
dês, Linus Torvalds, desenvolveu um kernel para computado-
res baseados no processador Intel 386, compatível com unix, 
que chamou LINUX.
Linus Torvalds
Unidade 1Criação e evolução do desenvolvimento de software
15
Esse kernel foi também de-
senvolvido como software livre, e 
rapidamente foi crescendo graças 
à colaboração de programadores 
de todo mundo. Nesse momento 
Linux tem sido portado a toda faixa 
de processadores Intel a partir do 
i386: (486, Pentium, Pentium II e III, 
Celeron), a processadores para PCs 
de Cyrix e de AMD, e inclusive a pro-
cessadores tipo sparc (SUN), aos processadores Motorola 68000 (Apple MacIntosh), a 
processadores Alpha (de 64 bits, utilizados por Compaq, antes Digital). Dessa manei-
ra, em 1992 foi possível combinar o kernel Linux com os utilitários do projeto GNU 
e surgiu o primeiro sistema operacional completamente baseado em software livre.
1.2.1 Crise do software
Em 1990, a crise do software fundamentou-se no tempo de criação de software, 
além de um grande custo e pouca flexibilidade.
Basicamente, a crise do software refere-se à dificuldade em escrever progra-
mas livres de defeitos, facilmente compreensíveis, e que sejam verificáveis. As causas 
são, entre outras, a complexidade que supõe a tarefa de programar e as mudanças 
que se tem que ver submetido um programa para ser continuamente adaptado às 
necessidades dos usuários.
Além disso, não existem ainda ferramentas que permitam estimar de uma 
maneira exata, antes de começar o projeto, qual é o esforço que se precisará para 
desenvolver um programa. Esse fato faz com que na maioria das vezes não seja pos-
sível estimar quanto tempo levará um projeto, nem quanto pessoal será necessário. 
Quando se fixam prazos, normalmente não se cumprem por esse fato. Do mesmo 
modo, em muitas ocasiões aumenta-se o pessoal atribuído a um projeto com a espe-
rança de diminuir o prazo de execução.
Por último, as aplicações de hoje em dia são programas muito complexos, e 
de difícil compreensão por uma única pessoa. No seu início valorizou-se como causa 
também a imaturidade da engenharia de software, mas ainda hoje em dia não é pos-
Unidade 1 Criação e evolução do desenvolvimento de software 
16
sível realizar estimativas precisas do custo e tempo que precisará para se realizar um 
projeto de software.
Uma série de acontecimentos que se vinha observando nos projetos de desen-
volvimento de software podem ser aqui destacados. São eles: 
• Os projetos não terminavam no prazo;
• Os projetos não se ajustavam no orçamento 
inicial;
• Baixa qualidade do software gerado;
• Software que não cumpria as especificações;
• Código não mantido que dificultava o gerencia-
mento e evolução do projeto.
Ainda que propusessem diversas metodologias para tentar reparar os proble-
mas mencionados, o verdadeiro é que ainda hoje não existe nenhum método que 
tenha permitido estimar de maneira viável o custo e duração de um projeto antes de 
seu início.
A “crise do software” mostra a lenta evolução que tem tido a indústria do soft-
ware, que data para perto de 30 anos. Na OTAN, nos anos de 1967 e 1968, foram 
feitas duas reuniões com o fim de resolver esse problema e obter um padrão com-
pletamente definido. As fases que se trataram através dos anos até a data são as 
seguintes:
Unidade 1Criação e evolução do desenvolvimento de software
17
• Programar não é uma tarefa 
diferenciada do projeto de uma 
máquina;
• Uso da linguagem máquina e em-
samblador (unir perfeitamente o 
hardware com o software).
Primeira Fase. 
Os Albores (1945-1955):
• Aparece uma multidão de lingua-
gens;
• É possível fazer tudo.
Segunda Fase. 
O Florescimento (1955-1965):
• Desenvolvimento Inalcançável de 
grandes programas;
• Ineficiência, erros, custos impre-
visíveis;
• Nada é possível.
Terceira Fase. 
A Crise (1965-1970):
• Fundamentos de Programação;
• Verificação de Programação;
• Metodologias de Desenho.
Quarta Fase. Inovação Conceitual
(1970-1980):
• Meios de programação;
• Especificação Formal;
• Programação Automática.
Quinta Fase. O Desenho do
Problema (1980- 1990):
Unidade 1 Criação e evolução do desenvolvimento de software 
18
1.2.2 Falhas conhecidas
Esta foi a primeira missão da NASA para 
sobrevoar Vênus. O foguete não durou mais 
de 5 minutos em voo quando se desviou de 
sua trajetória e foi autodestruído pelos res-
ponsáveis. O motivo desse desvio foi a omis-
são de um guia no programa que controlava 
o foguete. 
1962 Mariner 1
A Atomic Energy of Canada Limited (AECL) 
criou uma máquina de radioterapia utilizada 
para meios médicos. Durante um período 
existiram seis acidentes em que os pacientes 
receberam alta sobredose de radiação. Nas 
investigações responsabilizou-se o software 
tanto no projeto, por ser um código não do-
cumentado e praticamente ofuscado, como 
em falhasconcretas detectadas.
1985-1987 Therac
 
É um míssil antiaéreo que se utiliza 
também para a interceptação de mísseis ba-
lísticos a modo de defesa. Durante a Guerra 
do Golfo em 1991, um Scud iraquiano matou 
28 soldados ao atingir um quartel norte-ame-
ricano, já que esses mísseis falharam. Opi-
nou-se que foi um erro de software no relógio 
do sistema, que tinha se atrasado um terço 
de segundo por ter estado ativado 100 horas.
1991 MIM-104 Patriot
Unidade 1Criação e evolução do desenvolvimento de software
19
Esta foi uma missão em que o voo 501 
se desviou e se partiu, durando somente 40 
segundos em voo. O problema foi que o sis-
tema de referência inercial tratado com da-
dos de ponto flutuante de 64 bits o convertia 
a 16 bits com valores inteiros. Em uma dessas 
operações o valor era demasiado grande, o 
que provocou um desbordamento aritmético 
no hardware.
1996 Ariane-5
A Mars Climate Orbiter foi uma sonda 
enviada pela NASA para estudar a atmosfera 
de Marte. Um problema no sistema de nave-
gação fez sair de sua trajetória e desintegrar-
-se. O motivo era a utilização de diferentes 
sistemas de medida no software. Enquanto o 
controle de terra utilizava o Sistema Anglosa-
xão de Unidades, a nave realizava com o Sis-
tema Métrico Decimal. 
1999 The Mars Climate Orbiter
Osprey é um híbrido entre avião e heli-
cóptero de propósito militar. Em dezembro de 
2000, uma dessas instâncias teve um acidente. 
Um dos sistemas hidráulicos falhou e o avião 
se espatifou em um pântano matando toda a 
tripulação. Atualmente, conhece-se que a ori-
gem do problema estava no software, mas se 
segue sem conhecer o motivo exato.
2000 Osprey
Unidade 1 Criação e evolução do desenvolvimento de software 
20
Uma máquina de Cobalto-60 no Institu-
to Nacional do Câncer do Panamá produziu 
uma sobredose de radiação gama a mais de 
duas dúzias de pacientes. O excesso de tra-
balho e o cansaço dos técnicos na manuten-
ção foram parte do problema. Em algum mo-
mento provaram a alinhar os escudos para 
trabalhar de uma maneira mais eficaz. Esse 
comportamento não estava no manual, mas funcionava. Ao utilizar algo não 
documentado em uma atualização do software, o comportamento mudou para 
esse caso de maneira que, ao estarem os escudos alinhados se produzia uma 
sobreradiação sobre o paciente. Este problema manteve-se durante sete me-
ses.
2001 Multidata Systems/Cobalt 60
1.2.3 Projetos de software
Unidade 1Criação e evolução do desenvolvimento de software
21
Em 1986, Fred Brooks publicou seu artigo “Não há balas de prata”, argumen-
tando que nenhuma tecnologia individual ou prática jamais faria uma melhora de 10 
vezes na produtividade dentro de 10 anos.
Unidade 1 Criação e evolução do desenvolvimento de software 
22
O debate sobre as balas de prata rugia na década seguinte. Os componentes e 
processos continuaram anos utilizando a sua tecnologia favorita, que seria uma bala 
de prata.Os céticos não estiveram de acordo. Finalmente, quase todo mundo aceitou 
que nunca se encontrará nenhuma bala de prata. No entanto, afirmações sobre ba-
las de prata saltarão de vez em quando ainda hoje em dia.
Alguns interpretam que não há balas de prata significativas que comprovem 
que a engenharia de software tenha fracassado. No entanto, com outras leituras, 
Brooks (1961, p. 26) vai dizer: “seguramente faremos progressos substanciais nos 
próximos 40 anos; uma ordem de magnitude em mais de 40 anos é quase mágico...”.
A busca de uma única chave para o sucesso nunca funcionou. Todas as práti-
cas e tecnologias conhecidas só têm feito melhoras incrementais em produtividade 
e qualidade. Apesar de tudo, também não há balas de prata para qualquer outra 
profissão. Outros interpretam que não há balas de prata como prova de que a en-
genharia de software finalmente tenha amadurecido e reconhece que os projetos de 
sucesso são devido ao duro trabalho.
No entanto, poderia ser dito também que, de fato, na atualidade há uma faixa 
de balas de prata, incluindo metodologias levianas, calculadoras de folha de cálculo, 
navegadores personalizados, motores de busca em sites, geradores de reportes de 
banco de dados, editores de código, provas de desenho integrados e lojas especiali-
zadas que geram software de nicho, como websites de informação, a uma fração do 
custo de desenvolvimento de um site totalmente personalizado. 
No entanto, o campo da engenharia do software aparece demasiado comple-
xo e diverso para uma única “bala de prata” que sirva para melhorar a maioria dos 
problemas, e a cada problema representa só uma pequena porção de todos os pro-
blemas de software.
1.2.4 Problemas no desenvolvimento de software
Têm existido falhas similares em todos os âmbitos. Em algumas ocasiões só 
produz problemas aos usuários. Em outras ocasiões, a imagem da empresa respon-
sável desse software fica prejudicada.
Em todo caso, aparecerão mais casos de problemas por falhas pelo software e 
sistemas que caem, dado a que nosso meio vai se tornando cada vez mais complexo 
e cada vez mais globalizado (tanto em atualizações como em sistemas compartilha-
Unidade 1Criação e evolução do desenvolvimento de software
23
dos). Isto não significa que antes tivessem falhas. Seguramente que em uma grande 
percentagem, o computador tinha problemas. Mas agora as falhas afetarão mais 
pessoas juntamente e farão mais ruído.
Nossos estudos continuam no AVA! Acesse a midiateca e leia os textos dis-
poníveis na pasta da unidade 01: 
• Modelos de processos.
• Modelos de processos evolutivos.
1.3 Considerações da unidade I
Destacamos aqui a atenção que as empresas devem ter em relação ao manu-
seio, controle, cronograma e gerenciamento de ações ligadas ao processo e desen-
volvimento de software. A utilização de tecnologias para garantir a funcionalidade se 
tornaram tarefas difíceis devido as constantes evoluções. 
Os modelos apresentados são fundamentais para que a Qualidade de Software 
seja atendida e por consequência, a satisfação do cliente. Aqui, diversos modelos fo-
ram apresentados, cabe ao responsável definir o modelo que melhor se adequa ou 
utilizar a mescla de todos para atingir o objetivo.
A Braz CubasUnidade 2Processo unificado de desevolvimento (RUP) 
25
2Unidade II
Processo unificado de desevolvimento (RUP)
Objetivos da Unidade:
• Apresentar o Processo Unificado de Desenvolvimento (RUP);
• Entender a Visão Sistêmica / Requisitos;
• Aplicar os Modelos de Desenvolvimento.
Competências e Habilidades da Unidade:
• Conhecimento do Processo Unificado de Desenvolvimento (RUP);
• Descrição do Conceito de Visão Sistêmica / Requisitos;
• Conhecimento do Processo de Capacitação dos Usuários.
A Braz CubasUnidade 2 Processo unificado de desevolvimento (RUP)
26
2.1 Processo unificado
A Braz CubasUnidade 2Processo unificado de desevolvimento (RUP) 
27
Cada uma dessas fases é por sua vez dividida em uma série de interações (a 
de início só consta de várias interações em projetos grandes). Essas interações ofe-
recem como resultado um incremento do produto desenvolvido, que acrescenta ou 
melhora as funcionalidades do sistema em desenvolvimento.
Cada uma dessas interações divide-se por sua vez em uma série de disciplinas, 
que relembram as definidas no ciclo de vida clássico ou em cascata: análise de re-
quisitos, desenho, implementação e prova. Ainda que todas as interações costumem 
incluir trabalho em quase todas as disciplinas, o grau de esforço dentro de cada uma 
delas varia ao longo do projeto.
 
Figura 1 – Fases da concepção do processo unificado.
Fonte: Adaptado de <http://www.devmedia.com.br/artigo-engenharia-de-software-o-processo-unificado-integrado-ao-desenvolvimento-web/8032>. 
2.2 Fase da concepção
Essa fase agrupa tanto atividades de comunicação com o cliente como de pla-
nejamento. Ao colaborar com os participantes, se identificam as necessidades do 
negócio, propõe-se uma arquitetura aproximada para o sistema e desenvolve-se um 
plano para a natureza interativa e incremental do projeto em questão. Essas neces-
A Braz CubasUnidade 2 Processo unificado de desevolvimento (RUP)
28
sidades detalham as características e funções que deseja cada classe principal de 
usuários. O fluxo de trabalho da engenharia do software está distribuído através de 
todas as fases do PU.
Durante a fase de concepção, desenvolve-se uma visão do produto final e apre-
senta-se o modelo do negócio para o produto. Essencialmente, essa fase responde 
às seguintes perguntas:
O que vai fazer o sistema para 
cada um dos grupos de usuários?
Como poderia ser a arquitetura 
do sistema?
Qual é o plano e quanto custará 
desenvolver o produto?
2.2.1 Visão do sistema
O objetivo deste fluxo de trabalho é traduzir os requisitos a uma especificação 
que descreve como implementar o sistema. 
Os objetivos da análise e desenho são: 
Transformar Desenvolver Adaptar
Os requisitos ao 
desenho do futuro 
sistema.
Uma arquitetura 
para o sistema.
O desenho para que seja 
consistente com o meio de 
implementação, desenhan-
do para o rendimento.
A Braz CubasUnidade 2Processo unificado de desevolvimento (RUP) 
29
A análise consiste em obter uma visão sistêmica que se preocupa com o uso 
dos requisitos funcionais.
Por outro lado, o desenho é um refinamento da análise que leva em conta os 
requisitos não funcionais que define o cumprimento do sistema e seus objetivos. 
O resultado final mais importante desse fluxo de trabalho será o modelo de 
desenho, o qual consiste em colaborações de classes, que podem ser agregadas em 
pacotes e subsistemas. 
Outro produto importante desse fluxo é a documentação da arquitetura de 
software, que captura várias vistas arquitetônicas do sistema.
2.2.2 Requisitos
Este é um dos fluxos de trabalho mais importantes, porque nele se estabelece 
o que tem que fazer exatamente o sistema que se constrói. Nesta linha os requisitos 
são o contrato que deve ser cumprido, de modo que os usuários finais têm que com-
preender e aceitar os requisitos que são especificados. 
Os objetivos do fluxo de dados “Requisitos” são: 
• Estabelecer e manter um acordo entre clientes e outros stakeholders sobre 
o que o sistema poderia fazer;
• Prover aos programadores um melhor entendimento dos requisitos do sis-
tema;
• Definir o ambiente do sistema;
• Prover uma base para o planejamento dos conteúdos técnicos das intera-
ções;
• Prover uma base para estimar custos e tempo de desenvolvimento do sis-
tema;
• Definir uma interface de usuários para o sistema, focando as necessidades 
e metas do usuário.
Para capturar os requisitos, é preciso entrevistar todos os interessados no projeto, 
não só os usuários finais, e anotar todas suas requisições. A partir delas deve se desco-
brir o que precisam para colocar todas essas informações em forma de requisitos.
A Braz CubasUnidade 2 Processo unificado de desevolvimento (RUP)
30
2.2.3 Caso de uso
Um sistema de software é criado para servir 
seus usuários. Portanto, para construir um siste-
ma de sucesso deve se conhecer o que querem e 
precisam os usuários prospectos.
O termo usuário refere-se não somente 
aos usuários humanos, mas a outros sistemas. 
Nesse contexto, o termo usuário representa algo 
ou alguém que interage com o sistema a ser de-
senvolvido.
Um caso de uso é uma peça na funcionalidade do sistema que dá ao usuário 
um resultado de valor. Os casos de uso capturam os requerimentos funcionais. To-
dos os casos de uso juntos constituem o modelo de casos de uso o qual descreve a 
funcionalidade completa do sistema. Esse modelo substitui a tradicional especifica-
ção funcional do sistema. 
Uma especificação funcional tradicional concentra-se em responder à pergunta: 
“O que se supõe que o
sistema deve fazer?”
 
 A estratégia de casos de uso pode ser definida agregando três palavras ao final 
da pergunta: 
“[...] por cada usuário?”.
A Braz CubasUnidade 2Processo unificado de desevolvimento (RUP) 
31
Estas três palavras têm um envolvimento importante, forçando a pensar em se 
ter o valor aos usuários e não somente em termos das funções que seria bom que 
tivesse. No entanto, os casos de uso não são somente uma ferramenta para especi-
ficar os requerimentos do sistema, também dirigem seu desenho, implementação e 
provas, isto é, dirigem o processo de desenvolvimento.
Ainda quando os casos de uso dirigem o processo, não são eleitos de maneira 
isolada. São desenvolvidos simultaneamente com a arquitetura do sistema, isto é, os 
casos de uso dirigem a arquitetura do sistema e a arquitetura do sistema influencia a 
eleição dos casos de uso. Portanto, a arquitetura do sistema e os casos de uso ama-
durecem conforme se avança o ciclo de vida.
2.3 Fase da elaboração
A Fase de Elaboração
Inclui as atividades de comunicação e de modelagem da es-
trutura geral do processo.
Melhora e amplia os casos de uso preliminares desenvolvi-
dos como parte da fase da concepção.
Aumenta a representação da 
arquitetura para incluir pontos 
de vista diferentes do software.
Os modelos: 
• de casos de uso, 
• de requerimentos, 
• de projeto, 
• da implementação e 
• do desenvolvimento.
 
Durante a fase de Elaboração, a maioria dos casos de uso do produto é especi-
ficada em detalhe e desenha-se a arquitetura do sistema. Ao final dessa etapa, o ge-
A Braz CubasUnidade 2 Processo unificado de desevolvimento (RUP)
32
rente do projeto está em uma posição de planejar as atividades e estimar os recursos 
requeridos para completar o projeto.
Atenção:
Estão disponíveis na pasta da unidade 02 da nossa midiateca textos que 
complementam aseu entendimento sobre a fase da elaboração.
2.4 Fase da construção
A Fase da Construção do PU
É idêntica à atividade de construção definida pelo processo 
geral do software.
Desenvolve ou adquire os componentes do software que farão com que 
cada caso de uso seja operacional para os usuários finais.
Para consegui-lo, completam-se os modelos de requerimentos e projeto 
que se começaram durante a fase da elaboração.
Depois implementam-se em código fonte todas as características e fun-
ções necessárias para o incremento de software.
Na Fase de Construção constrói-se o produto, por isso é o momento que se 
requer a maioria dos recursos. A arquitetura do sistema é estável, mas podem ser 
discutidas mudanças menores à mesma. Ao final dessa fase, o produto contém to-
dos os casos de uso que a gerência e os usuários do sistema lembraram desenvolver.
A Braz CubasUnidade 2Processo unificado de desevolvimento (RUP) 
33
Atenção:
Estão disponíveis na pasta da unidade 02 da nossa midiateca textos que 
complementam o seu entendimento sobre a fase da construção.
2.5 Fase de transição
A Fase de Transição do Processo Unificado
Inclui as últimas etapas da 
atividade geral de construção
E a primeira parte da atividade de 
desenvolvimento geral (entrega e 
feedback)
Entrega-se o software para os 
usuários finais para realiza-
rem testes beta
Os quais reportam tanto os defei-
tos como as mudanças necessárias.
A fase de transição, ao final do processo, cobre o período durante o qual o 
produto se move das versões de prova, passando por refinamentos sucessivos, até o 
produto final, este se instala, se capacita aos usuários, o produto entra em um ciclo 
de manutençãoe se dá por terminado o projeto.
Atenção:
Estão disponíveis na pasta da unidade 02 da nossa midiateca textos que 
complementam aseu entendimento sobre a fase da transição.
A Braz CubasUnidade 2 Processo unificado de desevolvimento (RUP)
34
2.6 Considerações da unidade II
Destacamos aqui a importância da utilização dos conceitos de requisitos, visão 
sistêmica, concepção, elaboração, modelo de negócio que as empresas e profissio-
nais devem ter sobre eles com relação ao manuseio e gerenciamento de todas as 
ações. 
Os modelos apresentados nas Unidades I e II mostram que o conceito e o mo-
delo serão tratados de forma igual, respeitando o objetivo a ser atendido. As etapas 
devem ser cumpridas rigorosamente para que a qualidade seja atendida.
Os profissionais da área tecnológica devem buscar aprimoramentos contínuos 
por meio das metodologias existentes em desenvolvimento de software na busca da 
excelência. 
Caro(a) aluno(a), é importante para o seu desenvolvimento na disciplina que 
busque mais informações nas teleaulas, podcast e fóruns no AVA. 
A Braz CubasUnidade 3Modelos de workflow
35
3Unidade III
Modelos de Workflow
Objetivos da Unidade:
• Apresentar os principais modelos de Workflow;
• Compreender a utilização e requisitos dos modelos de Workflow;
• Aplicar os Modelos de Workflow.
Competências e Habilidades da Unidade:
• Conhecimento dos principais modelos de Workflow;
• Descrição da utilização e requisitos;
• Conhecimento da aplicabilidade dos modelos de Workflow.
A Braz CubasUnidade 3 Modelos de workflow
36
3.1 Atividades técnicas
As atividades técnicas são fundamentais para a elaboração do Plano de Ação 
da área responsável pelo projeto e dos usuários envolvidos. Após esta definição, os 
próximos passos na execução serão efetuados visando a excelência no desenvolvi-
mento.
3.1.1 Workflow de requisitos
 A finalidade deste workflow é: 
3.1.2 Atores e casos de uso
Um sistema de software faz sentido de prestação de serviços a seus usuários. 
Os casos de uso são uma ferramenta para especificar os requisitos de um sistema 
através da descrição dos serviços prestados.
A Braz CubasUnidade 3Modelos de workflow
37
Um caso de uso é uma parte da funcionalidade que fornece ao usuário um re-
sultado importante. O caso de uso surge a partir do ponto de vista do usuário, desde 
suas necessidades, a sua interação e a sua própria avaliação da importância.
Casos de uso podem ser dirigidos para o processo de desenvolvimento. Orien-
tar a concepção, implementação e teste do sistema. 
As necessidades reais são aquelas que agregam valor para os usuários do sis-
tema.
Figura 2 – Modelo de caso de uso
Fonte: Adaptado de YANAGA (2006)
A Braz CubasUnidade 3 Modelos de workflow
38
3.1.3 Interface do sistema
A interface é a camada de um sistema orientado a objetos que gerencia todas 
as ações do usuário, ou seja, a interface é a parte do sistema que interage com o 
usuário. Ao implementar uma interface, a classe deve fornecer o comportamento 
para cada um de seus eventos.
Figura 3 - O uso de uma interface no sistema 
Fonte: Adaptado de RODRIGUES (2008)
3.2 Workflow de análise e projeto
O conceito de documento é relativo em cada etapa do workflow. No workflow 
de requisitos entende-se como documento, um requisito. No workflow de análise e 
projeto, como a especificação para solução do requisito. No workflow de implemen-
tação como uma tarefa da especificação que pode ser atendida por um desenvolve-
dor. E, finalmente, no workflow de teste, documento significa a validação ou não de 
uma funcionalidade, que pode envolver mais de um requisito (KANTORSKI e KROTH, 
A Braz CubasUnidade 3Modelos de workflow
39
2013).
O tempo total utilizado em um workflow significa o tempo real despendido para 
realização de uma atividade do fluxo. Ele é tomado com base no envio e recebimento 
de documentos dos usuários durante a fase de utilização da ferramenta. 
O tempo total estimado de um workflow é o tempo estimado para realização 
da atividade, sendo que o somatório do tempo de cada atividade no workflow dará 
o tempo total estimado para realização. Esses tempos são tomados na configuração 
dos fluxos de cada workflow, definidos durante a fase de configuração da ferramenta 
(KANTORSKI e KROTH, 2013).
3.2.1 Classes de análise
As classes definem atributos, em um nível mais alto nível. Os atributos são 
conceituais e reconhecíveis no domínio do problema. Podem se tornar classes no 
projeto e implementação (GIMENES, 2009).
Segundo Andrey (2013), as classes de análise são óbvias no contexto do domí-
nio do problema. São mais conceituais e de granulidade maior do que as classes de 
projeto e implementação. Elas definem:
Responsabilidades – dificilmente incluem operações.
Atributos, em um nível mais alto nível. Os atributos são conceituais e reconhecíveis 
no domínio do problema. Podem se tornar classes no projeto e implementação.
São inicialmente obtidas a partir do modelo de objetos de negócios. O mode-
lo de classes de análise é composto pelos objetos identificados na análise do 
domínio e da aplicação. Seu objetivo é descrever o problema representado pelo 
sistema a ser desenvolvido sem levar em consideração características da solu-
ção a ser desenvolvida.
A Braz CubasUnidade 3 Modelos de workflow
40
As classes de análise são modeladas em termos de estereótipos. Não existe 
um livro de receitas que ensine como descobrir classes. O RUP (Rational Unified Pro-
cess) sugere que as classes de análise sejam descobertas no desenvolvimento do 
sistema, procurando as classes de limite, controle e entidade. Esses três estereótipos 
ajustam-se, ponto de vista model-view-controler e permitem ao analista particionar o 
sistema, separando a visão do domínio do controle necessário pelo sistema.
Tendo como base que a análise e o projeto do processo são interativos, a lista 
de classes irá mudar ao longo do tempo. O conjunto inicial de classes provavelmente 
não será o conjunto de classes que vai ser efetivamente implementado. Para nós, o 
termo candidato para uma classe é frequentemente usado para descrever o primei-
ro conjunto de classes descobertas para o sistema.
3.2.1.1 Limite
Classes limite cuidam da comunicação entre o meio com o qual o sistema in-
terage e o sistema propriamente dito. Elas fornecem a interface para um usuário ou 
para um outro sistema (interface para um ator). Elas constituem a parte do sistema 
que dependem do meio em que elas estão. Classes limite são utilizadas para mode-
lar as interfaces do sistema.
Cada par ator/cenário é examinado para descobrir as classes limite. As classes 
limite escolhidas na fase de elaboração do desenvolvimento são tipicamente de alto 
nível. Por exemplo, você pode modelar uma janela, mas não modela cada caixa de 
diálogo e botões. Nesse ponto você está documentando os requerimentos da inter-
face com o usuário, não implementando a interface.
Os requerimentos das interfaces com o usuário tendem a ser muito vagos, os 
termos amigáveis e flexíveis são muito utilizados. Mas, amigável tem significados 
diferentes para pessoas diferentes. Nesse caso, as técnicas de prototipagem podem 
ser muito úteis. O cliente pode dar uma olhada e sentir o sistema e realmente enten-
der o que o termo amigável significa. O “o que” é então compreendido, assim como 
a estrutura e o comportamento da classe limite. Durante o projeto essas classes são 
refinadas para levar em consideração os mecanismos da interface escolhida.
Classes limite são também adicionadas para facilitar a comunicação com ou-
tros sistemas. Durante o projeto essas classes são refinadas para levar em conside-
ração o protocolo de comunicaçãoescolhido.
A Braz CubasUnidade 3Modelos de workflow
41
3.2.1.2 Controle
Classes controle modelam uma sequência de comportamento específico a um 
ou mais casos de uso. Classes controle coordenam os eventos necessários para a 
realização do comportamento especificado em um caso de uso. Ela representa a 
dinâmica do caso de uso. Essas classes normalmente são classes dependentes da 
aplicação.
Logo nos primeiros estágios da fase de elaboração, uma classe controle é adi-
cionada para cada par ator/caso de uso. A classe controle é responsável pelo fluxo 
de eventos do caso de uso.
O uso de classes controle é muito subjetivo. Muitos autores sentem que o uso 
de classes controle resulta no comportamento, sendo separado dos dados. Isso pode 
acontecer se a classe controle não foi escolhida prudentemente. Se uma classe con-
trole está fazendo mais do que estabelecer uma sequência, então ela está fazendo 
coisas demais. Por exemplo, no sistema de matrículas, um estudante seleciona um 
curso ofertado, se o curso ofertado está disponível, o estudante é matriculado nele. 
Quem sabe como matricular um estudante: a classe controle ou a oferta curso? A 
resposta correta é oferta curso.
A classe controle sabe quando o estudante deveria ser matriculado, o curso 
ofertado, sabe como matricular o estudante. Uma péssima classe controle não sabe-
ria só quando matricular o estudante, mas como matricular o estudante.
A adição de uma classe controle para cada par ator/caso de uso é somente um 
começo. Enquanto a análise e o projeto continuam, as classes controle podem ser 
eliminadas, explodidas ou combinadas.
3.2.1.3 Entidade
Uma classe entidade modela informação e comportamento associado, que ge-
ralmente tem uma vida longa no sistema. Esse tipo de classe pode refletir uma enti-
dade do mundo real, ou ela pode ser necessária para executar uma tarefa interna do 
sistema. Elas são tipicamente independentes do meio em que estão, isto é, elas não 
precisam saber como as classes, que estão no limite, se comunicam com o sistema. 
Muitas vezes, elas são aplicações independentes, isso significa que muitas delas po-
derão ser utilizadas por mais de um sistema.
A Braz CubasUnidade 3 Modelos de workflow
42
O primeiro passo é examinar as responsabilidades documentadas no fluxo de 
eventos para o caso de uso identificado (i.e., o que o sistema deve fazer). Classes 
entidade são normalmente utilizadas pelo sistema para definir alguma responsabi-
lidade.
Os nomes e as frases usadas para descrever a responsabilidade podem ser um 
bom ponto de partida. A lista inicial de nomes deve ser filtrada, pois ela pode conter 
nomes que estão fora do domínio do problema, nomes que são somente expressão 
de linguagem, nomes que são redundantes e que são descrições da estrutura da 
classe.
Classes entidade são normalmente encontradas na fase de elaboração. Elas 
são frequentemente chamadas de classes de domínio, desde que elas sejam usual-
mente tratadas como abstrações de entidades do mundo real.
3.2.2 Diagrama de comunicação
O diagrama de comunicação é composto de:
Atividades
Transições
Decisões
Um caso especial dos Diagra-
mas de Estados, com a maio-
ria das transições resultantes 
do término das atividades.
Semelhantes aos 
antigos fluxogramas
Muito usados para 
modelar atividades 
concorrentes
São:
A Braz CubasUnidade 3Modelos de workflow
43
Figura 4 – Exemplo de diagrama de atividade 
Fonte: Adaptado de YANAGA (2006)
A Braz CubasUnidade 3 Modelos de workflow
44
Figura 5 – Diagrama de atividade - exemplo 
Fonte: YANAGA (2006)
A Braz CubasUnidade 3Modelos de workflow
45
3.2.3 Análise arquitetural
Seguem os itens mais utilizados na Análise Arquitetural:
Workflow de Análise - Descobrir as classes de análise.
Realizar a análise arquitetural descobrindo os pacotes de análise e os pacotes 
de serviço.
Use case realization – análise - descobrir como concretizar os casos de uso.
3.2.3.1 Pacotes de análise
De acordo com Gimenes (2009), os pacotes de análise:
Visam organizar os artefatos do modelo de análise em partes gerenciáveis.
Consistem de classes de análise, use case realizations e outros pacotes de análise 
(recursivamente).
Devem ser coesos e fracamente acoplados.
São facilmente reconhecidos pelas pessoas com conhecimento do domínio.
São agrupados em camadas para formar a arquitetura do sistema.
A Braz CubasUnidade 3 Modelos de workflow
46
3.2.3.2 Pacotes de serviço
Para Gimenes (2009), os pacotes de serviço:
Representam serviços forneci-
dos pelo sistema aos pacotes 
de mais alto nível.
São entrada para as ativi-
dades de projeto e imple-
mentação subsequentes.
 Ex. verificar ortografia e controlar acesso.
Nossos estudos continuam no AVA! Acesse a midiateca e leia os textos dis-
poníveis na pasta da unidade 03: 
• Workflow de implementação.
• Workflow de teste.
3.3 Considerações da unidade III
Como considerações para os Processos e Desenvolvimento de Software, desta-
camos a importância da utilização do workflow, das classes de análise, diagrama de 
comunicação, análise da arquitetura, builder e deployment.
Os modelos apresentados mostram que o conceito e o modelo serão tratados 
de forma igual, respeitando o objetivo a ser atendido. As etapas devem ser cumpri-
das rigorosamente para que se tenha qualidade e o projeto seja atendido na sua 
plenitude.
A Braz CubasUnidade 4Utilização da modelagem visual, ferramenta case e diagramas
47
4Unidade IV
Utilização da modelagem visual, ferramenta case 
e diagramas
Objetivos da Unidade:
• Apresentar a Modelagem Visual, Ferramenta Case e Diagramas;
• Compreender a utilização da Modelagem Visual, Ferramenta Case 
e diagramas; 
• Aplicar os Modelos.
Competências e Habilidades da Unidade:
• Conhecimento da Modelagem Visual, Ferramenta Case e Diagramas; 
• Descrição do Conceito de Modelagem, Ferramenta Case e Diagramas; 
• Aplicabilidade dos Modelos.
Fonte: Adaptado de <http://www.devmedia.com.br/imagens/sqlmagazine/mar2006/29-06pic03.JPG>. 
Acesso em: 06/01/2014.
A Braz CubasUnidade 4 Utilização da modelagem visual, ferramenta case e diagramas
48
4.1 Modelagem visual
A modelagem de um modelo de processo é realizada utilizando as linguagens 
de definição de processos existentes nos SGW. Um processo de software é definido e 
o mesmo é modelado na notação do SGW utilizado. (BETEMPS, 2003)
O SGW faz o monitoramento dos eventos e dispara as ações associadas (como 
o assinalamento e início de nova atividade) quando condições prévias são alcança-
das. Essas condições e ações são todas definidas na notação da linguagem de defini-
ção de processos de workflow do SGW (BETEMPS, 2003).
Quando uma nova atividade é assinalada, (lista da sequência definida previa-
mente), o SGW prioriza e, de acordo com as definições, o próprio ambiente fornece 
as informações necessárias sobre ela, inclusive mostrando uma provável solução, 
que é chamada de gabarito (serve de modelo e guia para execução da atividade). 
Todas essas informações referentes às atividades, como gabaritos, ferramen-
tas e documentos associados - além de informações sobre os desenvolvedores ca-
dastrados no ambiente, papéis desempenhados, projetos em execução e atividades 
já executadas, o próprio modelo de processo, e outras – são mantidas no repositório 
do ambiente (banco de dados) e podem ser recuperados pelo SGW (para manter a 
execução e o monitoramento do processo) e pelas páginas de script (ASP, javascript) 
para a geração das páginas de acesso dos desenvolvedores ao ambiente (BETEMPS, 
2003).
Quando um projeto é iniciado por um gerente de projeto (este é um papel 
que pode ser desempenhadopor um desenvolvedor [RAT 2001]), uma instância do 
modelo de processo, definido na linguagem de modelagem do SGW, é criada. A par-
tir desse momento, qualquer modificação ocorrida dentro desse projeto (ao nível 
de atividades) é monitorada pelo SGW que, segundo o modelo de processo, toma 
as ações pertinentes em relação ao mesmo projeto. Modificação do estado de um 
projeto não causa modificações em um outro projeto, são instâncias totalmente se-
paradas e que não influenciam umas as outras (BETEMPS, 2003).
4.2 Ferramenta case
Ferramenta CASE (Engenharia de Software assistida por computador)
A Braz CubasUnidade 4Utilização da modelagem visual, ferramenta case e diagramas
49
Ferramenta CASE (Engenharia de Software assistida por computador)
São aplicações de software diferentes para aumentar a pro-
dutividade em custos de desenvolvimento de software em ter-
mos de tempo e dinheiro.
Ajuda em todos os aspectos 
do ciclo de vida das tarefas de 
desenvolvimento de software.
Como o processo de fazer um 
projeto de design, verificação 
de custos, implementação de 
parte do código automatica-
mente com determinado pro-
jeto, compilação automática, 
documentação ou detecção de 
erros, entre outros.
Como o processo de fazer um projeto de design, verificação de custos, imple-
mentação de parte do código automaticamente com determinado projeto, compila-
ção automática, documentação ou detecção de erros, entre outros.
Pode-se citar que a primeira ferramenta caso era excelerator, que veio a luz em 
1984 e trabalhou sob uma plataforma PC. 
Ferramentas case atingiu seu limite máximo no início da década de 1990. Na 
época a IBM tinha uma aliança com o software da empresa AD/ciclo para trabalhar 
com os mainframes, essas duas empresas trabalhavam ferramentas case que co-
briam o ciclo de vida do software inteiro. 
Embora não seja fácil e não há uma única forma de classificá-los, ferramentas 
case podem ser classificadas tendo em conta os seguintes parâmetros:
A Braz CubasUnidade 4 Utilização da modelagem visual, ferramenta case e diagramas
50
Plataformas que sup
ortam
Fases do ciclo de vid
a do desenvolvimento
 
de sistemas que cob
rem
A arquitetura de apl
icativos que produze
m
Sua funcionalidade
A seguinte classificação é a mais comum, com base nas fases do ciclo de desen-
volvimento, abrangendo:
Upper-CASE (caso-U)
Ferramentas que ajudam nas fases de planejamento, análise de requisitos e estra-
tégia de desenvolvimento, utilizando, entre outros diagramas, UML.
CASE médio (M-caso)
Ferramentas para automatizar tarefas na análise e design do aplicativo.
Letras minúsculas (CASE-L)
Ferramentas que semiautomatizam a geração de código, criação de programas 
de deteção, suporte a depuração de programas e testes. Além de automatizar por 
funcionalidade de nós poderia diferenciar alguns, tais como:
Ferramentas de geração de 
código semiautomática Editores de UML
Ferramentas de 
refatoração de código
Ferramentas de manuten-
ção, tais como sistemas de 
controle de versões
A Braz CubasUnidade 4Utilização da modelagem visual, ferramenta case e diagramas
51
Figura 6 – Print do editor UML 
Fonte: UML (2013)
Descreve como modelar visualmente aplicativos para capturar a estrutura e o 
comportamento da arquitetura e componentes. Rational Rose é a melhor fer-
ramenta para realizar a modelagem visual. Ele permite ocultar e mostrar os 
detalhes de acordo com o nível de abstração exigido e escrever seu aplicativo 
usando blocos de construção gráficos. Abstrações visuais podem comunicar 
diferentes aspectos do software; mostrar como os elementos do sistema se 
encaixam; certificar que os blocos são consistentes com o código; manter a 
coerência entre a concepção e execução; e promover uma comunicação clara 
entre todos os participantes do projeto.
Rational Unified Process
A Braz CubasUnidade 4 Utilização da modelagem visual, ferramenta case e diagramas
52
É a ferramenta case que os desenvolvedores de UML comercializam e 
que suporta totalmente a especificação UML. Essa ferramenta propõe o uso de 
quatro tipos de modelo para um projeto de sistema, usando uma visão estática 
e outra dinâmica do sistema, um lógico e outros modelos físicos. Permite criar 
e refinar essas exibições, criando dessa forma um modelo completo que repre-
senta o domínio do problema e o sistema de software.
Rational Rose
4.3 Diagramas estáticos
Sua função no processo de desenvolvimento são simplificações da realidade e 
construídas para entender melhor o sistema que vamos desenvolver. Os arquitetos, 
por exemplo, usam e constroem aviões (modelos) de edifícios; designers de carro 
grande preparam modelos em sistemas de CAD/CAM com todos os detalhes. Sendo 
assim, os engenheiros de software também devem construir modelos de sistemas de 
software. 
Para a construção de modelos, deve incidir os detalhes relevantes enquanto 
outros são ignorados, porque com um único modelo não se tem o suficiente. Vários 
modelos fornecem diferentes pontos de vista de um sistema, que nos ajudam a com-
preendê-lo de várias frentes. Assim, a UML recomenda o uso de nove diagramas para 
representar os diferentes pontos de vista de um sistema.
Prática de criação de diagramas para visualizar perspectivas de sistemas ou 
diferentes pontos de vista não está limitada a indústria da construção civil. No con-
texto de software existem cinco exibições adicionais que são os mais importantes 
visualizar, especificar, construir e documentar a arquitetura do software. Em UML os 
pontos de vista existentes são:
 
A Braz CubasUnidade 4Utilização da modelagem visual, ferramenta case e diagramas
53
Vista casos de uso:
Modo Design:
Formulários com diagramas de casos de uso, colabora-
ção, estados e atividades.
Visão de Processos: 
Implantação Vista:
Implantação Vista:
Formas com diagramas de classes, objetos, colaboração, 
estados e atividades.
Formulários com diagramas da visão de design, enfati-
zando as classes e objetos relacionados com processos.
É formado com diagramas de componentes, colabora-
ção, estados e atividades.
É formado com diagramas de implantação, interação, 
estados e atividades.
Como podemos ver, o número de diagramas é muito alto, nos casos mais ex-
cessivos e UML permite que se defina apenas o necessário, uma vez que nem todos 
são necessários em todos os projetos. 
UML para modelagem de sistemas grandes e complexos, deve se ter em mente 
que podem ser compostos de milhões de linhas de código e ser realizados por equi-
pamentos de centenas de programadores. 
Na prática, todos os diagramas são bidimensionais, mas a UML permite criar 
diagramas em três dimensões para modelos mais específicos. 
Com UML devemos esquecer o destaque excessivo dado ao diagrama de clas-
se, isto representa uma parte importante do sistema, mas apenas uma visão estática, 
ou seja, mostra o sistema em pé. Sabemos de sua estrutura, mas não sabemos o que 
acontece quando o sistema inicia as suas diferentes partes.
A Braz CubasUnidade 4 Utilização da modelagem visual, ferramenta case e diagramas
54
4.3.1 Diagramas de casos de uso
Um caso de uso especifica uma exigência funcional. Um diagrama de caso de 
uso é composto dos seguintes elementos: 
Ator
Um ator é um papel que tem um usuário no que diz respeito ao sistema, ou 
seja, seria um usuário do sistema. É importante destacar o uso da palavra “papel”, 
uma vez que especifica que um ator não necessariamente representa uma pessoa 
em particular, se não o trabalho que realizamos no sistema.
A Braz CubasUnidade 4Utilização da modelagem visual, ferramenta case e diagramas
55
Por exemplo, em um sistemade vendas, o papel do vendedor em relação ao 
sistema pode ser feito por um vendedor ou pelo chefe do local.
Você deve ter um nome significativo, que é representado pelo modelo a seguir:
Caso de uso
É uma operação ou tarefa específica que é executada depois que uma ordem ou 
incentivo de um agente externo, pode ser um ator ou invocação de outro caso de uso. 
Ela é representada pelo gráfico a seguir:
Relações
Associação
É o tipo de relação mais básico, indica a invocação de um jogador ou uso de 
outro caso de operação (caso de uso). Essa relação é indicada com uma seta simples:
A Braz CubasUnidade 4 Utilização da modelagem visual, ferramenta case e diagramas
56
Dependência ou instanciação
É uma forma muito particular de relacionamento entre classes, em que uma 
classe depende da outra, ou seja, é a instância (criada). Essa relação é indicada por 
uma seta pontilhada: 
Generalização
Este tipo de relacionamento é um dos mais amplamente utilizados, tem uma 
função dupla dependendo do seu estereótipo, que pode ser de Uso (<<uses>>) ou de 
Herança (<<extends>>).
Esse tipo de relacionamento é orientado exclusivamente para casos de uso. 
Herança: é recomendado quando um caso de uso é semelhante a outro (em 
recursos). 
Uso: é recomendado quando você tem um conjunto de características que são 
similares em mais de um uso caso e não quer manter copiada a descrição do recurso. 
Ele é representado com a seta a seguir:
Nossos estudos continuam no AVA, onde daremos sequência aos diagra-
mas estáticos! Além disso, vamos apresentar os diagramas dinâmicos!
4.4 Considerações da unidade IV
Destacamos aqui a importância da modelagem visual, ferramentas case e dia-
gramas. Essas ferramentas ajudam a simular o uso do software que será implantado 
na contenção de possíveis falhas e aumentar a qualidade para evitar manutenção 
corretiva no curto e médio prazo.
A Braz CubasUnidade 4Utilização da modelagem visual, ferramenta case e diagramas
57
Os modelos apresentados entre as Unidades III e IV mostram que os conceitos 
de workflow, modelagem e ferramentas case facilitam e organizam os procedimentos 
a serem adotados no desenvolvimento do software. As etapas devem ser cumpridas 
para que o objetivo seja atendido.
Acredita-se que a UML (Linguagem de Modelagem Unificada ou Unified Mode-
ling Language) é a melhor solução para todos os profissionais envolvidos com a análi-
se de sistemas, pois se ele contata-nos para trabalhar em um projeto de software em 
que sabemos que o número de membros não é por nada reduzido (se trabalhou em 
grandes empresas), sem a aplicação da UML torna-se complicado para se chegar a 
um acordo sobre as metodologias a serem utilizadas, nas notações para serem usa-
das para cada modelo (análise ou implementação). Portanto, este novo paradigma 
de projeto nos permite unificar todos os nossos critérios para compreender mais e 
melhor a organização dos projetos.
Como desvantagem pode-se destacar (embora para alguns ou muitos não se-
ria assim) que a UML permite especificar, visualizar e construir software orientado a 
objeto. 
Podemos pensar que isso não vai acontecer, no máximo será mostrada uma 
extensão da UML para considerar qualquer aspecto do modelo formal, mas acredi-
tamos que não seria muito justificável, porque o que é alvo neste momento é a apli-
cação de metodologias orientadas a objeto, já que elas fornecem muitas vantagens e 
resolvem muito dos problemas que surgem nas metodologias estruturadas.
Referências
59
Referências
BETEMPS, Carlos Michel. Construção de um Ambiente de Desenvolvimento de 
Software baseado em um Sistema de Gerência de Workflow e outros Produtos Co-
merciais. Porto Alegre: PPGC. Dissertação (Mestrado, Programa de Pós-Graduação 
em Computação) 162 fls. UFRGS, 2003.
DEPLOYMENT. Disponível em http://sce.uhcl.edu/helm/rationalunifiedprocess/pro-
cess/workflow/deployme/wfd_dep.htm. Acesso em: 20 dez. 2013.
D’SOUZA, D.; WILLS A. Objecs, Components, and Frameworks with UML: The Ca-
talysis Approach. Addison-Wesley, 1998. 
GIMENES, Dra. Itana Maria de Souza. O Processo Unificado: Workflow de Análise 
(2009). Disponível em: http://www.din.uem.br/~itana/esi-informatica/2009/notas-E-
SI-2009-07-ana.pdf. Acesso em: 20 dez. 2013.
JACOBSON, G. B.; J. RUMBAUGH. O processo unificado de desenvolvimento de 
software. Madrid: ABC, 2002.
JACOBSON, Ivar; BOOCH, Grady; RUMBAUCH, James. The unified modeling langua-
ge. Madrid: Addison Wesley, 1999.
KANTORSKI, Gustavo Zanini; KROTH, Marcelo Lopes. Controle de métricas no pro-
cesso de desenvolvimento de software através de uma ferramenta de workflow. 
Disponível em: http://sites.multiweb.ufsm.br/sites/portalcpd/templates/meutempla-
te1.0b/images/artigos/2004/2540.pdf. Acesso em: 20 dez. 2013.
ORACLE CORPORATION. Oracle Workflow Cartridge. Redwood, CA, USA, Nov. 1998. 
Disponível em: <http://www.atloaug.org/presentations/nov98Workflow.pdf>. Acesso 
em: 23 nov. 2013.
PRADO, A. F., LUCRÉDIO, D; MVCASE. Ferramenta case orientada a objetos - Sessão 
de Ferramentas do XIII Simpósio Brasileiro de Engenharia de Software - SBES’2000. 
João Pessoa-PB, Brasil. 4 - 6 de Outubro, 2000. 
RATIONAL CORPORATION. Rational Unified Process 2001. Disponível em: <http://
www.rational.com/>. Acesso em: 20 dez. 2013-12-27
RODRIGUES, Edson Junior Lobo. Curso de engenharia de software. São Paulo: Dige-
rati Books, 2008, 112 p.
Referências
60
RUMBAUGH, James; BLAHA, Michael; PREMERALNI, William, HEDI, Frederick; LOREN-
SEN, William Lorensen. Models and object - UNWTO methodology - oriented de-
signs. Washington: Prentice Hall, 1996.
UML EDITOR. Disponível em: http://www.myeclipseide.com/index.php?module=
htmlpages&func=display&pid=266. Acesso em: 20 dez. 2013.
UNIVERSIDADE FEDERAL DO PARANÁ UFPR. Bacharelado em Ciência da Computa-
ção. SOFT. AULA NÚMERO: 09. Prof. Andrey. Disponível em: http://www.inf.ufpr.br/
andrey/ci221/SOFTua09.pdf. Acesso em: 20 dez. 2013.
YANAGA, Edna Tomie Takano. Engenharia de Software I. (2006). FUNDAÇÃO UNI-
VERSIDADE ESTADUAL DE MARINGÁ. Disponível em: http://www.din.uem.br/~itana/
esi-informatica/notas-ESI-2006-Edna-01.pdf. Acesso em: 20 dez. 2013.
	Apresentação
	O Professor
	Introdução
	1Unidade I
	Criação e evolução do desenvolvimento de software
	1.1 Desenvolvimento de software
	1.2 Evolução 
	1.2.1 Crise do software
	1.2.2 Falhas conhecidas
	1.2.3 Projetos de software
	1.2.4 Problemas no desenvolvimento de software
	1.3 Considerações da unidade I
	2Unidade II
	Processo unificado de desevolvimento (RUP)
	2.1 Processo unificado
	2.2 Fase da concepção
	2.2.1 Visão do sistema
	2.2.2 Requisitos
	2.2.3 Caso de uso
	2.3 Fase da elaboração
	2.4 Fase da construção
	2.5 Fase de transição
	2.6 Considerações da unidade II
	3Unidade III
	Modelos de Workflow
	3.1 Atividades técnicas
	3.1.1 Workflow de requisitos
	3.1.2 Atores e casos de uso
	3.1.3 Interface do sistema
	3.2 Workflow de análise e projeto
	3.2.1 Classes de análise
	3.2.1.1 Limite
	3.2.1.2 Controle
	3.2.1.3 Entidade
	3.2.2 Diagrama de comunicação
	3.2.3 Análise arquitetural
	3.2.3.1 Pacotes de análise
	3.2.3.2 Pacotes de serviço
	3.3 Considerações da unidade III
	4Unidade IV
	Utilização da modelagem visual, ferramenta case e diagramas
	4.1 Modelagem visual
	4.2 Ferramenta case
	4.3 Diagramas estáticos
	4.3.1 Diagramas de casos de uso
	4.4 Considerações da unidade IV