Engenharia de Software

pontodeensino.com

Professor
Emiliano S.
[Versão 7 Agosto/2019] Monteiro
 2.8. Processo: Desenvolvimento orientado ao reuso

• Sommervile (2003), na maioria dos projetos de software, ocorre algum reuso de

software. Isto acontece quando as pessoas envolvidas no projeto de um software
conhece outros projetos similares.
• Estes softwares similares sofrem pequenas modificações e são incorporados ao novo
projeto em desenvolvimento.
• A abordagem voltada para a componentização de software, também trata do reuso de
código entre projetos.
• Uma categoria de sistemas que se beneficia desta forma de trabalho são “softwares de
prateleira”, pois muitos possuem funções similares, nesta categoria entram pequenas
automações comerciais.
• Sua principal vantagem esta na redução de software a ser produzido, também propicia
a redução do tempo de entrega. Sua desvantagem esta no controle sobre a evolução
do sistema, pois partes do sistema, componentizadas estão sob controle de terceiros.
 2.9.Processo: Modelo V
• É uma variação do modelo em
cascata. Proposto pelo
ministério de defesa da
Alemanha em 1992. A
codificação é o vértice do V, a
análise e projeto ficam em um
lado e o testes do outro.
Durante a verificação de
problemas (lado direito), caso
encontrados) o lado esquerdo
pode ser revisto, permitindo a
correção.
• O modelo V pode ser Principais desvantagens: Não aborda operações,
incrementado com prototipação. manutenção, reparo nem descarte de sistemas!
 2.12. Processo RUP
2.12.1. Rational Software
• Foi uma empresa fundada em 1981 para prover ferramentas para o desenvolvimento da
engenharia de software (principalmente o desenvolvimento modular e interativo).
• Lançado em 1985 o ambiente Rational era uma IDE para ADA.
• Posteriormente a empresa mudou de nome de “Rational Machines” para “Rational
Software Corporation” e fundiu-se com a Verdix Corporation.
• Na época ela fornecia geradores de código de compiladores e debuggers para várias
arquiteturas.
• Em 1990 a Rational lançou o ambiente Rational para ADA para rodam em estações Unix
da Sun e IBM e uma ferramenta de modelagem chamada Rose desenvolvida por Grady
Booch. A Rose versão 1.0 foi lançada em 1992, mas devido a baixa performance foi
retirada do mercado.
• A Rose 2.0 foi combinada com a notação Booch e lançada para a plataforma Windows,
incluindo a geração de código.
 2.12.1. Rational Software
• Após a fusão da Rational com a Verdix o que formalizou o nome da empresa em Rational
Software.
• Em 1995, James Rumbaugh entrou na empresa e Ivar Jacobson com sua empresa Objectory AB,
na época Grady Booch já estava na empresa, desta forma os 3 maiores metodologias da
engenharia de software orientado a objetos estavam na Rational.
• A principal missão deles foi eliminar a fragmentação dos métodos, então os três desenvolveram
a Linguagem de Modelagem Unificada – UML.
• Este esforço os denominou de “os três amigos” na indústria de software.
• Philippe Kruchten teve a tarefa de explicitar um framework para suportar a engenharia de
software com a utilização de UML, o que resultou no Rational Unified Process completando
gerando um tripé estratégico:
– A) um processo que guia o desenvolvimento
– B) ferramentas que automatiza o processo
– C) serviços que aceleram a adoção de ambos: processos e ferramentas
 2.12.1. Rational Software
• Em 6 de dezembro de 2002 a IBM adquiriu a Rational.
• Algumas ferramentas da Rational:
1. Rational Application Developer para desenvolvimento de software com Java
2. Rational ClearCase ferramenta para suportar o gerenciamento de configuração, controle de versão e
gerenciamento de código fonte.
3. Rational Rose – Modelagem UML
4. Rational Quality Manager – Gerenciamento colaborativo do ciclo de vida da aplicação e ambiente de
teste
 2.12.2. Iterativo x interativo
Iteração é um ciclo ou uma etapa
de uma repetição maior.

Interação é uma comunicação

bidirecional mútua entre as partes.

Fonte: https://www.ime.usp.br/~pf/algoritmos/aulas/footnotes/interativo.html
 2.12.2. Iterativo
• Iterativo é um termo que anda sempre com o termo incremental, isto
pode ser visto em vários processos de desenvolvimento de software.
• As iterações e incrementos são executadas no ciclo de desenvolvimento
em mais de uma etapa e podem ser executadas ao mesmo tempo
durante o ciclo.
• A combinação de iteração e incrementes tornam os processos
evolucionários e fornecem construções incrementais.
• O relacionamento entre iterações e incrementas estão entre todos as
metodologias de desenvolvimento de software ou processos de
software.
Requisitos

Análise e
Planejamento
projeto

Evolução Implementação

Testes
Deploy
(implantação/entrega)
 2.13. Processo: ASD - Desenvolvimento de software ágil

• São princípios de desenvolvimento nos quais os requisitos

e a solução evoluem através esforço colaborativo de
equipes multifuncionais.
• Estes processo incentivam o uso de planejamento
evolucionário, desenvolvimento evolucionário e entrega o
mais cedo possível bem como a resposta rápida a
mudanças além da contínua evolução.
• O termo Agile foi cunhado pela primeira vez em 2001 no
“Manifesto for Agile Software Development”
 2.14. A nomenclatura que unificou todos

1. RAD 1991
2. Processo Unificado 1994
3. SCRUM 1995
4. Cristal Clear e XP 1996
5. Feature-Driven 1997
6. Entre outros o manifesto Agile de 2001 colocou
todos sob o mesmo guarda chuva !
 2.15. Os 4 pilares do manifesto:

1. Indivíduos e interações
Auto-organização e motivação são importantes, assim como iterações e programação
de pares.
2. Software funcionando
Software funcionando (rodando) é mais útil e bem-vindo do que apenas apresentar
documentos aos clientes em reuniões.
3. Colaboração com o cliente
Os requisitos não podem ser totalmente coletados no início do ciclo de
desenvolvimento de software, portanto, o envolvimento contínuo com os clientes ou
partes interessadas é muito importante.
4. Respondendo à mudança
Métodos ágeis são focados em respostas rápidas à mudança e desenvolvimento
contínuo.
 2.16. Os 12 princípios ágeis:
1. Satisfação do cliente pela entrega precoce e contínua de software
2. Bons requisitos, mesmo em desenvolvimento tardio
3. Software em funcionamento (pronto para rodar) é entregue com freqüência (semanas, em
vez de meses)
4. Cooperação estreita e diária entre empresários e desenvolvedores
5. Os projetos são construídos em torno de indivíduos motivados, que devem ser confiáveis
6. A conversa cara-a-cara é a melhor forma de comunicação
7. O software funcionando é a principal medida do progresso
8. Desenvolvimento sustentável, capaz de manter um ritmo constante
9. Atenção contínua à excelência técnica e ao bom design/projeto
10. Simplicidade é essencial
11. As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas
12. Regularmente, a equipe reflete sobre como tornar-se mais eficaz, e se ajusta conforme a
necessidade
 2.17. Exemplos de processos ágeis
1. Acceptance Test Driven Development (ATDD) 10. Graphical System Design (GSD)
2. Agile Modeling 11. Kanban
12. Lean software development
3. Agile Unified Process (AUP)
13. Scrum
4. Continuous integration (CI) 14. Scrum-ban
5. Crystal Clear 15. Story-driven modeling
6. Crystal Methods 16. Test-driven development (TDD)
7. Dynamic Systems Development Method (DSDM) 17. Velocity tracking
18. Software Development Rhythms
8. Extreme Programming (XP)
9. Feature Driven Development (FDD)
 2.17. Exemplos de processos ágeis
1. Adaptive software development (ASD)
2. Agile modeling
3. Agile Unified Process (AUP)
4. Crystal Clear methods
5. Disciplined agile delivery
6. Dynamic systems development method (DSDM)
7. Extreme programming (XP)
8. Feature-driven development (FDD)
9. Lean software development
10. Kanban
11. Scrum
12. Scrumban
13. Rapid application development (RAD)
 2.18. Processo: Agile Unified Process - AUP

• É uma simplificação do RUP desenvolvida por Scott Ambler.

• Ela descreve de forma simples de fácil de entender a abordagem de desenvolver
sistemas de negócios usando técnicas ágeis e conceitos da RUP.
• A AUP aplica técnicas ágeis como: TDD e modelagem ágil, gerenciamento de
mudanças e refatoração do banco de dados para aumentar a produtividade.
• Possui 11 disciplinas:
– 1. Modelo
– 2. Implementação
– 3. Teste
– 4. Deploy
– 5. Gerenciamento da configuração
– 6. Gerenciamento de projeto
– 7. Ambiente (ferramentas, hardware, etc é fornecido corretamente a equipe)
 2.18. Agile Unified Process
Filosofias AUP:
1. Sua equipe sabe o que eles estão fazendo
2. Simplicidade
3. Agilidade
4. Foco nas atividades de alto valor
5. independência de ferramentas
6. Você pode alterar a AUP para suas necessidades
 2.19. Processo: OpenUP
• É parte do Eclipse Process Framework, um processo aberto desenvolvido pela
Eclipse Foundation.
• Seu objetivo é facilitar a adoção de básico e principal do RUP.
• Tudo o que é opcional no RUP foi removido do processo, como objetivo de
simplificar o processo, incluindo equipes de pessoas o qual é recomendado de 3
a 6 por equipes.
4. UML

Professor
Emiliano S.
Monteiro
 4.1. Conceitos de UML
• É uma padronização de modelagem.
• Ele é desenhada!
• Como é uma linguagem desenhada, os desenhos podem ser codificados em qualquer
linguagem de qualquer forma, não necessariamente por linguagens 100% OO.
• Se forem utilizadas ferramentas automatizadas (CASE) para a elaboração dos diagramas,
então estas ferramentas podem auxiliar gerando códigos para os programadores,
minimizando erros.
• Os diagramas “básicos”... são eles:
– 1.Diagrama de classes
– 2.Diagrama de objetos
– 3.Diagrama de casos de uso
– 4.Diagrama de sequências
– 5.Diagrama de colaborações
– 6.Diagrama de transição de estados
– 7.Diagrama de atividades
– 8.Diagrama de componentes
– 9.Diagrama de implantação Demais diagramas: https://pt.wikipedia.org/wiki/UML
 4.2. Lista completa de diagramas da UML
Diagramas estruturais
1. Diagrama de classes
2. Diagrama de objetos
3. Diagrama de componentes
4. Diagrama de instalação ou de implantação
5. Diagrama de pacotes
6. Diagrama de estrutura composta
7. Diagrama de perfil
Diagramas comportamentais ou dinâmicos
8. Diagrama de caso de uso
9. Diagrama de transição de estados ou de estados
10. Diagrama de atividade
11. Diagramas de interação:
11.1. Diagrama de sequência
11.2. Diagrama Visão Geral de Interação ou de interação
11.3. Diagrama de colaboração ou comunicação
11.4. Diagrama de tempo ou temporal
 4.3. Diagramas básicos

1 Diagramas de classe
2 Diagramas de objetos
3 Diagramas de componentes
Diagramas estruturais 4 Diagramas de implementação ou instalação
5 Diagramas de pacotes
6 Diagramas de estrutura composta
7 Diagrama de perfil

1 Diagrama de caso de uso

2 Diagrama de sequência
Diagramas comportamentais 3 Diagrama de colaboração
4 Diagrama de transição de estados
5 Diagrama de atividade
 4.3.1. Diagrama de classes

• É um diagrama que representa os agrupamentos

de objetos, pois a palavra classe é o mesmo que
grupo, categoria ou espécie
 4.3.1. Diagramas de classe

Avançamos neste sentido

Nome

Atributos

Operações

Implementação
Conceito Especificação
Físico
 4.3.1.1. Cartões CRC

Criados numa era pré-uml!

Não são mais utilizados !
4.3.1.2. Diagramas de classe - relacionamentos

Composição Dependência Realização de

Generalização Associação Agregação
interface
4.3.1.3. Diagramas de classe - cardinalidade

1 Exatamente um

• Um para um 0..1 Zero ou um

• Um para muitos
• Muitos para muitos
* Zero ou mais

1..* Um ou mais

{Ordenado} Ordenador
4.3.2. Relacionamentos

Pai

Filho
9. Mercado de trabalho

Professor
Emiliano S.
Monteiro
Ofertas de emprego (maio/2019)
 Referências bibliográficas
• Básica
– PFLEEGER, Shari Lawrance. Engenharia de software – teoria e prática. 2ª. ed. São Paulo :
Prentice Hall, 2004.
– SOMMERVILLE, Ian. Engenharia de Software. 6ª. Ed. São Paulo : Addison Wesley, 2003.
– BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML. 1.ed. Rio de Janeiro:
Elsevier, 2007.
• Complementar
– FERNANDES, Aguinaldo, Aragon. TEIXEIRA, Descartes de Souza. Fábrica de software –
implantação e gestão de operações. São Paulo : Atlas, 2004.
– LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e o projeto orientados a
objetos e ao processo unificado. 2.ed. Porto Alegre: Bookman, 2004. .

• Outras referências podem ser encontradas na página da disciplina em: www.pontodeensino.com

Prof. Emiliano S. Monteiro