Postagens

#9 Modelagem Casos de Uso

Ainda com o exemplo do sistema Bike Vitória, vamos aprender sobre os conceitos da Modelagem Casos de Uso. Incluindo: Ator: é um usuário do sistema, pode ser um humano ou outro sistema, e realiza alguma ação. Representado por um boneco e um nome. Casos de uso: são funções que os atores realizam no sistema. Representado pela forma geometrica elipse. Relações: é a relação existente entre o ator e os casos de uso, ou entre atores. Aplicando no nosso exemplo, de forma simples, o Modelo de Caso de Uso do Bike Vitória fica da seguinte forma:

#8 Diagrama de Classes

Imagem
Como falado nos Posts #5 e #6 : Existe uma linguagem para padronizar os modelos de um sistema. A UML é uma Linguagem de Modelagem Unificada (do inglês, UML - Unified Modeling Language ), e a linguagem-padrão para a elaboração da estrutura de projetos de software. Nessa postagem vamos identificar as classes , atributos , e associações entre classes; por meio da Análise do sistema que vamos usar como exemplo, já visto no post #2 , o Bike Vitória . Mas como identificar as classes? No sistema existe bicicletas, que estão armazenadas em uma estação, onde as pessoas alugam as bicicletas, pagam por meio do cartão de crédito por algum tipo de plano (diário, mensal, anual, cartão de passe), e dessa forma podem utilizá-las para se locomover. Logo, verificamos que existem 4 classes: Bicicleta, Estacao, Cliente, Planos. E como identificar os atributos? Devemos olhar as características que cada classe tem, por exemplo, cliente tem nome, telefone, cpf. De maneira simples os atributos...

#7 Modelagem Estrutural

Imagem
A Modelagem Estrutural tem alguns conceitos principais, que são importantes para a Análise de um Sistema, abaixo cito, explico e exemplifico cada um deles: Classes: Uma classe representa objetos do mundo real, com seus atributos e métodos/funções. Por exemplo, uma empresa pode ter classes: pessoa, compra, produto, estoque. E ter métodos: cadastrarClientes(), efetuarCompra(), efetuarPagamento(), abastecerEstoque(), etc. Atributos: Cada classe tem atributos, que são as características que um objeto tem. Além de possuir também tipos (int, float, double, String, etc). Por exemplo, uma classe pessoa tem os atributos: nome (String), idade (int), cpf (String), etc. Associações: As classes podem se relacionar entre si, logo elas estão conectadas. E esse tipo de relacionamento é chamado de associação. Em uma empresa, por exemplo, a classe cliente está relacionada com a classe compra, que está relacionada com a classes itens, que está relacionada com a classe produto. Assumindo...

#6 Modelagem de Sistema

Imagem
Modelar um sistema é um processo importante na Análise de Requisitos, é dessa forma que conseguimos entender melhor os requisitos do sistema. Mas o que é modelar? É representar graficamente um sistema, com uma organização de visão da realidade, e auxiliando assim o processo de planejamento do projeto. A modelagem facilita o entendimento e a construção do sistema para a equipe de desenvolvimento. Os modelos podem ser feitos em forma de desenhos ou diagramas, e os mais utilizados são os: Diagramas de Classes: um modelo estrutural, onde ele contém várias classes com relações entre si. Uma classe possui um nome, e seusatributos. Figura 1 - Diagrama de Classes Casos de Uso: um modelo comportamental, onde contém vários atores do sistema que também se relacionam entre si. Um ator de sistema possui fluxos de eventos, que são comportamentos que ele executa no sistema. Figura 2 - Caso de Uso Para organizar melhor os modelos, existe uma linguagem para padronizar a...

#5 Análise de Requisitos

Imagem
O primeiro passo ao começar um projeto é levantar todos os requisitos necessários para o sistema (os requisitos funcionais, não funcionais, e as regras de negócio). Depois de levantar os requisitos, precisamos analisá-los. Na Análise de Requisitos cada requisito documentado de acordo com as necessidades do cliente são analisados com mais atenção. Então basicamente o Levantamento de Requisitos acha as peças soltas do quebra-cabeça, e a Análise de Requisitos procura juntar essas peças para formar o quebra-cabeça. No levantamento é muita documentação em forma de texto. Já na análise é aumentado o grau de detalhamento do sistema, então pode ser representado por modelos e diagramas. Durante esse processo são usadas algumas técnicas, como Prototipação, Diagrama de Classes, Casos de Uso. Dessa forma esboçando as principais classes do sistema, e suas interações. A UML é uma Linguagem de Modelagem Unificada (do inglês, UML - Unified Modeling Language ), e a linguagem-padrão para a elabo...

#4 Levantamento de Requisitos e Técnicas

Levantar requisitos é muito importante para um projeto, mas não é um processo fácil. O analista tem algumas dificuldades, o cliente muitas vezes não sabe o que quer, e quando sabe não consegue explicar. Para conseguir realizar uma boa documentação podemos utilizar técnicas. Essas técnicas ajudam o analista e a equipe, e evitam uma análise de requisitos mal feita.  Existem várias técnicas, irei citar algumas: Entrevista: é bem comum, pode ser feita tanto pessoalmente como à distância. Por mais que corra o risco de ter subjetividade, já que depende se as perguntas serão bem feitas pelo analista, e se as respostas do cliente serão claras; gera um contato mais próximo com o cliente. Questionário: é mais objetivo, e também pode ser não presencial. São perguntas bem feitas que raramente a resposta fugirá do assunto. Prototipagem: nessa técnica são feitos protótipos sobre o sistema proposto, onde tanto os resultados como o feedback acontecem de forma mais rápida.  W...

#3 Requisitos e Agilidade

Que passos seguir no planejamento de um sistema? E que técnicas utilizar? Nessa postagem trago um pouquinho sobre Requisitos de Sistemas, Histórias de usuários, a técnica MoSCoW, e Metodologias ágeis. Ao criar um projeto de software é preciso levantar Requisitos do Sistema, que são as características e funções que o sistema deve ter. Essa é a fase inicial, uma comunicação da equipe com o cliente, e ela pode gerar problemas já que não é tão simples entender o que o cliente quer, e ter certeza que tudo que ele pede é necessário. É possível organizar os Requisitos de Sistemas por meio das Histórias de usuários, que são descrições simples do ponto de vista do usuário. As Histórias capturam o "quem", "o quê", e "por quê" de um requisito de sistema. Devem ser curtas, simples, e claras. E podem ser transmitidas por meio de pequenos cartões, em uma conversa, ou por meio de uma confirmação mais formal. É um desejo de algo que o cliente quer no sistema, ou um p...