Modelling I 1 Paper for Next Class

Modelling I: 1

Paper for Next Class • Are “Non-functional” Requirements really Non-functional? An Investigation of Non-functional Requirements in Practice – Jonas Eckhardt, Andreas Vogelsang, and Daniel Méndez Fernández – Technische Universität München, Germany – 2016 IEEE/ACM 38 th IEEE International Conference on Software Engineering 2

General Theory of Systems • Every system is a sub-system that is part of a larger system • Interconnected parts aiming a common goal • Hierarchy – Tree structure • Divide and Conquer 3

Abstraction Source: S. Easterbrook - Uof. T • Most used tool for rationalized software • Why? – Allows to ignore inconvenient details – Allows different entities do be treated equally – Simplify many types of analysis • On Coding – Abstraction is the process of naming composite objects and deal with they as unique entities • Don’t Solve problems – But simplifies ! 4

Models • Model: It is an abstraction from reality emphasizing specific characteristics • One single model is not enough to represent all the characteristcs a system must have • Models are useful to organize information and to specify requirements • Model can guide elicitation – Helps to find new questions 5

Models – Main Objectives • Represent a viewpoint for the environment before the system is implemented • Show alternative solutions • Show future needs • Represent parts of the system • Allow to incrementally deal with complexity – from the more abstract level to the detailed level • Provide quantitative information about the scope and complexity of the problem • Allow to communicate with developers and stakeholders 6

Types of Model • Natural Language – Easy to understand to communicate with stakeholders – Good for elicitation not that much for modelling – Ambiguity is always a problem 7

8

Level of Formality in Models [1] • Formalism seeks minimize – Ambiguity – Inconsistency – Omission • Aim for unique and well-defined interpretation of the specification • Rigor and formalism in specification aims at maximizing the above qualities 9

Level of Formality in Models [2] • Natural language (Informal) – Extremely expressive and flexible • Good for elicitation (not so much for modeling) • Useful for annotating models for readability – Easy to understand to communicate with stakeholders – Poor at capturing key relationships – Ambiguity is always a problem 10

11

Level of Formality in Models [3] • Semi-formal notation – Captures structure and some semantics – Can perform (some) reasoning, consistency checking, animation, etc. • E. g. diagrams, tables, structured English, etc. – Mostly visual – for rapid communication with a variety of stakeholders – E. g. , UML 12

Level of Formality in Models [4] • Formal notation – Precise semantics, model checking and extensive reasoning possible • Underlying mathematical model (e. g. , set theory, Finite State Machines, Petri Nets, etc. ) – Very detailed models (may be more detailed than we need) • RE formalisms are for conceptual modeling, hence differ from most computer science formalisms – Formal problems are hard to understand • e exemplar ( b library belongs(b. code, e. n_item)) 13

Desiderata for Modeling Notations • Implementation Independence – Does not model data representation, internal organization, etc. • Abstraction – Extracts essential aspects • E. g. , things not subject to frequent change • Formality – Unambiguous syntax – Rich semantic theory • Constructability – Can construct pieces of the model to handle complexity and size – Construction should facilitate communication • Ease of analysis – Ability to analyze for ambiguity, incompleteness, inconsistency • Traceability – Ability to cross-reference elements – Ability to link to design, implementation, etc. • Executability – Can animate the model, to compare it to reality • Minimality – No redundancy of concepts in the modeling scheme • I. e. , no extraneous choices of how to represent something 14

Modeling Techniques • Modeling Enterprises – – Goals & objectives Organizational structure Tasks & dependencies Agents, roles, intentionality • Modeling Information & Behaviour – Information Structure (ERD, Class diagrams) – Behavioural views (state machines, sequence diagrams) – Scenarios and Use Cases – Information flow (DFDs) – Process flow (BPMN, activity diagrams) – Timing/Sequencing requirements • Modelling System Qualities (NFRs) – All the ‘ilities’: • Usability, reliability, evolvability, safety, security, performance, interoperability, 15

Divide and Conquer • Old Times “divide et impera” DIJKSTRA http: //www. cs. utexas. edu/users/UTCS/notices/dijkstra/ewdobit. html ) (programming considered a human activity) • Specify the parts individually • Satisfied? The Problem is solved? If one part is still complex: Subdivide it. 16

Divide and Conquer • Top down Approach • Disadvantages (Michael Jackson) – Choosing is a risk • The big decision is about what division should I make ? • Decision is made too early – Lack of knowledge – Lack of understanding about the problem – Real world is not always organized in a hierarchical form • Parallel and concurrent strucutres 17

Decomposition • Decompose the problem until: – Every sub-problem is in the same level of detail – Every sub-problem can be solved in an independent way – Solutions for each sub-problem can be combined to solve the original problem • Advantages – Different people can work different sub-problems – Facilitates parallelism – Maintenance gets easier • Disadvantages – Solutions for sub-problems may not combine in such a way that would solve the problem – Real world structure is not hierarquical [Michael Jackson] 18

Example: Functional decomposition function 2 conction conection Input Output function 1 conection function 4 conection function 3 19

Decomposition Source: S. Easterbrook - Uof. T • Decomposition may be of great help – Restaurant Menu • Not always work – Theatre Play Role actor 1 Write Roles Role actor 2 Role actor 3 Joint parts • Not always Possible – Complex problems – Atomic problems (add 1+1) 20

Modeling Computational World Real World Solutions Problems Semantic Gap Requirements Modeling 21

Objects • The world is composed by Objects (+-) • Objects are independent, have memory and behavior • Objects communicate through messages • Objects are organized in class (Generalizations) 22

Object • Disadvantages (Jackson): – The object idea comes from programming languages and can not be mapped to most of the individuals in the real world • What was the last time you sent a message to your car? • When the sun rises does it send a message to birds to sing ? 23

Objects “ The world outside the machine is very rich, full of whim and recalcitrantly multifaceted to be captured in the form of objects. M. Jackson 24

Goals • Goal-Oriented Models • For Example KAOS – System goals x Client Goals 25

KAOS • Developed in the early 90’s • Has been applied to a number of industrial cases • Is supported by a stable and well defined tool 26

Composition • Informal Goal structuring model • Producing Formal definitions in temporal logic for each entity 27

Example – Goals (Kaos) 28

Agents • • Actors and devices are very important They are responsible for carrying out the tasks Agent-Oriented Models New properties – – Pro-Active Autonomous Distributed Intelligent, etc 29

Organizational Modelling • Models about organizational aspects • Must portrait aspects relate to management/business • Software Engineering models are restricited • Modelling elements linked to organizational concepts are needed 30

Organizational Models has Company has Supplier Strategic Goal Checks Supplies has Process Function Client 31

Business Rules • Policies (not procedures) • identification – limits – responsibilities – tights • Stability 32

Business Rules Non-Functional Business Rules from the Macrosystem Quality Rules 33

Examples Functional Rules • A meeting can be rescheduled or canceled • Supervisors answer to the VP Macrosystem Rules • CIT and CPP must be deducted every month 34

Modelling Requirements • Need Models (languages to build a software system) • Requirements Model • Specification Model • Multi-purpose models 35

Modelling • Representation • Organization • Storage Perspective about the Product 36

Representation • • Lexicon Scenarios Sentences Requirements Documents • Glossary 37

Language Extended Lexicon (LEL) • Technique that aims to describe the symbols a a certain language. LEL’s main idea is the existence of an application language. This idea departs from the notion that in the Uof. D there is one (or more) cultures (social group) and each has its own language. • Thus, the main objective to be followed by REs is the identification of words or sentences that are peculiar to the social environment under study. Only after these words and sentences are identified the RE will search for their meaning. 38

Language Extended Lexicon • Use one or more technique for fact gathering (interviews, observation, document reading) • Target: Words or sentences that seem to have a special/relevant meaning in the application • Words or sentences that are frequently used or that brings doubts or that seem to be out of context. • List of words and sentences. • Big difference: Elicit functions vs Elicit symbols. 39

Language Extended Lexicon • Each symbol is describe with Notions and Behavioral Responses. Notion represents what the symbol means (denotation). Behavioral Responses describe the effects from the use of this symbol. Characterize constraints imposed to the symbol or imposed by the symbol 40

Language Extended Lexicon • Circularity and Minimum vocabulary principles. – Minimal Vocabulary: Refers to the sole use of frequent words with clear meaning and that are part of a restricted vocabulary – Circularity: Refers to the use of symbols from the language (LEL symbols) to described notions and behavioral responses • Studies show that while explaining a symbol actors (stakeholders/users) use symbols from their language. 41

LEL 42

Language Extended Lexicon v Renew Book • Notions Book exemplar is rented to a library user – User wants to keep the book exemplar longer. • Behavioral Responses: – Library Employee changes return date for the book exemplar 43

Language Extended Lexicon v Return Date • Notion – Established Data to return rented book • Behavioral Response: – If return date is prior to current date the book exemplar is overdue 44

45

Specification-Oriented Modelling Techiniques • For some time they were seen as elicitation techniques (Analysis) • Range from the more formal to the most used by developers • Some of them will be covered here: – DFD, Decision Table, State Chart , External Events, ER, Data Dictionaries. 46

What to Model • Information structure – Entity relationship diagram – Class Diagram • Process and Information Flow – Dafaflow diargams – UML activity diagram • System Behavior – Statecharts – Sequence diagrams 47

DFD EE 1 i 1 X i 2 EE 2 ® process (task, action, activity) ® Data storage i 1 X i 2 X y 48

DFD ® External Entities (origem/destino) ® Data Flow EE 1 i 49

DFD - Functional Decomposition - Context Diagram - Level 0, 1, 2, … - Every information that is inputted has to be somehow used - Stop Condition for decomposition – When I can describe the process within one page using pseudocode a a 1 a 2 X X 1 b xa 1 X 2 xa 2 X 3 b 50

DFD – Context Diagram Example Finance Management Employee tax Pay Salaries Total-Payement Money Order Manager Worked-hours salaries Human Resources info-employee 51

info-employee Worked-hours DFD Calculate Payment Groos-salary salaries Net-salary Tax Deduct Tax Generate Money Order Total-payment Add to Total Pay Salaries total-paid 52

DFD info-employee Worked-hours Separate Regular Hours Regular-hours salaries Overtime Calculate Individual salaries Regular-salary Calculate Payment Salary-overtime Calculate Gross Salary Gross-Salary 53

DFD - Rules: - Names: - Process: verbal phrase - Flow: substantive or substantivated phrase (use hyphens) - Data Storage: Same as in Flow -External Entity: substantive or substantivated phrase playing the role of subject - Use different names (Output is always different from input). 54

Structured Analysis • Key point: DFDs are the center of SAD • Mainly used for information systems – But there adaptations for real-time systems • Process – Define current Physical system (concrete) – Define current logical system (Abstraction) – Create New logical system – Create New physical system 55

Evaluation of SA as a whole • Pros -easy to learn -Automated Tool support - Use of abstraction and decomposition -Facilitates communication -Clear definition of system boundaries • Cons -Confusion between Modelling the problem and Modelling the solution -Models the system but not the application domain -Timing issues are invisible 56

Entity Relationship Model • Objective To give a description for the date used in the software and how these data relate to each other. It is used to describe the Data base conceptual model • Concepts - Entity [type] - Relationship ® cardinality (1: 1, 1: M, M: N) -Attributes ( characterize entities or relationships) 57

Entity Relationship Model • Exemple Code name time days room Course N M enrolls Student N address. number address 1 teaches name Prof. group Prof. ID 58

Entity Relationship Model • Pros -well known -data map - easy to translate to a physical implementation • Cons - Almost can‘t represent constraints - Doesn‘t model behavior - weak semantics (based on hypothesis and natural language) 59