A UML é uma linguagem de modelagem. Sendo assim, deve proporcionar a capacidade de expressar de maneira diferenciada e complementar o conhecimento adquirido do domínio de aplicação estudado. Como o desenvolvimento de software reque uma análise dos diversos aspectos do comportamento de um sistema, a linguagem de modelagem deve oferecer ferramentas que se adaptem a cada situação observada.
É importante enfatizar a diferença existente entre o conceito de "linguagem de modelagem" e de "metodologia", já que às vezes se confunde em qual desses conceitos a UML se encontra.
Uma linguagem de modelagem consiste em uma notação (símbolos usados nos modelos) e também apresenta um conjunto de regras (que definem como usar os modelos). As regras que podemos encontrar em uma linguagem de modelagem podem ser divididas em:
Regras sintáticas: Definem o formato e como os símbolos podem ser combinados.
Regras semânticas: Definem o significado dos símbolos e suas interpretações no contexto.
Regras pragmáticas: Definem as intenções através das quais o propósito do modelo é alcançado e se torna legível.
Já o conceito de metodologia está diretamente relacionado à forma explícita de estruturar pensamentos e ações. A metodologia define, basicamente: o que, como, quando e por que fazer.
Ao criarmos um modelo para um sistema de software, devemos ter o cuidado de representar o sistema considerando diversas perspectivas que se complementam. A maneira como a UML formaliza o entendimento dos cenários estudados é feita com o uso de uma notação visual composta de diversas regras e propósitos distintos. Para formalizar tais regras, a UML utiliza um metodologia e estruturar pensamentos e ações. Os modelos utilizados formalizam o resultado do uso do método, que é expresso em uma linguagem de modelagem propriamente dita.
Como toda linguagem a, UML necessita seguir um processo ou instruções de forma a indicar o que podemos fazer, quando como e por quê. Como se trata de uma linguagem visual, a sua sintaxe é indicada por símbolos que podem ser combinados. A UML representa, então, um conjunto de notações gráficas, apoiadas por um metamodelo único, como o objetivo de compreender, como observado anteriormente, aspectos distintos do software a ser desenvolvido. Usamos a UML principalmente quando desenvolvemos software pelo paradigma orientado a objetos, embora alguns de seus diagramas possam ser utilizados por outros paradigmas de programação. A seguir, apresentamos objetivos complementares que ilustram as diversas contribuições da UML para o desenvolvimento de software.
Grady Booch, um dos criadores da UML, diz que ela deve atingir quatro objetivos, descritos a seguir:
- Ajudar a equipe de projeto a visualizar um sistema como ele é ou como ele pretende ser.
- Ajudar a especificar a estrutura ou comportamento do sistema.
- Proporcionar um modelo que sirva de guia para a construção do sistema.
- Documentar as decisões tomadas pela equipe de desenvolvimento do projeto.
- Fornecer aos desenvolvedor uma linguagem de modelagem visual, pronta para uso no desenvolvimento e na comunicação de modelos riscos e significados.
- Oferecer mecanismos de especialização para ampliar os conceitos principais.
- Dar suporte às especificações de projeto independente das linguagens de programação e do processo de desenvolvimento.
- Prover uma base formal para o entendimento de uma linguagem de modelagem.
- Encorajar o crescimento do mercado de ferramentas de software orientadas a objetos.
- Dar suporte aos conceitos de desenvolvimento de alto nível. Como componentes, colaboração, frameworks e padrões.
Pesquisando na literatura que explora esse tema, certamente encontraremos muitas outras definições, que podem divergir um pouco se comparadas às já apresentadas. Se isso ocorrer, será devido apenas à ênfase que pode ser dada a determinado aspecto ou contribuição da linguagem. De maneira geral, ao observamos a essência de cada um dos objetivos citados, podemos dizer que todos eles podem ser divididos em dois objetivos mais abrangentes, proporcionando à UML:
- Consistência, informando ao patrocinador do projeto que o domínio do problema está bem entendido.
- Modelo para implementação adequado ao software estudado.
Considerando esses dois aspectos, é importante salientar que, na prática, a UML muitas vezes é utilizada para fazer um esboço do software, ajudando a transmitir aspectos importantes e desejados para o sistema. Nesse caso, sua ênfase estaria na comunicação em vez de na especificação. Sob o ponto de vista de desenvolvimento de software, de uma maneira resumida e objetivando complementar o que foi exposto anteriormente, podem,os também utilizar a UML para ajudar nas seguintes tarefas:
- Apresentar os limites do sistema e suas principais funções utilizando casos de usos e atores.
- Ilustrar as realizações dos casos de uso.
- Representar a estrutura estática do sistema (classes).
- Modelar o comportamento dos objetos (estados).
- Revelar a arquitetura física - Implementação (componentes).
Agora que estamos familiarizados com o conceito de utilização da UML, vamos conhecer os elementos básicos e diagramas associados a UML. Inicialmente precisamos nos familiarizar com os elementos básicos utilizados pela UML, responsáveis pelas relações estabelecidas (que relacionam seus diversos elementos) pelos diagramas (que agrupam os elementos). Este estudo é importante porque é com a base nesses elementos que podemos definir os modelos. Também vamos estudar os diagramas da UML que estão associados aos elementos descritos, ou seja, que diagramas da UML utilizam os conceitos referentes aos elementos básicos estudados.
Atores
Atores são representações de qualquer elemento que possa vir a interagir com o sistema. Observe que não fazem parte do sistema, mas representam os elementos externos que interagem com o sistema como, por exemplo:
- Usuários
- Sistemas legados.
- Equipamentos ligados ao sistema etc.
É fácil perceber que um sistema de automação empresarial, por exemplo, pode ter diversos tipos de usuários, como diretores, gerentes, vendedores, almoxarifes, etc. Consequentemente, cada tipo de usuário terá interesse em um determinado conjunto de operações disponíveis no sistema. Utilizamos, portanto, o conceito de ator para representar essas necessidades, ou seja, representar cada tipo de usuário, grupos de pessoas etc. Os atores podem tanto entrar com informações no sistema como receber resultados ou ambos. Como vimos antes, um ator é representado por um esterótipo de usuário do sistema, que não precisa ser necessariamente, uma pessoa, uma vez que outro software (sistema legado), por exemplo, também pode interagir com o sistema.
De maneira geral, podemos dizer que ator é alguém ou alguma coisa que interage com o sistema. É importante perceber que um atore representa um papel, não um usuário individual do sistema. Assim, uma pessoa poderia assumir o papel de diferentes atores em um mesmo sistema. Tecnicamente falando, ator é uma classe, que consequentemente deve ter um nome que indique o seu papel no sistema. A maneira como um ator interage com o sistema ocorre pela troca de mensagens.
Acima temos a presentação de exemplos de atores, e uma relação de especialização entre atores, onde um operador, pode se especializar e ser um aluno ou professor.
Enfim, uma vez entendido o que os atores representam, torna-se necessário perceber de que mandeira podemos identificá-los no cenário estudado. Existem diversas técnicas e recomendações que auxiliam nessa identificação. Normalmente os atores são descobertos a partir de entrevistas com o cliente ou com especialistas da área estudada. Para inspirar a identificação de atores durante as entrevistas que realizamos, podemos fazer algumas perguntas básicas, tais como:
- Quem são os clientes ?
- Quem utilizará as funcionalidades principais do sistema ?
- Quem está interessado em uma determinada operação ?
- Quem necessita administrar e manter o sistema funcionando ?
- Quem será beneficiado pelo sistema?
- Quem precisará de suporte do sistema para fazer suas tarefas diárias ?
- Quem fornece informação para o sistema ?
- Quem remove informação do sistema ?
- Quem tem interesse nos resultados que o sistema vai produzir ?
- Quem fornece suporte ou manutenção para o sistema ?
- O sistema utiliza recursos externos ?
- Com quais outros sistemas o sistema precisará interagir ?
- Quais dispositivos de Hardware o sistema precisará manipular ?
- Alguém realiza diversos papéis no sistema ?
- Diversas pessoas realizam o mesmo papel no sistema ?
Não existem regras para a identificação de um bom ator. O que existem são recomendações e bom senso em ambos os lados.
Nenhum comentário:
Postar um comentário