Alexandre Mota (acm@cin.ufpe.br) Análise do Sistema Alexandre Mota (acm@cin.ufpe.br)

Desenvolvendo o Sistema Sub-sistemas Documento de Requisitos Problema Solução ... : Estudante Form. Matrícula 1: entra id 2: verifica id 3: entra semestre atual 4: cria novo cronograma 5: processa Modelo dos requisitos Detalhes e Dec. de projeto Perspectiva do Usuário Perspectiva do Desenvolvedor

Modelo UML: “Visão 4+1” Logical View Development View Use Cases/ Funcionalidade Configuração Logical View Development View Class diagrams, Sequence diagrams Component diagrams Use Cases/ Scenarios Use Case diagrams, Sequence diagrams Rational’s view of architecture contains 5 perspectives to accommodate the variety of concerns with which architects must deal. Inside each box representing a view is listed the system qualities that are of most concern within that view. Underneath each box, primary stakeholders of each view are listed. Rational has a separate course for software architects. What follows in this course is a brief overview for the management audience suitable for understanding of the central role of architectures in the process. Process View Physical View Deployment diagrams Deployment diagrams Performance Topologia 8

Modelo Para criarmos um modelo do sistema, temos que identificar: Objetos Classes Atributos Métodos Associações entre classes Outros relacionamentos entre classes

<< Estereótipo >> Classes << Estereótipo >> NomeDaClasse * * pode ser: {persistent} + atribPub: Tipo = Inicial # atribProt - atribPriv << constructor>> new() <<query>> getRiscos(o: Cliente)

Semântica das Classes Análise Projeto A descrição da classe deve Focar em seu propósito (funcionalidade) e não em sua implementação Na análise, as classes só devem estar relacionadas ao domínio do problema The definition is typically two to three sentences. Difficulty in describing the class may be an indication of a poorly defined abstraction A few things can happen: You can come up with a clear, concise definition -- good candidate class You cannot come up with a definition -- do more analysis You need a book to define the class -- not a good class -- doing too much -- break it up You come up with a definition that matches another class -- combine the classes The HOWS are determined during design which occurs in the elaboration and construction phases of the development process. Essência é “O QUÊ” e não “COMO” Análise Projeto

Abordagem 1: Linguagem Para identificar objetos, classes e interfaces, liste todos os nomes (substantivos), pronomes e frases do seu documento de requisitos/casos de uso Nomes próprios e frases que indiquem unicidade representam objetos João, ela, minha conta, o elevador 1 Nomes comuns ou no plural indicam classes ou interfaces Clientes, contas, um elevador

Abordagem 1: Linguagem Para identificar serviços (métodos), atente para os verbos ou frases verbais Clientes podem depositar na poupança Para identificar atributos, analise as frases que expressam propriedades de objetos/classes Clientes possuem uma senha, ou A senha do cliente deve ser de no mínimo 8 caracteres

Abordagem 1: Linguagem Verbos também podem identificar associações entre objetos, classes ou interfaces Uma disciplina tem pelo menos 3 alunos matriculados Assim como, relacionamentos de herança, dependência, etc. Uma poupança é um tipo especial de conta bancária

Infelizmente... Na documentação informal, existirão nomes que não serão objetos, classes e nem interfaces Não há um algoritmo que nos permita modelar um sistema da forma perfeita Tudo depende de experiência e julgamentos corretos na hora de escolher o grau de abstração certo

Utilidade dos casos de uso Casos de uso são mais interessantes que texto informal pois são mais estruturados e orientados a serviços Casos de uso naturalmente são vistos como métodos As intenções de um subconjunto de casos de uso revelam as classes Demais elementos são obtidos pelos fluxos de ações ou diag. de seqüência

Diagrama de Seqüências Sistema Gerente BD Abre Conta Solicita Info Cliente Info Cliente Fornecida Solicita Tipo de Conta Tipo de Conta Fornecida Solicita Saldo Inicial Saldo Inicial Fornecido Cria Conta Confirmação

Abordagem 2: Cartões CRC CRC vem de Class-Responsibility-Collaboration Um cartão CRC mostra Nome da classe e descrição Suas responsabilidades Conhecimento interno (atributos) Seus serviços (métodos) Os colaboradores das responsabilidades Um colaborador é uma classe cujos serviços são necessitados por uma responsabilidade Two great books on CRC cards are: Designing Object-Oriented Software by Rebecca Wirfs-Brock, Brian Wilkerson, and Laura Wiener. Prentice Hall, 1990 Using CRC Cards by Nancy M. Wilkinson. SIGS Books, 1995 They are sometimes called a “poor man’s case tool”

Uma sessão CRC Grupo de pessoas desenvolvem um cenário Um cartão é criado para cada objeto no cenário Cada participante é associado a grupo de cartões A pessoa torna-se a “classe”

Uma sessão CRC Os cenários definidos são praticados pelos participantes Os cartões são anotados com as responsabilidades e colaborações Novos cartões surgem para novos objetos descobertos

{ { Exemplo de CRC Atributos Métodos Class Name Catalog Responsibilities Collaborations Catalog number Remove Book Add Book Book Catalog store { Atributos { Course collaborating with the Course means that two objects in the same class have to “talk” Métodos

{ { Atualizações Atributos Métodos Class Name Catalog Responsibilities Collaborations Catalog number Remove Book Add Book Book Catalog store { Atributos { Métodos Diagrama de Classes + Diagrama de Seqüências

Evolução Trabalho vai bem se . . . Todas as classes têm nomes significativos, domínio específico e pequeno conjunto de colaboradores Não há classes “instáveis” (uma classe que colabora com alguém precisa ser re-definida completamente) Mudança nos requisitos só envolve classes Don’t dwell on this chart. The point is to give the students some idea of how you evaluate the process while it is going on. These are heuristics collected from a number of places

Evolução E mal se . . . Várias classes não têm responsabilidades Mesma responsabilidade atribuída a várias classes Todas as classes colaboram com todas as outras classes

Estereótipos (<< >>) Um estereótipo representa a classificação de uma classe Toda classe deve ter apenas um estereótipo Mais comuns Boundary, Entity, Control, Exception, Utility Explain that boundary, control and entity stereo types are discovered during analysis. The other stereotypes are usually added during design since they represent a “how”

Boundary Classe boundary modela a comunicação entre a parte interna e externa do sistema Mais comuns Windows (GUI) Protocolo de comunicação (interface do sistema) Interface com a impressora Sensores It handles the communication between the system surroundings and the inside of the system It constitutes the surroundings-dependent part of the system It clarifies the system's boundaries Class Name <<boundary>>

Boundary Informações entre ator e sistema devem estar contidas em classe boundary Diagramas de seqüência são examinados para identificar o conteúdo da classe : Estudante Form. Matrícula 1: entra id 2: verifica id 3: entra semestre atual 4: cria novo cronograma 5: processa Explain that the form must allow the user to enter an id number, select a semester (either current or future), select a registration option (listed in the use case) and submit the form for processing. Other scenarios would be examined to add any additional information e.g., a Cancel button. It is not necessary to model all the components of the form. Typically one class per window is all that is needed since the class will most likely be built using some sort of GUI builder. Form. Matrícula <<boundary>>

Janelas Protótipos (desenhos) de janelas podem ser criados para representar a classe boundary ao usuário

Interface com outros Sistemas Classe boundary também pode ser usada para modelar interface com outros sistemas Suas características são: Informação a ser comunicada com o outro sistema Protocolo de comunicação usado nesta transferência

Entidade Classe de entidade modela informação geralmente “persistente” Valores de seus atributos são freqüentemente fornecidos por um ator Exemplos seriam Curso Estudante Professor Conta The behavior is surroundings-independent means that it is not sensitive to how the surroundings communicate with the system <<entity>> Conta

Diagrama de Seqüência Os diagramas de seqüência são atualizados Classes adicionais são incluídas no diagrama Objetos no diagrama são associados a classes This is when control classes are added to the sequence diagram. Note that messages may be moved and/or changed when a control is added to the diagram.

Diagrama Atualizado :Registration :Schedule :Registration :Catalogue :Course :Student :Course :Schedule :Billing System John : Form Form Manager Record Roster Student 1: enter id 2: validate id 3: enter current 4: create new 5: display 6: display 7: select course 8: process Note: explain that the object names have been omitted from this diagram. this is a “readability” problem -- if the object names are shown, the diagram is too big for one slide ! 9: create schedule 10: get prerequisite 11: prerequisite taken ? 12: add student (John) 13: print 14: send to billing system 15: registration complete 16: registration complete

Bibliografia Sommerville, I. Software Engineering Kruchten, P. The Rational Unified Process: An Introduction Tepfenhart, W. et al. Practical Object-Oriented Development with UML and Java