02. (Conceptual) Modeling. F. Dalpiaz & J. Mylopoulos -- OIS Slide 1

Size: px

Start display at page:

Download "02. (Conceptual) Modeling. F. Dalpiaz & J. Mylopoulos -- OIS Slide 1"

Alisha Barker
5 years ago
Views:

1 02. (Conceptual) Modeling F. Dalpiaz & J. Mylopoulos -- OIS Slide 1

2 Updates about the exam Assignment 1 is due April 20th (was, April 15th) After receiving feedback from the TA, students have 2 weeks to revise the deliverable Deadline for Assignment 2 is May 30th (as planned) However, ~10 days before the deadline, a lab session will be devoted to Q&A (date TBD) F. Dalpiaz & J. Mylopoulos -- OIS Slide 2

3 Engineering Artefacts Engineering is about designing things (=artifacts) All engineering disciplines are founded on models that are analyzable and can predict the properties of the artifact being engineered Examples: Electric circuits, bridges, buildings, car engines What kinds of models can we build for organizations? business processes? software? And how do we analyze them? We review modelling and analysis techniques for organizations, business processes and software (information systems) F. Dalpiaz & J. Mylopoulos -- OIS Slide 3

4 (Conceptual) Modeling Key problem: Have to give an unambiguous, easy to understand account of our understanding of a complex phenomenon (organization, business process, software). English descriptions? OK, but are often cumbersome, incomplete, ambiguous and can lead to misunderstandings ( see next slides!) As an alternative, we will use models (also called conceptual or visual models) to describe elements of an organization, business process or information system. Models (try to) capture people s understanding (conceptualization) of what is being modeled. Models are usually represented in terms of a graph structure. F. Dalpiaz & J. Mylopoulos -- OIS Slide 4

5 Modeling in the very old days! This graffito is a primitive conceptual model. What does it represent? F. Dalpiaz & J. Mylopoulos -- OIS Slide 5

6 Natural languages can be ambiguous This is clause 4 from the UN Security Council resolution 1441: [on Iraq] Decides that false statements or omissions in the declarations submitted by Iraq pursuant to this resolution and failure by Iraq at any time to comply with, and cooperate fully in the implementation of this resolution shall constitute a further material breach of Iraq's obligations and will be reported to the Council for assessment in accordance with paragraphs 11 and or 12 below US (apparent) understanding: a material breach occurs if the declaration submitted by Iraq contains any false statements Other security council members: the breach only occurs if Iraq also does not cooperate with the inspection process F. Dalpiaz & J. Mylopoulos -- OIS Slide 6

7 What was the problem? The clause has the logical structure: (A B C D) E A = false statements [in the declarations submitted by Iraq] B = omissions in the declarations submitted by Iraq C = failure by Iraq at any time to comply with [this resolution] D = [failure by Iraq at any time to] cooperate fully in the implementation of this resolution E = a further material breach of Iraq's obligations the two interpretations: ((A (B C D))) E -- US ((A B) C D)) E -- other security council members' F. Dalpiaz & J. Mylopoulos -- OIS Slide 7

8 What is modeling? Item Order models Model Ship via Business Process runs on modeling uses a standardized (conventional) graphical notation a modeling language Computer System F. Dalpiaz & J. Mylopoulos -- OIS Slide 8

9 On the importance of conventions What would happen if a country decides to switch to the following conventional signs for primary needs? F. Dalpiaz & J. Mylopoulos -- OIS Slide 9

10 Origins of conceptual modeling Numerous proposals for modeling languages, in different areas: Ross Quillian proposed in his PhD thesis semantic networks in order to model the structure of human memory (1966) Ole-Johan Dahl proposed in 1967 Simula, an extension of ALGOL 60, for simulation applications which require some world modelling Jean-Robert Abrial proposed a semantic model in 1974, shortly followed by Peter Chen s Entity-Relationship model (1975) as advances over logical data models, such as Codd s Relational model proposed only a few years before Doug Ross proposed in the mid-70s the Structured Analysis and Design Technique (SADT) as a language for communicating ideas. The technique was used by Softech, a Boston-based company, in order to specify requirements for software. F. Dalpiaz & J. Mylopoulos -- OIS Slide 10

11 What do we model? Organizations Actors that make up an organization: agents, positions, roles Social relations among them: delegation, permission, ownership, authority Business processes Their components: also business processes or activities Information systems Their functions: use cases Interfaces with users and other systems Databases, through conceptual schemas Modelling languages The concepts of a modeling language: a metamodel -- model of a model F. Dalpiaz & J. Mylopoulos -- OIS Slide 11

12 Why do we model? To enhance human communication and support formal analysis F. Dalpiaz & J. Mylopoulos -- OIS Slide 12

13 Expressions Expressions are communication statements of linguistic and/or pictorial nature through which an agent (human or otherwise) accumulates information about an application Natural language statements are expressions So are books... So are Predicate Calculus assertions... So are SQL statements... So are digitized pictures... So are Web pages... F. Dalpiaz & J. Mylopoulos -- OIS Slide 13

14 Impressions Impressions (also models) are internal symbol structures held by an agent (human/software) that represent fragments of an application Example impressions: human memory, mental states, databases, knowledge bases, websites,... Impressions have two properties: Functional role: arise by virtue of the history and coupling of the agent to its environment, and give rise to the agent s future actions Representational import: stand in a content relationship to an application the agent is in contact with F. Dalpiaz & J. Mylopoulos -- OIS Slide 14

15 Semantic networks Animal isa isa Feather has isa - can fly Fish - can swim Bird - can fly isa Mammal Penguin - can t fly Novelty: impressions are built out of concepts and associations Inheritance of attributes: default, single Computation in terms of spreading activation: e.g. meaning of horse food Horse animal eat food isa - can t fly eats Shark Human Horse animal madeof meat food F. Dalpiaz & J. Mylopoulos -- OIS Slide 15

16 Entity-Relationship model (ER) Customer Places/ PlacedBy 1 M Order Customers place orders; each order contains many books Book M Contains/ iscontained M Assumes that applications consist of entities and relationships Entity: Customer, Order, Book Relationship: Places, Contains Shows how a conceptual schema can be mapped onto a logical one F. Dalpiaz & J. Mylopoulos -- OIS Slide 16

17 Extended ER (EER) Baseline: the ER model Extensions to support: Generalization Attributes Identifiers Better mapping to relational databases F. Dalpiaz & J. Mylopoulos -- OIS Slide 17

18 EER: example F. Dalpiaz & J. Mylopoulos -- OIS Slide 18

19 SADT Structured Analysis and Design Technique (SADT) Modeling the operating environment of a software system Models organized in terms of box-inside-box notation Seed & Vegie Prices Plan & Budget Weather Budget Plan Money Buy Supplies Fertilizer Seeds Cultivate Plants Pick Produce Vegetables Vegetables Extract Seeds Grow Vegetables F. Dalpiaz & J. Mylopoulos -- OIS Slide 19

20 The Unified Modeling Language Third generation Object-Oriented method Still evolving Attempt to standardize the proliferation of OO variants Is purely a notation No modelling method associated with it! Was intended as a design notation Has become an industry standard Has a standardized meta-model Use case diagrams, class diagrams, sequence diagrams, activity diagrams, state diagrams, module diagrams, platform diagrams F. Dalpiaz & J. Mylopoulos -- OIS Slide 20

21 UML: Use cases and sequence Add new staff member Add new staff grade Change rate for staff grade Accountant Change grade for staff member Calculate staff bonuses F. Dalpiaz & J. Mylopoulos -- OIS Slide 21

22 UML: class diagram Class name attributes Patient Name Date of Birth Height Weight aggregation methods 0..1 multiplicities 1..2 Kidney Operational? 0..2 Eye Colour Diameter Correction Heart generalization 1 Normal bpm Blood type In-patient Room Bed Physician Out-patient Last visit next visit physician Organ Natural/artif. Orig/implant donor F. Dalpiaz & J. Mylopoulos -- OIS Slide 22

23 Anatomy of CM Languages (CMLs) Basic building blocks: Terms descriptions concepts,... Composition rules: Abstractions abstraction mechanisms semantic relationships structuring mechanisms,... Analysis and management tools simulation, verification, normalization,... F. Dalpiaz & J. Mylopoulos -- OIS Slide 23

24 Formality We need to define the primitive elements of our CML types of nodes link labels Early CMLs were informal, or their semantics were defined by the programs that manipulated them Progress in CML research has been measured by the degree of formality of CMLs, also by the types of constructs they include Without formality, no sound analysis F. Dalpiaz & J. Mylopoulos -- OIS Slide 24

25 From informal to formal Informal models, minimal syntax, no primitive terms or semantics e.g., concept maps Informal models, syntax, primitive terms, informal semantics e.g., SADT, DFDs Formal models with primitive terms, syntax and semantics e.g., EER, some OOA models Formal models, with primitive terms, syntax, semantics and an assertional sub-language for user-defined constraints and rules e.g., RML, KAOS F. Dalpiaz & J. Mylopoulos -- OIS Slide 25

26 Informal models Diagrammatic notations for sketching an application Offer boxes (nodes) and labelled arrows (links) No guidance on what boxes and arrows to use for a particular application There is no agreed upon semantics attached to either the boxes or the arrows; users interpret them in terms of their labels, other informal documentation, as well as their own perspective F. Dalpiaz & J. Mylopoulos -- OIS Slide 26

27 Good and bad notations Both informal and formal notations are drawn and read by people How to ensure mutual understanding? Semantics is important, but one wants to understand immediately! Cognitive effective visual notations are fundamental! Unfortunately, notations in the area of information systems are not that good from this perspective [Daniel Moody, 2009, Transactions on Software Engineering] F. Dalpiaz & J. Mylopoulos -- OIS Slide 27

28 Cognitive effectiveness F. Dalpiaz & J. Mylopoulos -- OIS Slide 28

29 Good and bad patterns Class diagrams have two ways to denote an interface Novices confuse rectangles and diamonds in ER diagrams Good and bad variants usage of clearly different shapes F. Dalpiaz & J. Mylopoulos -- OIS Slide 29

30 Analysis of models Formality is important for a CML for two basic reasons: It eliminates, or at least reduces, ambiguity It can be used as a foundation for (algorithmic) analysis of models Analysis may consist of various forms of consistency, completeness, For example, one can check whether a UML class is coherent, i.e., can have instances Analysis techniques are essential in giving users confidence that a model captures their understanding of a domain F. Dalpiaz & J. Mylopoulos -- OIS Slide 30

31 Analyzing UML consistency [R. Van Der Straeten, Description of UML Model Inconsistencies, SOFT-TR ] Owned element (mutual containment) Abstract operation Cyclic inheritance Dangling parameter type (Cash) + return parameters (Card, Cash) F. Dalpiaz & J. Mylopoulos -- OIS Slide 31

32 Analyzing business processes [a] act1 [not a] Infinite process act2 Unreachable activity act2 act1 act3 F. Dalpiaz & J. Mylopoulos -- OIS Slide 32

Requirements & Domain Models. Lecture 13: Object Oriented Modelling. Nearly anything can be an object. Object Oriented Analysis

Requirements & Domain Models. Lecture 13: Object Oriented Modelling. Nearly anything can be an object. Object Oriented Analysis Lecture 3: Object Oriented Modelling Object Oriented Analysis Rationale Identifying Classes Attributes and Operations Class Diagrams Associations Multiplicity Aggregation Composition Generalization Easterbrook