Desenvolvimento de Aplicativos Web Empresariais

TEMA I: INTRODUÇÃO AOS SISTEMAS DE INFORMAÇÃO 4

Unidade 1.1. INTRODUÇÃO. Sistemas de Informação 4
Unidade 1.2. Definição de sistema de informação 5
Unidade 1.3. Contexto organizacional e tipos de informação numa organização 7
Unidade 1.3. EXERCÍCIOS INTEGRADOS das unidades deste tema 14
Bibliografia 14

TEMA II: DESENVOLVIMENTO NO CONTEXTO DA ENGENHARIA DE

SOFTWARE E RISCOS 15
Unidade 2.1. INTRODUÇÃO. Engenharia de Software e Riscos 15
Unidade 2.2. Riscos ligados aos requisitos 22
Unidade 2.3. Riscos Tecnológicos 27
Unidade 2.4. Riscos de competência 28
Unidade 2.5. Riscos políticos 28
Bibliografia 29

TEMA III: DIFERENTES TIPOS DE MODELOS DE SISTEMA DE INFORMAÇÃO

30
Unidade 3.1. INTRODUÇÃO. Modelos de Sistemas de informação 30
Unidade 3.2. Modelos predictivos 31
Unidade 3.3. Modelos normativos 32
Unidade 3.4. Modelos descritivos 32
Bibliografia 34

TEMA IV: DIFERENTES NÍVEIS DE ABSTRAÇÃO DE SISTEMAS DE

INFORMAÇÃO 35
Unidade 4.1. INTRODUÇÃO. Níveis de Abstração de Sistemas de informação 35
Unidade 4.2. Nível conceptual 37
Unidade 4.2. Nível de especificação 37
Unidade 4.3. Nível de implementação 38
Unidade 4.2. Nível de instalação 39
TEMA V: O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 39
Unidade 5.1. INTRODUÇÃO. Ciclo de vida de Desenvolvimento de Software 39
Unidade 5.2. Modelo waterfall 40
Unidade 5.3. Modelo espiral 44
Unidade 5.4. Modelo RAD 45
Bibliografia 47

TEMA VI: PROPOSTA DE UM PROCESSO DE DESENVOLVIMENTO DE

SOFTWARE 48
 Unidade 6.1. INTRODUÇÃO. processo de desenvolvimento de software 48
Unidade 6.2. Desenvolvimento interactivo e incremental 48
Bibliografia 50
TEMA VII: MODELAÇÃO DE SISTEMAS DE INFORMAÇÃO EM UML 50
Unidade 7.1. INTRODUÇÃO. UML 50
Unidade 7.2. Modelação Orientada aos Objectos 51
Unidade 7.3. Modelação Estrutural 52
Unidade 7.4. Modelação Comportamental 52
Bibliografia 53
TEMA VIII: MODELAÇÃO ESTRUTURAL CLASSES E RELACIONAMENTOS 54
Unidade 8.1. INTRODUÇÃO. Diagrama de classes e relacionamentos 54
Bibliografia 62
TEMA IX: MODELAÇÃO COMPORTAMENTAL 63
Unidade 9.1. INTRODUÇÃO. Modelação Comportamental 63
Unidade 9.2. Diagramas de Use Case 63
Unidade 9.2. Diagramas de Interacção (sequência e colaboração) 68
Unidade 9.2. Diagramas de Transição de Estado 70
Unidade 9.2. Diagramas de Actividade 72
Bibliografia 73
TEMA X: MODELAÇÃO ARQUITECTURAL 73
Unidade 10.1. INTRODUÇÃO. Deployment (Instalação) 73
Bibliografia 79

TEMA XI: GESTÃO E ORGANIZAÇÃO DE MODELOS (DIAGRAMAS DE

PACKAGE) 80
Unidade 11.1. INTRODUÇÃO. Modelos 80
Unidade 11.2. Diagrama de pacotes 81
Bibliografia 82
TEMA XII: ESTUDO DE CASOS 83
Unidade 12.1. INTRODUÇÃO. Estudo de casos 83
Bibliografia 84

TEMA XIII: ESTUDO DE UM AMBIENTE DE SUPORTE AO DESENVOLVIMENTO

DE SISTEMAS DE INFORMAÇÃO MODELADOS EM UML 85
Unidade 13.1. INTRODUÇÃO. Ambiente 85
Unidade 13.2. Geração de código a partir do ambiente e diagramas UML: Java, JDBC 88
Unidade 13.3. Mini-projecto – Desenvolvimento de um aplicativo 91
Criando packages 98
Criando uma Java Class 100
Console 102
Teclas de atalhos do Eclipse 106
Bibliografia 108
TEMA I: INTRODUÇÃO AOS SISTEMAS DE INFORMAÇÃO

Unidade 1.1. INTRODUÇÃO. Sistemas de Informação

O Século XX é considerado aquele do advento da Era da Informação. A partir de então, a

informação começou a fluir com velocidade maior que a dos corpos físicos. Desde a invenção
do telégrafo elétrico em 1837, passando pelos meios de comunicação de massa, e até mais
recentemente, o surgimento da grande rede de comunicação de dados que é a Internet, o ser
humano tem de conviver e lidar com um crescimento exponencial do volume de dados
disponíveis.
O domínio da informação disponível é uma fonte de poder, uma vez que permite analisar
fatores do passado, compreender o presente, e principalmente, antever o futuro.
Os sistemas de informação surgiram antes mesmo da informática.
Antes da popularização dos computadores, os sistemas de informação nas organizações se
baseavam basicamente em técnicas de arquivamento e recuperação de informações de grandes
arquivos. Geralmente existia a figura do "arquivador", que era a pessoa responsável em
organizar os dados, registrá-los, catalogá-los e recuperá-los quando necessário.
Esse método, apesar de simples, exigia um grande esforço para manter os dados atualizados
bem como para recuperá-los. As informações em papéis também não possibilitavam a
facilidade de cruzamento e análise dos dados. Por exemplo, o inventário de estoque de uma
empresa não era uma tarefa trivial nessa época, pois a atualização dos dados não era uma tarefa
prática e quase sempre envolvia muitas pessoas, aumentando a probabilidade de ocorrerem
erros.
Com isso, podemos concluir que a pré-história dos Sistemas de Informação foi marcada pela
simplicidade dos dados, informações, métodos e técnicas, assim como pela limitação do
sistema e pela sua ineficiência.
Conceito de Tecnologia da Informação a Tecnologia da Informação (TI) é o conjunto de
recursos não humanos dedicados ao armazenamento, processamento e comunicação da
informação, e a maneira como esses recursos estão organizados num sistema capaz de executar
um conjunto de tarefas". A TI não se restringe a equipamentos (hardware), programas
(software) e comunicação de dados. Existem tecnologias relativas ao planejamento de
informática, ao desenvolvimento de sistemas, ao suporte ao software, aos processos de
produção e operação, ao suporte de hardware.
A primeira geração é caracterizada pelo surgimento dos Sistemas Operacionais ou Orientados
à Operação, automatizados através de grandes computadores (em seu início) e mais à frente
migrado para microcomputadores.
Nas organizações foram surgindo sistemas especialistas, aqueles destinados a executarem uma
determinada tarefa, como, por exemplo, um sistema de folha de pagamento. Esses sistemas
forneciam informações para um determinado setor da empresa e isso era um grande avanço até
então.

Unidade 1.2. Definição de sistema de informação

Sistema de Informação (SI) é um conjunto de componentes inter-relacionados que coletam,

manipulam e disseminam dados e informação, proporcionando um mecanismo de
realimentação (feedback) para atender a um objetivo determinado. Os sistemas de informação
estão difundidos por todas as funções organizacionais. Eles são usados por áreas como
contabilidade, finanças, vendas, produção e assim por diante. Em conseqüência, esse uso
generalizado aumenta a necessidade por novos sistemas cada vez mais complexos e por
profissionais com conhecimento no seu desenvolvimento e gerenciamento.

Conceitos gerais
Sistema de informação pode ser definido como "qualquer sistema utilizado para prover
informações qualquer que seja sua utilização" (POLLONI, 2000). Todo sistema de informação
pode ser visto, do ponto de vista mais técnico, como um conjunto de programas e de estruturas
de dados. Os métodos de análise e projeto de sistemas historicamente enfocaram dados e
processos. Mas de uma ênfase inicial em algoritmos, programas e processos, as metodologias
de desenvolvimento migraram para uma abordagem centrada nos dados. A partir dai, as
preocupações dos desenvolvedores e dos usuários foram passando dos dados operacionais para
as informações agregadas envolvidas no processo de tomada de decisão. Os sistemas evoluíram
para acompanhar a gerência de negócios.
Apesar da importância dos sistemas de informação no apoio a decisões estratégicas, os
resultados obtidos pelo uso da informação nos processos decisórios não têm sido satisfatórios.
Uma das prováveis causas das limitações dos sistemas de informação pode ser creditada à visão
unilateral da informação por parte dos responsáveis pelo desenvolvimento de metodologias de
análise estruturada de sistemas. Esta diferença explica as limitações dos sistemas de informação
para uso em decisões estratégicas.
É possível classificar os sistemas de informações em sistemas de processamento de transações
e sistemas de suporte à decisão. "Os sistemas de processamento de transações têm como
principal objetivo o registro acurado das operações e fatos relevantes das áreas de negócio. A
ênfase nesses sistemas é com a validação dos dados, visando maior qualidade e depuração das
bases de dados. Já os sistemas de suporte à decisão "são projetados para apoiar os gestores de
negócio no processo de tomada de decisão numa perspectiva de mais longo prazo, no trato da
informação, do que os sistemas de processamento de transações e envolvendo um maior
julgamento humano" (DHAR e STEIN, 1997).

Outras definições
Sistema de Informação (em inglês, Information System) é a expressão utilizada para descrever
um sistema automatizado (que pode ser denominado como Sistema de Informação
Computadorizado), ou mesmo manual, que abrange pessoas, máquinas, e/ou métodos
organizados para coletar, processar, transmitir e disseminar dados que representam informação
para o usuário.
Além disso, o termo também é utilizado para descrever a área de conhecimento encarregada
do estudo de Sistemas de Informação, Tecnologia da Informação e suas relações com as
organizações. Neste contexto, esta disciplina é comumente classificada como uma Ciência
Social Aplicada, ao contrário de sua disciplina correlata Ciência da Computação, considerada
uma Ciência Exata.
A área de conhecimento Sistemas de Informação é considerada pelos pesquisadores como uma
área multi ou trans-disciplinar, devido às inter-relações com outras área de conhecimento, tais
como Ciência da Computação, Administração, Economia, Sociologia, Direito, Engenharia de
Produção, Ciência da Informação e outras.
Um terceiro uso para a expressão Sistemas de Informação refere-se a um curso de graduação
cujo foco é o desenvolvimento e aplicação de Sistemas de Informação Computadorizados nas
organizações. O conteúdo deste curso abrange aspectos técnicos, gerenciais e sociológicos,
abrangendo, em linhas gerais, os conteúdos relevantes estudados na área de conhecimento
Sistemas de Informação.
As concepções mais modernas de Sistemas de Informação contemplam também os Sistemas
de telecomunicações e/ou equipamentos relacionados; sistemas ou subsistemas interconectados
que utilizam equipamentos na aquisição, armazenamento, manipulação, gestão, movimento, no
controle, na exposição, na troca, no intercâmbio, na transmissão, ou na recepção da voz e/ou
dos dados, e inclui o software e hardware utilizados. Em relação a esta última definição, é
comum nos meios acadêmicos a utilização do termo Tecnologias da Informação e
Comunicação (ICT - Information and Communication Technologies).
Um Sistema de Informações pode ser então definido como todo sistema usado para prover
informação (incluindo o seu processamento), qualquer que seja o uso feito dessa informação.
Um sistema de informação possui vários elementos inter-relacionados que coletam (entrada),
manipulam e armazenam (processo), disseminam (saída) os dados e informações e fornecem
um mecanismo de feedback.
Segundo a definição adotada pelo Ministério da Educação e Cultura brasileiro, o curso de
Sistemas de Informação estuda a computação como atividade-meio, ou seja, estuda a aplicação
da computação nas organizações. Esta definição é oposta à definição do MEC para os cursos
de Ciência da Computação e Engenharia da Computação, que estudam a computação como
atividade-fim.

Unidade 1.3. Contexto organizacional e tipos de informação numa

organização
Não é necessário dizer que ter um bom sistema de informações à disposição dos gerentes das
organizações no momento da tomada de decisões é fundamental em um ambiente competitivo.
Isso pressupõe a existência de uma estrutura informacional que atue agilmente e com
segurança, pois isso fortalece a atuação da organização.
A competição acirrada, actualmente, permeia qualquer atividade empresarial, acentuada nos
negócios, exige uma gestão eficiente, bom visão estratégica e baseada na utilização de
tecnologia de informação. Esta fornece recursos tecnológicos e computacionais para a geração
de informações e os sistemas de informação, cada vez mais sofisticados, alterando a forma e o
processo de fazer-se negócios.
Gerar relatórios que consolidem as informações para a tomada de decisões é apenas uma das
tarefas de um sistema de informação gerencial. Ele deve ir além. Deve fornecer informações
estruturadas e diversificadas que sejam relevantes para o processo decisório.
Uma organização exige dois tipos de informação que se complementam, mas de natureza
distinta: as operacionais e as gerenciais. Para Mülbert e Ayres (2007) as informações
operacionais são utilizadas no momento de se processar as atividades rotineiras ou mesmo cada
transação, o que gera um volume enorme de dados. Já, as informações gerenciais contemplam
o resumo das informações operacionais, e possibilita ao decisor estar a par dos fatos e eventos
tendo assim, melhores condições para decidir diante de uma situação.
A perspectiva mais abrangente que impera nas organizações na atualidade é de que um sistema
de informação é composto por tecnologia, organizações e pessoas. Chamada de abordagem
sociotécnica (MÜLBERT e AYRES, 2007), observada na Figura abaixo, apresentada a seguir.

Ao analisarmos a Figura, acima, percebemos que as organizações são vistas como locais de
procedimentos operacionais e administrativos, que podem estar formalizados, escritos ou
registrados, ou serem originários de práticas informais. Esses procedimentos normalmente são
passados para um sistema de informação. As pessoas são vistas como os usuários que se
aproveitam das informações de um sistema para executar o seu trabalho. São elas que inserem
entradas no sistema, utilizam suas saídas e tornam o sistema todo produtivo. Eles devem estar
preparados para realizar as suas tarefas e usar eficientemente os sistemas de informação, pois
a sua atitude afeta profundamente o desempenho organizacional. A desmotivação e um
ambiente de trabalho não adequado contribuem para uma atitude negativa perante o uso da
informação disponível. Portanto, os sistemas devem ser construídos às necessidades daqueles
que os utilizam, e não o contrário (MÜLBERT e AYRES, 2007).
Podemos afirmar, então, que se a organização tiver as melhores condições em termos de
procedimentos, pessoas e tecnologia a possibilidade de ter um excelente sistema de
informações é grande e isso é de extrema importância em um cenário tão competitivo que se
vive actualmente no mundo. Esses sistemas devem proporcionar ganhos ou no mínimo
equivaler ao investimento realizado neles.
Os sistemas de informação desempenham 3 papéis vitais em qualquer tipo de organização:
● Suporte de seus processos e operações
● Suporte nas tomadas de decisões de seus funcionários e gerentes
● Suporte em suas estratégias em busca de vantagem competitiva

Para classificarmos os vários modos de sistemas de informação usaremos a fornecida por

Mülbert e Ayres (2007), mas diversas classificações com nomenclaturas diferentes podem ser
encontradas, sem, contudo uma invalidar a outra, pois na essência todas convergem. Elas
podem ser categorizadas por abrangência organizacional, áreas funcionais principais, e tipo de
suporte que proporcionam (MÜLBERT e AYRES, 2007, p. 99-103):
Classificação por abrangência organizacional: ênfase na abrangência que o sistema de
informação tem em relação à estrutura organizacional. São sistemas construídos para pessoas
específicas da empresa, ou para atender grupos específicos como divisões e departamentos, ou
para dar suporte à empresa como um todo, e até mesmo sistemas envolvendo várias empresas.
Operam isoladamente ou interligados.
Sistemas de informação pessoal: são aplicações que os profissionais usam para melhorar sua
produtividade que dão suporte às comunicações, análise e tomada de decisão, e registro e
monitoramento das atividades.
Sistemas de informação de grupo ou departamental: facilitam o processo e o fluxo de
informação de um grupo de trabalho. É construído, normalmente, para atender a uma função
específica. Podem ser aplicativos para determinadas áreas funcionais da organização.
Sistemas de informação empresarial ou corporativo: dão suporte a todas as divisões e outras
unidades de uma organização, integrando as ações desenvolvidas pelas diversas unidades
empresariais, de modo a facilitar o fluxo de informação entre elas. Para viabilizar esta
integração, tais sistemas de informação envolvem bancos de dados centralizados,
compartilhados pelas várias unidades usuárias.
Sistemas de informação Interorganizacional: sistemas que conectam duas ou mais empresas.
Estes sistemas são comuns entre parceiros de negócios e usados extensivamente no comércio
eletrônico, frequentemente via extranet. Sistemas de informação interorganizacionais que
interligam uma corporação internacional ou multinacional, cujas instalações estão localizadas
em dois ou mais países, são chamados de Sistemas de informações globais.
Classificação por área funcional: os sistemas de informação podem, também, ser
classificados pela especialidade funcional a que servem. São sistemas voltados a atender as
principais macroatividades das empresas: operações e produção, vendas e marketing, finanças
e contabilidade, e recursos humanos.
Sistemas de informação industrial: tratam do planejamento, desenvolvimento e manutenção
das instalações de produção; do estabelecimento dos objetivos de produção; da aquisição,
armazenamento e disponibilidade dos materiais de produção; e do planejamento do
equipamento, instalações, materiais e mão de obra necessários a produção.
Sistemas de vendas e marketing: acompanham as tendências de vendas, monitoram o
desempenho dos concorrentes; dão suporte a pesquisas de mercado, campanhas promocionais
e de propaganda e decisões quanto a preços; permitem análises de desempenho das vendas e
do pessoal de vendas; ajudam na localização e contato de clientes em potencial, no
acompanhamento das vendas, no processamento dos pedidos e no fornecimento do serviço de
suporte ao cliente.
Sistemas de finanças e contabilidade: estabelecem objetivos de investimentos em longo prazo
e fornecem previsões do desempenho financeiro da empresa; ajudam a visualizar e controlar
os recursos financeiros; monitoram o fluxo de caixa, contas a receber e a pagar, e emitem
relatórios de balanço e livros fiscais.
Sistemas de recursos humanos: identificam requisitos da força de trabalho em termos de
habilidades, nível de instrução, tipos e números de posições; também ajudam a acompanhar e
analisar o recrutamento, o direcionamento e o desligamento de empregados; e, registram a
seleção e a colocação dos empregados.
Luppin (2012) descreve os tipos de sistemas de informação que podem ser utilizados pelos
diversos níveis hierárquicos e de decisão em uma organização da seguinte forma:
Sistemas de Processamento de Transações (SPTs): sistemas integrados que atendem o nível
operacional são computadorizados, realizando transações rotineiras como folha de pagamento,
pedidos etc.. Os recursos são predefinidos e estruturados, e é por meio deles que os gerentes
monitoram operações internas e externas a empresa. São fundamentais e críticos, pois se
deixarem de funcionar podem causar danos às atividades rotineiras do negócio.
Sistemas de Trabalhadores de Conhecimento (STCs) e Sistemas de Automação de Escritório
(SAEs): atendem necessidades do nível de conhecimento envolvendo trabalhadores de
conhecimento, pessoas com formação universitária como engenheiros e cientistas e
trabalhadores de dados, como secretárias, contadores, arquivistas etc.. Diferenciam-se, pois
trabalhadores de conhecimento criam informações e trabalhadores de dados usam informações
prontas. A produtividade destes é aumentada com o uso dos sistemas de automação de
escritório que coordenam e comunicam diversas unidades, trabalhadores, e fontes externas
como clientes e fornecedores. Eles manipulam e gerenciam documentos, programação e
comunicação, envolvendo além de textos, gráficos etc., hoje publicados digitalmente em forma
de portais na internet e intranet para facilitar o acesso e distribuição de informações.
Sistemas de Informação Gerenciais (SIGs): dão suporte ao nível gerencial através de relatórios,
processos correntes, histórico através de acessos online, orientados a eventos internos,
apoiando o planejamento controle e decisão, dependem dos SPTs para aquisição de dados,
resumindo e apresentando operações e dados básicos periodicamente.
Sistemas de Apoio a Decisão (SADs): atendem também o nível de gerência ajudando a tomar
decisões não usuais com rapidez e antecedência a fim de solucionar problemas não
predefinidos, usam informações internas obtidas dos SPTs e SIGs e também externas, como
preços de produtos concorrentes etc.. Têm maior poder analítico que os outros sistemas sendo
construídos em diversos modelos para analisar e armazenar dados, tomar decisões diárias. Por
isso, possuem uma interface de fácil acesso e atendimento ao usuário, são interativos, podendo-
se alterar e incluir dados através de menus que facilitam a entrada deles e obtenção de
informações processadas.
Sistemas de Apoio ao Executivo (SAEs): atendem ao nível gerencial, os gerentes seniores que
tem pouca ou nenhuma experiência com computadores, servem para tomar decisões não
rotineiras que exigem bom senso avaliação e percepção. Criam um ambiente generalizado de
computação e comunicação em vez de aplicações fixas e capacidades específicas. Projetados
para incorporar dados externos como leis e novos concorrentes, também adquirem informações
dos SIGs e SADs a fim de obter informações resumidas e úteis aos executivos, não só sob a
forma de textos, mas também gráficos projetados para solucionar problemas específicos que se
alteram seguidamente, através de modelos menos analíticos. Ele é formado por estações de
trabalho, menus gráficos, dados históricos e de concorrentes, bancos de dados externos, e
possuem fácil comunicação e interface.
Ainda, segundo Luppi (2012), os Sistemas de Informação relacionam-se uns com os outros a
fim de atender os diversos níveis organizacionais. E isto sendo os SPTs a fonte de dados mais
importante para os outros sistemas, os SAEs são os recebedores de dados de sistemas de níveis
inferiores, os outros trocam dados entre si. Também atendem diferentes áreas funcionais, por
isso é importante e vantajoso a integração entre eles para a informação chegar às diferentes
partes de uma organização. Mas, isto tem um alto custo de implantação e de manutenção, é
demorado e complexo, por isso cada organização deve interligar os setores que acha necessário
para atender suas necessidades e dentro das suas possibilidades.
Sistemas de Informação de Marketing (SIMs): responsáveis pela venda e comunicação do
produto ou serviço. Procuram identificar o que os consumidores ou usuários querem consumir
ou utilizar e também os melhores compradores, criando e mostrando novos produtos ou
serviços por meio de propagandas e promoções. Além disso, auxiliam no contato aos clientes,
oferecem novos produtos e serviços, fecham pedidos, acompanham a transação. No nível
estratégico, eles monitoram e apoiam novos produtos e oportunidades e identificam o
desempenho dos concorrentes. No nível tático, dão suporte a pesquisas de mercado, campanhas
promocionais e determinação e preços, analisando o desempenho do pessoal de vendas dando
suporte ao atendimento e localização de clientes.
Sistemas de Informação de Fabricação e Produção (SIFPs): responsáveis pela produção de bens
e serviços tratam do planejamento, desenvolvimento, manutenção e estabelecimento de metas
de produção aquisição e armazenagem de equipamentos, matérias primas para fabricar
produtos acabados. Ajudam a localizar novas fábricas e investir em novas de tecnologias de
fabricação, analisam e monitoram custos, recursos de fabricação e produção, criam e
distribuem conhecimentos especializados orientando o processo de produção, e também
monitoram e controlam a produção.
Sistemas de Informação Financeira e Contábil (SIFCs): responsáveis pela administração de
ativos financeiros visando o retorno ao investimento. A função Finanças encarrega-se de
identificar novos ativos financeiros (ações títulos e dividas) através de informações externas.
Já, a função Contabilidade é responsável pela manutenção e gerenciamento de registros
financeiros (recibos folha de pagamento etc.)
Sistemas de Recursos Humanos (SRHs): responsáveis por atrair, aperfeiçoar e manter a força
de trabalho da empresa esses sistemas ajudam a identificar funcionários potenciais e selecionar
novos, desenvolver talentos e potencialidades. Identificam habilidades, escolaridade e tipos de
cargos que atendem os planos de negócio. Monitoram o recrutamento, alocação e remuneração
de funcionários, descrevem funções relacionadas ao treinamento, elaboração de planos de
carreira, relacionamentos hierárquicos entre funcionários, registram o recrutamento e
colocação de funcionários da empresa.
Para Luppi (2012), além de SIs para coordenar atividades e decisões da empresa, por meio de
Sistemas Integrados e Processos de Negócios automatizando, assim, o fluxo de informações,
também necessitam de Sistemas para Gerenciamento de Relações com Clientes (CRM) e da
cadeia de suprimento (SCM) para coordenação de processos que abrangem diferentes funções
empresariais, inclusive compartilhadas com clientes e outros parceiros da cadeia de
suprimento.
O uso de diversos SIs não integrados em uma organização pode dificultar o acesso e
compreensão de informações por parte da gerência e outros níveis organizacionais ou até
mesmo apresentar a informação de forma errada e incompreensível causando grandes danos.
Por isso, muitas empresas estão montando ERPs – Enterprise Resource Program (Sistemas de
Informação de Planejamento Empresarial) que modelam e automatizam os processos de
negócio atendendo todos os níveis da empresa, coletando e armazenando, em um único arquivo,
os principais dados dos processos de negócio. Estes podem ser acessados por todos os setores
da empresa proporcionando aos gerentes informações precisas para coordenação das
informações diárias da empresa com ampla visão dos processos de negócio e fluxo de
informações. (LUPPI, 2012).

Tipos de Sistemas de Informação

Em termos conceituais , os sistemas de informação podem ser classificados de maneiras
diferentes. Algumas delas veremos a seguir.
Sistema de Apoio a Operações: existem 3 tipos principais de sistemas de apoio a decisões.
São eles:
Sistema de Processamento de Transações: o objetivo deste tipo de sistema é reduzir custos
através de automatização de rotina. Um dos primeiros sistemas empresariais a ser
computadorizado foi o sistema de folha de pagamento.Como estess sistemas tratavam e
processavam transações, foram chamados de sistemas de processamento de transações.
Sistema de Controle de Processos: monitoram e controlam processos físicos.
Sistemas Colaborativos: aumentam as comunicações e produtividade das equipes e grupos de
trabalho.
Sistema de Apoio Gerencial: existem 3 tipos principais de sistema de apoio gerencial. São
eles:
Sistema de informação gerencial: foram criados a partir da decada de 60 e são caracterizados
pelo uso do sistema de informação para produzir relatórios gerenciais.
Sistema de apoio a decisão: nas decadas de 70 e 80, grandes aperfeicoamentos da tecnologia
resultaram em sistemas de informação que custavam menos e eram muito mais
poderosos.Pessoas de todas as áreas da empresa passaram a usar microcomputadores para fazer
um variedade de tarefas e não dependiam mais de um setor específico para realizar as suas
atividades.Neste período foi constatado que um sistema de informação baseado em computador
poderia dar apoio adicional a tomade de decisão.
Sistema de Informação Executiva: fornecem informações críticas em quadros de fácil
visualização para uma multiplicidade de gerentes .

Unidade 1.3. EXERCÍCIOS INTEGRADOS das unidades deste tema

Bibliografia

VER EM ANEXO
TEMA II: DESENVOLVIMENTO NO CONTEXTO DA ENGENHARIA
DE SOFTWARE E RISCOS

Unidade 2.1. INTRODUÇÃO. Engenharia de Software e Riscos

As organizações vivem atualmente grande competitividade comercial, demandando rápidas

decisões, melhor alocação de recursos e uma clara definição de foco. Em um ambiente de
desenvolvimento de software típico não é diferente. Vários tipos de projetos são propostos,
com diferentes objetivos, em que é preciso gerenciar estrategicamente de acordo com as metas
organizacionais. Em gerenciamento de projetos, para garantir o sucesso das metas
organizacionais e dos objetivos definidos do projeto, é preciso identificar fatores positivos e
adversos, considerados críticos. Os fatores positivos, também chamados oportunidades, são
diferenciais em um ambiente mercadológico e tecnológico competitivo, e o tratamento dos
fatores adversos, tidos como riscos, favorecem o alcance das oportunidades identificadas. Os
riscos possuem diferentes significados, como os de ordem física, estrutural, econômica, social
e ambiental. Podendo ainda se desdobrar em diversos componentes e sucessivos níveis de
detalhamento. As incertezas fazem parte do cotidiano humano. Desde os primórdios o homem
procura defender-se dos riscos que o cercam, galgando níveis de satisfação das necessidades
básicas, de segurança e culminando nas necessidades de cunho puramente profissional. As
pessoas, em sua grande maioria, diariamente fazem escolhas, com graus diferenciados de
riscos, mas também com um alto grau de oportunidade e benefícios associados. Atualmente
todos os ramos da atividade humana dependem de alguma forma da utilização de software para
operar, dar suporte, controlar equipamentos e fluxos de informações, gravar ou processar
atividades. A área de Engenharia de Software tem promovido vários estudos com a finalidade
de produzir modelos de melhoria, processos, métodos e ferramentas para aumentar a
probabilidade de sucesso na execução de projetos de software, garantindo a qualidade de seus
produtos e minimizando possíveis problemas associados [SEI 2001, PMI 2004]. Portanto, na
capacidade de prevenir e controlar essas variáveis pode estar o diferencial para gerir os riscos
de projetos na indústria de software. Todo projeto de software enfrenta problemas de qualidade,
de cronograma, e de custo que estão sendo afetados por riscos que são inesperados, não
planejados ou ignorados simplesmente pela falta de conhecimento. Através de perspectivas
globais de negócios muitas organizações estão tornando-se cada vez mais dependentes do
sucesso ou do fracasso dos softwares que desenvolvem. Neste contexto, a Gerência de Riscos
não é apenas baseada em boas práticas para o desenvolvimento de software, mas sim, boas
práticas para gerir negócios.

Riscos em Engenharia de Software

Ainda que o conceito de risco esteja bastante associado a perigos e impactos negativos, já vem
sendo utilizado como "exposição a conseqüências da incerteza", sendo cada vez mais aplicado
tanto no gerenciamento de perdas como no de ganhos potenciais. Nas próximas seções serão
tratados os conceitos relativos à incerteza, oportunidade e riscos.

Incerteza, Oportunidade e Risco

Um fator comum que provoca preocupação na análise de projetos e no seu investimento é a
incerteza. Surge como uma das conseqüências da falta de controle absoluto dos eventos que
acontecerão num futuro próximo. Pode-se fazer a previsão sobre o comportamento de
determinados eventos, mas não se pode determinar exatamente quando e em que intensidade
eles deverão ocorrer. Exemplos desses eventos são os comportamentos futuros da economia de
um país, as vendas futuras de determinados produtos e sua aceitação no mercado, o desgaste e
custos de manutenção de equipamentos, entre outros.
Considerando que a noção de risco associada à possibilidade de dano, perda ou estrago é de
conhecimento claro e direto, alguns autores fazem uma distinção teórica entre o risco e
incerteza. Marshall [Marshall 2002] e Knight [Knight 1921] diferenciam risco – resultados que,
embora não certos possuem probabilidades quantificáveis pela experiência ou dados
estatísticos e para a qual é possível fazer uma estimativa – de incerteza, quando a ausência de
experiências ou ocorrências anteriores impossibilita quantificar adequadamente o resultado.
No entanto, conforme M. H. Simonsem [Simonsem 1994], em seu livro Dinâmica
Macroeconômica (1994: p. 399), “Risco é quando a variável aleatória tem uma distribuição de
probabilidades conhecida e, Incerteza, quando essa distribuição é desconhecida”.
No contexto da Gerência de Projetos, o risco de projeto pode ser definido como o efeito
cumulativo das incertezas que adversamente afetam os objetivos do projeto. Em outras
palavras, é o grau de exposição a eventos negativos e a probabilidade de ocorrência e seu
impacto nos objetivos do projeto, expressos em termos de escopo, custo, prazo e qualidade.
A meta principal do gerenciamento de riscos de projeto é afastar as incertezas relacionadas aos
riscos e direcionar os projetos para oportunidades. Outra forma de tratar os riscos é listar fatores
de riscos que são variáveis que podem tornar-se riscos em um baixo, médio ou alto grau de
incidência no ambiente.
Categorias e Tipos de Riscos
Risco na área de software foi representado de forma sistemática por Barry W. Boehm, em 1988,
através do Modelo Espiral [Boehm et al 2004], que tem como princípio ser incremental e
dirigido à análise de riscos. O desenvolvimento incremental é uma estratégia para a obtenção
de progresso em pequenos passos, pela divisão de um problema em subproblemas e a posterior
combinação das soluções encontradas (alternativas definidas).
Atualmente, a área que trata riscos na Engenharia de Software evoluiu, passando de uma
análise dentro das fases do modelo de desenvolvimento de software para se tornar uma gerência
que permeia todos os processos do ciclo de vida do software (o ciclo de vida do software vai
desde a concepção de idéias até a descontinuidade do produto de software).

Risco de software pode ser caracterizado como [PMI 2004]:

Riscos de Projeto de Software. Define os parâmetros operacionais, organizacionais e
contratuais do desenvolvimento de software. Inclui limites de recursos, interfaces,
relacionamentos com fornecedores ou restrições de contratos.
Riscos de Processo de Software. Relacionam-se os problemas técnicos e de gerenciamento.
Nos procedimentos de gerência podem-se encontrar riscos em atividades como: planejamento,
definição e contratação de equipe de trabalho, garantia de segurança e configuração de
gerência. Nos procedimentos técnicos, podem-se encontrar riscos nas atividades: análise de
requisitos, projeto, codificação e testes, por exemplo.
Riscos de Produto de Software. Contém as características intermediárias e finais do produto.
Estes tipos de riscos têm origens nos requisitos de estabilidade do produto, desempenho,
complexidade de codificação e especificação de testes.
Muitas classificações são encontradas na literatura relacionada à Gerência de Projetos
[Gustafson 2002, PMI 2004], uma delas é o uso de taxonomia de riscos (Taxonomy-Based Risk
Identification) como a apresentada pelo Instituto de Engenharia de Software (SEI - Software
Engineering Institute), onde os riscos são classificados dentro de categorias para melhor
entendimento de sua natureza. Alguns estudos e abordagens na literatura, que tratam a área de
Gerência de Riscos, evoluíram, ou mesmo adaptaram, as categorias de riscos inicialmente
apresentadas na taxonomia proposta pelo SEI [Costa et al 2005, Gusmão et al 2005 e Webster
et al 2005].
As categorias de riscos favorecem a identificação dos riscos em um ambiente, promovendo
uma classificação e organização dos riscos identificados em grupos lógicos. Alguns exemplos
de categorias de riscos e suas abrangências estão relacionados na Tabela 1.
Não existe uma diferenciação clara entre os termos “classificação e categorização de riscos”
na literatura de Engenharia de Software. Em muitas abordagens são utilizados como sinônimos.
O próprio Guia PMBOK (Project Management Body of Knowledge), tanto na sua segunda
quanto terceira edições, além de sub-classificar os riscos, os organiza em categorias [PMI
2004].

Categoria Descrição
Técnico e Riscos associados a aspectos técnicos do projeto. Pode estar
Desempenho relacionado ao grau de inovação tecnológica do projeto em
questão.

Negócio Risco associado ao marketing ou ao tempo de lançamento de

releases dos produtos ou novas versões. Também pode estar
associado às informações dos competidores.

Gerência de Projeto Riscos associados com o processo de gerenciamento de projeto,

maturidade organizacional e habilidade.

Processo Riscos associados ao processo de negócio ou outro processo

que possa impactar a organização, o usuário (cliente) ou o
projeto.

Gerência de Riscos e Tomada de Decisão

A incerteza é um fator que pode dificultar a tomada de decisão racional. A maioria das decisões,
sobretudo aquelas importantes, está baseada em algum tipo de estimativa, colocando a
incerteza como elemento do processo decisório. E mesmo que a situação não exija estimativa,
deve-se considerar a insuficiência das informações para a tomada de decisão.
Um risco só deveria ser tratado quando o seu benefício potencial (oportunidade) para a
organização e as chances de ganhos excedesse o valor do custo reparador de uma decisão mal
sucedida e as chances de perdas dentro de uma margem satisfatória. Para que isso possa
acontecer é preciso que o gerente de projeto, ou o profissional responsável pelo risco, encontre
as respostas para algumas questões, tais como o motivo pelo qual o risco deve ser tratado; quais
são os ganhos associados ou o que poderá ser perdido; as reais chances de sucesso (ou fracasso);
o que poderá ser feito se os objetivos definidos não forem alcançados; se o custo de estratégias
de tratamento vale o esforço para um risco em específico.
Dessa forma, torna-se importante fazer uma análise do grau de incerteza existente no processo
de decisão, ou seja, procurar uma estimativa dos riscos envolvidos. Deve-se ressaltar a
importância do uso de abordagens qualitativa e quantitativa na análise e desenvolvimento dos
investimentos, de uma empresa, seja ela de pequeno, médio ou grande porte [Moura et al 2004].
A evolução das organizações, a complexidade das demandas dos mercados e o processo de
globalização tornaram a utilização das práticas das finanças, as estratégias e o marketing cada
vez mais desafiantes. Dominar e compreender a aplicação de técnicas de análise de
oportunidade e incerteza, quantitativamente ou qualitativamente, é imposição real para a
sobrevivência organizacional, quer pelas implicações do trabalho assalariado, quer pelas
operações de compra e venda, quer pelos investimentos e decisões associadas.
Geralmente, quando se fala em correr riscos, pensa-se logo em perdas ou sacrifícios
financeiros. Muitos riscos fazem parte de nosso dia a dia de tal forma, que mal os levamos em
consideração, ao invés disso, as reações muitas vezes são subconscientes.
Ao atravessar uma rua, o pedestre deve olhar para ambos os lados e quando não houver tráfego,
atravessará. Caso esteja com pressa, pode assumir riscos e atravessar entre os veículos, quando
aparecer uma chance. Se o trânsito estiver pesado, prudentemente, deve se dirigir às áreas de
cruzamento de pedestre, garantindo sua passagem com segurança.
Caberá à gerência optar por assumir estes riscos e enfrentar o desafio. Tudo vai depender do
contexto não significando que outros riscos não serão visualizados ou percebidos.

Gerência de Riscos versus Gerência de Projetos

A Gerência de Riscos tem uma aplicabilidade bastante ampla em ambientes organizacionais.
Quando se fala em gerir projetos, é inevitável que se fale em gerir riscos. Por este motivo,
muitas vezes, é difícil definir limites entre as duas gerências.
Ainda não existe um consenso sobre o relacionamento entre a gerência de projetos e a gerência
de riscos. Normas, padrões e modelos são apresentados, na área de Engenharia de Software,
mas não tratam esse relacionamento de forma explícita. Não existe um padrão que descreva o
elo existente entre a Gerência de Riscos e a Gerência de Projeto, nem tão pouco apresente o
objetivo do processo e das atividades da Gerência de Riscos. Isto evidencia a imaturidade da
comunidade de Engenharia de Software, onde as normas e modelos deveriam consolidar este
conhecimento já existente.
Uma das áreas de aperfeiçoamento futuro da Gerência de Projetos, segundo David Hillson
[Hillson 2005] é a integração da Gerência de Riscos e a cultura organizacional. Esta visão
enfoca o uso da Gerência de Riscos como parte integral do negócio organizacional sendo um
processo construtivo e não repreensivo.
A falta de padronização dificulta o entendimento, a definição de processos e papéis em relação
à Gerência de Riscos, o cumprimento dos objetivos organizacionais, pois não se tem uma visão
integrada. A Tabela 2 apresenta uma coletânea de visões, capturadas na literatura da área de
Engenharia de Software, sobre os possíveis relacionamentos existentes entre a Gerência de
Projetos e a Gerência de Riscos de Software.
De acordo com Stephen Grey existem três visões, de uma forma geral, para o relacionamento
entre a Gerência de Riscos e a Gerência de Projeto [Grey 1995]:
● Dependência – A Gerência de Riscos é vista como parte da gerência de projeto. A
execução é de responsabilidade do gerente de projeto ou é delegada a outro membro da
equipe de projeto. Desta forma, as atividades de gestão de riscos são realizadas em nível
de projeto na organização (nível operacional);
● Existência – A motivação para a execução de um projeto é a gerência de seus riscos. A
existência da gerência de projetos está condicionada à Gerência de Riscos. Se não existe
risco, não existe necessidade da gerência de projeto. Neste caso tornar-se-ia uma mera
atividade administrativa. Este tipo de abordagem é comumente conhecido como
“gerência de projetos dirigida a riscos”;
● Independência – através desta visão, a Gerência de Riscos é um processo distinto e de
apoio para todos os projetos da organização, desde o nível estratégico até o operacional.
Nos dias atuais, os ambientes organizacionais demandam uma crescente dinamicidade e
proatividade nas respostas aos problemas e fatores de riscos associados, isso devido à grande
influência exercida pela globalização, pelas inovações e mudanças não só internamente, mas
também externamente. Decorrente dessa nova realidade, funções relacionadas à gestão de
riscos estão sendo incorporadas nas organizações traduzindo um empenho em manter boas
práticas nos ambientes corporativos.
Atualmente, gerir riscos envolve o estabelecimento de uma cultura e infra-estrutura adequadas,
bem como a aplicação de uma metodologia lógica e sistemática para administrar os riscos
associados a qualquer atividade, função, processo ou projeto.
Uma limitação atual da Gerência de Riscos é a quantidade pequena de estudos práticos
divulgados, apresentando indicadores de sucesso dos projetos de software desenvolvidos,
conforme relato em pesquisadas disponibilizadas na área [Coelho 2004, Leopoldino 2004].
Cada dia fica mais clara a percepção de que gerenciar projetos é gerenciar riscos. Mas isto não
basta. É necessário que o gerente de projetos seja capaz de identificar problemas concretos e,
de preferência, com a probabilidade de sua ocorrência. Além disso, há riscos e riscos!
Determinados tipos de projetos são intrinsecamente mais arriscados do que outros.
Possuir uma visão integrada do risco é fundamental para as organizações que buscam o
desenvolvimento e a continuidade do negócio, e ainda dependem de uma infra-estrutura
operacional sob risco controlado.
Uma grande dificuldade atual para o gerenciamento dos riscos do processo de desenvolvimento
de software é a existência de diversas visões parciais sobre as técnicas e formas de
gerenciamento. Quando transportadas para a prática estas visões podem trazer muitos
problemas e ineficiências. Isto porque qualquer desenvolvimento, por maior a hegemonia de
um determinado conteúdo tecnológico, implica em conhecimento diversificado. Cada visão
parcial carrega consigo também um vocabulário e determinados valores próprios, dificultando
a integração entre os diversos profissionais pela ausência de padronização.
Enfrentar esta situação depende da construção de uma imagem única e integrada do processo
de gerenciamento, em especial, da Gerência de Riscos. Nisto, percebe-se a importância da
disseminação dos conceitos de gestão nos ambientes de desenvolvimento de software, como
também a definição de um processo que suporte as atividades de gerenciamento dos riscos dos
projetos.
A realização e concretização dos projetos organizacionais estão associadas a eventos
inesperados e incertos, é por tal motivo que a Gerência de Riscos tem sua importância,
permitindo avaliar a viabilidade das atividades a serem realizadas, bem como os custos e
benefício (oportunidades) das mesmas.
Este artigo apresentou uma visão inicial sobre a área de gerenciamento de riscos, através de
conceitos e fundamentos que são considerados chave na área de Engenharia de Software.
Dentro deste contexto, nas próximas edições, serão apresentados alguns modelos e abordagens
para gerenciamento de riscos; em seguida ferramentas, técnicas e métodos de apoio e, por fim,
serão tratadas algumas tendências, como maturidade de projetos, portfólio e gerenciamento de
riscos em ambientes de múltiplos projetos.
Unidade 2.2. Riscos ligados aos requisitos

O processo Engenharia de Requisitos possui certa complexidade no seu desenvolvimento,

através dele que o analista começa a projetar o sistema, nessa fase inicial, diversos riscos devem
ser considerados e prevenidos.
As empresas, organizações, clientes não compreendem o quão importante é este processo, para
eles é um tempo demasiadamente longo e custoso, pois possuem ansiedade na finalização do
sistema.
Umas das maiores dificuldades no processo de Engenharia de requisitos é entender o que os
contratantes, usuários esperam do sistema, qual a sua perspectiva do sistema, tornar aquilo que
é imaginado pelo usuário em um sistema funcional que atenda todas as suas exigências ou pelo
menos as exigências viáveis. Quando o objetivo do projeto estiver em concordância com os da
empresa então esse projeto terá uma melhor aceitação por parte da empresa.
Essa dinâmica, comunicação com os stakeholders deve está presente em todas as fases desse
processo, é através das informações que as partes interessadas fornecem ao analista que os
requisitos são identificados, analisados e negociados, documentados e paralelamente a essas
atividades, eles são geridos. A incompreensão desses requisitos e a falta dessa dinâmica geram
riscos e conseqüentemente prejuízos, como perda de tempo e de dinheiro, o que pode acarretar
atrasos nos prazos e até anulação de contrato.
A proposta deste trabalho não visa explicar o processo de Engenharia de Requisitos, mas sim
apresentar a sua complexidade e como um descuido na execução do mesmo pode acarretar
erros no desenvolvimento do sistema e até mesmo a sua não conclusão como também
apresentar os pontos críticos existentes na produção e gerência de requisitos.

Produção de Requisitos e seus pontos críticos

Leffingwell (2003) ressalta que 40% a 60% de todos os problemas encontrados em um projeto
são causados por falhas no processo de requisitos (ausência ou a não utilização de um processo
de definição de requisitos adequado). A ineficácia de um processo de requisitos gera a produção
de documentos de requisitos que não atendem as necessidades reais dos clientes.
Os requisitos são a base para o desenvolvimento de software, se essa base for construída de
forma inadequada logo o software gerado por ela será de má qualidade.
A produção de requisitos se divide em algumas atividades: Identificação, Análise e
Negociação, Documentação e Validação de requisitos. Essas atividades possuem fatores
considerados críticos no seu desenvolvimento, esses fatores têm forte potencialidade, ou seja,
o grau de risco é maior, na fase inicial do projeto (identificação de requisitos) e também na
compreensão dos requisitos, objetivos do sistema (análise e negociação de requisitos).
Antes de começar a identificação de requisitos o analista deve verificar a viabilidade do projeto
e também fazer uma análise de risco, seria um esforço desnecessário começar a fazer uma
identificação de requisitos se o projeto não for aprovado, considerado viável.

A VIABILIDADE DO PROJETO E A ANÁLISE DE RISCOS

De acordo com Pressman (2006) se o risco do projeto for grande, a viabilidade de se produzir
um software de qualidade é reduzida. Quanto menor a taxa de risco de um projeto maior a
possibilidade de se produzir um software com qualidade, para resolver essa questão um Estudo
de Viabilidade deve ser elaborado. Um Estudo de Viabilidade tem por objetivo de verificar se
as necessidades do cliente podem ser satisfeitas, se as tecnologias de software e hardware atuais
dão suporte para realização do mesmo, verifica-se também o orçamento para execução do
projeto e quais serão os benefícios alcançados. Para que um projeto possa ser considerado
viável é necessário verificar os riscos que ameaçam o seu desenvolvimento. Esses riscos
precisam ser identificados e assim tratados, através dessa identificação poderá ser feita uma
análise a fim de sanar ou diminuir a sua potencialidade. No Estudo de Viabilidade, fatores
como: falhas de equipamentos, perda de pessoal, abandono de profissionais, ferramentas que
não podem ser utilizadas entre outros problemas, precisam ser considerados, por isso a
importância de se fazer um Estudo de Viabilidade concomitantemente com uma Analise de
Risco, quanto mais cedo esses riscos forem tratados melhor. O Estudo de Viabilidade se divide
em três categorias, viabilidade técnica, econômica e organizacional. Na Viabilidade Técnica o
analista deve se preocupar com a possibilidade de construir o sistema. Deve ser feito um estudo
da função, do desempenho e das restrições que possam afetar a capacidade de se conseguir um
sistema aceitável (PRESSMAN, 2006). A viabilidade Econômica tem como finalidade
identificar o risco financeiro associado ao projeto é onde se avalia a relação custo-benefício
para isso alguns fatores precisam ser considerados como a estratégia de renda corporativa a
longo prazo; o impacto sobre outros centros de lucro ou produtos; e o custo dos recursos
necessários ao desenvolvimento e crescimento em potencial de mercado. Uma pesquisa de
mercado deve ser realizada, principalmente se o ramo de atuação da empresa for instável, e
costumeiramente sofre por várias mudanças que possam afetar o sistema. A Viabilidade
Organizacional em essência é uma análise que tenta responder à seguinte pergunta: “Se nós
construirmos, ele será usado?” (DENNIS & WIXON, 2005) Se o objetivo do projeto estiver
em conformidade com o objetivo da empresa, então esse projeto terá uma melhor aceitação das
partes interessadas, ou seja, ele será usado. A usabilidade do software é um fator importante,
averigua-se aqui se os usuários em questão precisarão de algum tipo de treinamento para
familiarizar-se com o sistema. Solicitações freqüentes de alteração no sistema, necessidades
não observadas, usuários que não entendem os requisitos e falta de comunicação entre analista
e usuários são alguns problemas que trazem riscos ao desenvolvimento do projeto, exatamente
pela não observação da usabilidade do software. Ao avaliar os aspectos, técnicos, econômicos
e organizacionais de uma empresa e o seu ramo de atuação o analista conseguirá obter uma
análise de risco mais detalhada e terá assim maior probabilidade de solucionar eventuais
problemas que possam vir a acontecer durante e posteriormente o desenvolvimento do seu
sistema.

IDENTIFICANDO CONFLITOS
A resolução de conflitos sem dúvidas é uma das tarefas mais difíceis de executar, normalmente
esses conflitos estão relacionados à: comunicação entre analista e o cliente, a complexidade do
sistema a ser desenvolvido e as mudanças que podem ocorrer antes mesmo de terminar o
processo de análise de requisitos. Uma das formas de solucionar esses conflitos é determinar a
prioridade dos requisitos junto ao cliente, alguns requisitos são considerados mais urgentes do
que outros, então a parti dele pode se montar uma hierarquia de requisitos. Fazer uma
hierarquização requisitos e subrequisitos é uma solução que pode ser usada para resolução de
alguns conflitos, desta forma é possível identificar como os requisitos estão interligados,
avaliar as dependências desses requisitos. Outra técnica que pode auxiliar ao analista na solução
de conflitos é o checklist e pode ser usada como ferramenta para justificar a prioridade de um
requisito. Checklist é uma lista de questões usadas para avaliar os requisitos. O requisito é
mesmo necessário? O requisito é testável? O requisito poderia ser decomposto em
subrequisitos? Essas são algumas perguntas que servem como observação daquilo que é
importante considerar na análise. Priorizar um requisito muitas vezes se torna um problema
para o analista uma vez que os stakeholders considerem todos os requisitos essenciais, ou seja,
todos eles são de grau importância. Cabe ao analista saber lidar com essa situação e possuir
bons argumentos na hora da negociação dos requisitos. Primeiro ele deve identificar os
requisitos considerados problemáticos e então entrar na fase de negociação desses requisitos.
A negociação de requisitos se dá sobre os requisitos que foram considerados problemáticos,
aqueles que apresentaram alguma inviabilidade ou simplesmente demonstram dúvidas quanto
a sua existência, a intenção é aqui é encontrar um objetivo global, nessa negociação aspectos
como tecnologia, custo, regras jurídicas, fatores políticos e sociais devem ser considerados.
Gerência de Requisitos e seus pontos críticos
Diversos fatores contribuem para a instabilidade dos requisitos ao longo do tempo, mudanças
externas no ambiente tais como: mudança na legislação, mudança no mercado, mudança e
posicionamento estratégico da empresa, ou até mesmo erros incorridos no processo de
requisitos, entre outros, levam a necessidade de alterar os requisitos e tais alterações precisam
ser conduzidas ordenadamente a fim de não se perder o controle de prazo e custo do
desenvolvimento. De acordo com Sommerville (2003) o Gerenciamento de Requisitos é o
processo de compreender e controlar as mudanças nos requisitos de sistemas. Esse processo é
realizado em conjunto com os outros processos da Engenharia de Requisitos, o seu
planejamento tem início desde levantamento inicial dos requisitos, ou seja, no processo de
Identificação de Requisitos, a partir do momento em que um esboço da versão do documento
de requisitos estiver disponível. O processo de Gerenciamento é de extrema importância, é nele
que são tratados os riscos bem como a sua prevenção. São realizadas várias atividades dentro
deste processo como: o gerenciamento de mudanças, rastreabilidade, configuração e qualidade
dos requisitos. Que os requisitos podem sofrer constantes mudanças ao longo do
desenvolvimento do sistema é incontestável, saber como lidar com essas mudanças é árduo
trabalho que o analista deve realizar, essa será algumas das preocupações a serem discutidas
no processo de Gerenciamento de Requisitos como tratar as mudanças de requisitos e também
como rastrear esses requisitos.

MUDANÇAS DE REQUISITOS
Por natureza alguns requisitos sofrem alterações devido ao ramo de atividade da empresa, uma
solicitação feita por parte do cliente que pode de alguma forma acarretar modificações nos
requisitos do projeto e também da legislação do país. Essas mudanças precisam ser controladas
a fim de não atrapalhar o desenvolvimento do sistema. O Gerenciamento de Mudanças de
requisitos tem por objetivo elaborar procedimentos, processos e padrões que serão utilizados
para gerenciar as mudanças dos requisitos do sistema, saber quando e qual foi o motivo da
mudança. Primeiramente o problema de requisito deve ser identificado, essa identificação
poder sido feita por uma análise mais detalhada do documento de requisitos ou até mesmo
como já foi dito de novas necessidades do cliente. Posteriormente a essa identificação a
solicitação de mudança será analisada, observa-se então se outros requisitos serão afetados pela
esta solicitação e qual o custo que essa mudança pode gerar após essa a análise a solicitação de
mudança pode ser aceita ou não. É importante possuir formulários de solicitação de mudanças
de requisitos e armazená-los e também informar as partes interessadas as mudanças solicitadas
e se elas afetarão o orçamento e o cronograma do projeto. Novamente nota-se a necessidade de
comunicação.

RASTREABILIDADE DE REQUISITOS
A rastreabilidade de requisitos é uma habilidade que tem por finalidade identificar e
compreender as ligações, os relacionamentos entre os requisitos, arquitetura e implementação
final do sistema, alguns requisitos são originados de outros requisitos, logo, a alteração de um
requisito pode afetar outro requisito, e conseqüentemente a arquitetura e implementação do
sistema. Além disso, a rastreabilidade também pode apoiar a detecção precoce de alguns
requisitos não atendidos pelo software. A rastreabilidade serve também como auxilio em outros
processos, desde identificação de requisitos até a validação de requisitos, durante o processo
de identificação a resolução de requisitos em conflito é um problema para o analista, este
problema muitas vezes persiste até análise de requisitos e validação, a rastreabilidade pode
auxiliar na identificação das origens do requisito conflitante e assim buscar uma solução para
o problema detectado, ela também pode auxiliar o gerenciamento de riscos uma vez que ela
serve de apoio para identificar os artefatos atingidos por cada fator de risco levantado,
possibilitando a elaboração de estratégias para tratamento ou redução dos riscos. Se o analista
souber qual a relação entre os mais diversos produtos, e sistemas, o risco será bem menor e
conseqüentemente o custo para a empresa também. A ratreabilidade de um requisito pode-se
se dar em dois sentidos: pré-rastreabilidade e pós-rastreabilidade. A pré-rastreabilidade ou
rastreabilidade para frente localiza quais os resultados do desenvolvimento serão afetados por
cada requisito, a ratreabilidade para trás ou pósrastreabilidade procura saber existência de cada
requisito, e quem ou o que o originou.
A Engenharia de Requisitos é base para o desenvolvimento de software, ela pode ser
considerada como um pré-requisito para obtenção de sucesso. Se um projeto começar de forma
errada, significará que todo o seu desenvolvimento estará comprometido. Na Engenharia de
Requisitos pode se avaliar diversos fatores de riscos que podem comprometer o
desenvolvimento de software, ela não produz a apenas documentos que pra muitos são
considerados como desperdício de tempo, ela também produz uma política de segurança, de
prevenção e de tratamento para redução de riscos, e também facilita as relações pessoais, entre
analista e cliente/ usuário como os relacionamentos dentro da própria equipe de TI, que
necessita de uma Engenharia de Requisitos bem definida e clara para o desenvolvimento do
sistema, afinal de contas nenhum sistema pode ser considerado de qualidade se houver
requisitos problemáticos. Os requisitos de software são a fundação a partir da qual a qualidade
é medida. A falta de conformidade com os requisitos é falta de qualidade (PRESSMAN. 2006).
Portanto apenas cumprir atividades contidas na Engenharia de Requisitos não é suficiente para
garantia de qualidade de software deve-se observar o fator risco em cada atividade
desenvolvida, desde identificação de requisitos bem como a sua gerência, até a fase de
validação e testes, a fim de se obter um produto de qualidade que principalmente atenda e
satisfaça os clientes, a organização, empresa, pessoa que solicitou o sistema, dessa forma a
possibilidade de criar um software de qualidade será maior.

Unidade 2.3. Riscos Tecnológicos

Dentro das engenharias existem classicamente algumas áreas e corporações técnico-científicas

que trabalham com o tema dos riscos tecnológicos. Para a engenharia, de modo geral, a noção
de risco estaria relacionada a uma expressão quantitativa que costuma ser expressa através do
resultado entre a probabilidade de eventos ou falhas vezes a magnitude das conseqüências sobre
o tempo. A quantificação das conseqüências costuma também ocorrer monetariamente,
demonstrando a influência economicista e do modelo custo-benefício. Contudo, devido às
críticas morais e políticas relacionadas às tentativas de quantificação monetária de vidas
humanas ou meio ambiente afetados, essas análises freqüentemente acabam por ser evitadas
nas discussões públicas.
Com as diversas transformações que se intensificaram a partir dos anos 70, tanto no nível
tecnológico, através do desenvolvimento de tecnologias complexas e cujas conseqüências
econômicas e políticas dos acidentes - notadamente nos setores aeroespacial, nuclear e,
posteriormente, químico -, como no nível social, a partir de uma maior organização e pressão
por parte de trabalhadores, ambientalistas e certos setores industriais críticos, a engenharia de
segurança clássica passou a ser cada vez mais pressionada a assumir um novo enfoque (Dwyer,
1992). Sua abordagem fragmentadora na compreensão do processo produtivo e culpabilizante
dos trabalhadores pautada nos conceitos de atos inseguros e condições inseguras, e que ainda
é amplamente utilizada por técnicos e engenheiros de segurança, já não mais respondia às
questões relacionadas aos riscos tecnológicos cada vez mais complexos.
As tecnologias que ganham maior impulso a partir dos anos 70 caracterizam-se por serem
extremamente complexas - o que Perrow (1984) denominou de sistemas complexos altamente
interligados -, onde disfunções em certos subsistemas podem, através do chamado efeito
dominó, levar a acidentes sistêmicos, onde todo ou expressiva parte do sistema é destruída,
implicando prejuízos de enorme valor. Nessas tecnologias, a confiabilidade técnica do sistema
precisava ser profunda e extensamente avaliada e controlada. Fica patente que a engenharia de
segurança clássica não poderia dar conta dessa demanda, e uma série de novas técnicas de
análise de confiabilidade, incluindo o cálculo probabilístico de falhas possíveis de
componentes a partir da lógica matemática booleana, foram criadas a partir dos anos 50.
Posteriormente, essas técnicas foram e vêm sendo disseminadas para o conjunto dos outros
setores industriais de menor complexidade tecnológica, conformando uma abordagem técnica
mais efetiva na compreensão, análise e controle dos acidentes industriais.
Os métodos sistêmicos de análises de riscos desenvolvidos vêm sendo aplicados nas indústrias
de processos, como é o caso das químicas de transformação, basicamente como ferramentas
para a decisão acerca da aceitabilidade de uma nova planta industrial e para a melhoria da
confiabilidade dos sistemas técnico e organizacional existentes. Segundo a UNEP (1992), os
resultados de tais métodos servem para decidir sobre: (a) a localização geográfica dos processos
e operações industriais perigosas; (b) os investimentos nos equipamentos voltados à prevenção
de acidentes e limitação de suas conseqüências; (c) os projetos tecnológicos de processos de
fabricação e sistemas de controle; (d) a criação de rotinas operacionais e de manutenção; (e) a
elaboração de documentos de segurança para a organização.

Unidade 2.4. Riscos de competência

É de extrema importância que a equipe tenha conhecimento do desenvolvimento do projeto e

de suas etapas, e que os seus desenvolvedores tenham conhecimento das tecnologias definidas.
Os riscos de habilidades se referem à competência da equipe em usar as técnicas escolhidas.
Os recursos podem ser modificados durante o andamento do projeto, desde recursos
orçamentais até humanos. Mesmo que novos membros se incorporem à equipe, provavelmente
necessitarão de tempo para se adaptar.

Unidade 2.5. Riscos políticos

A definição de um evento pode ser feita através de uma ocorrência que podem ser originadas
através de fontes internas ou externas que influenciam nos objetivos de forma positiva, negativa
ou ambas.
Os eventos em potenciais, internos ou externos, que trarão impacto negativo exigem uma
análise e um planejamento de uma resposta. Também podemos considerar os eventos de
impacto positivo, esses representam oportunidades para ajudar os objetivos a serem alcançados.
Com o objetivo de melhorar a análise dos eventos, pode ser útil fazer o agrupamento por
categorias. Através dessas informações podemos formar uma base mais consolidada de
informações, é possível ter uma visão melhor sobre as semelhanças, grau de completude de
seus esforços e outras informações que irão facilitar a identificação de riscos. As categorias
podem ser feitas de acordo com as necessidades do objetivo.

Bibliografia

VER EM ANEXO
TEMA III: DIFERENTES TIPOS DE MODELOS DE SISTEMA DE
INFORMAÇÃO

Unidade 3.1. INTRODUÇÃO. Modelos de Sistemas de informação

Modelo é representação abstrata e simplificada de um sistema real, com a qual se pode explicar
ou testar o seu comportamento, em seu todo ou em partes. (Cougo, 1997). O mundo real é
complexo e dinâmico. Assim, modelos são necessários para entendimento e documentação de
decisões. Um modelo é uma abstração ou uma aproximação que pode ser usada para simular
uma realidade. O desenvolvimento de software, assim como todo projeto complexo, é sempre
associado a atrasos, atualizações de cronograma e revisão de orçamentos. Mas pode se animar,
porque o desafio de criar um plano viável, fazer uma boa gestão do trabalho e monitorar o
andamento ganhou novos aliados com a evolução da tecnologia. Prepare-se para aumentar a
previsibilidade dos projetos e a precisão dos movimentos da sua empresa. Isso porque a era da
análise preditiva já começou. Um estudo da McKinsey levantou que, entre mais de 1.800
softwares desenvolvidos, apenas 30% dos projetos foram entregues no prazo. Além disso, 5%
só conseguiram seguir o cronograma porque tiraram do escopo do projeto algumas
funcionalidades. E você sabe muito bem o que significa um atraso no projeto: mais custos de
desenvolvimento e o aumento considerável de custos indiretos.
Ou pior ainda: a solução pode não ser lançada de acordo com o planejado. Com isso, o processo
perde eficiência, o cliente perde vendas, concorrentes ganham mais uma chance de superar o
seu trabalho e há um prejuízo institucional para a sua marca.
A primeira causa desse descompasso é subestimar a complexidade de um projeto. É preciso
entender que, muitas vezes, os métodos convencionais de análise não são o suficiente. É só
pensar em como é difícil prever quantas linhas de código serão necessárias, simplesmente
seguindo a intuição e o histórico dos programadores. Então, como diversas equipes estão
trabalhando no mesmo projeto, a estimativa vira um chute, uma meta sem embasamento. Isso
porque não são levados em conta os estilos de programação de cada time ou os desafios que a
equipe enfrentará pela primeira vez.
É nesse contexto que ganharam força, no mercado, ferramentas de análise preditiva. Com essa
prática, as empresas já começam a colher os frutos de poder estimar o esforço e os recursos
necessários para concluir um projeto com maior precisão. Isso é possível, porque, apesar de
cada projeto ser único, os recursos que influenciam o andamento e compõem o trabalho de um
desenvolvimento de software possuem similaridades. A análise preditiva, então, permite
encontrar esses padrões e jogar luz ao trabalho de planejar com exatidão.
Segundo a mesma pesquisa da McKinsey, o planejamento com análise preditiva provoca
ótimos resultados. A variação nas datas do cronograma chega a cair em 90% com a utilização
do modelo. E o efeito não é só no prazo, mas na qualidade do desenvolvimento. Os defeitos
por linha de código mostram uma redução de 30% a 40%.

Unidade 3.2. Modelos predictivos

ara entender como a análise preditiva contribui para o desenvolvimento de software, é preciso
pensar sobre como explorar ao máximo os dados. Neste artigo sobre data mining, mostramos
os modelos utilizados com mais frequência na mineração de dados. Além dos benefícios desse
método, que se apoia em machine learning para dar novos usos ao big data.

Um tipo de modelagem importante, nesse caso, é a descritiva. Nela, a ferramenta busca, em

dados não parametrizados, possíveis padrões, formas de agrupá-los e de levantar hipóteses. A
partir daí, surge a modelagem preditiva, que lança o olhar para o futuro. Com a aplicação dos
padrões revelados pela mineração de dados, é possível indicar tendências e traçar projeções
com precisão. Um exemplo prático é a criação de um aplicativo para gerenciar processos de
TI. Já que se torna possível prever, no desenvolvimento, uma série de ocorrências para preparar
a solução para elas.

Demandas e insights
O surpreendente dessa nova vertente dos negócios guiados por dados, também conhecidos
como data driven business, é a possibilidade de encontrarmos respostas para perguntas que
nem sabíamos que eram relevantes. O machine learning voltado para a mineração de dados
reconhece padrões diferentes do que estamos habituados a identificar.
A partir dessas análises que desenham o futuro, é possível alinhar o planejamento estratégico
da empresa com as tendências levantadas. Agora, pense como essa análise pode fornecer
insights valiosos em diversas camadas. Tanto no desenvolvimento de software, quanto no de
produtos, serviços e projetos. Desde demandas ocultas, até detalhes de user experience (como
por exemplo, o aperfeiçoamento de um e-commerce voltado para melhorar a experiência do
usuário), e características que farão seu trabalho ser bem-sucedido.
Análise preditiva na sua gestão de projetos
Além de insights para o desenvolvimento de software, você pode contar com a prática no
trabalho de desenvolvimento em si. Isso inclui gestão de horas da equipe, coordenação dos
talentos e controle de prioridade das tarefas que compõem o projeto.
E a ferramenta para coletar e analisar os dados do seu fluxo de trabalho já existe. Braço direito
dos gestores, o Runrun.it é a solução para o seu negócio. Com algoritmos poderosos, a
plataforma fornece estimativas reais das entregas dos projetos, prevê possíveis atrasos e se o
orçamento tende a estourar. Com isso, você pode tomar medidas para evitar que o prazo estoure
e os custos extrapolem o programado.
Além de contar com a análise preditiva para antever problemas, você também consegue
planejar melhor os projetos. Isso porque o sistema organiza o fluxo de trabalho, ajuda a
distribuir demandas e gerenciar a equipe. E, mais do que estar a par do monitoramento das
tarefas, quem faz a gestão de um time sabe quando poderá alocar uma nova demanda de acordo
com a agenda da pessoa.

Unidade 3.3. Modelos normativos

Um modelo normativo é um instrumento que tem por objetivo organizar e padronizar as

atividades de um desenvolvimento de software, pela criação e utilização de um conjunto de
regras, critérios e parâmetros que, associado aos processos de trabalho, propiciam o
cumprimento das diretrizes estabelecidas e o alinhamento com as determinações estratégicas
da organização. No geral, trata-se de um conjunto de padrões expressos em documentos que
contêm instruções normativas, distribuídas entre políticas, diretrizes, normas e procedimentos
normativos.

Unidade 3.4. Modelos descritivos

O Modelo Descritivo contém informações sobre o problema a ser solucionado, bem como a
maneira de fazê-lo. Especificamos isso utilizando textos.

Devemos especificar textualmente:

● O Problema a ser solucionado.
● O Objetivo do projeto.
 ● Quais serão os requisitos funcionais.
● Quais serão os requisitos não funcionais.
● Como será implantado o sistema.

Para terminarmos o Use Case View, devemos utilizar os seguintes diagramas:

● Diagrama de Caso de Uso
● Diagramas de Seqüência
● Diagramas de Colaboração
● Diagramas de Atividade

Problema a ser solucionado

Aqui especificamos as deficiências do cliente, por exemplo: Toda vez que é necessário fazer a
contagem de horas trabalhadas dos funcionários, o pessoal do RH, lê todos os cartões de ponto,
atualmente o ponto é manual, usando o tradicional cartão de papelão para marcá-lo. A empresa
possui 200 funcionários, tornando o trabalho muito cansativo e com grandes riscos de
acontecerem erros.

Objetivo do Projeto
Aqui especificamos como podemos solucionar o Problema a ser solucionado, por exemplo:
Desenvolver um sistema de software que acesse um banco de dados que terá as informações
das horas de entrada e saída dos funcionários, precisará ponto eletrônico para realizar a
marcação do ponto e cada funcionário deverá ter um cartão magnético, cujo terá as informações
de se respectivo portador (funcionário). O sistema deverá gerar relatórios com o total de horas
trabalhadas e não trabalhadas de cada funcionário.

Requisitos funcionais
Aqui definimos todas as funcionalidades do sistema, por exemplo:
● Cadastrar novos funcionários
● Gerar relatório
● Definir folgas de funcionários
● Definir feriados
● Realizar compensação de horas
● Calcular horas extras
● Marcar ponto de funcionário
 ● Funcionários poderem realizar consultas de suas respectivas horas trabalhadas.

Requisitos não funcionais

Aqui definimos tudo que não é funcionalidade do sistema, mas sim o que é necessário para
qualificar os Requisitos Funcionais, por exemplo:
● O sistema será operado em ambiente Windows
● O banco de dados deverá estar instalado em um servidor.
● O sistema será em plataforma Web.
● O sistema deverá ser instalado em um servidor IIS versão 6 ou superior.

Como será Implantado (Soluções de Automação)

Aqui definimos o tipo de equipamentos que será necessário para o sistema funcionar, bem
como os softwares que serão necessários para seu perfeito funcionamento. Dividimos essa
etapa em dois subgrupos: Hardware e software, por exemplo:
● Hardware:
○ Dois servidores Dell com a configuração:
○ Um ponto eletrônico do modelo: bla, fabricante: Etc.
○ Computadores nas estações cliente com as configuração mínima: ......
● Software:
○ Nos servidores, sistema operacional Windows 2000 ou superior.
○ Nos clientes, sistema operacional Windows 98 ou superior.
○ Banco de dados Microsoft SQL Server 2005

Bibliografia

VER EM ANEXO
TEMA IV: DIFERENTES NÍVEIS DE ABSTRAÇÃO DE SISTEMAS DE
INFORMAÇÃO

Unidade 4.1. INTRODUÇÃO. Níveis de Abstração de Sistemas de

informação

A complexidade é uma questão central no desenvolvimento de software. Elevando o nível de

abstração ajuda a reduzir a complexidades, assim como a quantidade de documentação
necessária ao projeto. Isso pode ser obtido através de reutilização, o uso de ferramentas de
modelagem de alto nível, e estabilizando a arquitetura inicialmente. Um dos principais
problemas que enfrentamos no desenvolvimento de software e a complexidade. Sabemos que
reduzir a complexidade apresenta maior impacto sobre a produtividade. Trabalhar em um nível
maior de abstração reduz a complexidade e facilita a comunicação.
Uma abordagem efetiva de se reduzir a complexidade é reutilizar ativos existentes, como
componentes reutilizáveis, sistemas legados, processo de negócios existente, padrões ou
software de código aberto. Dois grandes exemplos de reutilização que apresentaram o maior
impacto sobre a indústria de software na última década são:
A reutilização de middleware, como bancos de dados, servidores de Web e portais, e mais
recentemente,
Software de código aberto que oferecem muitos componentes menores e maiores que podem
ser alavancados.
Avançando, os serviços da Web provavelmente terão maior impacto na reutilização, já que
oferecem formas simples de reutilizar as principais parte da funcionalidade através de
plataformas diferentes e com acoplamentos soltos entre o consumidor e o provedor de um
serviço. Isso significa que podemos elevar mais facilmente diferentes combinações de serviços
para atender às necessidades comerciais. A reutilização também é facilitada pelos padrões
abertos, como RAS, UDDI, SOAP, WSDL, XML e UML.
Um dos problemas com a reutilização é que dois componentes precisam conhecer a experiência
um do outro no momento do desenvolvimento. As arquiteturas orientados para o serviço
minimizam esse problemas fornecendo o que chamam de consumidor solto: O consumidor de
um serviço pode encontrar dinamicamente um provedor de um serviço. Podemos, portanto,
agrupar os componentes existentes ou sistemas legados dentro dos serviços, permitindo que
outros componentes ou aplicativos obtenham acesso dinamicamente a suas capacidades através
de uma interface baseada em padrões, independentemente da plataforma e da tecnologia de
implementação.
Outra abordagem para reduzir a complexidade e melhorar a comunicação consiste em alavancar
ferramentas, estruturas e linguagens de níveis mais altos:
Linguagens padrões com a UML (Unified Modeling Language) e linguagem de aplicativos
rápidos como EGL fornecem a capacidade de expressar constructos de alto nível, como
processo de negócios e componentes de serviços, que facilitam a colaboração entre constructos
de alto nível enquanto ocultam detalhes desnecessários.
Design e ferramentas de construção podem automatizar o movimento de constructos de alto
nível para código de trabalho:
Eles fornecem assistentes que automatizam o design, a construção e testam tarefas gerando
códigos e ativando o uso de trechos de código.
Eles convertem integração e teste em tarefas de desenvolvimento perfeitas através de
desenvolvimento integrado, construção e ambientes de teste.
Ferramentas de gerenciamento de portifólio, que ativam o gerenciamento financeiro e outros
aspectos de vários projetos como uma entidade versus um conjunto separado de entidades.
Em resumo, ferramentas de alto nível capturam graficamente informações de modelagem, o
que é uma forma atrativa de resumir e apresentar essa informação. Os benefícios da modelagem
visual são explorados mais detalhadamente em Material de Suporte: Modelagem Visual.
Uma terceira abordagem para gerenciar a complexidade é focalizar na arquitetura, tanto para
definir um negócio como para desenvolver um sistema ou aplicativo. Em desenvolvimento de
software, procuramos obter uma arquitetura projetada, implementada e testada antes do projeto.
Isso significa que, antes de um projeto, focalizamos os seguintes objetivos:
Definir blocos de construção de alto nível e os componentes mais importantes, suas
responsabilidades e suas interfaces.
Projetar e implementar os mecanismos arquiteturais, ou seja, soluções prontas para problemas
comuns, como por exemplo, como lidar com a persistência ou a coleção de lixo.
Obtendo a arquitetura logo de início, fornecemos uma estrutura de esqueleto para nosso
sistema, tornando-o mais fácil de gerenciar a complexidade na medida em que incluímos mais
pessoas, componentes, capacidades e código ao projeto. Também identificamos quais ativos
reutilizáveis podemos alavancar e quais aspectos do sistemas precisam ser customizados.
Unidade 4.2. Nível conceptual

É o o modelo de mais alto nível, ou seja, que esta mais próximo da realidade dos usuários. O
nível conceitual é desenvolvido com alto nível de abstração, a partir dos requisitos do sistema,
extraídos na fase de levantamento de requisitos. Esse modelo pode ser elaborado por meio de
dois diagramas: Diagrama de Entidade e Relacionamento e/ou o Diagrama de Classes.
Exemplo de um DER – Diagrama de Entidade e Relacionamento

Exemplo de um Diagrama de Classes da UML

Unidade 4.2. Nível de especificação

Descreve como os dados serão armazenados no banco e também seus relacionamentos. Esse
modelo adota alguma tecnologia, pode ser: relacional, orientado a objetos, orientado a colunas,
entre outros.
Exemplo de um Banco de dados relacional
Turma

idTurma capacidade
 2235 30

7984 32

Professor

idProfessor telefone nome

78 957465512 Augusto

Paulo
96 987453687

Unidade 4.3. Nível de implementação

Descreve, por meio de alguma linguagem, como será feita a armazenagem no banco. Nesse
nível se escolhe qual Sistema gerenciador de Banco de dados (SGBD) será usado, levando em
consideração o modelo lógico adotado. Pode ser: PostgreSQL, MySQL, dentre outros.

Exemplo de código SQL para criação de objetos no banco

1. CREATE TABLE `turma` (
2. `idturma` INTEGER(4) NOT NULL AUTO_INCREMENT,
3. `capacidade` INTEGER(2) NOT NULL,
4. `idProfessor` INTEGER(4) NOT NULL,
5. PRIMARY KEY (`idturma`),
6. FOREIGN KEY(`idProfessor`) REFERENCES
professor(idProfessor),
7. UNIQUE KEY `idturma` (`idturma`)
 8. )

1. CREATE TABLE `professor` (

2. `idProfessor` INTEGER(4) NOT NULL AUTO_INCREMENT,
3. `telefone` INTEGER(10) NOT NULL,
4. `nome` CHAR(80) COLLATE NOT NULL DEFAULT '',
5. PRIMARY KEY (`idProfessor`),
6. FOREIGN KEY(`idTurma`) REFERENCES turma(idturma),
7. UNIQUE KEY `idProfessor` (`idProfessor`)
8.

Unidade 4.2. Nível de instalação

Compreende a instalação do software no ambiente do usuário. O que inclui os manuais do
sistema, importação dos dados para o novo sistema e treinamento dos usuários para o uso
correto e adequado do sistema. Em alguns casos quando da existência de um software anterior,
também é realizada a migração de dados anteriores desse software.

TEMA V: O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

Unidade 5.1. INTRODUÇÃO. Ciclo de vida de Desenvolvimento de Software

O ciclo de vida é a estrutura contendo processos, atividades e tarefas envolvidas no

desenvolvimento, operação e manutenção de um produto de software, abrangendo a vida do
sistema, desde a definição de seus requisitos até o término de seu uso.
O modelo de ciclo de vida é a primeira escolha a ser feita no processo de software. A partir
desta escolha definir-se-á desde a maneira mais adequada de obter as necessidades do cliente,
até quando e como o cliente receberá sua primeira versão operacional do sistema.
Processo de software é o conjunto de atividades que constituem o desenvolvimento de um
sistema computacional. Estas atividades são agrupadas em fases, como: definição de requisitos,
análise, projeto, desenvolvimento, teste e implantação.
Em cada fase são definidas, além das suas atividades, as funções e responsabilidades de cada
membro da equipe, e como produto resultante, os artefatos.
O que diferencia um processo de software do outro é a ordem em que as fases vão ocorrer, o
tempo e a ênfase dados a cada fase, as atividades presentes, e os produtos entregues.
Com o crescimento do mercado de software, houve uma tendência a repetirem-se os passos e
as práticas que deram certo. A etapa seguinte foi a formalização em modelos de ciclo de vida.
Em outras palavras, os modelos de ciclo de vida são o esqueleto, ou as estruturas pré-definidas
nas quais encaixamos as fases do processo. De acordo com a NBR ISO/IEC 12207:1998, o
ciclo de vida é a “Estrutura contendo processos, atividades e tarefas envolvidas no
desenvolvimento, operação e manutenção de um produto de software, abrangendo a vida do
sistema, desde a definição de seus requisitos até o término de seu uso.”
O modelo de ciclo de vida é a primeira escolha a ser feita no processo de software. A partir
desta escolha definir-se-á desde a maneira mais adequada de obter as necessidades do cliente,
até quando e como o cliente receberá sua primeira versão operacional do sistema.
Não existe um modelo ideal. O perfil e complexidade do negócio do cliente, o tempo
disponível, o custo, a equipe, o ambiente operacional são fatores que influenciarão diretamente
na escolha do ciclo de vida de software a ser adotado.
Da mesma forma, também é difícil uma empresa adotar um único ciclo de vida. Na maior parte
dos casos, vê-se a presença de mais de um ciclo de vida no processo.
Os ciclos de vida se comportam de maneira sequencial (fases seguem determinada ordem) e/ou
incremental (divisão de escopo) e/ou iterativa (retroalimentação de fases) e/ou evolutiva
(software é aprimorado).

Unidade 5.2. Modelo waterfall

O modelo cascata é utilizado principalmente quando os requisitos de um determinado problema

são bem compreendidos. Uma forma de utilizar o modelo cascata é quando precisamos fazer
adaptações ou aperfeiçoamentos em um sistema já existente. Por exemplo, quando temos um
sistema já pronto e precisamos fazer uma adaptação porque alguma lei governamental foi
alterada ou criada.

Também podemos utilizar o modelo cascata quando um software necessita de uma nova
funcionalidade e os requisitos estão bem definidos e são estáveis.
O modelo cascata também é chamado de ciclo de vida clássico ou tradicional.

Este modelo sugere uma abordagem sequencial e sistemática para o desenvolvimento de

software. Dessa forma, começamos com o levantamento de requisitos ou necessidades junto
ao cliente, depois vamos para a fase de planejamento onde definimos estimativas, cronograma
e acompanhamento, após isso partimos para a modelagem onde fazemos a análise e projeto,
seguindo da construção onde codificamos e testamos, passamos para a implantação ou emprego
onde efetuamos a entrega, suporte e feedback do software concluído.

Basicamente na etapa de levantamentos de requisitos ou necessidades estabelecemos junto aos

clientes os requisitos do produto desejado pelo cliente que consiste dos serviços que devem ser
fornecidos, limitações e objetivos do software. Esta etapa também consiste da documentação e
o estudo de viabilidade do projeto para determinarmos o processo de inicio de desenvolvimento
do projeto do sistema. Na etapa de planejamento temos a definição de estimativas, cronograma
e acompanhamento baseando-se nos requisitos e na determinação das tarefas que, por sua vez,
são determinadas pelos requisitos. A etapa de modelagem é uma prévia da próxima etapa de
construção, nesta etapa define-se a estrutura de dados, arquitetura do software, interfaces, etc.
A etapa de construção abrange a implementação, onde os programas são efetivamente criados
e também os testes que é onde se testam as lógicas internas do software e as funcionalidades
externas. As funcionalidades internas normalmente são realizadas com o uso de testes unitários
e as fases externas podem ser realizadas por testadores e pelo próprio cliente. Por fim, a etapa
de emprego ou implantação abrange e entrega efetiva do software no cliente que é onde
instalamos o software no servidor ou na máquina do cliente junto com outros utilitários como
banco de dados ou outros itens dependendo do software sendo construído. O suporte é onde
tiramos dúvidas dos clientes e a manutenção consiste na correção de erros que não foram
previamente detectados.
Devido à sua simplicidade, o modelo em cascata é fácil de ser entendido pelo cliente. É um
modelo que supõe um início e fim claro e determinado, assim como uma estimativa precisa de
custo logo no início, fatores importantes na conquista do cliente.
O problema se dá depois, quando o cliente, após esperar até o fim do processo para receber a
primeira versão do sistema, pode não concordar com ela. Apesar de cada fase terminar com
uma documentação aprovada, certamente haverá lacunas devido a requisitos mal descritos pelo
cliente, mal entendido pelo analista ou por mudança de cenário na organização que exija
adaptação de requisitos. O modelo em cascata não prevê revisão de fases.
Assim, o risco é muito alto, principalmente para sistemas complexos, de grande porte, afinal o
modelo em cascata pressupõe uma realidade estática e bem conhecida, comparado a uma linha
de produção fabril. Mas a rotina do negócio do cliente não reflete isso. Manipulação de usuários
com diferentes habilidades, ambientes operacionais distintos, tecnologia em crescente
evolução, necessidade de integração com outros sistemas (em plataformas antigas ou mais
novas), mudanças organizacionais, até mudanças na legislação do município/estado/país,
pedem um modelo mais flexível.
Por outro lado, o modelo em cascata adéqua-se bem como um "submodelo" para outros
modelos. Por exemplo, no modelo "cascata com realimentação" permite-se que, a cada
descoberta da fase posterior, haja uma correção da fase anterior.
Os principais problemas encontrados no modelo cascata são:
 ● Os projetos de software reais construídos e evoluídos na indústria de software
raramente seguem o fluxo sequencial que o modelo prega. Apesar de que esse modelo
em forma sequencial possa conter iterações, onde poderíamos passar diversas vezes
pelas mesmas atividades, ele o faz indiretamente. Como resultado tem-se que mudanças
podem provocar bastante confusão na medida em que a equipe de projeto prossegue.
● É muito raro e difícil para o cliente saber e estabelecer explicitamente todas as suas
necessidades. O modelo cascata é muito fortemente baseado nisso e tem dificuldade
para adequar a incerteza natural que existem no inicio dos projetos.O cliente precisa ter
muita paciência, o que raramente acontece. Uma versão operacional (pronta para ser
executada no cliente) não estará disponível até estarmos próximo ao final do projeto.
Se tivermos um erro grave nas etapas iniciais, como uma especificação mal
compreendida e mal especificada, podemos ter um resultado desastroso.
Outro grande problema que temos com os projetos que usam modelos cascata é o bloqueio que
existe em alguns membros da equipe que precisam esperar que os outros completem as suas
tarefas para que eles possam dar sequencia ao trabalho. O tempo gasto nessa espera pode
exceder o tempo gasto em trabalho produtivo que levaria à conclusão do projeto. Estudos
mostram que o estado de bloqueio tende a prevalecer no início e no final de um processo
sequencial linear. Um exemplo clássico disso é a brincadeira das moedas. Imagine que temos
5 moedas de 10 centavos na mão esquerda e faremos uma rodinha com 5 pessoas sendo que
existe uma cadeira ao lado de cada pessoa para que possamos colocar as moedas já lançadas.
Cada pessoa deve pegar uma moeda da mão esquerda com a sua mão direita e atirar essa moeda
para cima e deixar a moeda cair na mesma mão direita, após isso colocamos a moeda na cadeira
ao lado. Após lançarmos todas as moedas e colocarmos na cadeira ao lado o próximo colega
deve pegar essas cinco moedas deixadas na cadeira pelo colega anterior e novamente lançar as
moedas, repetindo os mesmo procedimentos do colega anterior. Agora vamos recomeçar a
brincadeira e o colega deve lançar as moedas novamente, porém quando tivermos duas moedas
na cadeira o próximo colega deverá começar a lançar as moedas, sem precisar esperar que as
cinco moedas estejam disponível. Calcule o tempo gasto nas duas brincadeiras. Veremos que
há uma boa diferença quando não precisamos esperar até que cad um realize toda a atividade
para que possamos começar o trabalho. Temos um grande ganho de produtividade.

Atualmente também temos um ritmo bastante acelerado no desenvolvimento de software e

estamos cada vez mais sujeitos a uma cadeia de mudanças que são intermináveis que surgem
desde necessidades do negócio, necessidades dos clientes até exigências impostas por leis
governamentais. O modelo cascata é inapropriado para este trabalho. Como dito anteriormente
o modelo cascata é útil apenas em situações onde os requisitos são fixos e o trabalho deve ser
todo finalizado de forma linear.

Unidade 5.3. Modelo espiral

O modelo proposto por Boehm em 1988 trata de uma abordagem cíclica das fases do processo,
onde a cada “volta” ou iteração temos versões evolucionárias do sistema.

Este é um modelo guiado por risco, suporta sistemas complexos e/ou de grande porte, onde
falhas não são toleráveis. Para isso, a cada iteração há uma atividade dedicada à análise de
riscos e apoiada através de geração de protótipos, não necessariamente operacionais (desenhos
de tela, por exemplo) para que haja um envolvimento constante do cliente nas decisões.

Cada iteração ou volta é dedicada a uma fase do processo de vida de um software (viabilidade
do projeto, definição de requisitos, desenvolvimento e teste,...). Ao mesmo tempo, cada volta
é seccionada em 4 setores, da seguinte forma:
Os quatro setores são explicados da seguinte forma:
Na Definição de Objetivos, desempenhos, funcionalidade, entre outros objetivos, são
levantados. Visando alcançar esses objetivos são listadas alternativas e restrições, e cria-se um
plano gerencial detalhado.
Na Análise de Riscos, as alternativas, restrições e riscos anteriormente levantados são
avaliados. Neste setor (porém não apenas neste) protótipos são utilizados para ajudar na análise
de riscos.
No Desenvolvimento e Validação um modelo apropriado para o desenvolvimento do sistema
é escolhido, de acordo com o risco analisado no setor anterior (cascata, interativo,...).
No Planejamento da Próxima fase ocorre a revisão do projeto e a decisão de partir para a
próxima fase.
Ou seja, cada volta ou iteração do processo é vista por quatro ângulos.
No final da Viabilidade do Projeto teremos como resultado a Concepção das Operações; da
Definição de Requisitos o produto serão os requisitos; no final do Desenvolvimento e Testes o
projeto é criado e os testes habilitados. Pode-se parar por aí, pode-se incluir mais fases, pode a
espiral ficar adormecida até uma nova alteração do sistema se requisitada, e desta forma
estender até o fim de vida do sistema.
Neste modelo, apenas o início é definido. A evolução e amadurecimento dos requisitos
demandam tempo ajustável (assim como custo). Isto torna o sistema difícil de ser vender ao
cliente e exige um alto nível de gerenciamento em todo o processo.

Unidade 5.4. Modelo RAD

Este modelo formalizado por James Martin em 1991, como uma evolução da “prototipagem
rápida”, destaca-se pelo desenvolvimento rápido da aplicação. O ciclo de vida é extremamente
comprimido, de forma a encontrarem-se exemplos, na literatura, de duração de 60 e 90 dias. É
ideal para clientes buscando lançar soluções pioneiras no mercado.
É um ciclo de vida incremental, iterativo, onde é preferível que os requisitos tenham escopo
restrito. A diferença principal do ciclo anterior é o forte paralelismo das atividades, requerendo,
assim, módulos bastante independentes. Aqui os incrementos são desenvolvidos ao mesmo
tempo, por equipes diferentes.
Além do paralelismo, a conquista do baixo tempo se dá graças à compressão da fase de
requisitos e da fase de implantação. Isso significa que, na obtenção dos requisitos, costumam-
se optar por metodologias mais dinâmicas e rápidas, como workshops ao invés de entrevistas.
Permite-se também um desenvolvimento inicial no nível mais alto de abstração dos requisitos
visto o envolvimento maior do usuário e visibilidade mais cedo dos protótipos.

As fábricas de software que resolvem por adotar este modelo devem ter uma estrutura prévia
diferencial de pessoas e ferramentas, tais como:

Pessoas:
Profissionais experientes (funcional e gerência);
Profissionais de rápida adaptação;
Equipes de colaboração mútua;
Maior quantidade de pessoas;
Gerenciamento:
Empresas pouco burocráticas que encorajem a eliminação de obstáculos;
Alto controle do tempo;
Uso de Ferramentas:
CASE;
Muita diagramação;
Prévia biblioteca de componentes reutilizáveis (APIs, wizards, templates,...);
Fácil manutenção (ex.: linguagens de programação que suportem Orientação a Objetos,
tratamento de exceção, ponteiros);
Adoção de ferramentas maduras, pois não há tempo de atualizar versões e tratar erros
inesperados;
Os sistemas desenvolvidos no ciclo RAD tendem a ter uma padronização de telas muito forte,
devido a bibliotecas reutilizáveis e templates, porém tendem a perder em desempenho do
sistema e na análise de risco (atividades estas que demandam tempo em qualquer projeto).
Assim, é preferível seu uso para softwares de distribuição pequena.

Bibliografia

VER EM ANEXO
TEMA VI: PROPOSTA DE UM PROCESSO DE DESENVOLVIMENTO
DE SOFTWARE

Unidade 6.1. INTRODUÇÃO. processo de desenvolvimento de software

O processo de desenvolvimento iterativo e incremental é uma tendência que vem dominando

o mercado de criação de softwares. Isso provavelmente se explica pela agilidade e flexibilidade
que a metodologia traz para times e clientes.
Embora o modelo tradicional em cascata ofereça uma série de vantagens e atenda a diversos
cenários, ele apresenta alguns pontos fracos por não se alinhar às urgências e constantes
mudanças do mercado atual. Assim, para lidar com essas demandas e atingir melhores
resultados em médio e longo prazo, é preciso buscar novas saídas.

Unidade 6.2. Desenvolvimento interactivo e incremental

Um processo iterativo é aquele que faz progresso através de tentativas sucessivas de

refinamento. Por exemplo, uma equipe de desenvolvimento faz sua primeira tentativa para
construção de um software, porém, existem pontos de informação falhos ou incompletos em
algumas (talvez muitas) partes. A equipe de forma iterativa refina essas partes até que o produto
atinja o ônus de satisfatório. Com cada iteração, o software é melhorado através da adição de
mais e mais detalhes.
Vamos a outro exemplo, em uma primeira iteração, temos que codificar uma tela de relatórios
que suporte apenas o tipo mais simples para exibição. Na segunda iteração, podemos adicionar
critérios de pesquisa para ampliar o leque de opções no relatório. Finalmente, em uma terceira
iteração, poderíamos adicionar gráficos para explanar visualmente o relatório.
Como processo de desenvolvimento iterativo, podemos entender a atividade em que a criação
de um software é realizada por meio de progressos sucessivos. Assim, é comum que o sistema
seja apresentado ainda incompleto ou com algumas partes deficitárias. O objetivo é que o
refinamento do produto aconteça por etapas até que o resultado pretendido seja alcançado.
Assim, o método iterativo é frequentemente comparado ao trabalho de um escultor:
primeiramente, ele seleciona uma pedra do tamanho adequado para o seu trabalho; na
sequência, ele começa a esculpir a peça de um modo geral, quando já é possível ter uma ideia
de qual será o seu desfecho; na última etapa, ocorre o refinamento de detalhes, resultando em
uma arte que cumpre com o seu propósito.
Um processo incremental é aquele em que o software/produto é construído e entregue por
pedaços. Cada pedaço ou incremento representa um subconjunto de funcionalidades completas.
O incremento pode ser pequeno ou grande, por exemplo, ele pode variar apenas de uma tela de
relatórios simples, para um conjunto altamente flexível de telas de gerenciamento de dados.
Cada incremento é totalmente codificado e testado, e a expectativa geral é que o trabalho tenha
a conclusão mais completa possível.
Métodos ágeis são tanto iterativos, quanto incrementais. São iterativos por que o trabalho
realizado é sempre melhorado em ciclos subsequentes. São também incrementais, por que o
trabalho planejado é entregue em partes que são adicionadas ao todo do projeto.
O desenvolvimento incremental, por outro lado, é aquele em que o software é entregue
separadamente — ou seja, por pedaços, que são chamados de incrementos. Independentemente
do tamanho desses subconjuntos, o fato que é que eles são entregues já na sua versão final.
Assim, há uma concentração de esforços em determinadas partes até que elas estejam em pleno
funcionamento.
Podemos dizer, ainda, que no desenvolvimento iterativo há uma repetição das etapas do
processo de criação do software até que o resultado almejado seja obtido; já no
desenvolvimento incremental, novas partes são integradas ao longo do período de construção.

Características do desenvolvimento iterativo e incremental

A criação de um processo de desenvolvimento iterativo e incremental está nas bases das
metodologias ágeis, como a Scrum. A ideia é que a criação de um software seja pautada por
vários ciclos curtos, em que funcionalidades são introduzidas, feedbacks coletados e requisitos
revistos.
Assim, é possível atingir um maior nível de satisfação do cliente e garantir que o resultado final
esteja dentro do esperado. Se no modelo em cascata a evolução é feita como um processo
contínuo e sequenciado, no desenvolvimento iterativo e incremental, a empresa diminui tarefas
e repete etapas sempre que for necessário.
Pretende-se, com isso, reduzir o número de falhas na solução entregue ao usuário, criando um
ambiente de trabalho que seja mais prático e capaz de fazer mudanças em todas as etapas de
desenvolvimento.

Vantagens desse modelo

A adoção de um processo de desenvolvimento iterativo e incremental pode trazer uma série de
vantagens para o negócio — e elas vão além da melhora dos produtos entregues aos clientes.
A seguir, veja alguns dos benefícios desses modelos:

criação de um fluxo de entrega de softwares em que os requisitos são apresentados em pequenas

partes funcionais;
maior capacidade de acompanhar a evolução do desenvolvimento da aplicação;
identificação precisa de erros e falhas durante a criação do sistema;
redução de riscos a cada etapa do projeto;
maior capacidade de modificar a direção de um projeto;
criação de soluções de software com maior valor agregado;
capacidade de otimizar a ferramenta continuamente;
escopo de software mais flexível;
mais agilidade e produtividade no dia a dia de cada time.
Todos esses fatores contribuem para que a empresa possa atuar com mais agilidade e segurança.
O negócio poderá solucionar demandas de clientes, eliminar falhas e diminuir as chances da
solução final não entregar uma experiência de usuário de qualidade. Assim, o nível de sucesso
de cada sistema será muito maior.

Bibliografia

VER EM ANEXO

TEMA VII: MODELAÇÃO DE SISTEMAS DE INFORMAÇÃO EM UML

Unidade 7.1. INTRODUÇÃO. UML

A UML é a linguagem mais utilizada quando o assunto é modelagem de software. Definida de

forma simples como um conjunto de diagramas que representam elementos, características e
comportamentos de um software, essa opção traduz para o programador como ele deve
transformar os requisitos do software em código, ao mesmo tempo em que respeita a arquitetura
proposta.
Nesse contexto, para representar os elementos identificados durante a análise de um sistema
que segue esse paradigma, é necessário conhecermos um pouco sobre modelagem, de modo
que saibamos como construir, de forma visual, os componentes da solução através de notações
e diagramas padronizados.
UML é uma linguagem utilizada para modelar sistemas orientados a objetos. Surgiu em 1994
com a junção dos conceitos de Booch, OMT E OOSE, métodos de modelagem existentes na
época. Esta linguagem possibilita que desenvolvedores tenham uma noção abstrata do
funcionamento de um sistema. Possui como principal objetivo auxiliar na análise e
desenvolvimento de sistemas orientados a objetos, computacionais ou não.
Essa linguagem tem sido muito consumida na elaboração de sistemas corporativos, de
transporte, de vendas, de telecomunicações, de serviços bancários, dentre muitos outros. A
UML já é a linguagem mais utilizada para modelagem de sistema. Nesse post iremos nos conter
ao domínio de sistemas computacionais, mas como visto, a UML pode ser usada para modelar
qualquer coisa que possua por traz orientação a objetos.
A Unified Modeling Language, do inglês, é composta de vários tipos de diagramas que são
usados para demonstrar, graficamente, o funcionamento do sistema. Esses diagramas são
divididos em duas principais categorias: Diagramas Estruturais e Diagramas Comportamentais.

Unidade 7.2. Modelação Orientada aos Objectos

No desenvolvimento de sistemas tratamos a orientação a objetos como um paradigma de

programação, ou seja, como uma forma de se implementar um código. No entanto, este é um
tema com aplicação em diversas áreas e por este motivo as literaturas sobre o assunto podem
apresentar definições às vezes divergentes. Ampliando os horizontes, pode-se dizer que a
orientação a objetos vem antes mesmo da engenharia, ou até da tecnologia. Os mecanismos
que o cérebro humano utiliza para pensar e ver o mundo são totalmente orientados a objetos.
Percebemos isso ao notar que categorizamos e agrupamos os elementos em nossa percepção
para poder compreendê-los, exatamente como fazemos em uma análise orientada a objetos.

Unidade 7.3. Modelação Estrutural

Entre os conjuntos de diagramas da UML (Unified Modeling Language) estão os diagramas

estruturais, utilizados para visualizar, especificar, construir e documentar os aspectos estáticos
de um sistema. Este artigo tem como objetivo, introduzir de forma simplificada cada um dos
diagramas estruturais da UML 2.0. São eles os diagramas de Classe, Objetos, Componentes,
Implantação, Pacotes e Estrutura.
Os diagramas de estrutura são utilizados para fazer a modelagem de colaborações. Uma
colaboração descreve uma visão de um conjunto de instâncias que cooperam entre si para
executar uma tarefa específica. Da mesma forma, apresenta as ligações entre as instâncias e os
papéis que as mesmas representam para a respectiva tarefa.

Por fim, são os diagramas estruturais que definem a estrutura do sistema tanto na parte de
software, quanto de hardware. Da mesma forma, nem todos os diagramas estruturais se fazem
necessários para a documentação de um sistema, onde a seleção correta dos diagramas, bem
como a combinação destes, se torna um detalhe importante para uma modelagem eficiente.
São eles:
● Diagrama de Classes
● Diagrama de Objetos
● Diagrama de Componentes
● Diagramas de Instalação
● Diagramas de Pacotes
● Diagramas de Estrutura Composta

Unidade 7.4. Modelação Comportamental

Diagramas comportamentais são aqueles onde existe alguma alteração de comportamento das
classes. Os principais diagramas comportamentais da UML são: Diagrama de Caso de Uso,
Diagrama de Seqüência e Diagrama de Atividade. Este artigo tem o objetivo de descrever as
principais características destes diagramas.
Os diagramas comportamentais demonstrados aqui são uma pequena parte do que a linguagem
UML pode trazer, apesar disso, esses diagramas são muito úteis para se ter uma melhor
visualização do funcionamento (ou comportamento) do sistema.
Individualmente o diagrama de caso de uso auxilia e facilita a comunicação entre o cliente e o
analista de sistemas, e os diagramas de estado e atividade podem ser muito úteis para alterações
posteriores já que demonstram as funcionalidades do sistema onde é possível visualizar o que
pode ser alterado e não ocasionar erros em partes do sistema que estão funcionando.
São eles:
● Diagrama de Caso de Uso
● Diagrama de Sequência
● Diagrama de Estados
● Diagrama de Atividades
● Diagrama de Comunicação

Bibliografia

VER EM ANEXO
TEMA VIII: MODELAÇÃO ESTRUTURAL CLASSES E
RELACIONAMENTOS

Unidade 8.1. INTRODUÇÃO. Diagrama de classes e relacionamentos

Em programação, um diagrama de classes é uma representação da estrutura e relações das

classes que servem de modelo para objetos. Podemos afirmar de maneira mais simples que
seria um conjunto de objetos com as mesmas características, assim saberemos identificar
objetos e agrupá-los, de forma a encontrar suas respectivas classes. Na Unified Modeling
Language (UML) em diagrama de classe, uma classe é representada por um retângulo com três
divisões, são elas: O nome da classe, seus atributos e por fim os métodos. Vejam abaixo na
Figura sua representação:

Porque é tão importante encontramos as classes para o desenvolvimento de um sistema? É

simples, pois cada classe do diagrama representa uma tabela do banco de dados, por esse
motivo é tão importante encontrarmos. Observe também que para identificar-se uma classe,
precisamos antes identificar seus objetos com características semelhantes.

Perspectivas
Um diagrama de classes pode oferecer três perspectivas, cada uma para um tipo de observador
diferente. São elas:
Conceitual
● Representa os conceitos do domínio em estudo.
● Perspectiva destinada ao cliente.

Especificação
● Tem foco nas principais interfaces da arquitetura, nos principais métodos, e não como
eles irão ser implementados.
● Perspectiva destinada as pessoas que não precisam saber detalhes de desenvolvimento,
tais como gerentes de projeto.
Implementação - a mais utilizada de todas
● Aborda vários detalhes de implementação, tais como navegabilidade, tipo dos atributos,
etc.
● Perspectiva destinada ao time de desenvolvimento.
Um diagrama de classes contém:
Entidades
● Classe
Representação gráfica

Classe Concreta
Uma classe é representada na forma de um retângulo,
contendo duas linhas que separam 3 partes. A primeira
contém no nome da classe, a segunda os atributos da classe
e a última os métodos da mesma.

Classe Abstrata
A representação de uma classe abstrata em UML é quase
igual à representação de uma classe concreta, a única
diferença é o estilo da fonte do nome da classe, que, neste
caso, está em itálico.

● Interface
Representação Gráfica

Representação Icon

Representação Label

Perspectivas:
● Conceitual
Apenas classes são utilizadas. Neste tipo de perspectiva, uma classe é interpretada como
um conceito. Apenas atributos são utilizados.
● Especificação
Tanto classes como interfaces são utilizados neste tipo de perspectiva. O foco consiste
em mostrar as principais interfaces e classes juntamente com seus métodos.
Não é necessário mostrar todos os métodos, pois o objetivo deste diagrama nesta
perspectiva é prover uma maior entendimento da arquitetura do software a nível de
interfaces.
● Implementação
Nesta perspectiva, vários detalhes de implementação podem ser abordados, tais como:
○ visibilidade de atributos e métodos;
○ parâmetros de cada método, inclusive o tipo de cada um;
○ tipos dos atributos e dos valores de retorno de cada método.

Relacionamentos
● Papel
● Descreve o relacionamento.

Multiplicidade (utilizado em todas as

perspectivas de forma uniforme)
Notações possíveis

Tipos Significa

0..1 Zero ou uma instância. A notação n..m indica n para

m instâncias.
 0..* ou * Não existe limite para o número de instâncias.

1 Exatamente uma instância.

1..* Ao menos uma instância.

Exemplos:

● Associação (utilizado em todas as perspectivas)

Representação Gráfica
Associação

Perspectiva:
● Conceitual
Define um relacionamento entre duas entidades conceituais do sistema.
● Especificação
Define responsabilidades entre duas classes. Implica que existem métodos que tratam
desta responsabilidade.
● Implementação
Permite saber quem está apontando para quem, através da representação gráfica da
navegabilidade. Além disto, é possível compreender melhor de que lado está a
responsabilidade.

Herança ou Generalização (utilizado em todas as perspectivas)

● Representação Gráfica

Perspectiva:
Seja B uma generalização (extensão) de A.
○ Conceitual
Considera que B é um subtipo ou um tipo especial de A. O que é válido para A,
também é válido para B.
 ○ Especificação
Ocorre uma herança de interface.
○ Implementação
Ocorre uma herança de implementação.
● Exemplo de uma herança de implementação:

Navegabilidade (utilizado apenas na

perspectiva de implementação)
Um relacionamento sem navegabilidade implica que ele pode ser lido de duas formas, isto é,
em suas duas direções. Ex.:

Uma empresa possui um trabalhador, como também um trabalhador trabalha em uma empresa.
Utilizando a propriedade de navegabilidade, podemos restringir a forma de ler um
relacionamento. Isto é, em vez de termos duas direções, teremos apenas uma direção (de acordo
com a direção da navegação). Ex.:

Uma empresa possui um trabalhador.

● Agregação (utilizado apenas na perspectiva de implementação)
● Definição
Agregação é uma associação em que um objeto é parte de outro, de tal forma que a
parte pode existir sem o todo.
Em mais baixo nível, uma agregação consiste de um objeto contendo referências para
outros objetos, de tal forma que o primeiro seja o todo, e que os objetos referenciados
sejam as partes do todo.
A diferença entre os relacionamentos de associação e agregação ainda é algo de bastante
discussão entre os gurus. De forma geral, utiliza-se agregação para enfatizar detalhes
de uma futura implementação (perspectiva de implementação).
Representação gráfica
 Agregação com navegabilidade

Composição (utilizado apenas na perspectiva de

implementação)
Definição
Em mais baixo nível, em termos de passagem por parâmetro, seria uma passagem por
valor. Enquanto que agregação seria uma passagem por referência.
O todo contém as partes (e não referências para as partes). Quando o todo desaparece,
todas as partes também desaparecem.
Representação Gráfica

● Implementação (utilizado apenas na perspectiva de implementação)

Em Inglês: realization
Definição
Utilizado para indicar que uma classe implementa uma interface
Representação Gráfica

Exemplo

Implementação de uma interface Implementação de uma

representada por um círculo interface representada por um
retângulo
Bibliografia

VER EM ANEXO
TEMA IX: MODELAÇÃO COMPORTAMENTAL

Unidade 9.1. INTRODUÇÃO. Modelação Comportamental

Diagramas comportamentais são aqueles onde existe alguma alteração de comportamento das
classes. Os principais diagramas comportamentais da UML são: Diagrama de Caso de Uso,
Diagrama de Seqüência e Diagrama de Atividade. Este artigo tem o objetivo de descrever as
principais características destes diagramas.
Os diagramas comportamentais demonstrados aqui são uma pequena parte do que a linguagem
UML pode trazer, apesar disso, esses diagramas são muito úteis para se ter uma melhor
visualização do funcionamento (ou comportamento) do sistema.
Individualmente o diagrama de caso de uso auxilia e facilita a comunicação entre o cliente e o
analista de sistemas, e os diagramas de estado e atividade podem ser muito úteis para alterações
posteriores já que demonstram as funcionalidades do sistema onde é possível visualizar o que
pode ser alterado e não ocasionar erros em partes do sistema que estão funcionando.

Unidade 9.2. Diagramas de Use Case

Objetivo
O Diagrama de Use Cases tem o objetivo de auxiliar a comunicação entre os analistas e o
cliente.
Um diagrama de Use Cases descreve um cenário que mostra as funcionalidades do sistema do
ponto de vista do usuário.
O cliente deve ver no diagrama de Use Cases as principais funcionalidades de seu sistema.
Notação
O diagrama de Use Cases é representado por:
● atores;
● use cases;
● relacionamentos entre estes elementos.
Estes relacionamentos podem ser:
● associações entre atores e use cases;
● generalizações entre os atores;
● generalizações, extends e includes entre os use cases.
Estes use cases podem opcionalmente estar envolvidos por um retângulo que representa os
limites do sistema.
Em maiores detalhes:
● Atores

Um ator é representado por um boneco e um rótulo com o nome do

ator. Um ator é um usuário do sistema, que pode ser um usuário
humano ou um outro sistema computacional.

● Use case

Um use case é representado por uma elipse e um rótulo com o nome

do use case. Um use case é uma funcionalidade do sistema.

● Relacionamentos
○ Ajudam a descrever os use cases
○ Entre um ator e um use case
■ Associação

Define uma funcionalidade do sistema

do ponto de vista do usuário.

○ Entre atores
■ Generalização

- Os use cases de B são também use cases de A

- A tem seus próprios use cases

○ Entre use cases

■ Include
Um relacionamento include de um use case A para um use case B indica
que B é essencial para o comportamento de A.
■ Extend
Um relacionamento extend de um use case A para um use case B indica
 que o use case A pode ser acrescentado para descrever o comportamento
de B (não é essencial). A extensão é inserida no ponto de extensão do
use case B.
Ponto de extensão em um use case é uma indicação de que outros use
cases poderão ser adicionados a ele. Quando o use case for invocado, ele
verificará se suas extensões devem ou não serem invocadas.
■ Generalização ou Especialização (é_um)
Use case B é_um use case A (A é uma generalização de B, ou B é uma
especialização de A).
Um relacionamento entre um use case genérico para um mais específico,
que herda todas as características de seu pai.

Relac onamento/ Extend Include Generalização

Propriedade

Comportamento base Use case base Use case base Use case Pai

Comportamento Use case de Use case de inclusão Use case Filho

adicionado extensão

Direção O use case de O use case base O use case filho

extensão referencia referencia o use case referencia o use case
o use case base de inclusão pai

O comportamento do O use case base é A execução do use O comportamento

use case base é independende do case base executa o do use case pai não é
modificado pelo use case extensão, use case de inclusão. modificado. Os
comportamento do use mas se este for Portanto, este efeitos do novo
case adicionado? invocado, o modifica o comportamento só
comportamento do comportamento do são observados no
use case base será use case base. use case filho.
modificado.
O novo use case é Não. Não. Sim.
diretamente
instanciável?

O novo use case pode Pode acessar e O use case base Acessar e modificar.
ver os atributos do use modificar. provê os atributos
case base? necessário para o
use case de inclusão.

O use case base pode ver Não. O use case Sim, mas não pode Não. O pai é
o novo use case? base é independente acessar os seus independente do
do filho. atributos. filho.

Repetição Depende da Uma única vez. O use case controla

condição. sua própria
execução.

● Sistema
○ Limites do sistema: representado por um retângulo envolvendo os use cases que
compõem o sistema.
○ Nome do sistema: Localizado dentro do retângulo.
Exemplo 1
Exemplo 2
Unidade 9.2. Diagramas de Interacção (sequência e colaboração)

Diagramas de Interação são modelos que descrevem como grupo de objetos colaboram em um
determinado comportamento.
Um diagrama de interação captura o comportamento entre objetos dentro um único use case.
Utiliza-se o diagrama de atividade para representar o comportamento de objetos entre vários
use cases.

Tipos:
● Diagrama de Sequência
● Diagrama de Colaboração

Diagrama de Sequência
Consiste em um diagrama que tem o objetivo de mostrar como as mensagens entre os objetos
são trocadas no decorrer do tempo para a realização de uma operação.
Em um diagrama de seqüência, os seguintes elementos podem ser encontrados:
● Linhas verticais representando o tempo de vida de um objeto (lifeline);
● Estas linhas verticais são preenchidas por barras verticais que indicam exatamente
quando um objeto passou a existir. Quando um objeto desaparece, existe um "X" na
parte inferior da barra;
● Linhas horizontais ou diagonais representando mensagens trocadas entre objetos. Estas
linhas são acompanhadas de um rótulo que contém o nome da mensagem e,
opcionalmente, os parâmetros da mesma. Observe que também podem existir
mensagens enviadas para o mesmo objeto, representando uma iteração;
● Uma condição é representada por uma mensagem cujo rótulo é envolvido por colchetes;
● Mesagens de retorno são representadas por linhas horizontais tracejadas. Este tipo de
mensagem não é freqüentemente representada nos diagramas, muitas vezes porque sua
utilização leva a um grande número de setas no diagrama, atrapalhando o entendimento
do mesmo. Este tipo de mensagem só deve ser mostrada quando forfundamental para a
clareza do diagrama.
Observe a figura abaixo.
Representado processos concorrentes
Este tipo de diagrama também permite representar mensagens concorrentes assíncronas
(mensagens que são processadas em paralelo sem um tempo definido para a sua realização).
Exemplo:

Diagrama de colaboração
A grande diferença entre um diagrama de colaboração e um de seqüência consiste no fato de
que o tempo não é mais representado por linhas verticais, mas sim através de uma numeração,
que pode ser de duas formas:
● simples (1,2,3,...)
● composta (1.1, 1.2, 1.2.1, ...)
Um objeto é representado como um retângulo, contendo no seu interior um rótulo, que informa
o nome do objeto e o nome da classe, separados por dois pontos. Detalhe: ambos podem ser
omitidos.
A troca de mensagens entre os objetos segue o mesmo padrão que o apresentado nos diagramas
de seqüência.
Veja o exemplos abaixo:

Unidade 9.2. Diagramas de Transição de Estado

Em um diagrama de estado, um objeto possui um comportamento e um estado.

O estado de um objeto depende da atividade na qual ele está processando.
Um diagrama de estado mostra os possíveis estados de um objeto e as transações responsáveis
pelas suas mudanças de estado.
Exemplo:
Descrição do exemplo: Modelagem do sistema de login. Para que o usuário seja autenticado,
ele deve fornecer dois valores: SSN (Social Security Number) e o PIN (Personal ID Number).
Após a submissão é feita uma validação.
Diagrama de estado para o objeto Login.

Um diagrama de estados pode estar aninhado.Estados relacionados podem estar agrupados em

um único estado.
Exemplo:
Descrição do exemplo: um sistema de leilão. Para que um lance seja efetuado com sucesso, a
oferta tem que ser válida e o cliente tem que ter crédito suficiente.
Unidade 9.2. Diagramas de Actividade

O objetivo do diagrama de atividades é mostrar o fluxo de atividades em um único processo.

O diagrama mostra como um atividade depende uma da outra.
Um diagrama de atividade pode ser regiões denominadas swimlanes. Estas regiões esão
associadas a um objeto do modelo. Desta forma, dentro de cada região, encontram-se as
atividades relativas ao objeto da região.
As atividades são conectadas através de arcos (transições), que mostram as dependências entre
elas.
Exemplo:
Descrição do exemplo: Retirando dinheiro de um caixa eletrônico (para cartões de crédito).
Bibliografia

VER EM ANEXO

TEMA X: MODELAÇÃO ARQUITECTURAL

Unidade 10.1. INTRODUÇÃO. Deployment (Instalação)

O Diagrama de Implantação é o diagrama com a visão mais física da UML (GUEDES, 2007).
Este diagrama foca a questão da organização da arquitetura física sobe a qual o software irá ser
implantado e executado em termos de hardware, ou seja, as máquinas (computadores pessoais,
servidores etc.) que suportam o sistema, além de definir como estas máquinas serão conectadas
e por meio de quais protocolos se comunicarão e transmitirão as informações. Os elementos
básicos deste diagrama são os Nós, que representam os componentes, Associações entre Nós,
que são as ligações entre os Nós do diagrama, e os Artefatos, representações de entidades
físicas do mundo real. Veremos cada um dos componentes que compõem o Diagrama de
Implantação a seguir.
Nós são componentes fundamentais do Diagrama de Implantação. Um nó pode ilustrar um item
de hardware, como um servidor em que um ou mais módulos do software são executados ou
que armazene arquivos consultados pelos módulos do sistema, ou pode representar um
ambiente de execução, ou seja, um ambiente que suporta o sistema de alguma forma.

Nós podem conter outros nós, sendo comum encontrar um nó que representa um item de
hardware contendo outro nó que representa um ambiente de execução, embora nó que
represente um item de hardware possa conter outros nós representando itens de hardware, e um
nó que represente um ambiente de execução possa conter outros ambientes de execução.

Quando um nó representa um hardware, deve possuir o estereótipo <>; quando, porém, um nó

representa um ambiente de execução, pode utilizar o estereótipo <>. A Figura 1 apresenta
exemplo de utilização de nó para representar um item de hardware. Outros exemplos de
ambientes de execução são os sistemas operacionais ou sistemas e banco de dados.
Os estereótipos são um dos três mecanismos de extensão da UML. Eles dão mais poder à UML,
permitindo classificar elementos "com algo em comum" (Wikipédia).

Os Nós possuem ligações físicas entre si de forma que possam se comunicar e trocar
informações. Essas ligações são chamadas associações e são representadas por retas ligando
um Nó a outro. Uma associação pode conter estereótipos utilizados para determinar, por
exemplo, o tipo de protocolo e comunicação utilizado entre os nós.
A Figura abaixo demonstra um exemplo de associação entre o Nó que representa o Servidor de
Comunicação e o Nó que representa o Servidor de Firewall. O protocolo de comunicação é
descrito na Associação como um estereótipo <<TCP/IP>>.

Figura. Exemplo de Nó (GUEDES, pg. 162, 2007)

Figura. Exemplo de associação entre Nós (GUEDES, pg. 162, 2007)

Figura. Exemplo de Diagrama de Implantação (adaptado Guedes, 2007)

Figura. Diagrama de Componentes do Sistema de Controle de Submissões (adaptado de

GUEDES, 2007)
Na edição 67 da SQL Magazine, apresentamos o Diagrama de Componentes. O Diagrama de
Componentes, como o próprio nome sugere, apresenta a identificação dos componentes que
compõem um sistema, subsistema ou mesmo componentes ou classes internas de um
componente individual. Para maiores detalhes, leia os artigos anteriores da série Utilizando
UML.[/nota]
Exemplo de Diagrama de Implantação
Os Diagramas de Implantação são conhecidos, principalmente, pela sua simplicidade e
facilidade de compreensão. Como facilitador, apresentaremos um exemplo de Diagrama de
Implantação referente à arquitetura física necessária para suportar um Sistema de Controle de
Submissões (ver Figura 3).
O exemplo apresentado na Figura 3 é o mesmo modelado na edição 67 da SQL Magazine. O
sistema que estamos modelando representa um processo de submissão de artigos à edição de
um periódico.
A Figura 3 demonstra as associações existentes entre os vários Nós, que representam cada um
dos hardwares existentes na arquitetura de implantação do sistema. Através deste diagrama,
notamos que a comunicação entre o Nó Hardware do Autor, equipamento utilizado pelo autor
para desenvolver o artigo, e o Nó Servidor de Aplicação I, equipamento instalado do lado do
servidor onde a aplicação Sistema de Controle de Submissões está instalada, passa pelos Nós
Servidor de Comunicação, equipamento que garantirá a boa performance e zelará pela
transmissão e recepção dos dados, e Servidor de Firewall, responsável pela proteção da
arquitetura do sistema. Podemos notar que após a comunicação com o Nó Servidor de
Aplicação I, há a comunicação com os Nós Servidor de Banco de Dados, onde ocorre a
persistência e gestão dos dados do sistema, e o Nó Servidor de Aplicação II, que neste contexto
representa um modelo de balanceamento ou de administração de sistemas de apoio, como por
exemplo, ferramentas de controle administrativo.
Podemos obter também através da leitura deste diagrama o Protocolo de comunicação adotado
entre os vários Nós, representado pelo estereótipo <<TCP/IP>>.
A Figura apresenta o Diagrama de Componentes equivalente aos módulos executáveis do
Sistema de Controle de Submissões que estamos modelando.
Alguns módulos não são exatamente executáveis, como é o caso do componente que representa
a página de submissão de artigos, ou pertencem exclusivamente ao sistema, como o
componente que representa o Sistema Gerenciador de Banco de Dados, mas são indispensáveis
para o funcionamento do mesmo.
Figura. Exemplo de Artefato implementado em um Nó

Figura. Exemplo de Artefato manifestado a partir de um Componente

Podemos observar a utilização dos relacionamentos entre componentes por meio de Interfaces
Fornecidas e Requeridas, onde podemos notar, por exemplo, que o componente Sistema de
Gerenciamento de Banco de Dados é Interface Fornecida por outros oito componentes:
Gerenciador de Login, Gerenciador de Submissões do Autor, Cadastro de Avaliadores,
Cadastro de Temas, Gerenciador de Avaliações, Relatório de Avaliações, Notificação de Autor
e Gerenciador de Submissões do Coordenador. O componente Página Eletrônica de Submissão
de Artigos é o componente inicial deste diagrama. Percebemos isso porque é através dele que
o Submissor tem o acesso a executar o componente Controlador de Submissões. O componente
Controlador de Submissões é Interface Provida pelo componente Página Eletrônica de
Submissão de Artigos, e Interface Requerida para os componentes Gerenciador de Login e
Gerenciador de Submissões do Autor.
[subtitulo]Artefatos[/subtitulo]
Um artefato é uma entidade física, um elemento concreto que existe realmente no mundo real,
assim como os nós que o suportam. Um artefato pode ser um arquivo fonte, um arquivo
executável, um arquivo de ajuda, um documento de texto etc. Um artefato deve estar
implementado em um Nó.
componente e o artefato, contendo o estereótipo <<manifest>>, significando que o artefato é
uma representação do componente do mundo real.

Figura. Artefato implementado em um Nó (adaptado de GUEDES, 2007)

No artigo publicado na edição 64 da SQL Magazine, abordamos a definição e a estrutura do
Diagrama de Sequência. O Diagrama de Sequência serve para representar a ordem temporal
em que as mensagens são trocadas entre os objetos envolvidos em determinado processo. Um
diagrama de sequência mostra a colaboração dinâmica entre os vários objetos de um
sistema.[/nota]
Figura. Especificação de Implantação
Outra forma de manifestar um artefato contido em um Nó, segundo Guedes em seu livro UML
- Guia Prático, é utilizar um relacionamento de dependência, contendo o estereótipo <> entre
o nó e os artefatos.
Um Nó pode conter componentes da mesma forma que artefatos, como uma maneira de
demonstrar em que lugar os componentes poderão ser localizados no hardware que suportará
o sistema.
Especificação de Implantação
A Especificação de Implantação especifica um conjunto de propriedades que determinam
parâmetros de execução de um artefato implementado em um Nó.

Bibliografia
VER EM ANEXO
TEMA XI: GESTÃO E ORGANIZAÇÃO DE MODELOS (DIAGRAMAS
DE PACKAGE)

Unidade 11.1. INTRODUÇÃO. Modelos

Para RICARTE (2001), no desenvolvimento de pequenas aplicações Java, pode ser viável
manter o código em um mesmo diretório. Entretanto, para aplicações maiores, colocar todos
os arquivos em um mesmo local, sem organização, pode aumentar a possibilidade de colisão
de classes (classes com o mesmo nome no mesmo escopo) e dificultar a localização de um
determinado código.
Em Java, a solução para esses problemas está na organização de classes em pacotes. Um pacote
ou package na tecnologia Java nada mais é do que um conjunto de classes localizadas na mesma
estrutura hierárquica de diretórios. Usualmente, são colocadas em um package classes
relacionadas, construídas com um propósito comum para promover a reutilização de código;
assim, sobre certos aspectos, os packages reproduzem a ideia das bibliotecas de código
(libraries e units), de outras linguagens de programação.
Na programação Java a reutilização de código pode ser apoiada pela construção de pacotes de
classes com métodos destinados a solucionar tarefas bastante corriqueiras, como por exemplo,
validação de CPF e CNPJ, operações com data, manipulação de vetores, cálculos matemáticos
como médias e percentuais, entre outras.
O próprio código base da tecnologia Java está todo estruturado em pacotes, como pode ser
observado na especificação da API (Application Programming Interface, ou Interface de
Programação de Aplicações) da plataforma Java SE, apresentada parcialmente na Tabela
abaixo.
Assim, no desenvolvimento de novos sistemas, os programadores Java podem escolher entre
as inúmeras classes da API do Java e classes disponibilizadas em pacotes implementadas por
terceiros, de modo que a quantidade de código realmente novo a ser implementado seja
minimizada, acelerando o processo de desenvolvimento de aplicações (RAD – Rapid
Application Development).
Pretende-se demonstrar como organizar um conjunto de classes relacionadas em pacotes, como
realizar a distribuição dos pacotes através de um arquivo JAR (Java ARchive) e como
implementar a importação de uma ou mais classes de um pacote conhecido.
Os estudos de casos que serão apresentados foram implementados usando o ambiente de
desenvolvimento NetBeans e estão estruturados, como mostra a Figura 1, em dois projetos
denominados de “Pacotes” e “UsandoPacotes”. No primeiro projeto (Pacotes), as classes
Matematica, FuncaoMatematica e Vetor foram organizadas em dois pacotes:
pr.com.profomero.pacoteum e pr.com.profomero.pacotedois. Já no segundo projeto
(UsandoPacotes), as aplicações Exemplo1, Exemplo2 e Exemplo3 utilizam as classes
importadas dos pacotes definidos no primeiro projeto.

Unidade 11.2. Diagrama de pacotes

Objetivo principal: agrupar classes em pacotes.

Notação:

Pacote

Dependência

Exemplo:

Bibliografia

VER EM ANEXO
TEMA XII: ESTUDO DE CASOS

Unidade 12.1. INTRODUÇÃO. Estudo de casos

A qualidade em sistemas de software passa pela qualidade das especificações e modelagem

destes sistemas. Neste sentido, a UML apresenta uma série de diagramas para a construção de
sistemas baseados no paradigma da orientação a objetos. Neste contexto, este artigo apresenta
baseado em um estudo de caso os principais diagramas da UML.
O que são Estudos de Caso?
Estudos de caso são um método de pesquisa ampla sobre um assunto específico, permitindo
aprofundar o conhecimento sobre ele e, assim, oferecer subsídios para novas investigações
sobre a mesma temática.
No livro Estudo de Caso Planejamento e Métodos, o cientista social Robert K. Yin define o
estudo de caso como uma estratégia de pesquisa que responde às perguntas “como” e “por que”
e que foca em contextos da vida real de casos atuais.
Também o considera como uma investigação empírica que compreende um método
abrangente, com coleta e análise de dados.
Mas Yin não é o único autor a dar a sua definição sobre os cases.
William Goode diz que o estudo de caso é um meio de organizar os dados, preservando do
objeto estudado o seu caráter único.

Para que servem os Estudos de Caso?

Normalmente, toda pesquisa ou investigação parte de de um modelo a seguir, o qual serve de
referência para o novo trabalho.
Em um primeiro momento, é justamente para isso que servem os estudos de caso: eles são
modelos referenciais.
Sabemos que cada caso tem sua particularidade, ou seja, é único.
Mas as experiências de quem já trilhou um caminho parecido, sendo elas transmitidas a quem
está começando agora, diminuem bastante as chances de erro.
Por outro lado, os objetivos de um estudo de caso podem variar conforme a área na qual são
utilizados.
Quando focam na inovação, por exemplo, mantém o caráter de referência, servindo até mesmo
como uma ação de benchmarking, a partir da qual negócios buscam aprender com as melhores
práticas do mercado.
Na área acadêmica, podem ser solicitados como pré-requisito para cursos de graduação ou pós-
graduação.
Nesses casos, têm o propósito de atestar a capacidade do aluno de investigar um problema e de
propor soluções.

Vantagens dos Estudos de Caso

Ao conhecer detalhes sobre os estudos de caso e suas aplicações, algumas vantagens já ficam
claras.
● Usar o mesmo método em áreas diferentes: você pode aproveitar a estrutura de um caso
para aplicar em outro
● Ter rico conhecimento a partir da exploração intensa de um único caso: você pode usar
um estudo de caso pronto para explorar contextos diferentes
● Aperfeiçoar serviços a partir de experiências de sucesso: cases são referências para não
se começar do zero
● Informações detalhadas baseadas em situações da vida real: pesquisas baseadas em
vivências e fatos são mais atrativas e aplicáveis à própria realidade
● Conceder autoridade sobre determinado assunto: com exemplos de estudos de casos,
seu autor constrói autoridade e pode se tornar referência sobre um assunto, informação
ou produto.

Bibliografia

VER EM ANEXO
TEMA XIII: ESTUDO DE UM AMBIENTE DE SUPORTE AO
DESENVOLVIMENTO DE SISTEMAS DE INFORMAÇÃO
MODELADOS EM UML

Unidade 13.1. INTRODUÇÃO. Ambiente

DE, ou ambiente de desenvolvimento integrado, é um software que combina ferramentas

comuns de desenvolvimento em uma única interface gráfica do usuário (GUI), facilitando o
desenvolvimento de aplicações. Um IDE geralmente consiste em:
Editor de código-fonte: é um editor de texto que auxilia na criação de código de software por
meio de funcionalidades como destaque da sintaxe com indicadores visuais, recurso de
preenchimento automático específico da linguagem e verificação de bugs durante a criação.
Automação de compilação local: são utilitários que automatizam tarefas simples e repetíveis
durante a criação de uma compilação local do software usada pelo desenvolvedor. São tarefas
como compilação de código-fonte em código binário, criação de pacotes de código binário e
execução de testes automatizados.
Debugger: é um programa usado para testar outros programas e mostrar graficamente a
localização do bug no código original.

Para que serve um IDE?

Os ambientes de desenvolvimento integrado ajudam os desenvolvedores a programar novas
aplicações de forma rápida, já que os vários utilitários não precisam ser ajustados e integrados
manualmente durante a configuração. Os desenvolvedores também não precisam passar horas
aprendendo a usar cada uma das diferentes ferramentas, porque cada utilitário está localizado
no mesmo workbench. Isso é especialmente útil quando há desenvolvedores novos em um
projeto. Eles podem contar com o IDE para se atualizar em relação às ferramentas e fluxos de
trabalho da equipe. Na verdade, o objetivo da maior parte das funcionalidades é economizar
tempo: o preenchimento inteligente e a geração automática de código, por exemplo, eliminam
a necessidade de digitar sequências inteiras.

Quais as vantagens de um IDE?

Outras funcionalidades comuns aos IDEs têm o objetivo de ajudar os desenvolvedores a
organizar seu fluxo de trabalho e solucionar problemas. Os IDEs analisam o código no
momento em que está sendo escrito. Assim, bugs causados por erro humano são identificados
em tempo real. Como todos os utilitários estão em uma única interface gráfica (GUI), os
desenvolvedores podem executar as tarefas sem precisar trocar de aplicação. A maioria dos
ambientes de desenvolvedor integrados também conta com destaque da sintaxe, usando
indicadores visuais para diferenciá-la da gramática no editor de texto. Além disso, alguns IDEs
incluem navegadores de classes e objetos, bem como diagramas de hierarquia de classes em
determinadas linguagens.
É possível desenvolver aplicações sem um IDE. O desenvolvedor também pode, basicamente,
compilar seu próprio IDE, integrando manualmente vários utilitários com um editor leve de
textos, como Vim ou Emacs. O benefício dessa abordagem é o alto nível de personalização e
controle que oferece aos desenvolvedores. No contexto empresarial, entretanto, a economia de
tempo, a padronização do ambiente e as funcionalidades de automação dos IDEs modernos
geralmente superam outros benefícios.
Atualmente, a maioria das equipes empresariais de desenvolvimento escolhe o IDE pré-
configurado que melhor serve ao seu caso de uso. A questão, portanto, não é decidir usar ou
não um IDE, e sim qual usar.

Quais são os tipos de IDE?

Existem inúmeros casos de usos técnicos e empresariais dos ambientes de desenvolvimento
integrados, portanto são muitas as opções proprietárias e open source no mercado. De modo
geral, as características mais importantes que diferenciam os IDEs são:
A quantidade de linguagens compatíveis: alguns IDEs são dedicados a uma linguagem
específica, por isso acabam sendo melhores para determinado paradigma de programação. O
IntelliJ, por exemplo, é conhecido principalmente como um IDE de Java. Outros IDEs
suportam uma vasta gama de linguagens. O Eclipse, por exemplo, é compatível com Java,
XML e Python, dentre outras.
Sistemas operacionais suportados: o sistema operacional do desenvolvedor limitará sua
escolha, exceto quando o IDE estiver na nuvem. Se a aplicação em desenvolvimento for
destinada a um usuário final com um sistema operacional específico (Android ou iOS, por
exemplo), isso também pode criar outra limitação.
Funcionalidades de automação: a maioria dos IDEs incluem editor de texto, automação de
compilação e debugger, e muitos são compatíveis com recursos adicionais, tais como
refatoração, pesquisa de código e ferramentas de integração e implantação contínua (CI/CD).
Impacto no desempenho do sistema: pode ser importante considerar o volume de memória de
um IDE se o desenvolvedor quiser executar, simultaneamente, outras aplicações que
demandem muito processamento.
Plug-ins e extensões: alguns IDEs permitem a personalização dos fluxos de trabalho,
adaptando-se às necessidades e preferências do desenvolvedor.
IDE para desenvolvimento de aplicações mobile
Praticamente todos os setores foram afetados pela crescente popularidade das aplicações para
smartphones e tablets. Além das tradicionais aplicações web, muitas empresas também
passaram a desenvolver aplicações mobile. Um dos principais fatores no desenvolvimento de
aplicações mobile é a escolha da plataforma. Por exemplo, se uma aplicação nova for usada em
iOS, Android e páginas web, talvez seja melhor usar um IDE que seja compatível com diversas
plataformas em vários sistemas operacionais.

IDE na nuvem
IDEs fornecidos na nuvem como Software como Serviço (SaaS) oferecem benefícios
exclusivos quando comparados a ambientes locais de desenvolvimento. Por exemplo, nas
soluções SaaS, não existe a necessidade de fazer o download de softwares e configurar
ambientes e dependências locais. Assim, os desenvolvedores podem começar a contribuir
imediatamente com o projeto. Isso também viabiliza um nível de padronização dos ambientes
da equipe, o que reduz problemas de incompatibilidade como "se funciona na minha máquina,
por que não funciona na sua?". Além disso, já que o gerenciamento do ambiente de
desenvolvimento é centralizado, os códigos não ficam no computador de uma só pessoa, o que
ajuda com questões de propriedade intelectual e segurança.

O impacto dos processos em máquinas locais também é diferente. Geralmente, executar

compilações e testar suites são processos intensos, por isso os desenvolvedores podem não
conseguir usar as estações de trabalho durante essas operações. Um IDE SaaS consegue
distribuir tarefas de longa duração sem monopolizar os recursos computacionais de uma
máquina local. Os IDEs de nuvem também não costumam depender de plataforma, permitindo
a conexão com diferentes fornecedores de nuvem.
Unidade 13.2. Geração de código a partir do ambiente e diagramas UML:
Java, JDBC

O Eclipse é uma ferramenta IDE que compreende vários tipos de linguagem e que aceita a
instalação de plugins para emular o desenvolvimento da plataforma.
Uma das principais vantagens é o uso do SWT (alternativa para quem desenvolve em SWING),
e a forte orientação ao desenvolvimento baseado em plugins ampliando o suporte do
desenvolvedor com centenas deles que procuram atender as diferentes necessidades.
Para a simulação do sistema que irá ser desenvolvido é necessário possuir o IDE Eclipse Java
EE;
Primeiramente baixe exatamente essa versão “Eclipse IDE for Java EE Developers” e escolha
para a versão Windows 32bit (mesmo se a máquina for 64bit) através da Página oficial do
Eclipse.

Figura 1. Escolhendo o sistema operacional para download

Figura 2. Escolhendo o servidor para baixar
Execução
Logo após isso, baixe e descompacte para a pasta desejada e acesse o arquivo executável
Eclipse.exe, conforme a Figura 3.

Figura 3. Arquivo executável da IDE Eclipse

Quando entrar no programa Eclipse, logo aparecerá uma opção para selecionar o local do
Workspace. O Workspace é o repositório/local dos projetos construídos pelo desenvolvedor.
Figura 4. Caminho do Workspace
Tela Boas Vindas
Visualização da tela de boas vindas

Figura 5. Tela de Boas Vindas

Após fechar a tela de boas vindas, é mostrado o Resource Workbench do Eclipse, que é onde
se encontram os recursos e ferramentas da IDE conforme a Figura 6.
Figura 6. Visão da IDE Eclipse

Unidade 13.3. Mini-projecto – Desenvolvimento de um aplicativo

A criação de um projeto pode ser feita através das opções abaixo:

● Botão Direito na aba do Project Explorer New > Project...

● Clicar no botão New (destacado com círculo em vermelho)
Figura 8. Criando projeto

Selecione Java Project e clique no botão Next:

Figura 9. Seleção do tipo de projeto

Após a ação de seleção do tipo de projeto, é avançado para a configuração do projeto

que está sendo adicionado conforme a Figura 10.
Figura 10. Página de configuração do projeto

Conforme a Figura 10 logo abaixo é mostrado cada significado da numeração

destacada na imagem.

● Project Name (Nome do Projeto) – Exemplo: ComunicacaoBanco.

 ● Location (Localização) – Define qual local da Workspace que será
armazenado.
● JRE (Java Runtime Enviroment) – Ambiente de execução do Java.
● Projeto layout - Define a estrutura do projeto.
● Working sets – Organiza o projeto, podendo criar categorias para separar as
Workspaces adicionadas, mais é uma maneira de organização.

Para criar o projeto, insira o nome do mesmo como no item 1 acima e clique no botão
Next. Após isso aparecerá a janela conforme a Figura 11.
Figura 11. Configuração do Projeto

Para adicionar uma biblioteca pode-se instalar através da janela ilustrado na Figura
11, clicando na aba Libraries.
Figura 12. Configuração Libraries (Bibliotecas)

Podemos deixar tudo padrão, apenas clique no botão Finish para criar o projeto. O
projeto deve estar parecido com a Figura 13.
´Figura 13. Visualização do projeto criado

Criando packages

Os packages também conhecidos por pacotes são criados para armazenar as classes
facilitando a organização do projeto e ajuda na reutilização de código.

Para criar uma package clique com o botão direito do mouse em cima do projeto vá
em New > Package então coloque o nome e clique no botão Finish.
Figura 14. Criando Package

Após isso a estrutura do projeto tem que estar parecida com a Figura 15.
Figura 15. Estrutura do projeto com um package

Criando uma Java Class

No bom português conhecido como “Classe” é o projeto de um objeto que armazena

as características e ação que definem seu estado e comportamento.

Na Figura 16 vamos criar uma classe testadora que irá gerar apenas uma saída.
Clique com o botão direito em cima do package e vá em New > Class, preencha
conforme a Figura 16. Observe que ao criar uma classe algumas propriedades
vieram já definidas como Source Folder (1), Package (2), SuperClass (5).
Figura 16. Criação da Classe

Para criar a classe insira o nome no indicador 3 e deixe selecionado a opção public

static void main(String[] args), onde estamos dizendo que criará uma classe de execução.
Ao término da criação da classe é gerada a tela conforme a Figura 17.
Figura 17. Exibição da classe testadora

Observe que por padrão já é inserido alguns comentários, você pode escolher em
deixá-los ou apagá-los.

Console

O Console do Eclipse é onde podem ser vistas saídas do programa através dos
objetos de saída, status dos servidos, logs de erros gerados pela aplicação entre
outros. Para mostrar o console siga os passos da Figura 18.
Figura 18. Visualização do Console

Após isso vamos gerar a saída de um texto, escreva conforme está apresentado na
Figura 19 e clique no botão Run destacado com um círculo.
Figura 19. Imprimindo um objeto de saída do console

Após essa ação pode aparecer uma tela para salvar e rodar a classe conforme a
Figura 20, apenas confirme.
Figura 20. Tela para salvar e executar a classe

Por final veja na aba do console a saída do texto que foi gerado, veja na Figura 21
o teste final.
Figura 21. Teste Final

Para finalizar estou disponibilizando alguns recursos sobre os atalhos do Eclipse,

vejam alguns deles.

Teclas de atalhos do Eclipse

Para maior produtividade é aconselhável ao programador saber de costume as teclas

de atalho para desempenhar certas ações mais rápidas. Abaixo é apresentado essa
lista, os destacados em vermelho são os mais usados.

● CTRL + SHIFT + W - Fechar todas as abas;

● CTRL + O - Localizar método / atributo em uma classe;
● CTRL + SHIFT + R - Localizar arquivos no workspace;
● CTRL + SHIFT + T - Descobrir onde estão as classes em um workspace mesmo
que dentro de um jar;
● CTRL + SHIFT + L - Lista de atalhos do Eclipse;
● CTRL + F6 - Navegar entre os arquivos abertos;
● CTRL + F7 - Navegar entre as abas da perspectiva;
● CTRL + F8 - Navegar pelas perspectivas abertas;
● CTRL + H - Pesquisa onde está sendo utilizado determinado método, basta
posicionar o cursor no método desejado;
● CTRL + SHIFT + F - Formata o código conforme os padrões setados nas
preferências do eclipse;
● CTRL + SHIFT + O - Organiza os imports da classe;
● CTRL + ALT + H - Mostra todas as ocorrências de um atributo ou método
dentro de uma classe;
● ALT + SHIFT + L - Extrai o que estiver selecionado para uma variável;
● ALT + SHIFT + M - Extrai o que estiver selecionado para um método;
● CTRL + SHIFT + C - Comentar / Descomentar um bloco de código;
● CTRL + SHIFT + / - Comentar um grande bloco de código com /* */;
● CTRL + SHIFT + \ - Descomentar um grande bloco de código com /* */;
● CTRL + I - Indenta corretamente o código conforme preferências do eclipse;
● CTRL + SHIFT + B - Inserir / excluir breakpoint na linha onde está o cursor;
● CTRL + M - Maximizar a tela de edição de código;
● CTRL + ESPAÇO - Autocompleta;
● CTRL + 1 - Correções quando há erros de compilação, para novas classes, ou
até mesmo quando precisar importar pacotes;
● CTRL + 3 - Busca um comando ou uma opção de menu baseado no que você
escreve;
Bibliografia

VER EM ANEXO