CmpE 104: Lesson 5

1. CmpE 104: Lesson 5

2. Many software engineers have long realized the importance of using logic for the purpose of specifying and developing software. Although important benefits accrue with its use, many practicing software engineers avoid logic due to the effort and time required in specifying any system formally. • The benefit of using logic is known to include the ability to analyse a specification in terms of consistency and completeness. These qualities are key to the validation of a software system specification. The precise and rich specifications that one can develop in logic serve as a theory of the desired system’s behaviour- a theory that can be suited to find subtle problems in and to gain a more through understanding of the system to be developed.

3. Logic is seldom used in practice, particularly in the United States. Many software engineers avoid it for the following reasons: • Logic-based specifications are often unsuitable for communicating the system properties with the client; • Logic-based specifications are typically not reusable or executable; • Logic-based specifications required that the system be fully defined in logic- a daunting undertaking for any major system.

4.  David Robertson & Jaume Agusti have developed have developed a graphical representation of First Order Predicate Calculus, in the spirit of the entity-relationship diagrams of Peter Chan. • The graphical representation addresses the concern about the communication with client. • Through the use of Prolog the authors indicate how specifications can be the basis of prototypes of system behaviours. • The authors describe how boundaries can be defined based upon those qualities of a desired system about which the specifier needs to be able to reason.

5. Models in a design lifecycle • The purpose of this chapter is to give a flavour of what it is like to combine different, simple, formal models in a design lifecycle. • The only convincing way to do this is with an example but this must be brief. • “bank loan approval problem”: which branches send loan requests from clients to a loan approval department which communicates with the bank’s central administration in deciding whether to approve each application. • The full details of systems to support this sort of operation can be subtle and complex but it is comparatively easy to describe what we believe to be the essence of the problem.

6. 2.1Requirements Analysis(1) Some of the requirements which bank example might need to satisfy.

7. Requirements Analysis(2) • The purpose of formal representations at this stage is not to nail down what the real requirements are but to provide a framework which links appropriate sections of requirements descriptions to subsequent stage of design. • To simplify example, we give next a sample of five requirements statements ( the headings for each will appear in subsequent requirements diagrams)

8. Requirements Analysis(3) • Loan application system: design a system for processing loan applications to the bank, via its various divisions. • Represent divisions: the design must consider the different roles played by each division(the branches, loan department and central administration.) • Represent communication: To discuss what information gets passed around during loan processing. This is particularly important since each division is physically separate. • Key role of loan department: the final decision on a loan is taken by the loan department, which bears responsibility for the outcome. • Wish to automate: there is a feeling within the bank that more of the loan processing procedures could be automated but it isn’t clear how this could be arranged.

9. Requirements Analysis(4) • As a preliminary to design, it is useful to organise these requirements in some shorthand form so that we can form a view of the overall problem. • A standard way of doing this is to construct a network containing summarised requirements, issues and decisions-connected by links which describe relations between these components. • By structuring the material in this way we introduce a first degree of formality into the requirements.

10. Requirements Analysis(5) The links we use in our example: • One requirement may specialize another requirement • A requirement may generate an issue • We may adopt a position in response to an issue • An issue may be suggested by an adopted position • A decision may be selected based on some position • A decision may resolve some issue • One decision may depend on another decision

11. Requirements Analysis(6) • The requirements, issues, positions and decisions are in boxes and the labels on the arrows indicate the types of relations between them. Together, they constitute what is sometimes called an argumentation network.

12. Fig. 2.2 Initial argumentation network for loan example

13. Requirements Analysis(7) • The reality at this stage is that we are not sure what we mean in general and will not be able to describe what we mean in particular until we build more detailed models. • Therefore, we treat each of the boxes in network as ‘atomic’. • Only describe formally the types of nodes and the types of links connecting them.

14. Requirements Analysis(8) • To do this we have chosen first to translate each box on the diagram into an expression of the form a_type(T,X), where T is the type of the box and X is the label of the box. • Then we translate each link of the diagram into a relation a_link(L,A,B), where L is the name of the link; A is the label of the box on the upstream end of the link and B is the label of the box on the downstream end of the link. • For example, the top-left link in Figure 2.2 translates as: a_type(requirement,’Represent divisions’)a_type(requirement,’Loan application system’) a_link(specializes, ’Represent divisions’, ’Loan application system’)

15. Requirements Analysis(9) • Having translated all of the links in this way, we can define expression which allow us to infer useful additional information. • For example, we often want to amass all the components of our network which contribute to the discussion of some issue. • We write contributes(A, B) to denote that a component, A,contributes to the discussion of component B if there is a direct link of some type from A to B or if there is a link from some intermediate component X to B and A contributes to X.Contributes(A, B) T.a_link(T, A, B)(2.1) Contributes(A, B) T, X.a_link(T, X, B) ^ contributes(A, X)(2.2)

16. Requirements Analysis(10) • Notice that this formal description would have been difficult to convey graphically using only our argumentation network. • The easiest ay to explain our formal expressions was through the use of natural language. • Often this form of natural language description connects closely to the structure of the formal expression which it summarizes.

17. Requirements Analysis(11) • We can use Expressions 2.1 and 2.2, along with our translated network to answer questions about which components contribute to which issues. • For example, we might ask if the decision to use an operator model contributed to the issue of describing divisions – expressed formally by attempting to find solution for the goal: contributes(‘An operator model’, ‘Describing divisions’)

18. Requirements Analysis(12) • By Expression 2.2, we can satisfy contributes(‘An operator model’, ‘Describing divisions’) if we can find a link a_link(T, X, ‘Describing divisions’) and we can satisfy contributes(‘An operator model’, X) • a_link(responds_to, ‘As operators’, ‘Describing divisions’) is satisfied from the network, which gives ‘As operators’ as an instance for X • contributes(‘An operator model’, ‘As operators’) is satisfied if we can find a link a_link(T, ‘An operator model’, ‘As operators’) • a_link(selects, ‘An operator model’, ‘As operators’) is satisfied from the network

19. Requirements Analysis(13) • We can also use our formal expressions to generate each possible contributor to an issue by instantiating the X in goals such as contributes(X,’Describing divisions’) • By following different combinations of expression 2.1 and 2.2, this allows us to instantiate X to each of the possible contributors • We can also generate the set of all contributors to an issue by satisfying a goal s = {X | contributes(X, ’Describing divisions’)} • Which in our example would instantiate S to :{‘Represent divisions’, ’As operators’, ’An operator model’,’ Model-based decision procedures’, ’All divisions represented as operators’}

20. Requirements Analysis(14) • In our small network there is not much benefit in performing this sort of analysis automatically because we can simply follow through the network by eye • However, most networks are much larger than this – in which case the benefits of automatic analysis can be significant. • In chapter 4, we look more closely at automated analysis of diagrammatic notation.

21. 2.2 Choice of representational paradigms • The major requirements for our model are first to describe the routes of communication between divisions and the interaction between theses; then the decision procedure for approving loans. • These two factors of the problem are significantly different in nature. On the communication side we might expect to concentrate on which messages get passes between divisions. • By contrast, the decision procedure for loan approval is not so concerned about what goes where but with understanding the logic of the decision. • This might lead us to select different representational paradigms for each facet, being careful to leave appropriate ‘hooks’ to connect them together.

22. Communication between Divisions(1) • One way to think about the communication of information between divisions is to view each division as a unit which can receive information from other units along stipulated channels and which can send out information if appropriate internal conditions hold. • These are the conditions which we will later use to connect the communication model with the model for decision procedures. • Labels on links refer to the data structures representing message passed along them.

23. Communication between Divisions (2) • Fig. 2.3 Basic Structure of an Operator Diagram • Operator 1 may transmit data D1 which may be received by operator2 • Operator 1 may receive D2 • Operator1 may transmit or receive D3(This possibility is to allow us to simulate sequences of changes to a data structure by a single operator) Division units Links operator

24. Communication between Divisions (3) • When we use the model based on this paradigm for analysis of its behavior(in section 2.4) we will see that allows us easily to simulate the effects of the sequencing of different messages between operators • If we so wished, we could also extend the model to include timing constraints on the links between operators.

25. Decision procedures within divisions(1) • Hard to think of the loan decision procedure as a system of linked operators, not easy to spot what the ‘communicating units’ of the decision might be • More nature to think of decisions as some sort of procedure, where we can identify the data on which our decision depends • Sometimes possible to find a library of standard procedures, conveniently expressed in a diagrammatic notation

26. Decision procedures within divisions(2) Overall structure of an assessment procedure which is ‘model based’: the assessment is made by selecting from a library a model matching a description of problem. Input & output data sets Functions operating over the data connected as inputs on the diagram & generating the data connected as outputs Fig. 2.4 A model –based assessment decision procedure

27. Decision procedures within divisions(3) • This type of diagram does not provide all details necessary for our decision procedure but it gives a starting point for further description • We need to be more specific about what the models in the library might look like, and we need to describe the mechanics of model selection • Some vocabulary is donated by the diagrams but of greater importance is the implicit acceptance. This implicit meaning will unfold as the design advances and is what makes such early notations paradigmatic

28. 2.3 Model Construction Communication between divisions(1) • We have chosen the operator-based model for describing the communication between divisions so we must now construct a diagram by initiating to our problem the components given in figure of Basic Structure of an Operator Diagram. • We are making no commitment to the number of branches, loan or administration departments but describe the interaction between typical examples of each kind. This is shown in figure of Diagrammatic representation of department communication (next page)

29. Communication between divisions(2) Fig. 2.5 Diagrammatic representation of department communication

30. Communication between divisions(3) The routes of transfer are: • Loan requests can be passed from branch to loan_dept. • The outcome decided after processing a loan can be passed back from loan _dept. • In order to process the loan application, the loan_dept needs to prompt the central_admin to send it relevant information on the person concerned. • The appropriate information should then be sent from the central_admin to the loan_dept via a loan_info message. • The central_admin maintains and updates a database of records of loan defaulters. • When a branch is aware of a loan defaulter it reports the offending person to the central_admin.

31. Communication between divisions(4) • We now refine figure of Diagrammatic representation of department communication into a more detailed so that we can connect it later to a decision procedure. • The algorithm for doing this is cumbersome to follow by hand but is straightforward to automate • Applying our algorithm to the diagram of figure of Diagrammatic representation of department communication yield operator definitions 2.3 to 2.9

32. Communication between divisions(5) • Operator definitions 2.3 to 2.9 Any branch,B, can transmit a loan request for any person, P. Output(B, loan_request(P,B), true) branch(B) ^ person(P) (2.3) Any branch,B, can transmit a notification of any known defaulter, P, at that branch. Output(B, defaulter(P), true) branch(B) ^ known_defaulter(B,P) (2.4)

33. Communication between divisions(6) The loan department can transmit a verdict on the outcome of considering a loan request for any person, P, provided that it has received a message , R, requesting a loan for that person; that it has received relevant loan information, I, on that person; and that it can reach a decision on the loan based on this. Output(loan_dept,outcome(P,R),(input(loan_request(P,B)) ^input(loan_info(P,I)) ^ loan_decision(P,B,I,R))) person(P) (2.5) The loan department can request information on any person. Output(loan_dept,info_request(P), true) person(P) (2.6)

34. Communication between divisions(7) The central administration department can transmit an empty database of defaulters Output(central_admin,database([]), true) (2.7) The central administration department can transmit a database of defaulters containing some new person, P, if information has been received by central administration that the person is a defaulter; it can access its current database, D; and that database does not contain the new person. Output(central_admin,database([P|D]), (input(defaulter(P)) ^input(database(D)) ^ not (P  D))) person(P) (2.8)

35. Communication between divisions(8) • The central administration department can transmit loan information on any person, P, if it has received a request, R, for information on • that the person; it can access; it can access its current database, D, of defaulters; and it can reach an assessment of the credit risk of that person based on these inputs. Output(central_admin,loan_info(P,R), (input(info_request(P)) ^input(database(D)) ^ risk_assessment (P,D,R))) person(P) (2.9) • Our next step is to define the predicates responsible for the decisions made within the loan department (via loan_decision)and central administration(via risk_assessment)

36. Decision procedures within divisions(1) Fig.2.6 Diagram of outline risk assessment for example

37. Decision procedures within divisions(2) Figure 2.4 contains simple linguistic labels, intended to prompts for the sort of information we need. We supply appropriate information, giving the diagram in Fig.2.6 • A description of the top-level procedure which the diagram represents, giving its predicate name and the types of its arguments. • For each oval function box we insert the name of the predicate in model which will supply hat function • For each rectangular data box: • Decide that the data will be supplied to the function via its arguments, and give types of arguments. Fig.2.4 is instantiated to 2 arguments of types person and datastore in fig.2.6 • Decide that the data will be supplied to the function from a source which is accessed from within the function(so it is not passed in as an argument). ‘Model library’ in fig.2.4 is instantiated to data source of types model in fig.2.6

38. Decision procedures within divisions(3) • Next step is to translate the information in figure of Diagram of outline risk assessment for example(fig2.6) into a more conventional logical notation, ready for further refinement. • As in the translation of our operator diagram, we can do this automatically, using the algorithm given formally at (2.2)

39. Formal interpretation of our diagram: We have a risk assessment for a person and some data source if there is some model which we can select for that person and data, and we can assess the loan risk based on that model. P  person.D database.R info.risk_assessment(P,D,R))  M model.(select_model( P,D,M)^assess_risk(M,R)) For every person and datastore we can select some model. P  person.D database.M model.select_model( P,D,M) For every model we can produce some assessment of loan risk. M  model.R info.assess_risk(M,R) Decision procedures within divisions(4) (2.10) (2.11) (2.12)

40. Decision procedures within divisions(5) • Expression 2.10 to 2.12 provide an outline of the main predicates required in the decision procedure. From this point it is up to the ingenuity of the designer to describe what the decision procedure actually is • What we do is to take the expressions above and add conditions to them which supply the details of the decisions while remaining consistent with the type constraints of the originals

41. We have a risk assessment for a person and some data source if there is some model which we can select for that person and data, and we can assess the loan risk based on that model. Decision procedures within divisions(6) (2.13) risk_assessment(P,D,R)) select_model(P,D,M)^assess_risk(M,R) • We can select a model, M, for some person, P, and datastore, D, if there is a model defined for M with characteristic features, F, and those features can be matched to P and D. (2.14) risk_assessment(P,D,R)) select_model(P,D,M)^assess_risk(M,R)

42. Decision procedures within divisions(7) • Each model definition defines a possible model type and a list of characteristics associated with that model type. (2.15) model(working_professional, ) (2.16) model(itinerant_labor, [may_face_redundancy]) (2.17) model(unreliable_client, [known_defaulter]) • A working professional is considered good loan risk, while itinerant laborers and unreliable clients are considered bad loan risks. (2.18) assess_risk(working_professional, good_risk) (2.19) assess_risk(itinerant_labor, bad_risk) (2.20) assess_risk(unreliable_client, bad_risk)

43. Decision procedures within divisions(8) • We have a complete match of the features of a model if we can confirm each feature in turn. There are two types of match: either we have a negated feature of the form not(F), in which case we must establish that is not possessed by person P and datastore D, or we have a non-negated feature, in which case we must establish that is possessed by person P and datastore D. match_features([not(F)|T],P,D)not(feature(F,P,D))^ match_features(T,P,D) (2.21) match_features([F|T],P,D) not(F = not(X))^feature(F,P,D)^ match_features(T,P,D) (2.22) match_features([],_,_) (2.23)

44. Decision procedures within divisions(9) • Lectures have secure jobs and professional career. Temporary lectures may face redundancy. Anyone who is in the datastore of defaulters is considered a known defaulter. (2.24) feature(secure_job,P,D) occupation(P,lecturer) (2.25) feature(professional_career,P,D) occupation(P,lecturer) feature(may_face_redundancy,P,D) occupation(P,temporary_lecturer) (2.26) feature(known_defaulter,P,D) P  D (2.27) • If the risk assessment is good_risk then we decide to agree the loan. If the information is bad_risk we disagree to the loan. loan_decision(P,B,good_risk,agree) (2.28) (2.29) loan_decision(P,B,bad_risk,disagree)