Você está na página 1de 52

PARADIGMAS DE

LINGUAGENS DE
PROGRAMAÇÃO
Bruno Zolotareff dos Santos

E-book 4
Neste E-Book:
INTRODUÇÃO���������������������������������������������� 3
ELABORAR ANÁLISES
E METODOLOGIAS DE
DESENVOLVIMENTO ÁGIL����������������������� 4
Origem dos métodos ágeis�������������������������������������6
Metodologias ágeis�������������������������������������������������8
Certificação Scrum Master���������������������������������� 12
Técnicas de Modelagem de Software����������������� 17
Projeto de Arquitetura de Software��������������������� 32
Padrões para arquitetura de software����������������� 37
Software Livre: antecedentes, histórico,
conceituação e cenário���������������������������������������� 40
Ferramentas livres para engenharia de software44

CONSIDERAÇÕES FINAIS ���������������������46


SÍNTESE�������������������������������������������������������47

2
INTRODUÇÃO
Neste módulo, abordaremos as principais metodo-
logias ágeis para o desenvolvimento de software e
arquitetura de sistemas. Além disso, conheceremos
alguns modelos utilizados para a prototipação de
sistema de software e uma breve introdução ao sof-
tware livre e suas ferramentas, que utilizam licenças
GPL e variações.

3
ELABORAR ANÁLISES
E METODOLOGIAS DE
DESENVOLVIMENTO ÁGIL
O desenvolvimento de software é um assunto tratado
sobretudo pelos Engenheiros de software. Entretanto,
a metodologia de desenvolvimento está ligada direta-
mente a um grupo de pessoas do mesmo projeto. A
complexibilidade dos projetos de software levou as
empresas a refletirem a despeito das metodologias
de desenvolvimento.

Antes das metodologias ágeis, os modelos clássicos


eram bem difundidos e utilizados. Isso até a década
de 1990.

As metodologias tradicionais eram tidas como


orientadas ao planejamento, no qual os requisitos
resumiam-se apenas a estáveis ou se havia alguma
previsão de uso no projeto. Muitas delas não foram
adotadas pelas empresas por questões de custos e
por envolver muitas vezes a falta de recursos e/ou
tecnologia, principalmente das empresas pequenas.

Nesse cenário, os modelos precisavam de alguns


esforços para arcar com os custos para adoção de
metodologias tradicionais. Então, algumas empre-
sas ficavam fora do mercado por não apresentarem
uma garantia da qualidade, também conhecida como
Quality Assurance (Qualidade Assegurada).

4
Com o tempo, as empresas perceberam que, além
dos custos, os modelos antigos eram muito burocrá-
ticos. Por essa razão, nos anos de 1990, iniciaram-
-se os primeiros indícios de metodologias conside-
radas mais leves. No entanto, foi apenas em 2001
que um grupo de engenheiros de software se reuniu
em Snowbird e definiu o nome metodologias ágeis,
publicando um manifesto que reúne as práticas do
que se considera uma metodologia ágil.

Conforme citado anteriormente, algumas dessas


metodologias já tinham sido iniciadas na década de
1990, dentre elas se destacam: Scrum, Crystal Clear,
Programação Extrema (XP), Adaptative Software
Development, Feature Driven Development (FDD),
Dynamic Systems Development Method (DSDM),
Microsoft Solutions Framework (MSF) e Lean.

A seguir, abordaremos algumas das metodologias


citadas, mas o importante é sabermos que há uma
preocupação em desenvolver projetos com qualidade
de maneira ágil. De fato, isso não é algo novo e, com
os anos, tem se tornado cada vez mais importante
para projetos de software.

Visando a entender mais simplificadamente a diferen-


ça dos modelos anteriores de metodologias para as
chamadas metodologias ágeis, precisamos entender
a diferença entre as duas formas utilizadas.

Na metodologia tradicional, o modelo era aplicado


com etapas bem definidas, ou seja, os requisitos
eram levantados e validados no projeto todo, entran-

5
do apenas os requisitos validados, mesmo aqueles
que futuramente entrariam no projeto.

No modelo de metodologia ágil, as iterações são


curtas, diferentemente do modelo tradicional, em
que elas são longas. Além disso, o modelo ágil uti-
liza ciclos iterativos e incrementais, e o resultado é
medido quando se faz a entrega do produto.

A metodologia ágil é conhecida por ter pouca ou qua-


se nenhuma documentação. Dessa maneira, o foco
principal é agregar valores reais ao produto dentro do
processo de produção. A maioria das metodologias
ágeis é formada por equipes que possuem maior
autonomia em tomar decisões e se organizar con-
forme as necessidades do projeto. Por esse motivo,
o resultado da entrega dos produtos é mais rápido
porque tem menos burocracia.

As metodologias ágeis são utilizadas no mundo in-


teiro pelo fato de elas serem eficazes e mostrarem
resultados rápidos comparados às metodologias
tradicionais. A tendência dos projetos de software
é que cada vez mais empresas de desenvolvimento
utilizem ou se adaptem ás metodologias ágeis.

Origem dos métodos ágeis


Muitos relacionam as origens da metodologia ágil
com o modelo empresarial Toyota, também conhe-
cido como Lean Manufacturing, que tinha uma sis-
tematização sem desperdícios, minimizando com

6
isso os custos. Há também uma semelhança com a
descrição iterativa escrita em um artigo por Hirotaka
Takeuchi e Ikujiro Nonaka, no qual abordam como
uma produção poderia ter um foco mais iterativo. No
entanto, nenhum desses argumentos tratava direta-
mente da metodologia ágil, são apenas especulações
que tratam de semelhanças.

A metodologia ágil surgiu em 200, na cidade


de Snowbird, Utah (EUA), onde foi lançado o
Manifesto Ágil, como citado anteriormente. Esse
manifesto foi feito por um grupo de 17 pessoas
que se reuniram para discutir os assuntos que
abordam a gestão de projeto. Ao final desse en-
contro, os integrantes assinaram um documento
para definir as características do que é a metodo-
logia ágil, que ficou conhecido como Manifesto
Ágil (Figura 1). (BRASILEIRO, s. d.).

Indvíduos e interações mais que processos e


ferramentas.

Software em funcionamento mais que


documentação abrangente.

Colaboração com o cliente mais que


negociação de contratos

Responder a mudanças mais que seguir o


plano

Figura 1: Métodos Ágeis – Manifesto Ágil. Fonte: Brasileiro (s. d.).

7
Metodologias ágeis

Scrum
Trata-se de um framework com características aplicá-
veis, iterativas e incrementais para o projeto; o Scrum
é usado em projetos grandes de alta complexibilidade
com objetivo definido, sendo o modelo mais utilizado
no mundo, em cerca de 80% dos projetos.

A metodologia Scrum caracteriza-se da seguinte for-


ma: a equipe é formada por nove membros, sendo
que um deles é o Scrum Master, o facilitador que
ajuda os membros a conseguirem terminar o proje-
to dentro dos prazos estabelecidos. O restante da
equipe trabalha em duplas, normalmente o mais ex-
periente com o menos experiente. A cada projeto, as
duplas são trocadas para obter mais experiência e
dinâmica na equipe.

A documentação normalmente é feita em um qua-


dro de tarefas, bastante conhecido como o método
Canvas. Nesse quadro, cada dupla coloca o status
em que se encontra a tarefa em desenvolvimento, a
saber: inicial, em andamento ou finalizada.

O Scrum Master e outros membros acompanham o


projeto por esse quadro. E quando algum membro
está com dificuldades na tarefa, a equipe auxilia a
dupla para que consigam realizar a tarefa ou tirar
algo que está atrapalhando o andamento do desen-
volvimento do processo.

8
Antes de começar um ciclo de projeto, o Sprint re-
aliza o Spring Planning, assim, o dono do projeto
apresenta os itens que serão tratados no produto
Backlog e o time seleciona os itens que comporão
o Sprint Backlog.
A tarefa só é passada a determinada dupla se for
algo especial que apenas aqueles membros têm o
conhecimento para resolver uma tarefa específica.
O Scrum é muito dinâmico, desta maneira, o projeto
pode ser feito por várias equipes de Scrum. A comu-
nicação dos membros é realizada em uma reunião
feita antes que a equipe comece a trabalhar nos pro-
jetos, ou seja, logo após todos chegarem à reunião,
é realizada em pé, com duração de 5 a 15 minutos
(Figura 2).

Podcast 1

Figura 2: Daily Scrum. Fonte: Vieira (2014).

9
Todos os membros são ativos e cada dupla esco-
lhe logo qual tarefa desenvolverá. A autonomia do
grupo é muito maior do que nos projetos realizados
em metodologias tradicionais, em que cada um tem
uma função específica. Na reunião, surgem algumas
perguntas básicas sobre o projeto:

O que fiz ontem que ajudou o time a atingir a meta


do sprint?

O que vou fazer hoje para ajudar o time a atingir


a meta do sprint?

Existe algum impedimento que não permita a mim


ou ao time atingir a meta do sprint?

Com essas perguntas, todos têm uma observação


geral e diária de como o projeto caminha e se está
no rumo certo para chegar aos objetivos.

A metodologia do Scrum possui o Sprint, ou seja, o


ciclo de semanas que é um ciclo de tarefas. Essas
tarefas são conhecidas como Product Backlog, que
são avaliadas e refinadas conforme o grau de relevân-
cia. As tarefas são diárias e, no final de cada Spring,
há entrega do produto (Figura 3).

10
Reunião
diária 1 dia

Sprint 2a4 Produto ou


Backlog semanas Funcionalidade
Concluída

Sprint

Product
Backlog

Figura 3: Scrum. Fonte: Vieira (2014).

Os backlogs são considerados artefatos no projeto,


pois são executados de acordo com a prioridade por
valor de negócio, o qual é determinado pelo dono do
produto (Product Owner). O envolvimento do dono do
projeto se dá diretamente com a equipe, tendo uma
resposta mais rápida na aprovação dos requisitos e
na tomada de decisão.

Os Sprints são ciclos que podem durar até um mês,


sendo que cada trabalho realizado em um Sprint gera
um valor tangível de ser realizado. Os Sprints têm
uma duração fixa (timeboxed) e cada um no projeto
deve ter a mesma duração (Figura 4).

11
Duração Fixa

Sprint 1 Sprint 2 Sprint 3 Sprint 4

Início Tempo
Duração Máxima
de 1 mês

Figura 4: Ciclo Sprints. Fonte: Vieira (2014).

Certificação Scrum Master


O Scrum Master é o membro da equipe que mais
deve conhecer os processos da metodologia e sa-
ber como aplicá-los da melhor maneira possível
para que o projeto consiga atingir seus objetivos
(METODOLOGIA ÁGIL, s. d.).

Observe que não adianta nada ter uma certificação


de Scrum Master sem ter experiência de projeto. Por
essa razão, quem se interessa por essa certificação
são pessoas que, em geral, já trabalham há algum
tempo em projetos utilizando essa metodologia.

A certificação de Scrum Master é oferecida por várias


empresas, sendo que cada uma tem suas caracte-
rísticas próprias de como essa prova é elaborada,
porém, todas visam a certificar o profissional da área.

12
Scrum Alliance: fundada pelos criadores da metodo-
logia, é a empresa que oferece a certificação Certified
Scrum Master (CSM). Além de treinamentos na área.
O curso oficial é realizado em dois dias e, assim que o
candidato consegue obter a certificação, a cada dois
anos é preciso fazer um novo teste, ou seja, revalidar.

Scrum ORG: Fundada por um dos criadores que não


concordou com algumas diretrizes de sua equipe,
criou-se o Professional Scrum Master (PSM). É uma
das certificações mais reconhecidas e recomenda-
das, justamente pelo fato de não exigir o curso oficial
para realizar a prova da certificação, cujo valor é em
média de U$150,00 (METODOLOGIA ÁGIL, s. d.).

PMI – ACP: Criada pela PMI, o instituto responsável


pelo PMBOK, temos a certificação PMI-ACP (Agile
Certified Practitioner). É procurada mais por profis-
sionais que têm a certificação PMP, pois seu custo
é elevado quando comparado a outras.

SCRUMStudy: Idealizada por uma empresa indiana


em 2013. Dentre suas certificações estão: Scrum
Fundamentals Certified (SFC), Scrum Master Certified
(SMC), Scrum Product Owner Certified (SPOC) e
Scrum Developer Certified (SDC).

EXIN: É uma empresa muito conhecida no mer-


cado por oferecer a certificação ITIL, Agile Scrum
Foundations (ASF) e Agile Scrum Master (ASM). O
custo das provas fica entre US$ 200 e US$ 300.

13
XP

Metodologia semelhante ao Scrum, a eXtreme


Programming (programação extrema), mais comu-
mente chamada de XP, foi desenvolvida em 1996 por
Kent Beck e tem como objetivo o uso de alguns valo-
res: comunicação, simplicidade, feedback, coragem
e respeito. Além disso, mantém o foco no escopo do
projeto (TELES, 2017).

Considerada uma metodologia ágil, é muito usada


em projetos pequenos, porém, há casos de seu uso
em grandes empresas, como a Chrysler dos EUA. A
XP possui os seguintes princípios básicos: Feedback
rápido, presunção de simplicidade, mudanças incre-
mentais, envolvimento de mudanças e trabalho de
alta qualidade.

A equipe de XP pode variar de dois a dez membros


que, semelhante ao Scrum, trabalham em pares e
todos devem ser proativos. Para a utilização de proje-
tos de softwares, há uma série de práticas realizadas
descritas na Tabela 1.

Práticas Descrição
Jogo de planeamento Desenvolvimento é feito em iterações
(Planning game) semanais.

Pequenas versões (Small Liberação de pequenas versões


releases) funcionais.

Metáfora Procura facilitar a comunicação com o


(Metaphor) cliente.

Projeto simples (Simple Adoção de práticas simples como a


design) primeira versão do software apenas para
avaliação.

14
Práticas Descrição
Time coeso Equipe é formada pelo cliente e pela
(Whole team) equipe de desenvolvimento.

Testes de aceitação Testes construídos pelo cliente em


(Customer tests) conjunto com analistas e testadores.

Ritmo sustentável Trabalho com qualidade, buscando ter


(Sustainable pace) ritmo de trabalho saudável (40 horas/
semana, 8 horas/dia).

Reuniões em pé (Stand-up Abordagem de tarefas realizadas e tare-


meeting) fas a realizar pela equipe.

Posse Coletiva (Collective Objetivo é fazer a equipe conhecer todas


ownership) as partes do sistema.

Programação em pares (Pair Programação em par/dupla em um


programming) único computador.

Padrões de codificação Equipe de desenvolvimento precisa


(Coding standards) estabelecer regras para programar e
todos devem seguir tais regras.

Desenvolvimento orientado Primeiramente, crie os testes unitários


a testes (unit tests) e, depois, crie o código para
(Test driven development) que os testes funcionem.

Refatoração (Refactoring) Processo que permite a melhoria contí-


nua da programação, com o mínimo de
introdução de erros.

Integração Contínua Sempre que se realiza uma


(Continuous integration) funcionalidade.

Tabela 1: Práticas no XP. Fonte: Souza (2007).

Feature Driven Development

O Feature Driven Development (FDD) é uma me-


todologia criada em 1997 em um grande projeto
conduzido em Java para o United Overseas Bank
em Singapura. Seu anúncio foi publicado em Java
Modeling in Color with UML: Enterprise components
and process, por Peter Coad, Eric LeFebvre e Jeff de
Luca (SANTOS, 2019).

15
Trata-se de uma metodologia ágil que utiliza diagra-
mas de classe da Unified Modeling Language (UML)
e que se completam com diagramas de sequência
para descreverem a interação dos objetos. Após
a identificação das funcionalidades do sistema,
realizadas pelos clientes, as funcionalidades são
utilizadas para guiar o desenvolvimento no FDD,
tarefas realizadas no máximo em duas semanas.

Para seu desenvolvimento, cada classe possui um


responsável, sendo que a equipe de FDD possui,
no mínimo, três membros e, no máximo, seis mem-
bros. Durante o desenvolvimento, são realizadas as
inspeções com vistas a assegurar a qualidade do
código e suas funcionalidades.

Os principais membros da equipe são Gerente de


projeto, Arquiteto chefe, Gerente de desenvolvimen-
to, Programador chefe, proprietário de classe e es-
pecialista do domínio. Os adicionais são Testador,
desenvolvedor e escritor técnico.

Microsoft Solutions Framework


O Microsoft Solutions Framework (MSF) é uma me-
todologia ágil que combina os Modelos cascata e
espiral: do cascata (Waterfall), baseia-se no plano
e no resultado; quanto ao espiral, nos benefícios de
feedback e na criatividade (Figura 5).

16
Deployment
Complete

End
ing ivi
oy si
Release pl Vision/Scope

on
De
Readiness Approved

ing
Approved

MSF
S t a b ili

nin g
an
zi n

Pl
g

De
velo pin g
Scope Project Plans
Complete Approved

Figura 5: Visão geral do Microsoft Solutions Framework. Fonte:


Devmedia.

Técnicas de Modelagem de
Software
A modelagem de software é um processo realizado
por modelos abstratos e representados por diagra-
mas, em que cada um apresenta uma visão diferente
do sistema. Os modelos utilizados para software são
normalmente da UML (SOMMERVILLE, 2018).

A UML possui diversos diagramas que auxiliam no


desenvolvimento do software. Tal qual um engenhei-
ro utiliza plantas para construir um edifício, o enge-
nheiro de software modela o software com a ajuda
de diagramas.

Há diversos tipos de modelo na UML - até a versão


mais recente da UML 2.2 - divididos em duas catego-

17
rias, estruturais (sete diagramas) e comportamentais
(sete diagramas):

Diagramas de estrutura: diagramas de classes, de


componentes, de objetos, de perfil, de estruturas
compostas, de implantação e de pacotes.

Diagramas de comportamentos: diagramas de ati-


vidades, de caso de uso, de iteração, de máquina de
estados, de sequência, de comunicação, de visão
geral de interação e de tempo.

Dentre esses modelos, abordaremos os diagramas


de caso de uso, de sequência e o de classe. Cada
modelo tem sua importância em determinados pro-
jetos, mas os aqui selecionados são muito utilizados
no paradigma de programação orientado a objetos.

O caso de uso é um diagrama de fácil entendimento.


Basicamente, demonstra a interação do ator com os
artefatos do sistema; sua notação é simples, ou seja,
considerada de pouca complexidade.

Já o diagrama de sequência auxilia a representação


do fluxo de informações no sistema, no qual cada
ação disparada mantém uma sequência de eventos
até atingir seu objetivo. Por exemplo, é possível co-
locar todo o trâmite da ação de apertar um botão em
uma máquina de refrigerante.

Quanto ao diagrama de classe, este está inter-rela-


cionado com a programação orientada a objetos.
É o modelo mais utilizados pelos programadores
dado que representa o sistema de maneira abstrata
e todas as suas ligações entre as classes.

18
Mais adiante, trataremos em detalhe esses modelos.
O importante, por ora, é entender que a modelagem
de software utiliza esse tipo de notações gráficas e
textuais visando a representar as partes essenciais
do funcionamento do software.

É necessário ter um planejamento no processo de


desenvolvimento de sistemas de software. Antes de
o software ser feito, alguns princípios da engenha-
ria de software recomenda a criação de modelos,
que podem ser vistos como a representação ideali-
zada do sistema que deverá ser construído. Dentre
os exemplos de modelos, temos plantas de casas,
maquetes de estruturas e fluxogramas.

Modelagem de software

Os diagramas feitos para representar o comporta-


mento do sistema seguem padrões lógicos, bem
como possuem diversos elementos gráficos com al-
gum significado. Além da forma gráfica, muitas vezes
é preciso adicionar notações em forma de texto com
o objetivo de explicar ou definir partes do diagrama.

A maneira de se projetar software com modelagem


teve início na década de 1950, quando se utilizavam
fluxogramas e diagramas de módulos. Após esse pe-
ríodo, surge a programação estruturadas, sendo que
alguns modelos eram utilizados como o Diagrama
de Fluxo de Dados (DFD) e o modelo Integration
Definition for Function Modeling (IDEF0).

Ambos modelos são utilizados em projetos de sof-


tware estruturais, tais quais outras metodologias

19
mais recentes, como o Business Process Modeling
Notation (BPMN) para ilustrar o fluxo de informações
em processos de negócios, podendo tornar-se um
software.

DFD - Diagrama de Fluxo de Dados

O Diagrama de Fluxo de dados (DFD) mapeia o fluxo


de informações de qualquer tipo de processo de sis-
tema. Para isso, são utilizados símbolos (retângulos,
círculos, flechas e etiquetas com pequenos textos) a
fim de mostrar o fluxo de entrada e saída de dados.

Algumas regras no uso do DFD são:


●●O processo deve constar uma entrada e saída.
●●O armazenamento deve conter o fluxo de dados
de entrada e saída.
●●Os dados armazenados devem passar por algum
processo no sistema.
●●Os processos feitos em um DFD devem possuir
um fluxo para ser repassado para outro DFD ou ar-
mazenar dados.

O DFD possui alguns níveis de camada, que podem


ser 0,1,2,3 ou mais, dependendo da necessidade de
cada projeto. O DFD 1 é o que oferece mais detalhes
do contexto do diagrama, pois ele destaca em espe-
cial as funções desempenhadas no sistema à medida
que o processo se expande. Na Figura 6, temos um
exemplo DFD nível 0:

20
dados_matrícula
Cursos

comprovante
Matrículas
Aluno Matricular
Aluno

Figura 6: Exemplo de DFD 0. Fonte: Vasconcelos (s. d., p. 7).

IDEF0 - Integration Definition for


Function Modeling

IDEF0 é um subconjunto da Técnica de Análise e


Projeto Estruturados, desenvolvido por Douglas Ross
no final na década de 1960. Trata-se de um modelo
funcional, usado para descrever formalmente um
processo.

Sua utilização tem variações como IDEF1X (mode-


lagem para informações) e o IDEF2 (modelagem de
sistemas dinâmicos). Pode ser aplicado em sistemas
complexos com vistas a detalhar o processo mais
clara e precisamente.

É preciso, porém, seguir algumas etapas para criar


a modelagem desse sistema. Seguem alguns pas-
sos antes de criar o primeiro item:
●●Etapa 1. Crie uma caixa de verbos (por exemplo,
“executar inspeção”).
●●Etapa 2. Determine as entradas, saídas, sistemas
de controle e sistemas de suporte desejados.

21
●●Etapa 3. Determine os sistemas pai.
●●Etapa 4. Determine os sistemas filhos.
●●Etapa 5. Desenhe o diagrama IDEF0.

O modelo é constituído por um retângulo com setas


mostrando as entradas e saídas dos dados. O nome
que está no retângulo representa a atividade ou a
subtarefa a ser executada no projeto (Figura 7):

Controles

Cada caixa representa Controles restringem


uma atividade ou direcionam as
sub-processo. atividades. Ex.:
Planos, especificações,
normas, regras.

Nome da
Entradas Atividade/sub Saídas
processo

Cada linha representa


Entradas são utilizadas uma informação
pela Atividade e gerada pela atividade.
transformadas em
saidas.

Mecanismos
Mecanismos são
aspectos físicos usados
na atividade. Ex.:
Pessoas, máquinas
ferramentas.

Figura 7: IDEF0. Fonte: sleite19701.

22
Definições relevantes
●●Seta de limite: é uma seta em que a extremidade da
fonte não está conectada a uma caixa em um diagrama.
●●Caixa: é um retângulo com nome e número que re-
presentam uma função.
●●Nome da caixa: é o verbo ou a frase do verbo dentro
da caixa que descreve a função.
●●Seta de chamada: é uma seta que vincula modelos ou
funções dentro de um modelo.
●●Diagrama filho: é o diagrama que detalha uma caixa
pai.
●●Função: é processo, transformação ou atividade por
que se identifica o nome da caixa.
●●Seta interna: é uma seta de entrada, controle ou saída
conectada às duas extremidades (origem e uso) a uma
caixa em um diagrama.
●●Caixa pai: é a caixa detalhada pelo diagrama filho.
●●Diagrama pai: é o diagrama que contém a caixa pai.

As atividades do modelo são detalhadas após a de-


finição da atividade em si. Há uma sequência lógica
detalhada no processo, no qual o nível vai sendo mais
detalhado em cada iteração. Observe que a Figura 8
é uma sequência de tarefas e que, para cada tarefa,
há um subsistema de hierarquia.

23
Inspection
Plan

Inspect
Team
0
Tools

A-0

2
3

A-0

2
3

A2

Figura 8: Sequência das tarefas. Fonte: ASQ Service Quality Division


(2016).

Para cada diagrama gerado nessa modelagem, acon-


selha-se a elaboração de um glossário que contenha
a descrição dos itens, no qual seja especificado su-
cintamente o que significa cada elemento do modelo.

Diagrama de caso de uso

O diagrama de caso de uso é utilizado para descre-


ver as funcionalidades do sistema de software e é
conhecido especialmente por ser uma ferramenta
que auxilia na fase de levantamento de requisitos
funcionais.

Podemos dizer que um caso de uso é um documen-


to narrativo que descreve a sequência de eventos

24
de um ator que usa um sistema para completar um
processo. Há muitas ferramentas Case disponíveis
no mercado para a elaboração desse tipo de mode-
lagem, o qual auxilia o desenvolvedor com a produ-
ção do modelo e, muitas vezes, com a geração de
documentação.

Uma das ferramentas mais conhecidas é o IBM


Rational, usada para a metodologia Rational Unifield
Process (RUP), que, por sua vez, é orientado aos mo-
delos de caso de uso. No entanto, considera-se o
RUP complexo e, muitas vezes, demorado, aplicado
a grandes projetos. Há uma adaptação do RUP, cha-
mada de “Rupinho”. Por esse motivo, existem cada
vez menos projetos utilizando o RUP, não por ser
uma metodologia ruim, mas devido à preferência
pelas metodologias ágeis que estão na moda, como
o Scrum.

Dessa forma, o diagrama de caso de uso represen-


ta as ações realizadas no software, visto que esse
modelo é considerado de fácil entendimento, bem
como fica claro a demonstração para o cliente, ou
seja, como são as funcionalidades do sistema.

Há uma interação do Ator (humano ou dispositivo


interativo) com os artefatos (conjunto de instâncias),
em que cada ação do sistema gera um resultado de
valor para um determinado agente. O caso de uso
consiste em algumas notações para que seja pos-
sível montar um modelo:
●●Ator: representa pessoa/dispositivo que interaja
com o sistema.

25
●●Elipse: conhecido como artefato, representa algum
requisito do sistema; é uma forma descritiva de do-
cumentar o sistema, um documento narrativo que
descreve a sequência de eventos realizado pelo ator.

Relacionamentos possíveis no caso de


uso
●●Linha: representa alguma relação entre o Ator e o
Artefato; na versão 1.3 da UML, utilizavam-se setas
na ponta, porém, na versão 2.0, é a linha que repre-
senta a relação.
●●Seta: Especialização/Generalização, na UML 2.0,
as setas representam o fluxo de alguma ação, e a
relação se dá pelos artefatos com características
semelhantes.
●●<<include>>: é utilizado em uma sequência lógica
no diagrama, ou seja, alguma ação já esperada pelo
sistema.
●●<<extends>>: representa uma exceção no sistema,
alguma ação que pode ou não ser escolhida. Por
exemplo, ao fechar o MS Word, podemos ou não
salvar o documento no formato “.pdf”. Entretanto, o
formato padrão utiliza a extensão “.docx.”.

26
Observe na Tabela 2 as notações citadas:

Notação Descrição
Relação Ator e Artefato
Especialização/Generalização
Ator

Elipse (Artefato)
<<include>>
<<extends>>

Tabela 2: Notações de caso de uso. Fonte: Guedes (2004).

Na Figura 9, temos um exemplo de um diagrama de


caso de uso representando ações em uma conta de
banco:

Sacar

<<include>>

Cliente Banco

Registrar
<<include>>
Movimento

Depositar

Figura 9: Caso de uso. Fonte: Maia (2016).

27
A modelagem de caso de uso, apesar de parecer
fácil, possui uma documentação para cada artefato,
sendo que a descrição do fluxo de informações é
detalhada nessa documentação. Na Tabela 3, temos
um exemplo de documentação de caso de uso:

Nome do Caso de Uso Abertura de Conta


Caso de Uso Geral

Ator Principal Cliente

Atores Secundários Banco

Resumo Este caso de uso descreve as


etapas percorridas por um cliente
para abrir uma conta

Pré-condição O pedido de abertura precisa ser


aprovado

Pós-condição É necessário realizar um depósito


inicial

Ações do ator Ações do Sistema

1. Solicitar abertura de conta

2. Consultar cliente por seu CPF

3. Se for necessário, gravar ou


atualizar o cadastro do cliente. Se
o cliente não possuir outras contas
deve ser registrado como inativo

4. Avaliar o pedido do cliente

5. Aprovar o pedido

6.Escolher a senha da conta

7. Abrir conta

8. Definir cliente como ativo

9. Fornecer valor a ser depositado

10. Registrar depósito

Tabela 3: Documentação de casos de uso.Fonte: Elaborada pelo autor


(2019).

28
Diagrama de Sequência

O Diagrama de sequência consiste em um que visa


a 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 sequência,
podemos encontrar os seguintes elementos:
●●Linhas verticais representando o tempo de vida de
um objeto (lifeline).
●●As linhas verticais são preenchidas por barras verticais
que indicam exatamente o momento em que um objeto
passou a existir. Quando um objeto desaparece, existe
um “X” na parte inferior da barra (segundo a norma da
UML).
●●Linhas horizontais ou diagonais representando men-
sagens trocadas entre objetos. Essas linhas são acompa-
nhadas de um rótulo que contém o nome da mensagem
e, opcionalmente, os seus parâmetros. Podem existir
também mensagens enviadas ao mesmo objeto, repre-
sentando uma iteração.
●●Uma condição é representada por uma mensagem
cujo rótulo é envolvido por colchetes.
●●Mensagens de retorno são representadas por linhas
horizontais tracejadas. Esse tipo de mensagem não é
frequentemente representado nos diagramas, em sua
maioria porque a utilização leva a muitas setas no dia-
grama, atrapalhando o entendimento. Este tipo de men-
sagem só deve ser mostrado quando for fundamental
para a clareza do diagrama.

29
A Figura 10 ilustra um diagrama de sequência:

<<boundary>> <<entity>>
:telaLogin :usuarios
:Usuario

informaDados
(”Login”, “Senha”)

usuarioOK
:=consultaUsuario(”Login, “Senha”)

<<create>>
<<boundary>>
[usuarioOK == True]:
new()
:telaPrincipal

<<destroy>>
kill()

Figura 10: Diagrama de sequência. Fonte: The Club.

Diagrama de classes

O diagrama de classes é o mais utilizado por ser o


mais importante na UML; seu objetivo é descrever
as classes contidas no sistema (em seus atributos
e procedimentos), bem como os relacionamentos
existentes entre classes (GUEDES, 2004).

O diagrama de classes guarda semelhanças com o


modelo entidade relacionamento da engenharia de

30
informações por ter sido propositalmente projeta-
do para ser uma evolução deste. Um dos fatores da
grande importância deste tipo de diagrama é funcio-
nar como base para a construção da maioria dos ou-
tros diagramas da linguagem UML (GUEDES, 2004).

Os relacionamentos, dentro do diagrama de clas-


ses, organizam-se segundo as noções de agregação,
quando uma classe é complementada por outra, em
uma relação todo-parte, composição quando a clas-
se filha existe somente em função da classe pai, e
associação ternária, quando duas ou mais classes
se relacionam. É útil para representar associações
complexas, sendo o conceito de multiplicidade extre-
mamente semelhante ao conceito de cardinalidade
utilizado no Modelo E-R (GUEDES, 2004).

O diagrama de classes traz uma visão da composi-


ção de cada classe (atributos e métodos), facilitando
o desenvolvimento e a manutenção do sistema. Na
Figura 11, temos um exemplo de diagrama de classe:

31
Moradia
<<property>>
+ Area() :Double
+ Endereco() :Endereco
ParedeQuarto
Parede
<<property>>

ParedeBanheiro
+ Altura() :Double
+ Largura() :Double

ParedeCozinha
+ Acabamento()
Casa :Acabamento

<<property>>
+ TelhadoAreaExterna() :Telhado
+ TelhadoAreaInterna() :Telhado
+ ParedeQuarto() :Parede
+ ParedeBanheiro() :Parede

TelhadoAreaExterna
+ ParedeCozinha() :Parede
EspelhoCorredor

+ EspelhoCorredor() :Espelho

TelhadoAreaInterna
Telhado
Espelho <<property>>
+ TipoTelha() :TipoTelha
<<property>> + Area() :Double
+ TipoVidro() :TipoVidro
+ Altura() :Double
+ Largura() :Double

Figura 11: Diagrama de classe. Fonte: Ateomomento.

Projeto de Arquitetura de
Software
O arquiteto de softwares define e organiza decisões
básicas de design do sistema. A arquitetura de sof-
tware é uma coleção de decisões do design de sof-
tware que são relevantes para o sucesso da empresa
e quaisquer processos que, se essas informações
forem definidas inadequadamente, podem causar
falha no projeto de software.

Uma boa arquitetura de software leva em


consideração:

32
●●A descrição dos elementos que compõem um sis-
tema de software.
●●Interações entre esses elementos.
●●Padrões de design que orientam a composição
do software.
●●Condições válidas (restrições) para os padrões
de design.

Uma boa arquitetura de software cumpre com per-


feição todos os objetivos para os quais o software
é usado.

A arquitetura de software de um sistema é o


conjunto de estruturas necessárias para tomar
decisões sobre o sistema que afetam os ele-
mentos de software, as relações entre eles e
as propriedades de ambos (BASS; CLEMENTS;
KAZMAN, 2003).

Arquitetura de software é um processo e


um objeto
A arquitetura de software serve para implementar
uma especificação de software. As arquiteturas de
software são um objeto e um processo na forma
de documentação e representações visuais do design
do software.

Assim, a arquitetura de software, por um lado, envol-


ve o processo de projeto arquitetônico de software
e sistemas de TI e, portanto, requer uma série de

33
decisões estratégicas, bem como a apresentação e
organização ideal dos resultados desse processo, por
exemplo, na forma de diagramas e documentação
arquitetônica.

Informações sobre a arquitetura do sof-


tware para todos os participantes do
projeto

Na prática, não é suficiente descrever apenas algu-


mas visualizações de arquitetura. Cientistas da com-
putação, engenheiros e desenvolvedores de software
exigem principalmente o conhecimento técnico, por
exemplo, como a arquitetura de software foi criada
e por que ela é assim.

Outros participantes do processo na empresa,


como gerenciamento ou controle, têm uma neces-
sidade completamente diferente de informações
com relação à arquitetura do software.

Por exemplo, em termos de custos, direcionadores


de custos ou puramente em termos de objetivos es-
tratégicos corporativos.

Conhecimento de processo para avalia-


ções arquiteturais de software

O conhecimento do processo é indispensável para a


avaliação arquitetônica do software. Todos os pro-
cessos relevantes da empresa devem estar perfeita-
mente cobertos pela arquitetura de software.

Os gerentes e tomadores de decisão, por outro lado,


exigem informações estratégicas, por exemplo,

34
como os processos de software interagem. Essas
diferentes necessidades de informações devem ser
consideradas na documentação, apresentando dife-
rentes visualizações de software de uma arquitetura
de software.

Sucesso com boa documentação da ar-


quitetura de software

Documentar a arquitetura de software é capturar e


editar decisões de projeto de arquitetura de software
e sistemas de TI. A documentação da arquitetura do
software antes, durante e após o desenvolvimento
também serve para:
●●Economizar custos de software e sistemas de TI.
●●Ter eficiência no desenvolvimento de software.
●●Permitir a personalização mais rápida do software.
●●Realizar software durável.
●●Atingir a mais alta qualidade de software em fun-
ção, design e aplicação.

O software sempre atende às metas


corporativas

O software nunca é criado para ser um fim em si


mesmo, mas para o alcance ideal dos objetivos de
negócios. Atualmente, o desenvolvimento de sof-
tware é muito mais caro do que o custo de hardware
necessário para a operação. Uma boa arquitetura de
software sempre suporta os principais objetivos de
negócios simultaneamente.

35
Localizando erros na arquitetura de
software

Os desenvolvedores, a equipe de serviço e os testa-


dores de software estão constantemente procurando
bugs e fontes de erros na arquitetura do software.
A detecção sistemática de erros de projeto oferece
um potencial de otimização considerável.

Ao encontrar um erro no sistema de software, torna-


-se relevante saber qual erro de design causou o pro-
blema e quais outros processos dependem dessa
decisão errônea.

Isso permite rastreabilidade, bem como oferece ao


operador de um sistema de software a qualquer mo-
mento a oportunidade de executar uma reversão
de maneira sistemática. As regras básicas para a
arquitetura de software são:

1. Estratégia de software: decisões estratégicas


sobre os requisitos de software determinam a arqui-
tetura geral do software.

2. Design sofisticado do sistema: para artefatos


de design resultantes na arquitetura de software, as
mudanças geralmente são difíceis e caras.

3. Escalabilidade: todas as propriedades relevantes


à arquitetura do software, como funções básicas
do sistema, desempenho e segurança, devem ser
consideradas com antecedência para cenários pre-
visíveis no futuro.

36
4. Observação dos objetivos corporativos: todas
as decisões de arquitetura de software devem ser
derivadas de requisitos e objetivos corporativos. A
regra é: nenhuma decisão sem uma boa razão.

As vantagens através de uma arquitetura de software


cuidadosamente planejada são:
●●Desenvolvimento eficiente de software.
●●Aumento do desempenho especificamente.
●●Obtenção e economia de tempo.
●●Otimização do orçamento do software.
●●Minimização dos riscos.
●●Projeção de software compacto  em escopo e
função.
●●Manutenção como um conhecimento valioso sobre
software na empresa.

Padrões para arquitetura de


software
A norma ISO 42010 define o tipo e o escopo da des-
crição da arquitetura para sistemas e engenharia
de software. A documentação de uma arquitetura
de software contém conceitos ou características
básicos de um sistema de TI em seu ambiente, in-
cluindo os elementos individuais, relacionamentos e
princípios de design e a evolução de software.

37
Dentro da área de padrões de arquitetura, alguns mo-
delos são conhecidos, como DODAF, MODAF, TOGAF,
COBIT e Zachman framework (IASA, 2019).

Apesar de ter vários padrões, o projeto de software


envolve princípios de arquitetura em uma estrutura
modular. Envolve também uma estrutura de dados e
uma definição de interfaces para que ocorra o fluxo
de informações nos processos de negócios. Com
isso, as propriedades devem ser especificadas como
parte do projeto arquitetural (APPARCH, 2019).

Nas propriedades estruturais, são definidos os com-


ponentes do sistema, como módulos e objetos, e
são ainda definidos como será feito a comunicação
entre os componentes.

Já nas propriedades extrafuncionais, a descrição


do projeto arquitetural deve se preocupar com os
requisitos e os aspectos envolvidos (desempenho,
capacidade, confiabilidade, segurança, adaptabili-
dade) e outros requisitos não funcionais do projeto.

O guia App Arch define que o estilo de arquitetura é


um conjunto de princípios que envolve a utilização
de frameworks abstratos para o uso em um grupo
de sistemas com finalidade em melhorar as solu-
ções referente a problemas nos processos. No guia
App Arch, alguns estilos de arquitetura são citados
(INFOQ, 2019):

Client-Server: agrega-se ao sistema em duas aplica-


ções, na qual o cliente faz uma requisição de serviço
ao servidor.

38
Arquitetura baseada em Componentes: decompõe
o design da aplicação em componentes lógicos e
funcionais que são independentes de local, além de
expor as interfaces de comunicação bem definidas.

Arquitetura em Camadas: separa as responsabi-


lidades da aplicação em grupos bem definidos
(camadas).

Message-Bus: é um sistema de software que pode re-


ceber e enviar mensagens baseado em um conjunto
de formatos conhecidos, de forma que os sistemas
possam se comunicar uns com os outros sem a ne-
cessidade de conhecer o destinatário atual.

N-tier / 3-tier: separa a funcionalidade em segmentos


de forma muito similar ao estilo de camadas, mas
com cada segmento sendo uma camada localizado
fisicamente em um computador separado.

Orientado a objetos: um estilo arquitetural baseado


na divisão de tarefas para uma aplicação ou sistema
em reutilização individual e objetos autossuficientes,
cada um contendo os dados e comportamentos re-
levantes ao objeto.

Apresentação Separada: separa a lógica para ge-


renciar a interação do usuário da visualização da
interface de usuário (UI) e dos dados com os quais
o usuário trabalha.

Service-Oriented Architecture (SOA): refere-se às


aplicações que expõe e consome as funcionalidades
como um serviço, usando contratos e mensagens.

39
Há outros padrões modernos para a escolha dos
estilos e da aplicação de acordo com a necessidade
do projeto.

Alguns modelos: Plug-in, Peer-to-Peer, Shared


Nothing Architecture, Representational State
Transfer (REST), Front-end e back-end.

Software Livre: antecedentes,


histórico, conceituação e
cenário
Antes de Bill Gates, o software era algo comparti-
lhado livremente nas universidades, pois não havia
softwares privados. Porém, esses sistemas perten-
ciam a grandes empresas e não eram acessíveis à
grande parte das pessoas.

O sistema operacional Unix e os computadores não


eram populares, apenas um grupo reservado de pes-
soas podia acessar esses sistemas nas empresas
ou nas universidades.

No Massachusetts Institute of Technology (MIT),


um grupo de cientistas queria manter o espírito de
compartilhar conhecimento e distribuir software li-
vremente. Um desses cientistas é Richard Stallman,
fundador do movimento do software livre e do projeto
GNU em 1989; Stallman acumulava muitos softwares
com códigos abertos e de propriedade livre. Porém, o
problema era que não havia um sistema operacional
livre para fazer esses programas funcionarem.

40
Enquanto o movimento do software livre crescia aos
poucos, mas não com muito sucesso, Linus Torvalds,
um estudante de uma universidade finlandesa resol-
veu estudar uma versão de Unix conhecida como
Minix.

Linus Torvalds, assim como os outros estudantes,


queria um sistema operacional para poder estudar
fora dos laboratórios do campus da universidade. Ele
pegou parte do código do Minix e fez uma miniver-
são, disponibilizando na rede para outros poderem
utilizar.

O efeito foi bastante positivo, pois muitos estudantes


e pessoas interessadas em ter um sistema operacio-
nal gostaram da ideia e contribuíram para o sistema
que Linus Torvalds batizou de Linux, em 1991.

Entretanto, nem todos pensavam assim. Bill Gates,


com a Microsoft, fez um manifesto sobre por que
cobrar por um software e, com o lançamento dos
primeiros computadores no mercado, a Microsoft
com o sistema operacional DOS estava entrando no
mercado aos poucos (MOON, 2019).

Nessa época, o Linux estava se aprimorando, e ou-


tras empresas, como Xerox e Apple, estavam desen-
volvendo seus sistemas. Richard Torvalds resolveu,
então, entrar em contato com Linus Torvalds para
fazer um acordo para uso do Linux.

No final o projeto, GNU conseguiu com base do sis-


tema de Linus fazer a primeira versão não comercial

41
para o Linux, que tinha um repositório enorme de
software para os usuários de softwares livre.

O projeto GNU lançou uma licença de software livre,


chamada de General Public License (GPL), em que
qualquer software livre ou com código aberto deve-
ria seguir as diretrizes dessa licença, protegendo os
direitos autorais (GNU, 2019).

A Microsoft estava dominando o mercado de siste-


mas operacionais e não havia uma versão de Linux
ainda para concorrer com o Microsoft Windows.
A primeira versão que conseguiu concorrer com o
Windows foi o Linux Red Rat, que oferecia suporte
de qualidade para os clientes.

Muitas empresas ficaram interessadas no Linux,


dentre elas a Sun Microsystems, que oferecia servi-
dores mais acessíveis e, que com o lançamento do
Linux, era possível instalar nos servidores, baixando
os custos.

Com o tempo, outras versões de Linux foram lança-


das, dentre elas Suse, Debian e Mandrak. Além do
Linux, outros sitemas operacionais surgiram, todos
semelhantes ao Linux, por serem baseados em ver-
sões do Unix.

A universidade de Berkely lançou versões de sistemas


operacionais conhecidas como FreeBSD, OpenBSD e
NetBSD, com licenças próprias, semelhante a GPL.
Aliás, a Apple projetou seu próprio sistema opera-
cional, baseado em Unix.

42
A própria Microsoft participou de projetos com o
Linux, principalmente no servidor Samba. Com a
disponibilidade de muitos sitemas operacionais, a
produção de software cresceu no mundo inteiro.

A tecnologia que mais ajudou na disponibilização de


softwares livres, além do projeto GNU, foi o Java. A
portabilidade e a Web fez com que o Java virasse a
tecnologia mais popular no mundo.

O melhor de tudo isso: a Sun Microsystems, em con-


junto com muitas empresas, desenvolvia tecnologias
e as disponibilizava gratuitamente.

As empresas tinham uma tecnologia avançada, e os


estudantes e empresários compartilhavam seus sof-
twares com licenças diferentes. A Sun Microsystems
disponibilizou o ambiente de programação Netbeans
e, em conjunto com a IBM e outras empresas, lan-
çaram o Eclipse.

Além do Java, empresas como a Apache desenvolvia


tecnologias livre como os servidores Web Apache e o
Tomcat. Havia todo tipo de software livre para todos
os gostos, diveros sistemas gerenciadores de banco
de dados: MySQL, FireBird, Postgres e surgimentos
de linguagens como o PHP e o Java Script.

A Microsoft possuia algumas ferramentas para escri-


tório e utilizava o Visual Basic (VB), como a principal
tecnologia de desenvolvimento em sua suite de de-

43
senvolvimento. Além do VB, era possível programar
em C++ e ASP com o servidor Web IIS.

Podcast 2

Ferramentas livres para


engenharia de software
As várias ferramentas para se utilizar gratuitamen-
te na modelagem de sistemas, como StarUML,
ArgoUML e Astah (Antes Jude). Algumas possuem
licenças diferentes, podendo ser de código aberto e
livre (sem custo).

Para banco de dados, uma das ferramentas mais


utilizadas para MySQL é o WorkBench, um ambiente
completo visual para administração do banco de
dados.

A Microsoft possui o SQL Server Express, um banco


de dados limitado, porém, de livre utilização dentro
da licença que é utilizada. A Microsoft, com o pas-
sar dos anos, liberou uma versão do Visual Studio
Express além do SQL Express.

Há outras empresas, como a Oracle, que liberou


versões Express do banco de dados Oracle. Além,
dessas ferramentas, o próprio Eclipse e a Netbeans
possuem plug-ins para utilizar diagramas da UML e
outras funções necessárias para utilizar em projetos
de software.

44
Conceituação e cenário
O software livre já é muito utilizado por empresas
e diversas instituições, como escolas e centros de
pesquisa. Muitos jogos são elaborados em ferra-
mentas livres e, com o advento de softwares sendo
instalados em smartphones, o uso de software livre
aumentou.

No entanto, apesar de não precisar pagar por uma


licença, o usuário precisa pagar pelo suporte do sof-
tware caso precise. As empresas, na maioria dos
casos, preferem softwares privados por oferecerem
segurança e suporte.

Apesar de algumas empresas oferecerem suporte


a sistemas livres, o cenário é dividido, pois muitos
utilizam parcialmente, ao passo que outros preferem
não utilizar por questões políticas da empresa.

Não estamos discutindo a qualidade do sofware, e


sim algumas vantagens e desvantagens na adoção
de software livre, que pode ou não ter um bom su-
porte para garantir todas suas funcionalidades.

No governo, o software livre é muito utilizado; por


exemplo, no metrô de São Paulo, há versões de Linux
instalado. Nos aeroportos de todo o Brasil, o Linux é
utilizado como parte do sistema.

O Servidor Web Apache, cuja licença é livre, tornou-se


o servidor mais utilizado no mundo, portanto, o uso
dependerá muito mais das necessidades e garantias
do que a empresa precisa.

45
CONSIDERAÇÕES FINAIS
A engenharia de software é uma disciplina que o
desenvolvedor deve conhecer para elaborar projetos
de software. Entender metodologias ágeis ajudam
auxiliar projetos como visto nesse módulo.

Para auxiliar nos protótipos de software alguns mo-


delos foram elaborados e disponibilizados na UML
como uma ferramenta para desenvolvimento do sof-
tware principalmente no paradigma de linguagem de
programação orientada a objetos.

Uma questão abordada que o desenvolvedor deve


pensar é a relação de software livre. A utilização de
software com licenças do tipo GPL pode trazer van-
tagens em projetos, desde que sabia como utilizar as
regras estabelecidas, envolvendo aspectos culturais.
A visão geral da engenharia de software auxilia qual-
quer envolvidos em projetos de software, não basta
apenas saber programar, o importante é utilizar as
ferramentas, metodologias e tudo o que envolva a
engenharia para obter um software de qualidade.

Ter o conhecimento de software livre pode ajudar na


escolha de boas ferramentas para auxiliar no proces-
so de desenvolvimento:
●●Surgimento do movimento software livre.
●●Software livre uma escolha certa.

46
SÍNTESE

Paradigmas de Linguagem
de Programação

1) Metodologias de Desenvolvimento
Ágil.

Métodos para desenvolver projetos de


software são necessários para controlar os
processos e a equipe de desenvolvimento:

• Metodologias ágeis: Scrum e XP;


• Certificações em metodologia ágil.

2) Técnicas de Modelagem de Software.

Protótipo para elaborar modelos lógicos de


projeto de software:

• Modelos da UML;
• Ferramentas CASE para elaborar UML.

3) Projeto de Arquitetura de Software.

A arquitetura de softwares define e organiza


as decisões básicas de design do sistema:

• Padrões de projetos;
• Processos de desenvolvimento.

4) Software Livre: antecedentes,


histórico, conceituação e cenário.

Ter o conhecimento de software livre pode


ajudar na escolha de boas ferramentas para
auxiliar no processo de desenvolvimento:

• Surgimento do movimento software livre;


• Software livre uma escolha certa.
Referências
Bibliográficas
& Consultadas
APPARCH. App Arch Guide 2.0 Knowledge
Base. Disponível em: https://archive.codeplex.
com/?p=apparch. Acesso em: 03 set. 2019.

ASQ - Service Quality Division. IDEF0 (Integrated


Definition for Function Modeling), 5 maio 2016.
Disponível em: http://asqservicequality.org/glos-
sary/idef0-integrated-definition-for-function-mode-
ling/. Acesso em: 20 ago. 2019.

BRASILEIRO, R. Métodos ágeis: o que é e por-


que você deve saber o que é. MétodoÁgil (s. d.).
Disponível em: http://www.metodoagil.com/meto-
dos-ageis/. Acesso em: 30 ago. 2019.

BASS, L.; CLEMENTS, P.; KAZMAN, R. Software


Architecture in Practice. 2. ed. Boston: Addison-
Wesley Longman Publishing Co., Inc., 2003.

CULTURA. Histórico, Definição, Importância.


Disponível em: http://cultura.ufpa.br/dicas/linux/li-
-lisol.htm. Acessado em 03 de setembro de 2019.

DEITEL, P.; Deitel, H.; Java: Como Programar. 10.


ed. São Paulo, Pearson Education do Brasil, 2016
[Biblioteca Virtual].

GUEDES, G. T. A. UML 2: uma abordagem prática.


São Paulo: Novatec, 2004.

GNU. O que é o software livre?. Disponível em:


https://www.gnu.org/philosophy/free-sw.pt-br.html.
Acesso em: 03 set. 2019.

IASA. Introduction to Enterprise Architecture and


TOGAF 9.1. Disponível em: https://pt.slideshare.
net/iasaglobal/introduction-to-enterprise-architec-
ture-and-togaf-91-38378019. Acesso em: 30 ago.
2019.

MANZANO, J. A. N. G. Algoritmos: lógica para de-


senvolvimento de programação de computadores.
28. ed. São Paulo: Érica, 2016 [Biblioteca Virtual].

MANZANO, J. A. N. G. Java 7: programação de


computadores: guia prático de introdução, orien-
tação e desenvolvimento. São Paulo: Érica, 2011
[Biblioteca Virtual].

MELO, A. C. V.; SILVA, F. S. C. Princípios de


Linguagem de Programação. São Paulo: Edgard
Blücher LTDA, 2003 [Biblioteca Virtual].
METODOLOGIA ÁGIL. Certificação Scrum Master:
a importância de uma certificação scrum.
Metodologia Ágil, [s. d.] Disponível em: http://
metodologiaagil.com/certificacao-scrum-master/.
Acesso em: 30 ago. 2019.

MOON, P. Conheça Richard Stallman, o ver-


dadeiro pai do software livre. 11 set. 2007.
ComputerWorld. Disponível em: https://
computerworld.com.br/2007/09/11/idgnoti-
cia-2007-08-23-1171671836/. Acesso em: 30 ago.
2019.

PACITTI, T. Paradigmas do software aberto. Rio de


Janeiro: LTC, 2006 [Minha Biblioteca]

PAULA FILHO, W. P. Engenharia de software: fun-


damentos, métodos e padrões. 3. ed. São Paulo:
Gen/LTC, 2009 [Biblioteca Virtual].

PRESSMAN, R. S.; MAXIM, B. R. Engenharia de


Software: uma abordagem profissional. 8. ed.
Porto Alegre: McGraw-Hill, 2016 [Biblioteca
Virtual].

SANTOS et al. FDD - Feature Driven Development.


Disponível em: https://pt.slideshare.net/engenharia-
desoftwareagil/fdd-5139226. Acesso em: 28 ago.
2019.
SBROCCO, J. H. T. C.; MACEDO, P. C. Metodologias
ágeis: engenharia de software sob medida. São
Paulo: Érica, 2012 [Biblioteca Virtual].

SOMMERVILLE, I. Engenharia de Software. 10. ed.


São Paulo: Pearson Education do Brasil, 2018.

SOUZA, L. M. Método ágil XP (Extreme


Programming). Revista Eletrônica da FIA, v. 3, n. 3,
jul./dez. 2007.

TELES, V. M. Extreme Programming: Aprenda


como encantar seus usuários desenvolvendo
software com agilidade e alta qualidade. 2. ed. São
Paulo: Novatec, 2017.

VASCONCELOS, A. Análise de requisitos.


Slideplayer, [s. d.]. Disponível em: https://slide-
player.com.br/slide/356348/. Acesso em: 20 ago.
2019.

VIEIRA, D. Scrum: a metodologia ágil explicada


de forma denifitiva. MindMaster, 26 jun. 2014.
Disponível em: http://www.mindmaster.com.br/
scrum/. Acesso em: 20 ago. 2019.