PROGETTO CORSO IS I { METODO DA USARE. Version 2.0. A method should make precise how many models have to be produced and which features

Transcription

1 PROGETTO CORSO IS I { METODO DA USARE Version 2.0 Assume to have to develop a software system System. A method should make precise how many models have to be produced and which features they should consider. Our method requires to produce the following models: PDM a model of the domain of the problem that the System must solve, without any reference to the System. Requirement Specication a very abstract model of the System making precise which problem it will solve, showing how it will be perceived by its users and what is the context in which it will operate. Design specication a model of the developed realization of the System. PDM (Problem Domain Model) The PDM (Problem Domain Model) is a UML package including at least a class diagram. It describes in an object-oriented fashion the part of the real world that concerns the System to be developed, but without any reference to the System itself. For example, in the case the System should handle a lift, the PDM should describe how the lift works, that is in which way the calls can be made, which policy must be followed to handle the calls, and what has to be done for the safety of the users. If the System, instead, should handle the invoicing of the orders of a company, the PDM should make clear what the orders are, which policy is followed to invoice them, how the payments are handled and so on. It is important to understand what is in and what it is out of this model. For instance, in this model the following aspects must not be considered. which is the problem that the System must solve. Consider a PDM describing the treatment of the order invoicing, it may be the starting point for solving dierent problems: { the automatization of the archiving of the orders/invoices (the System will be just a data base), { the automatization of the production of the invoices (the System will be a simple desktop application), { the full automatization of the order processing from receiving the orders to producing the invoices and archiving everything, to automatically generating warnings for problematic cases, and to automatically answering to inquiries about the status of the orders).

2 Version as a consequence of the above point, no hints about the proposed solution should be included (you cannot speak about the solution before knowing the problem). technology features that will be introduced to solve the problem (e.g., in the case of aword process you should not consider the internal format of the les but only speak about words, sentences, paragraphs and so on, or, in the case of a generic distributed system, of the used midlleware). However, the above requirements are not absolute, they strongly depend on the aim of the System. For example, if the System is an application to download web sites, then the PDM includes a full description of the HTML and of the HTTP protocol if the System is a component for compressing binary les, then the PDM includes a description of a bit le format if the System is about controlling a heating system where the hardware (heater, sensors,... ) is already decided, then heater, sensors,... are in the PDM if the System is about controlling the temperature in a building without any assumption on the technology that will be used, then the PDM will be only about temperatures, rooms, day hours and perhaps cost of increasing the temperature of one cubic meter of one degree. Requirement Specication The requirement specication consists of dierent views of the System, plus a part needed to give a rigorous description of such views. Its structure is shown in Fig. by a UML class diagram. Use Case View shows the main ways to use the System, making clear who/what is taking advantage of it, and who/ what outside the System must cooperate to accomplish such usages. (services oered bythesystem, making clear who/what is using them, and who/what outside the System must cooperate to realize such services oering other services.) [functionalities oered by the System, making clear who/what is using them, and who/what outside the System must cooperate to realize such functionalities oering other functionalities.] Context View describes the context of the System, making precise which entities will use and cooperate with the System. This view describes also abstractly the interface of such entities towards the System, the assumption made by the System on such entities, and the interface of the System towards them. Internal System View describes abstractly the internal structure of the System. This part of the requirement specication is needed to soundly describe the use cases.

3 Version White View Black View Combined View Use Case SYSTEM View definition: Statechart Use Case Interaction View definition: SequenceDiagram Use Case Causal View definition: ActivityDiagram * 0.. Use Case Diagram Use Case Description textualdescription: String..* Use Case View Context View definition: Package Internal S YSTEM View definition: ClassDiagram Requirement Specification Terminology definition: Package Figure : The Structure of a Requirement Specication

4 Version Terminology lists and makes precise all entities appearing in the presentations of the various views of the System for example the data exchanged between the System and the context entities, or the internal constituents of the System which are accessed in some use case. This global description of the terminology helps to avoid that the same entity is modelled dierently in dierent use cases or in dierent points of the same use case. Internal System View The Internal System View is a UML class diagram importing the package Terminology. Conceptually, it describes at an extremely abstract level the structure (architecture) of the System. This structure consists of a unique active object able to perform the System activities (abstract executor) and by manypassive objects abstractly describing the System Abstract State. Technically, it is a class diagram containing exactly one class of the stereotype <<ABSTRACT EXEC>> (without attributes and whose operations are in bijective correspondence with those of the <<SYSTEM>> class appearing in the Context View), and several passive classes. For what concerns the associations, it contains only a binary navigable association between the <<ABSTRACT EXEC>> class and each of the passive classes. Moreover, no new passive class may be dened, only those already dened in Terminology may be used. This diagram describes implicitly also the \Abstract State" of the System class appearing in the Context View in the following way: for each association <<ABSTRACT_EXEC>> A C such class has an attribute A: Bag(C). Use Case View The Use Case View consists of a UML \Use Case Diagram" and of the descriptions of all the use cases appearing in it. The actors appearing in the Use Case diagram must be of the two following stereotypes: <<SU>> <<SP>> Service User, they use the services provided by thesystem Service Providers, they provide the services used by the System. We require that the name of each <<SU>> should end with \ u" and that the name of each <<SP>> should end with \ p". A Service User named Name u will be visually represented as follows Name_u whereas a Service Provider named Name p will be visually represented as follows Name_p. Each use case appearing in the diagram must be accompanied by a\use Case Description" consisting of a textual presentation and of one or more views of the following kinds.

5 Version Use Case System View A Use Case System View is dened by a statechart for the system class describing the complete behaviour of the System with resepct to such use case. Let CH be a statechart dening a System View. The conditions and the actions appearing on the transitions of CH may test and modify the System Abstract State given in the Internal System View. The operations of the system class, as presented in the Context View, dene the call events that may appear in the transitions of CH. Finally, the operations of the context entity classes, as dened in the Context View, may appear in the actions of CH instead the other elements of such classes cannot. Use Case Interaction View A Use Case Interaction View is dened by a sequence (or collaboration) diagram. The objects appearing in such diagram are dierent for the various kind of view precisely: Black (box) View It represents the interactions among the System and the context entities happening in a scenario of the use case thus the objects appearing in the dening sequence diagram are either the System or the context entities, as dened in the Context View. We call it \Black View", because the System is considered as a black box, preventing to see anything inside it. White (box) View It represents the interactions among the abstract constituents of the System, as presented in the Internal System View, and a special object summarizing the external environment happening in a scenario of the use case thus the objects appearing in the sequence diagram are either the abstract executor, or the constituents of the System Abstract State, as dened in the Internal System View, or the generic \outside". We call it \White View", because the System is considered as a white box allowing to see what is happening inside at the most abstract level compatible with the requirement phase. The lifeline corresponding to the abstract executor will be marked by a big E. Combined View It is the combination of Black and the White View of the same scenario of the use case. It is obtained by replacing the lifeline of System in the Black View with the White View without the lifeline corresponding to the external world. In the visual representation we split the diagram in two swimlanes, by a dashed line, to show what is happening inside and outside the System. There are no restrictions on the number of the sequence diagrams appearing in this view, but they must be coherent with the System View (that is, they must represent particular executions of the complete behaviour described by such View). Technically, a Combined View is a standard sequence diagram, but the lifelines appearing in it correspond to objects in two distinct worlds: inside the System, and outside the System.

6 Version Use Case Causal View A Use Case Causal View is dened by an activity diagram describing all the relevant events appearing in the behaviour corresponding to the use case and their causal relationships. The appearing events can be only calls of the interface operations of System (described in the Context View) by the context entities, calls of the interface operations of the context entities (described in the Context View) by System, conditions on the System Abstract State (as described in the Internal System View), UML actions acting on the System Abstract State dened by the Internal System View. The various views listed above play dierent roles in the description of a use case and are partly complementary and partly overlapping. The choice of which to use depends on the nature of the considered use case. The only rule enforced by the method is that the System View is mandatory, because it obliges to present all the behaviour of the use case (e.g., all possible alternative scenarios are included), also if it may be less readable than the others. Context View The Context View is a UML package importing the package Terminology containing a class diagram (context diagram). All classes in the context diagram are all of the following three stereotypes <<SYSTEM>> that stands for the System there should be only one class in the diagram having this stereotype <<SU>> that stands for a user of the services provided by the System <<SP>> that stands for a provider of services used by the System. Moreover, in the context diagram there will be exactly one binary association from the system class into each other class, whereas other associations are not allowed. The classes of stereotype <<SU>> must be in bijective correspondence with the actors of the same kind appearing in the Use Case Diagram similarly for those of the stereotype <<SP>>. The <<SYSTEM>> class may have only operations that abstractly describe its interface. Each <<SU>> and <<SP>> class may have attributes, operations, constraints and a description of its behaviour. The operations represent the interface of such entities towards the System, whereas the other aspects of the class represent the assumptions on their behaviour on which the System relies. Terminology The Terminology consists of a UML package, which specializes PDM, describing all the entities needed to present the use cases, the System context and its internal structure.