Kĩ thuật lập trình - Chapter 2: Specification of software components

Chapter 2Specification of Software Components Page Building Reliable Component-based Systems Chapter 2 -Specification of Software ComponentsOverviewCurrent Component Specification Techniques Specifying the Semantics of Components Specifying Extra-Functional Properties of Components Summary Page Building Reliable Component-based Systems Chapter 2 -Specification of Software ComponentsWhat Is a Component Comprised of?Some Code The code represents the operations that the component will perform when invoked An interfaceThe interface tells the component-user everything he needs to know in order to deploy the component The interface of a component should provide all the information needed by its users The specification of a component is therefore the specification of its interface Page Building Reliable Component-based Systems Chapter 2 -Specification of Software ComponentsThe Specification of an InterfaceThis must consist solely of:A precise definition of the component's operations.All context dependencies.Page Building Reliable Component-based Systems Chapter 2 -Specification of Software ComponentsUsefulness of Component SpecificationFor users, The specification provides a definition of its interface, viz. its operations and context dependencies. Since it is only the interface that is visible to users, its specification must be precise and complete. For developers, The specification of a component also provides an abstract definition of its internal structure. Page Building Reliable Component-based Systems Chapter 2 -Specification of Software ComponentsCurrent Component Specification Techniques syntactic specifications Microsoft’s Component Object Model (COM) Common Object Request Broker Architecture (CORBA) JavaBeans Page Building Reliable Component-based Systems Chapter 2 -Specification of Software ComponentsComponents and Interfaces A component provides:The implementation of a set of named interfaces, or types, each interface being a set of named operations The following diagram is a UML metamodel This model allows an interface to be implemented by several different components, and an operation to be part of several different interfaces Page Building Reliable Component-based Systems Chapter 2 -Specification of Software ComponentsComponents and Interfaces IllustratedPage Building Reliable Component-based Systems Chapter 2 -Specification of Software ComponentsModel explainedThe model presents a generic representation of:The relationships between components, interfaces, and operations One can distinguish between: Object Oriented specifications and Procedural specifications Page Building Reliable Component-based Systems Chapter 2 -Specification of Software ComponentsIDL Exampleinterface ISpellCheck : IUnknown{ HRESULT check([in] BSTR *word, [out] bool *correct);}; interface ICustomSpellCheck : IUnknown{ HRESULT add([in] BSTR *word); HRESULT remove([in] BSTR *word);}; library SpellCheckerLib{ coclass SpellChecker { [default] interface ISpellCheck; interface ICustomSpellCheck; };};Page Building Reliable Component-based Systems Chapter 2 -Specification of Software ComponentsSpecification Usesthe primary uses of such specifications are:Type checking of client code. A base for interoperability between independently developed components and applications. An important aspect of interface specifications is how they relate to substitution and evolution of components Page Building Reliable Component-based Systems Chapter 2 -Specification of Software ComponentsSubstitutionSubstituting a component Y for a component X is said to be safe if: All systems that work with X will also work with YFrom a syntactic viewpoint, a component can safely be replaced if:The new component implements at least the same interfaces as the older components, orThe interface of the new component is a subtype of the interface of the old component. Page Building Reliable Component-based Systems Chapter 2 -Specification of Software ComponentsSpecifying the Semantics of Components Current component technologies assume that the user of a component is able to make use of such semantic information.COM dictates that the error codes produced by an operation are immutable, i.e. changing these is equivalent to changing the interface Page Building Reliable Component-based Systems Chapter 2 -Specification of Software ComponentsInterfaces A component:Implements a set of interfaces that each consists of a set of operations. In addition, a set of pre-conditions and post-conditions is associated with each operation.Page Building Reliable Component-based Systems Chapter 2 -Specification of Software ComponentsA Pre-conditionIs an assertion that the component assumes to be fulfilled before an operation is invoked.Will in general be a predicate over the operation’s input parameters and this statePage Building Reliable Component-based Systems Chapter 2 -Specification of Software ComponentsA Post-conditionIs an assertion that the component guarantees will hold just after an operation has been invoked, provided the operation’s pre-conditions were true when it was invoked. Is a predicate over both input and output parameters as well as the state just before the invocation and just afterPage Building Reliable Component-based Systems Chapter 2 -Specification of Software ComponentsAn InvariantIs a predicate over the interface’s state model that will always hold A set of invariants may be associated with an interface.Page Building Reliable Component-based Systems Chapter 2 -Specification of Software ComponentsInterface specification diagram This model allows the same state to be associated with several interfacesPage Building Reliable Component-based Systems Chapter 2 -Specification of Software ComponentsSemantic Specification in a UML metamodelPage Building Reliable Component-based Systems Chapter 2 -Specification of Software ComponentsInterface Specificationcontext ISpellCheck::check(in word : String, out correct : Boolean): HRESULTpre:word “”post:SUCCEEDED(result) implies correct = words->includes(word) context ICustomSpellCheck::add(in word : String) : HRESULTpre:word “”post:SUCCEEDED(result) implies words = words@pre->including (word) context ICustomSpellCheck::remove(in word : String) : HRESULTpre:word “”post:SUCCEEDED(result) implies words = words@pre->exluding(word)Page Building Reliable Component-based Systems Chapter 2 -Specification of Software ComponentsComponent specification diagram Specifying a component that provides interfaces Similarly to interface specification diagrams, components specification diagrams are used to specify which interfaces components provide and require.Page Building Reliable Component-based Systems Chapter 2 -Specification of Software ComponentsInter-interface ConstraintsThe component specification is completed by the specification of its inter-interface constraints, an example constraint is formulated in OCL below. context SpellChecker ISpellCheck::words = ICustomSpellCheck::wordsPage Building Reliable Component-based Systems Chapter 2 -Specification of Software ComponentsInterface dependency >SomeComponentISomeInterfaceIAnotherInterfaceIUsedInterfacePage Building Reliable Component-based Systems Chapter 2 -Specification of Software ComponentsRealization ContractsWe can also specify realization contracts using collaboration interaction diagrams. 1: op1/IUsedInterface1.1: op2/ISomeInterfaceWhenever the operation op1 is called, a component supporting this operation must invoke the operation op2 in some other componentPage Building Reliable Component-based Systems Chapter 2 -Specification of Software ComponentsSpecifying Extra-Functional PropertiesConventional software doctrine is the view that software specifications must be: Sufficient CompleteStatic HomogeneousPage Building Reliable Component-based Systems Chapter 2 -Specification of Software ComponentsCredentials A Credential is a triple Attribute: is a description of a property of a componentValue: is a measure of that propertyCredibility: is a description of how the measure has been obtained Attributes in .NET A component developer can associate attribute values with a component and define new attributes by sub-classing an existing attribute class. Page Building Reliable Component-based Systems Chapter 2 -Specification of Software ComponentsArchitectural component Structural properties Governing how a component can be composed with other components. Extra-functional propertiesSuch as performance, capacity, and environmental assumptions.Family propertiesSpecifying relations among similar or related components. Page Building Reliable Component-based Systems Chapter 2 -Specification of Software ComponentsEnsemble In Ensemble, a set of credentials may be associated with a single technology, product, or component, or with a group of such elements A UML metamodel with the concepts of syntactic specification augmented with credentials is shown in the following slide.Page Building Reliable Component-based Systems Chapter 2 -Specification of Software ComponentsExtra-functional PropertiesPage Building Reliable Component-based Systems Chapter 2 -Specification of Software ComponentsSummary A component has two parts: an interface and some code In current practice, component specification techniques specify components only syntactically. The use of UML and OCL to specify components represents a step towards semantic specifications. Specification of extra-functional properties of components is still an open area of research, and it is uncertain what impact it will have on the future of software component specification Page Building Reliable Component-based Systems Chapter 2 -Specification of Software Components