| Revisión actual |
Tu texto |
| Línea 136: |
Línea 136: |
| 1) | | 1) |
|
| |
|
| {| border="1"
| | Decomposition Style |
| |+Estilos - Viewtype Modulos
| | *Elements: Module, as defined by the module viewtype. A module that aggregates other modules is sometimes called a subsystem. |
| |-
| | *Relations: The relation is the decomposition relation, which is a refined form of the is-part-of relation. A documentation obligation includes specifying the criteria used to define the decomposition. |
| ! !! Elements !! Relations !! Prop. of elements !! Prop. of relations !! Topology
| | *Properties of elements: As defined by the module viewtype |
| |-
| | *Properties of relations: |
| ! Decomposition
| | ** Visibility, the extent to which the existence of a module is known, and its facilities available, to those modules outside its parent. |
| | Module, as defined by the module viewtype. A module that aggregates other modules is sometimes called a subsystem.
| | *Topology: |
| || The decomposition relation, which is a refined form of the is-part-of relation. A documentation obligation includes specifying the criteria used to define the decomposition.
| | ** No loops are allowed in the decomposition relation. |
| || As defined by the module viewtype
| | ** A module cannot be part of more than one module. |
| || Visibility, the extent to which the existence of a module is known, and its facilities are available, to those modules outside its parent.
| |
| || No loops are allowed in the decomposition graph.
| |
| A module cannot be part of more than one module in a view | |
| |-
| |
| ! Uses
| |
| | Module as defined by the module viewtype.
| |
| || The uses relation, which is a refined form of the depends-on relation. Module A uses module B if A depends on the presence of a correctly functioning B in order to satisfy its own requirements.
| |
| || As defined by the module viewtype.
| |
| || The uses relation may have a property that describes in more detail what kind of uses one module makes of another.
| |
| || The uses style has no topological constraints. However, if loops in the relation contain many elements, the ability of the architecture to be delivered in incremental subsets will be impaired.
| |
| |-
| |
| ! Generalization
| |
| | Module, as defined by the module viewtype
| |
| || Generalization, which is the is-a relation as in the module viewtype.
| |
| || Besides the properties defined for a module in the module viewtype, a module can have the "abstract" property, which defines a module with interfaces but no implementation.
| |
| || The generalization relation can have a property that distinguishes between interface and implementation inheritance. If a module is defined as an abstract module—the abstract property—restricting the generalization relation to implementation inheritance is not meaningful.
| |
| || A module can have multiple parents, although multiple inheritance is often considered a dangerous design approach.
| |
| Cycles in the generalization relation are not allowed; that is, a child module cannot be a generalization of one or more of its parent modules in a view.
| |
| |-
| |
| ! Layered
| |
| | Layers.
| |
| || Allowed to use, which is a specialization of the module viewtype's generic depends-on relation. P1 is said to use P2 if P1's correctness depends on a correct implementation of P2 being present.
| |
| || Name of layer.
| |
|
| |
|
| The units of software the layer contains. | | Uses Style |
| | *Elements: Module as defined by the module viewtype. |
| | *Relations: The relation is the uses relation, which is a refined form of the dependson relation. Module A uses module B if A depends on the presence of a correctly functioning B in order to satisfy its own specification. |
| | *Properties of elements: As defined by the module viewtype. |
| | *Properties of relations: The uses relation may have a property that describes in more detail what kind of uses one module makes of another. |
| | *Topology: The uses style has no topological constraints. However, if there are loops in the relation that contain many elements, the ability of the architecture to be delivered in incremental subsets will be impaired. |
|
| |
|
| The software a layer is allowed to use. This property is documented in two parts. The first part gives the inter- and intra-layer usage rules; such as "a layer is allowed to use software in any lower layer," and "software is not allowed to use other software in the same layer." The second part names any allowable exceptions to those rules.
| | Generalization Style |
| | | *Elements: Module as defined by the module viewtype. |
| The cohesion of the layer: a description of the virtual machine represented by the layer.
| | *Relations: Generalization, which is the is a relation as in the module viewtype |
|
| | *Properties of elements: Beside the properties defined for a module in the module viewtype, a module can have the “abstract” property, that defines a module with interfaces but no implementation. |
| || As for the module viewtype.
| | *Properties of relations: The generalization relation can have a property that distinguishes between interface and implementation inheritance. In case a module is defined as an abstract module (the abstract property) then restricting the generalization relationship to implementation inheritance is not meaningful. |
| || If layer A is above layer B, then layer B cannot be above layer A. Every piece of software is allocated to exactly one layer.
| | *Topology: |
| |}
| | ** a module can have multiple parents, although multiple inheritance is considered a dangerous design approach in many places. |
| | | ** Circles in the generalization relation are not allowed, that is any of the child modules cannot be a generalization of one or more of its parent modules. |
| {| border="1"
| |
| |+Estilos - Viewtype C&C
| |
| |-
| |
| ! !! Elements !! Relations !! Comput. Model !! Prop. !! Topology
| |
| |-
| |
| ! Pipe&Filter
| |
| | Component types: filter. Filter ports must be either input or output ports.
| |
| | |
| Connector types: pipe. Pipes have data-in and data-out roles.
| |
|
| |
| || Attachment relation associates filter output ports with data-in roles of a pipe and filter input ports with data-out roles of pipes and determine the graph of interacting filters.
| |
| || Filters are data transformers that read streams of data from their input ports and write streams of data to their output ports.
| |
| | |
| Pipes convey streams of data from one filter to another.
| |
|
| |
| || Same as defined by the C&C viewtype.
| |
| || Pipes connect filter output ports to filter input ports. Specializations of the style may restrict the association of components to an acyclic graph or a linear sequence.
| |
| |-
| |
| ! Shared Data
| |
| | Component types: shared-data repositories and data accessors.
| |
| | |
| Connector types: data reading and writing.
| |
| || Attachment relation determines which data accessors are connected to which data repositories.
| |
| || Communication between data accessors is mediated by a shared-data store. Control may be initiated by the data accessors or the data store.
| |
| || Same as defined by the C&C viewtype and refined as follows: types of data stored, data performance-oriented properties, data distribution.
| |
| || Data accessors are attached to connectors that are attached to the data store(s).
| |
| |-
| |
| ! Publish-Subscribe
| |
| | Component types: any C&C component type with an interface that publishes and/or subscribes to events.
| |
| | |
| Connector types: publish-subscribe.
| |
|
| |
| || Attachment relation associates components with the publish-subscribe connector.
| |
| || A system of independent components that announce events and react to other announced events.
| |
| || Same as defined by the C&C viewtype but refined as follows: which events are announced by which components and which events are subscribed to by which components, and when components are allowed to subscribe to events.
| |
| || All components are connected to an event distributor that may be viewed as either a bus—connector—or a component.
| |
| |-
| |
| ! Client-Server
| |
| | Component types: client, which requests services of another component, and server, which provides services to other components.
| |
| | |
| Connector types: request/reply, the asymmetric invocation of server's services by a client.
| |
|
| |
| || Attachment relation associates clients with the request role of the connector and servers with the reply role of the connector and determines which services can be requested by which clients
| |
| || Clients initiate activities, requesting services as needed from servers and waiting for the results of those requests.
| |
| || Same as defined by the C&C viewtype but refined by the server: the numbers and types of clients that can be attached and performance properties, such as transactions per second.
| |
| || In general, unrestricted. Specializations may impose restrictions:
| |
| Numbers of attachments to a given port or role
| |
| | |
| Allowed relationships among servers
| |
| | |
| Tiers
| |
| | |
| |-
| |
| ! Peer-2-Peer
| |
| |
| |
| Component types: peers.
| |
| | |
| Connector types: invokes procedure.
| |
| | |
| || The attachment relation associates peers with invokes-procedures connectors and determines the graph of possible component interactions
| |
| || Peers provide interfaces and encapsulate state. Computation is achieved by cooperating peers that request services of one another.
| |
| || Same as defined by the C&C viewtype, with an emphasis on protocols of interaction and performance-oriented properties. Attachments may change at runtime.
| |
| || Restrictions may be placed on the number of allowable attachments to any given port, or role. Other visibility restrictions may be imposed, constraining which components can know about other components.
| |
| |-
| |
| ! Communicating Processes
| |
| | Component types: concurrent units, such as tasks, processes, and threads
| |
| | |
| Connector types: data exchange, message passing, synchronization, control, and other types of communication
| |
|
| |
| || The attachment relation, as defined in the C&C viewtype
| |
| || Concurrently executing components that interact via the specific connector mechanisms
| |
| || Concurrent unit: preemptability, which indicates that execution of the concurrent unit may be preempted by another concurrent unit or that the concurrent unit executes until it voluntarily suspends its own execution; priority, which influences scheduling; timing parameters, such as period and deadline
| |
| | |
| Data exchange: buffered, which indicates that messages are stored if they cannot be processed immediately, or protocol, used for communication
| |
| || Arbitrary graphs
| |
| |}
| |
| | |
| {| border="1"
| |
| |+Estilos - Viewtype Allocation
| |
| |-
| |
| ! !! Elements !! Relations !! Prop. of elements !! Prop. of relations !! Topology
| |
| |-
| |
| ! Deployment
| |
| | Software element, usually a process from the C&C viewtype
| |
| | |
| Environmental elements: computing hardware—processor, memory, disk, network, and so on
| |
|
| |
| || Allocated-to, showing on which physical units the software elements reside
| |
| | |
| Migrates-to, copy-migrates-to, and/or execution-migrates-to if the allocation is dynamic
| |
|
| |
| || Required properties of a software element: the significant hardware aspects, such as processing, memory, capacity requirements, and fault tolerance
| |
| | |
| Provided properties of an environmental element: the significant hardware aspects that influence the allocation decision
| |
|
| |
| || Allocated-to relation: either static or dynamic, as discussed in Section 6.4
| |
| || Unrestricted
| |
| |-
| |
| ! Implementation
| |
| | Software element: a module
| |
| | |
| Environmental element: a configuration item, such as a file or a directory
| |
|
| |
| || Containment, specifying that one configuration item is contained in another
| |
| | |
| Allocated-to, describing the allocation of a module to a configuration item
| |
|
| |
| || Required properties of a software element, if any: usually, requirements on the developing environments, such as Java or a database
| |
| | |
| Provided properties of an environmental element: indications of the characteristics provided by the development environments
| |
|
| |
| || None
| |
| || Hierarchical configuration items: is-contained-in
| |
| |-
| |
| ! Work Assignment
| |
| | Software element: a module
| |
| | |
| Environmental element: an organizational unit, such as a person, a team, a department, a subcontractor, and so on
| |
|
| |
| || Allocated-to
| |
| || Skills set: required and provided
| |
| || None
| |
| || In general, unrestricted; in practice, usually restricted so that one module is allocated to one organizational unit
| |
| |}
| |
|
| |
|
| | Layers Style |
| | *Elements: Layers. |
| | *Relations: Allowed to use, which is a specialization of the module viewtype’s generic “depends on” relation. P1 is said to use P2 if P1’s correctness depends upon having a correct version of P2 present as well. |
| | *Properties of elements: |
| | ** Name of layer |
| | ** The units of software the layer contains |
| | ** The software a layer is allowed to use: (software in next lower layer, software in any lower layer, exceptions to downward-only allowable usage) |
| | ** The interface to the layer. |
| | ** The cohesion of the layer -- a description of the virtual machine represented by the layer |
| | *Properties of relations: The relation is transitive. |
| | *Topology |
| | ** Every piece of software is allocated to exactly one layer. |
|
| |
|
| 2) | | 2) |
