UML

Fonte: Eduardo Bauer Londero, Instituto de Informática da UFRGS

Introdução:

UML, ou Unified Modeling Language é a última buzz-word a chegar por estas plagas. O seu charme é a promessa de ser a última e definitiva metodologia de modelagem de sistemas. Outro apelo, é integrar todas as demais expressões (métodos empíricos todos eles) que atestam sua origem "nobre": orientação a objeto, padrões, GRASP. Sendo posterior a todas elas, promete ser uma maneira de se atualizar sobre todas elas de uma só vez.

Muitos dos exemplos, foram retirados de telas criadas com Rational Rose 98, uma ferramenta CASE da Rational. Convém mencionar que esta ferramenta não implementa inteiramente o UML, havendo diferenças de notação. Sempre que for o caso, a origem da imagem será indicada.

Perto do final do semestre descobrimos em [HAR97] referência a outra ferramenta CASE, a SA/Object, disponível em www.popkin.com, mas não conseguimos avalia-la ainda.

UML pretende:

1- Modelar sistemas, sejam eles empresas ou softwares, usando conceitos de orientação a objeto.
2- Estabelecer um acoplamento explícito tanto entre artefatos conceituais como executaveis (reais).
3- Encaminhar as questões de escala (num intendi...) inerentes em sistemas complexos e/ou de missão crítica.
4- Criar uma linguagem de modelagem usável por ambos: humanos e máquinas.

Método é uma maneira explícita de estruturar ações e pensamentos. Um método diz o que fazer, como, quando e porque. Métodos contém modelos e estes modelos são usados para descrever algo e comunicar os resultados do uso do método.
Um modelo é descrito em termos de uma linguagem de modelagem. Uma linguagem é composta por símbolos que compõem uma notação e regras sobre seu uso. Estas regras correspondem a três planos de entendimento:

• intaxe - Diz como devem parecer e como devem ser combinados os símbolos utilizados
• Semântica - Diz o que cada símbolo significa. São (a semântica e a sintaxe) referidos à própria relação entre os símbolos (regras internas )
• Pragmática - Define a intenção dos símbolos, de modo que o propósito do modelo é expresso e torna-se inteligível para outras pessoas. É uma referência externa/cultural à relação representada, é funcional e finalística

---

Fases do Desenvovimento do Sistema:1) Análise dos Requisitos:

UML se vale de use cases; diagramas para capturar o requisitos do usuário. Através dos use cases, atores externos são modelados em suas interações com o sistema. Semelhante ao DFD contextual, mas usando bonequinhos de palitos para representar os atores/agentes externos. Não é tão simples assim, mas a semelhança é óbvia.

2) Análise:

Nesta fase nos preocupamos com as abstrações primárias (classes e objetos) e mecanismos no domínio do problema. As classes são identificadas e representadas no diagrama de classes. Também são representadas as relações e colaborações entre as classes, de modo que as funcionalidades descritas nos use cases sejam alcançadas. Também se vale dos diagramas dinâmicos (estado, seqüência, colaboração e de atividades).
Na análise, somente classe do domínio do problema são modeladas. Aquelas que definem detalhes e soluções da implementação de software (interface, comunicação com banco de dados, concorrência, etc..) ficam para outra fase.

3) Projeto:
Na fase de projeto (design), o resultado da análise é expandido para uma solução técnica. Novas classes são acrescentadas para prover uma infraestrutura técnica: interface, manipulação de dados em um banco de dados, salvamento de arquivos, comunicação com outros sistemas e dispositivos. Nesta etapa as classes da análise são "embutidas" (embedded) nesta infraestrutura técnica, sendo possível alterar ambas independentemente.
O resultado é uma descrição detalhada para a fase seguinte, de programação.

4) Implementação:
As classes são convertidas para código real em uma linguagem OO (procedural não é recomendado).

5) Teste:
Idêntico a qualquer outro método de modelagem. Dividida em testes de unidades, testes de integração, teste de sistema e testes de aceitação.

---

Visões e Diagramas
São cinco visões (ou vistas, tradução para view) e nove diagramas. Visões

Visão dos Uses Cases	É central no UML, e define as funcionalidades do sistema e seu conteúdo define o desenvolvimento subseqënte das outras visões. É usado para validar o sistema junto ao usuário (é assim que você quer/queria ?). Usa o diagrama de use case.
Visão Lógica	Descreve como a funcionalidade do sistema é alcançada. Em contraste com os use cases, a visão lógica vê o sistema internamente. descre tanto a estrutura estática como a colaboração dinâmica que ocorre quando os objetos se comunicam para prover alguma função. Usa para a estrutura estática os diagramas de classes e objetos. Para a modelagem dinâmica usa os diagramas dinâmicos: estado, colaboração, seqüência e atividade.
Visão dos Componentes	É uma descrição dos módulos da implementação com suas estruturas e dependências. Consiste no diagrama de componentes e outros diagramas de caráter administrativo, tasi como relatório de progresso.
Visão Concorrente	Lida com a divisão do sistema em processos e processadores. É um aspecto não-funcional do sistema, que visa desempenho, eficiencia no uso dos recursos e manejo de eventos de eventos assíncronos do ambiente.
Visão do Desenvolvimento	Mostra o desenvolvimento físico do sistema, com computadores, sites, nós e como eles se conectam. Esta visão inclui um mapeamento que descreve como os componentes da visão lógica tornam-se componentes reais, e qual a sua localização física subseqüente.

Diagramas

Em amarelo, os diagramas estáticos. Em verde os dinãmicos.

Diagrama de Use Cases	Mostra atores externos e suas conecções com os use cases do sistema. Cada use case é a descrição de uma funcionalidade (um uso específico do sistema) que o sistema oferece.
Diagrama de Classes	Um diagrama de classes mostra a estrutura estática das classes. As classes são "as coisas" com as quais o sistema lida. São representadas por retângulos, com o nome da classe em negrito. Classes podem se relacionar umas com as outras de várias maneiras: associação, dependência, especialização ou empacotamento
Diagrama de Objetos	O diagrama de objetos se parece muito com o diagrama de classes, apenas mostra as classes instanciadas como objetos, como um snapshot possível da execução do sistema. A mesma notação é adotada, apenas o nome do objeto é escrito sublinhado. Diagrama de objetos é utilizado em diagramas de colaboração
Diagrama de Estados verdes:diagramas dinâmicos	O diagrama de estados é tipicamente um complemento do diagrama de classes. Mostra todos os possíveis estados de uma classe e quais eventos causam a mudança de estados. Mudanças de estado são chamadas de transições Ele é desenhado apenas para aquelas classes que tem um número bem definido de estados e cujo comportamento é mudado pelas transições. Pode também ser desenhado para o sistema inteiro.
Diagrama de Seqüência	O diagrama de seqüência mostra uma colaboração dinâmica entre objetos. O aspecto mais importante é mostrar uma seqüência de mensagens trocadas entre os objetos. Objetos são descritos como linhas verticais e mensagens como linhas horizontais entre os objetos. A mensagen bifuracada (uma origem, vários destinos aparece em [ERI97], mas o Rose98 não foi capaz de representá-la.
Diagrama de Colaboração	Mostra uma colaboração dinâmica, exatamente como o diagrama de seqüência. Freqüentemente é uma alternativa ao diagrama de seqüência, quando se deseja mostrar os objetos e seus relacionamentos (chamado de contexto). Se o tempo é mais importante, escolhe-se o de seqüencia e caso o contexto seja mais importante, escolha o de colaboração.
Diagrama de Atividades	Mostra uma seqüência de atividades como um grafo, o que permite representar decisões (bifurcações) graficamente, bem como estado inicial e final.
Diagrama de Componente	Traz uma visão interna da estrutura física do código, em termos de componentes. Um componente pode ser um código fonte, um componente binário ou um executável. É um mapeamento entre a visão lógica e a visão de componentes. Dependências entre componentes são mostradas, tornando fácil analizar alterações.
Diagrama de Desenvolvimento/Entrega	Mostra a arquitetura física - hardware e software no sistema. Representa-se os computadores e dispositivos reais e as conecções entre eles.

---

Elementos de Modelo

São os conceitos (o vocabulário) utilizados nos diagramas. Um elemento de modelo tem uma representação gráfica que o representa nos diagramas.
São exemplos de elementos: classe, objeto, estado, caso de uso, nó, interface, package, nota, componentes.
Também os relacionamentos são considerados elementos: associação, generalização, dependência e agregação.

---

Mecanismos GeraisAdornos:
Detalhes gráficos (chamados em inglês de adornos) podem ser acrescentados aos elementos dos diagramas, de modo a acrescentar significado semântico. Por exemplo, se um elemento representa um tipo, usa-se negrito, se representa um objeto aparece sublinhado. No caso de um nodo, no diagrama de desenvolvimento, pode-se escreve "impressora" ou "HP 5J - Sala dos professores".

Notas:
Uma nota pode ser acrescentada a qualquer diagrama, para lembrar de algo que a linguagem não possa representar. Como a UML e todas as suas predecessoras são abstrações limitadas, muitos detalhes do problema ficam de fora e precisam encontrar seu caminho dentro do projeto acomodadas, por exemplo, em notas acompanhado os diagramas.

Especificações:
Os elementos de modelo têem propriedades que guardam valores sobre os elementos. Uma propriedade é definida por um valor etiquetado . Existe um certo número de propriedades pré-especificadas: documentação, responsabilidade, persistencia e concorrência.
Tipicamente, é necessário acrescentar algum texto descritivo, existindo uma janela para este fim para cada elemento de modelo no Rose98.

---

UML Extendida

UML pode ser extendida para cumprir funções específicas. Em [ERI97] encontramos três exemplos destas extensões, que enriquecem a notação do Rose98:

Esteriótipos: é um mecanismo de extensão que traz uma semântica. Baseia-s em todos os elementos básicos (classe, nós, componentes e notas), bem como nos relacionamentos (associação, generalização e dependência).
É descrito colocando o seu nome entre << >> (referidos como guillemets, ou angle brackets), ou lhe atribuindo um ícone específico, como o do ator.

Valores etiquetados: elementos podem ter propriedades que contém pares de nomes-valores, com informação sobre eles. São valores marcados ou valores etiquetados. Qualquer informação pode ser acrescentada nestas etiquetas: informações administrativas, informações específicas do problema, dados para outras ferramentas.

Restrições: Um vínculo restritivo é uma limitação em um elemento, que resulta em limitação na sua associação. Por exemplo: a classe "grupo da terceira idade" relaciona-se com a classe "pessoa", com a restrição de que {idade > 60} (ou 110, para moradores do Caúcaso), ou seja, somente pessoas com mais de 60 anos podem participar da associação (ou funcionários-gerentes, outro exemplo).

Testes de Software - 2

BSI03

O artigo trata da importância de Testes de Software no processo de desenvolvimento, e o quanto ele pode garantir que sistemas tenham seu nível de qualidade na entrega acrescido. Através dos testes é possível filtrar grande parte de erros muitas vezes simples e de fácil resolução que não foram descobertos pelos desenvolvedores e que se fossem para cliente poderiam causar um constrangimento ou mesmo quebra de contrato.

Muitas vezes ele é descartado por empresas pelo fato de custar muito caro ( em torno de 40% do tempo, segundo pesquisas em empresas que adotam a metodologia) e por ter seus objetivos mal compreendidos. Assim, pensar que os testes devem ser executados de maneiras apenas manuais e cansativas ou que os testes apenas irão demonstrar as funcionalidades implementadas no sistema são equívocos comuns que desencorajam a utilização desta fase tão importante do ciclo de desenvolvimento.

Existem muitos tipos de testes que podem ser aplicados em momentos diferentes do desenvolvimento e de formas diferentes. Alguns são realizados de maneiras automatizadas (geralmente em testes que devem ser executados com maior freqüência ou que exijam imparcialidade) evitando que, por exemplo, um usuário que já esteja acostumado com o sistema passe pelos erros sem notá-los, devido ao vício causado pela constante utilização, ou mesmo para evitar que isto se torne uma atividade enfadonha para quem tem que testar. A automatização é muito útil em testes de unidade ou de integração.

Testes de Softwares são comumente relacionados a cores, onde os testes de caixa-branca representam a parte de testes responsáveis por garantir que todas as partes do código fonte estão funcionais e sem erros. Testes de caixa-preta preocupam-se apenas com os requisitos do software, verificando se estes estão sendo atendidos. E por fim também existem os testes de caixa-cinza que é a mesclagem entre os testes de caixa branca e preta.

Para que a execução dos testes seja feita de forma padronizada, existe uma área que deve ficar responsável apenas por isto. Nesta área encontram-se profissionais como testador, que executa o testes, analistas responsáveis pela montagem de ambiente e pela definição das condições dos testes, além do engenheiro que provê as soluções e o gerente que é o responsável por todo o processo.

Com isto percebe-se que testar software é algo bastante abrangente, mas que não deve ser utilizado sem a análise do projeto como um todo. Devido ao alto custo na execução de testes e a grande variedade de tipos é fundamental que se perceba quais testes realmente são necessários para o sistema e executá-los. Quando mal interpretados, testes podem elevar o custo/tempo de um projeto e não trazer o objetivo esperado, já que de nada adianta eu ter um teste de integração se meu sistema não é em módulos, por exemplo.

Testar deve ser premissa em desenvolvimento de software e isto é uma questão de cultura que deve ser adotada pela equipe como um todo. Eleger profissionais responsáveis por ferramentas ou testes mais pesados é excelente, mas se o programador não faz a parte dele fazendo um teste unitário ou outro teste mais simples que seja (mesmo manual) e pensando que encontrar os bugs é responsabilidade do testador só fará com que exista uma transferência de responsabilidade sobre o software parecendo que se o sistema tem bug é “problema” do testador.

Quando existir cooperação entre todos da equipe e a visão de que o produto é da empresa, testar passará a ser sinônimo de garantir um bom trabalho e com certeza um aumento de qualidade no que será percebido no que for entregue ao cliente final. Testar deixará de ser atividade trivial e desgastante para ser rotineira e gerar bons resultados.

Testes de Software

ECP04

Os autores abordam um tema em seu artigo de especial destaque hoje entre empresas de desenvolvimento, o setor de testes de software. Descrevem os principais pontos do conjunto estendendo-se da sua importância e planejamento até métodos e suas fases.

Introduzem o contexto abordando atributos da ISO 9126: funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade, que estão relacionados à qualidade de aplicações e podem ser alcançadas com o uso de testes que verifiquem estas condições.

Num segundo ponto, a estruturação e planejamento de testes, demonstrando questões que são apresentadas nesta etapa como o que, como, quem efetuará e quando efetuará os testes. Questões estas que são levantadas e propiciam o planejamento, segundo os autores.

Teste de caixa Branca/Preta – Estes dois métodos de testes acabam sendo descritos, sendo o caixa branca como um teste que avalia a parte interna, ou seja, o código e suas partes – decisões, fluxos, ciclos e caminhos lógicos; e o caixa preta avaliando conforme as entradas, as saídas que geram, sendo apresentados técnicas como Teste de Performance, Teste de Usabilidade, Teste de Carga, Teste de Stress, Teste de Confiabilidade e Teste de Recuperação. Em cima do teste de caixa branca, uma ferramenta profissional é apresentada: o JUnit, utilizado em testes de sistemas orientados a objeto, específico em Java.

O artigo trata de uma forma clara e rápida sobre as fases de teste, informando para o leitor os nove tipos (unidade, integração, sistema, aceitação, operação, regressão, alpha, beta e gama), descreve também o significado de cada um e sua importância como também é tratado o tema Release candidates, nesse caso dá-se um exemplo do que acontece com uma empresa de grande porte como a Microsoft.

Testes automatizados – de forma macro são apresentados o quê e o porquê dos testes automatizados, demonstrando que erros e más práticas de programação podem ser corrigidos facilmente. Além de mostrar sua importância como auxilio a incapacidade humana de chegar à perfeição, tanto na programação, quanto na execução de testes.

Embora sendo um artigo breve, os autores foram específicos, quanto à importância dos testes de software e uma observação de que os testes podem ajudar na implementação, e mesmo que seja uma alteração mínima no tempo de execução, isso pode ser de muita importância para o uso ou não da ferramenta.

Alguns pontos devem ser levados em consideração, como a citação de alguns termos sem a devida descrição, obrigando o leitor a procurar alguns conceitos básicos como o que é um arquiteto de testes, por exemplo. O título ficou muito abrangente dando a possibilidade infinita de conhecimento, olhando este ponto tem-se a impressão de que falta conteúdo, o que na verdade falta um melhor foco do título.

Projetos de sistemas de tempo real

BSI07

Um projeto de sistema de tempo real é bem peculiar por seus requisitos e metodologias de desenvolvimento e teste. Está inteiramente ligado ao tempo de execução do processo, pois este tem que ser concluído no menor tempo possível ou no exato momento definido.

Antigamente poucas empresas desenvolviam este tipo de projeto, a maioria dessas hoje estão firmes no mercado, pois a necessidade de aplicações de tempo real cresce até mesmo hoje em dia. Para se desenvolver uma aplicação dessas antigamente era algo muito complexo.

O grau de complexidade de um projeto reflete em seu custo, por isso projeto de sistemas de tempo real são muito caros, principalmente por seus rigorosos testes de requisitos.

O modelo DARTS auxilia a definir a ordem do desenvolvimento de um projeto de tempo real, isso em quatro passos:

1. Criação dos diagramas de fluxo de dados, DFD;
2. Dicionário de dados;
3. Definição de tarefas;
4. Definição de interfaces entre funções.

Entendemos que o desenvolvimento de projetos de sistemas de tempo real é uma atividade complexa, mas rentável e que com muita disciplina, embasamento técnico e testes pode-se ter um ótimo resultado.

Design Patterns

BSI05

O trabalho trata de vários Design Patterns, e os define como "soluções para problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos. Um padrão de projeto nada mais é do que uma solução para esse determinado problema". No artigo foram citados vários Design Patterns, são eles: Singleton, Facade, Iterator, e MVC.

É feita a definição onde separa estes vários design patterns em duas categorias. Os do tipo do tipo GoF, ou Gang of Four que dividem os design patterns em 3 categorias: criação, estrutural e comportamentais. E os do tipo Grasp, ou "General Responsibility Assignment Software Patterns" que conforme afirma a equipe existem diversos padrões, porém eles abordaram somente um Design Patter Grasp Controller.

Iniciando as explicações de Design Patterns, o primeiro a ser apresentado foi o Sigleton, este serve para garantir que somente uma instânsia de uma classe exista mantendo um único ponto global de acesso ao seu objeto. A equipe defende que este tipo de prática não sobrecarrega a memória do sistema e faz a distinção entre o singleton contra os métodos estáticos e contra injeção de dependência. Onde o primeiro não é aconselhado o uso do singleton para essa situação e destaca que seu uso abre mão de algumas vantagens como a perda do polimorfismo. Porém não há nenhum exemplo de código que demonstre a situação e não há um levantamento das vantagens e desvantagens do uso do Singleton em relação a outros design patterns.

Em seguida é comentado sobre o FACADE, onde cita que o facade pode ser considerado um encapsulador de classes, onde o programa fáz o acesso a elas atravéz do próprio FACADE facilitando a arquitetura do projeto como um todo. Esclaresce que o FACADE é uma interface simplificada para uma classe mais complexa, e que na verdade não passa de uma organização da classe ordenando os seus métodos por funcionalidades ou outros critérios.

O último design patterns citado do tipo GoF é citado o ITERATOR. Ele é usado para que iteradores utilizados para acessar os elementos de um conjunto de objetos, não exponham a sua arquitetura nem a forma como os objetos são iterados. Porém não há uma definição de por que isso traria alguma vantagem ao desenvolvimento, assim não ficando claro o objetivo do ITERATOR.

Por fim define o MVC em Model, View e Controller e explica cada uma destas camadas. Citando que o Model contém os dados das aplicações e as regras de negócio que se associam a ela. View como a camada que o usuário interage diretamente. E por fim o Controller como que responde a eventos normalmente disparados pelo usuário atravéz de uma View.

Em geral o artigo apresenta vários Design Patterns, mas não mostra exemplos de código nem as aplicações deles em software conhecidos. Desta forma não fica claro o grau de efetividade na adoção destes como ferramenta de trabalho. Porém ele é bem útil para mostrar a existência de diversos design patters, assim como a sua divisão entre os dois tipos direferentes de padrões GoF e Grasp os quais não conheciamos.

Ciclo de vida do Software

ECP01

Esse artigo mostra a importância dos modelos de ciclo de vida para o desenvolvimento de um software. Nesse artigo são destacados os modelos em cascata, de prototipação, espiral e interativo.

No modelos em cascata, uma fase só começa quando a anterior terminou, não podendo voltar atrás.

Segundo a proposta inicial de Winston Royce (Royce, 1970), considerado o inventor do modelo em cascata, este modelo se caracteriza por possuir uma tendência na progressão seqüencial entre uma fase de desenvolvimento e a seguinte.

No modelo de prototipação, são desenvolvidos protótipos para que o usuário final do sistema possa interagir com o software e assim ele pode dizer se era isso o que ele esperava. De acordo com Jalote a idéia básica deste modelo é que ao invés de manter inalterado os requisitos durante o projeto e codificação, um protótipo é desenvolvido para ajudar no entendimento dos requisitos.

No modelo espiral, é uma mistura do modelo em cascata com o de prototipação, porque como o modelo em cascata uma fase só começa depois da anterior ter terminado e como o de prototipação cada ciclo é gerado um protótipo. Segundo o site macoratti, Uma maneira simplista de analisar este modelo é considerá-lo como um modelo cascata onde cada fase é precedida por uma análise de risco e sua execução é feita evolucionariamente (ou incrementalmente).

No modelo incremental, são geradas versões, onde a próxima versão será criada em cima dos riscos encontrados na versão anterior. Segundo o site mundooo, um processo de desenvolvimento segundo esse modelo divide o desenvolvimento de software em iterações. Em cada iteração, são realizadas as atividades de análise, projeto, implementação e testes para uma parte do sistema.

Concordamos com os autores desse artigo, que concluiram que cada modelo tem sua vantagem e que deve ser escolhido conforme a situação de utilização e gostariamos de destacar que o modelo em cascata possui vantagens em se dedicar a cada fase individualmente o que posivelmente reduz erros, o modelo de prototipagem tem vantagem de interagir mais com o cliente, o que divide a responsabilidade do desenvolvedor com o cliente, o modelo em espiral mescla as vantagens dos modelos em cascata e de prototipação e o modelo incrementel tem a vantagem de realizar as funcionalidades mais importantes primeiro, o que para nós faz o modelo em espiral o mais interessante, porém tudo depende da aplicação.

MDA - Model Driving Architecture

ECP02

Os autores se preocupam no artigo em deixar claras as definições de MDA (Model Driving Architecture) e os padrões OMG (Object Mamagement Group) que a suportam, focando UML(Unified Modeling Language). MDA dá importância à modelagem no processo de desenvolvimento do software, baseado em um modelo abstrato do sistema, modelos mais concretos são criados seguindo processos de refinamento dos modelos empregados.

Nos quatro tipos de modelos: CIM (Computation Independent Model), PIM (Platform Independent Model), PSM (Platform Specific Model) e ISM (Implementation Specific Model) faltou uma comparação de modelos, destacando as vantagens de cada um. As idéias básicas com relação à natureza abstrata de um modelo: classificação do modelo, independência de plataforma e transformação do modelo e refinamento foram abordadas de forma clara mostrando o potencial do uso do MDA, mas o artigo peca por não ter exemplos práticos e estudos de caso. A finalização de maneira simples, contudo direta, lista as vantagens do uso da MDA.

O MDA é uma ótima ferramenta na resolução de problemas de integração através de especificações de interoperabilidade, tem papel fundamental não só na documentação como na implementação dos sistemas, auxiliando na redução de custos e prazos no desenvolvimento de aplicações.

A Aplicação da Engenharia de Software Sob Três Ambientes

BSI04

O artigo fala sobre diferentes formas para que o processo de desenvolvimento de software seja melhorado, enfatizando o estudo em três diferentes cenários e mostrando como a engenharia de software impacta positivamente, através da introdução de conceitos como fábrica de software e CMMI.

São explicados também os motivos que levam uma empresa a não utilizar a engenharia de software em seus procedimentos, na maioria dos casos ele é financeiro, pois os métodos que são utilizados geralmente só geram retorno a longo prazo. Mas a não implementação também pode ocorrer pela resistência a mudanças por parte dos funcionários

Devido ao grande avanço tecnológico, é de grande importância que as empresas de pequeno,médio e grande porte invistam em processo de Engenharia de Software , pois esta funciona como uma ferramenta de apoio ao desenvolvimento de software, pois a mesma se preocupa com todos os aspectos de produção de um software.

O processo de Engenharia de Software, deve ser implementado nas empresas independente de seu tamanho e estrutura, pois é preciso ter uma controle e uma seqüência de prioridade, independente de custo que se terá esta implantação, isso gerará para empresa uma qualidade de software tendo assim um destaque em sua produtividade.

O artigo não é muito claro no ponto em que se quer chegar com cada parte do texto, a forma de organização dos capítulos e assuntos mostrados dificulta o entendimento do real objetivo por trás da discução apresentada.Porém o artigo não deixa de ser uma boa fonte de pesquisa relacionada a melhora no processo de desenvolvimento.

Metodologia de Desenvolvimento Ágil

ECP05

As metodologias de desenvolvimento tradicionais são ineficientes, pois focam-se em burocracia ao invés dos resultados. Para que essas fossem bem sucedidas, deveriam focar-se nos resultados.

Com essa finalidade, em 2001, foi criado um novo modelo de desenvolvimento, e foi chamado de "Manifesto Ágil". As principais premissas da metodologia de desenvolvimento ágil são:

• Indivíduos e interação entre eles 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 um plano

Com isso, percebeu-se que os softwares desenvolvidos com essas novas metodologias tiveram maior aceitação tanto pelos clientes quanto pelas empresas desenvolvedoras, por haver uma maior agilidade na entrega do software e no processo de desenvolvimento do mesmo.

MVC e Django

BSI01

São duas ferramentas de alto nível para a área de desenvolvimento, são consideradas de alto nível e fácil manipulação do código fonte. Mas não muito difundidas pelas empresas por elas escolherem outras ferramentas a desenvolver suas aplicações.

A MVC gerencia múltiplos visualizadores usando o mesmo modelo é fácil manter, testar e atualizar sistemas múltiplos. É fácil incluir novos clientes, apenas incluindo seus visualizadores e controladores. É possível ter desenvolvimento em paralelo para o modelo, visualizador e controle, pois são independentes. Porém requer uma quantidade maior de tempo para modelar o sistema, necessita de pessoal capacitado e não é recomendável para pequenas aplicações.

De acordo com a descrição encontrada no site do Django Brasil, "Django é um framework web de alto nível escrito em Python que estimula o desenvolvimento rápido e limpo". Ele possibilita o desenvolvimento de sistemas de forma ágil, fazendo com que os programadores desenvolvam num curto espaço de tempo. Mas como é uma ferramenta não muito conhecida os programadores optam em desenvolver nas que estão mais difundidas no mercado.

Elas têm uma grande chance de se tornarem popular assim que empresas de grande porte adotarem ela no seu ambiente de desenvolvimento, tornando-as mais difundidas no mercado.

Aplicações cliente-servidor usando Delphi

ECP06

Conforme a apresentação dos alunos e o artigo em questão foi verificado que a plataforma Delphi se aplica a necessidade de comunicação cliente – servidor com vantagens resumidas anteriormente, porém, a linguagem não é uma das melhores utilizadas atualmente. Visto que, possuímos outras ferramentas com mesmas funcionalidades, até mesmo simplificadas e com mais aplicabilidade em várias plataformas, como por exemplo, para dispositivos móveis.

A versão do Delphi abordada no trabalho, por se tratar de um ambiente de desenvolvimento construído para suprir as necessidades da época, nos dias de hoje, possivelmente poderia ser substituído por tecnologias com maior aplicabilidade. No artigo relacionado foi dada ênfase a comunicação aplicação local – servidor, mas a maior tendência dos serviços web, não cabe ao contexto proposto. Apesar de que com a chegada do Delphi 7 integrando com a biblioteca IntraWeb aumentaria a gama de usabilidade da ferramenta em questão.

Em suma temos uma boa ferramenta para a construção de aplicações do gênero, porem com suas limitações.

Métodos de Desenvolvimento

BSI02

“Métodos de desenvolvimento” (IST, 2008, 10 páginas) dos estudantes Dayane da Silva Weinrich, Marco Aurelio Pontes, Rodrigo de Oliveira Cardoso apresenta um estudo sobre as ferramentas utilizadas para o desenvolvimento de software abordadas de forma sucinta e bastante clara para o entendimento do leitor.

Os autores procuraram deixar claro cada modelo de desenvolvimento apresentado e para isso fizeram uso de diagramas exemplificando cada processo.

O modelo em cascata apesar de dar a organização ao desenvolvimento, pois só permite o trabalho do próximo passo após a conclusão do atual, deixa a desejar no quesito de reestruturação do código. Caso tenha-se necessidade de acrescentar algo a um processo já feito, não lhe é permitido.

Com o modelo interativo os autores demonstram que o software é desenvolvido em partes, e testado pelos usuários conforme os códigos vão ficando prontos. Apesar de mostrar a facilidade de controle isso pode demandar muito tempo de desenvolvimento.

No modelo ágil o artigo comenta que é um método de desenvolvimento rápido e comenta apenas que perde em planejamento esquecendo de comentar sobre a qualidade do software que deixa muito a desejar.

Modelo formal é o modelo que se prepara melhor antes do desenvolvimento, evitando ao máximo possíveis erros de programação que geram custo elevado no inicio, mas compensa ao final do projeto.

Modelo aspiral abordado no artigo ficou muito vago, pois não ficou claro as forma como desenvolver.

Rup é um modelo completo que se utiliza de ferramentas para auxiliar no desenvolvimento.

E Cleanroom que é o método mais caro, mas com o software mais correto possível ao seu final.

Os autores tentam passar nesse artigo, uma idéia de modelos de desenvolvimento onde apresentam um a um cada ferramenta. Eles abordam muito bem os conceitos e definições de cada metodologia demonstrando inclusive diagramas do processo, porém esse artigo não deixa claro exemplos de utilização dos modelos, o que facilitaria muito o entendimento do desenvolvedor.

Um ponto que deixa dúvidas é sobre as fontes que os autores tomaram como base, sendo um site de colaboração publica, pode ocorrer informações imprecisas.

Apesar de tudo, o artigo contempla muita informação sobre as ferramentas e ajuda na decisão de qual caminho seguir no planejamento e desenvolvimento de software.

Engenharia de Componentes aplicada no Framework TOTVS Joinville

ECP03

A engenharia de software baseada em componentes é um assunto importante e um método de desenvolvimento que é robusto e de fácil utilização. Teremos aqui exposto o caso TOTVS na uitilização da ESBC (Engenharia de Software Baseada em Componentes).

Um componente nada mais é do que uma parte modular, possível de ser implantada e facilmente substituída de um sistema que encapsula a implementação e exibe o conjunto de interfaces. Com esta definição de componente resta ainda entender o que é a ESBC.

ESBC (Engenharia de Software Baseada em Componentes) tem uma simples e fácil explicação que foi explanada por Pressman em 2006: “É um processo que enfatiza o projeto e a construção de sistemas baseados em computador usando componentes de software reusáveis”

A empresa TOTVS Joinville vem fazendo uso da ESBC para melhorar o seu desenvolvimento de software. Eles utilizam um framework que contém as principais e mais importantes partes do software que já foram desenvolvidas para que a partir desse framework seja feita a reutilização dos componentes necessários para novos aplicativos, novas implementações, atualizações, correções, etc.

Este tipo de trabalho torna o desenvolvimento mais ágil sendo que antes de novos desenvolvimentos o framework é revisto com o intuito de melhorar o mesmo e verificar se as inovações necessárias já não estão presentes no framework.

A grande vantagem deste modelo é a confiabilidade dos componentes, pois existe uma grande carga de testes a cada reutilização. Podemos citar ainda menos gastos, maior agilidade, menores riscos, dentre outras tantas vantagens nesta abordagem.

Claro que existentes desvantagens, uma delas é o número de correções necessárias em caso de erro encontrado nos componentes. O problema pode ser ainda maior caso exista uma falta de documentação ou documentação incompleta do framework e seus componentes.

Desta forma podemos observar que o método da TOTVS Joinville com o uso da ESBC e seu framework trás grandes benefícios par a empresa a curto, médio e longo prazo. Afinal de contas o custo x benefício num desenvolvimento de software é melhorado exponencialmente junto com as novas implementações e complementos elaborados para o framework utilizado.