Modeling Components and Frameworks with UML Evolução da modelagem de componentes O que é Componente e notação em UML Diagrama de desenvolvimento Sobreposição semântica Frameworks Padrão ECF em EJB e COM+ Cesar Roberto Santos - Marcelo Kapp

Evolução da modelagem de componentes Promessa de modelos de objetos e componentes Crescimento de ferramentas de modelagem Componentes mais complexos

Definição de Componentes É a parte física, substituível do sistema que encapsula a implementação e provê a realização de um conjunto de interfaces Representa um pedaço físico de implementação, incluindo qualquer código de software

Notação UML para componentes Notação de interface longhand (detalhada) Notação de interface shorthand “lollipop” (ocultando detalhes)

Notação de componente e interface mostrando detalhes Calculate +calcWeight() +calcShipping() +calcTotal() ... ShoppingCart +weight +Shipping ... +orderItems +calcWight() +calcShipping() +addItem(item:OrderItem) +deleteItem() <<interface>> ChangeOrder +addItem(item:Item) +deleteItem() +saveItem() ... Notação de componente e interface mostrando detalhes

Notação de componente e interface ocultando detalhes Calculate ShoppingCart ChangeOrder Notação de componente e interface ocultando detalhes

Diagrama de Desenvolvimento Componentes são encontrados tipicamente em diagramas de modelo de implementação como: diagramas de componentes – mostra a organização e a dependência de componentes diagramas de desenvolvimento – mostra como componentes e instâncias de classes em nós computacionais são desenvolvidos Exemplo de diagrama de desenvolvimento

Diagrama de Desenvolvimento PrimaryServer:appServer <<database>> PrimaryDB: AccountsDB PrimaryQuoter: QuoteService <<call>> <<call>> primaryBroker :StockBroker <<copy>> <<copy>> <<copy>> <<become>> <<become>> backupServer:appServer backupBroker :StockBroker <<call>> <<call>> <<database>> backupDB: AccountsDB backupQuoter: QuoteService Diagrama de Desenvolvimento

Sobreposição Semântica A UML pode ser considerada uma linguagem de modelagem de propósitos gerais Porém a falta de exemplos (os existentes são triviais) e ferramentas para construções avançadas contribui para a sobreposição semântica Sobreposição semântica ocorre entre componentes, classe e subsistema é um dos problemas mais comuns para modeladores

Comparação Semântica de componente, Subsistema e classe   Componente Subsistema classe Is a classifier ? + Can have operations ? Can have methods ? - Can have attributes ? Can have interfaces ? Can be associated ? Can have thread of control ? Can be nested ? Is a grouping construct ? Can import/access ? Represents a unit in a physical system ? Contains Implementation of model elements ? Can create instances ? + (optional) Instances typically reside on nodes ?    

Auxílio para escolha de modelos de classificadores Deve-se utilizar heuristica de uso São diretrizes básicas mas não são regras Tabela de heuristica de uso para componentes, subsistemas e classes

Heuristica de uso para componentes, subsistemas e classes   Componente Subsistema classe Tend to be coarse-grained ? + - Typically modeled during analysis ? Typically modeled during desing ? Typical modeled during implementation ?  

Modeling Component Frameworks “Um framework é um projeto reutilizável de tudo ou parte de um sistema representado por um conjunto de classes abstratas e o modo que as suas instâncias interagem” “Um framework é o esqueleto de uma aplicação que pode ser customizado por um desenvolvedor de aplicação”

Definição da UML Frameworks “É um pacote estereotipo que consiste principalmente em padrões” “Um padrão arquitetônico que prove um modelo extensível para aplicações em um domínio específico”

Definindo um padrão comum As arquiteturas do Enterprise JavaBeans e COM+ são baseadas num padrão de arquitetura comum, o Enterprise Component Framework.

Enterprise Component Framework pattern Proxy original proxy Enterprise Component Framework pattern FactoryProxy Factory client <<call>> Component Factory Remote <<call>> original <<call>> RemoteProxy Remote <<call>> Client <<call>> Context <<call>> Container <<call>> Persistence Service client proxy Proxy

Aplicando o padrão Enterprise Component Framework A solução comum que o padrão Enterprise Component Framework provê para arquiteturas de componentes distribuídos pode ser demonstrada aplicando-o para modelar exemplos EJB e COM+.

Application of pattern to EJB Shopping Cart Specification Elements Realization Elements <<EJBHomeInterface>> ShoppingCartHome create(...) findbyPrimaryKey(...) HomeObject <<call>> <<EJBEntityClass>> ShoppingCartImpl <<call>> <<database>> ArtStore.DB <<call>> ArtStoreClient RemoteObject <<call>> <<call>> <<EJBRemoteInterface>> ShoppingCart getItemCount(...) setTotal(...) <<EJBContextObject>> ContextObject component context remoteProxy factoryProxy persistenceService container Enterprise Component Framework

Application of pattern to COM+ Shopping Cart Specification Elements Realization Elements <<COMInterface>> IClassFactory create(...) findbyPrimaryKey(...) FactoryWrapper <<call>> <<COMClass>> ShoppingCartImpl <<call>> <<database>> ArtStore.DB <<call>> ArtStoreClient ObjectWrapper <<call>> <<call>> <<COMInterface>> IShoppingCart getItemCount(...) setTotal(...) <<COMContextObject>> ContextObject component context remoteProxy factoryProxy persistenceService container Enterprise Component Framework

Conclusão A UML 1.3 provê um apoio básico para modelagem de componentes e frameworks. Notamos também que apesar das arquiteturas EJB e COM+ serem parecidas estruturalmente, existem diferenças que podem determinar o uso entre ambas.