1 / 63

Chapter 3

Chapter 3. Additions. Purpose. This chapter will also is just a reminder and we will only sketch it in the lecture. It serves mainly as a reference. Part 1 Knowledge Representation. Propositional Logic. Symbols represent propositions (facts). A proposition is either TRUE or FALSE.

bcameron
Download Presentation

Chapter 3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 3 Additions Prof.Dr.Michael M. Richter

  2. Purpose • This chapter will also is just a reminder and we will only sketch it in the lecture. • It serves mainly as a reference. Prof.Dr.Michael M. Richter

  3. Part 1 Knowledge Representation Prof.Dr.Michael M. Richter

  4. Propositional Logic • Symbols represent propositions (facts). • A proposition is either TRUE or FALSE. • Boolean connectives can join propositions together into complex formulas. • formulas are statements that are either TRUE or FALSE. • We introduce propositional logic mainly in order to learn about the computation of truth values which is the same for all other fragments of predicate logic. Prof.Dr.Michael M. Richter

  5. Propositional Logic Syntax • Propositions: Symbols such as P, R, S, ... • Constants (particular propositions): TRUE and FALSE. • Logical connectives:  AND, conjunction  OR, disjunction  Implication , conditional (If then)  Equivalence , biconditional  Negation (unary) ( ) parentheses (grouping) Prof.Dr.Michael M. Richter

  6. Definition: Formulas • True, False or any proposition symbol P,Q,R, ... is a formula • If a and b are formulas then • ( a ) • (a b) • (a  b) • (a  b) • (a  b) • ( a) are also formulas • Introduce binding rules to avoid parenthesis (): • binding strength (increasing order):    • same operator: assume left to right binding Prof.Dr.Michael M. Richter

  7. Attribute-Value Representations (1) • Attributes A1,..., An are intended to represent properties of objects. Attributes have domains (types): T1, ..., Tn (standard or user defined). • Values of attributes : a1ÎT1 ,..., anÎTn • If the set of attributes is fixed: • An attribute-value vector is an n-ary vector: F = (a1 ,..., an) ÎT1 x ... x Tn • Representation of unknown values: Use e.g. a special symbol “unknown”; aiÎTiÈ{unknown} or a typed variable. • If the set of attributes is variable : • An object is represented as a set: F = {A1=a1 ,..., An=an} with a1ÎT1 ,..., anÎTn Prof.Dr.Michael M. Richter

  8. Attribute-Value Representations (2) • An item can be represented by attribute-value-pairs. • Example: Price: 19.95 $ • The set of attributes is either fixed or can vary. • Each attribute has associated a domain (type) for the values, e.g., • Integer or Reals, • Symbols: Arbitrary finite set as {red, yellow, green} • Text: Strings of arbitrary length • Hypertext: HTML-Link • The order in which the pairs are listed may be of importance • If the value is a variable it means that the value is not (yet) known, e.g.: Price: 19.95 $, Weight: x (weight not determined) Attribute Value Prof.Dr.Michael M. Richter

  9. Predicate Logic: Overview (1) • Terms represent specific objects in the world.Can be • constants: refers to a fixed object • functions: allow us to refer to objects indirectly (via some relationship) • variables: stands for some object • Predicate Symbols refer to a particular relation among objects. • Quantifiers and variables allow us to refer to a collection of objects without explicitly naming each object. • Sentences represent knowledge made of of terms, logical connectives, quantifiers and predicate symbols. Prof.Dr.Michael M. Richter

  10. Predicate Logic: Overview (2) Some Examples • Predicates: Brother, Sister, Mother , Father • Objects: tom, susan, mary, roger • Facts expressed as atomic sentences a.k.a. literals: • Father(tom,mary) • Mother(susan,mary) • Brother(tom,roger) •  Father(roger,mary) Prof.Dr.Michael M. Richter

  11. Predicate Logic: Overview (3) Variables and Universal Quantification • Universal Quantification allows us to make a statement about a collection of objects: x Cat(x)Mammal(x) All cats are mammals xFather(tom,x) Mother(susan,x) All of Tom’s kids are also Susan’s kids. xyMarried(x,y) Married(y,x) The relation “Married” is symmetrical. “For All” Prof.Dr.Michael M. Richter

  12. Predicate Logic: Overview (4) Variables and Existential Quantification • Existential Quantification allows us to state that an object does exist (without naming it): x Cat(x)Black(x) There is a black cat. x Father(tom,x) Mother(susan,x) There is a kid whose father is tom and whose mother is susan “There exists” Prof.Dr.Michael M. Richter

  13. Predicate Logic: Overview (5) Functions • Functions are terms - they refer to a specific object. • We can use functions to symbolically refer to objects without naming them. • Examples: • fatherof(x) age(x) times(x,y) succ(x) • x Equal(x,x) • Equal(factorial(0),1) • x Equal(factorial (succ(x) ), times(succ(x), factorial(x) ) ) Prof.Dr.Michael M. Richter

  14. Notation for Predicate Logic (1) • Definition (primitive symbols): • Logical connectives: Ù, Ú, , Ø, • Quantifiers: ", $ • Function symbols: f, g,... f1, g1,... add, next, prev, ..., 1, 2, 3, ... • Predicate symbols: P, Q, ... P1, Q1,... , Inside, IsOn, ... • Variables: x,y,z,... x1,y1,z1,... • Arity of functions and predicats • every function symbol has an arity assigned = number of arguments the function gets • e.g. function “add” has arity 2 , function “abs” has arity 1 • 0-ary function symbols are called constants • every predicate symbol has an arity assigned = number of objects that the predicate puts into a relationship • e.g. in Inside(car, passenger), Inside has arity 2 • e.g. in IsOn(engine), IsOn has arity 1 • 0-ary predicate symbols are propositional symbols (as in propositional logic) Prof.Dr.Michael M. Richter

  15. Notation for Predicate Logic (2) • We construct terms from function symbols and variables • Definition (terms, ground terms) (i) Variables and 0-ary function symbols (these are called constants) are terms. (ii) If t1,...,tn are terms and if f is an n-ary function symbol (n>0), then f(t1,...,tn) is a term. (iii) Terms without variables are called ground terms • Examples: • 1 is a term, is a ground term, is a constant • add(6,3) is a term, is a ground term • add(x,8) is a term, is NOT a ground term • f( g(h(x,a), b, c), h(5,x) ) is a term, is NOT a ground term • f( g(h(a,a), b, c), h(5,a) ) is a term, is a ground term Prof.Dr.Michael M. Richter

  16. Part 2 UML Prof.Dr.Michael M. Richter

  17. Motivation • The Unified Modeling Language tries to integrate older approaches • Developed by Rational (CASE tool) • they hired Booch, Rumbaugh, Jacobsen • Standardized at version 1.1 by the OMG (Object Management Group) • Supported by almost all OO CASE tools … but with some limitations … • Currently it is at version 1.4 (OMG working on 2.0) Prof.Dr.Michael M. Richter

  18. Goals of UML • Provide users with ready-to-use, expressive visual modeling language to develop and exchange meaningful models. • Provide extensibility and specialization mechanisms to extend the core concepts. • Be independent of particular languages and processes. • Provide formal basis for understanding the modeling language. • Encourage the growth of the OO tools market. • Support higher-level development concepts such as collaborations, frameworks, patterns and components. • Integrate best practices. Prof.Dr.Michael M. Richter

  19. UML has 9 Kinds of Diagrams • Class Diagram • Object Diagram • Component Diagram • Deployment Diagram • Use Case Diagram • Sequence Diagram • Collaboration Diagram • Statechart Diagram • Activity Diagram Structural Diagrams Behavioral Diagrams Prof.Dr.Michael M. Richter

  20. Structural Diagrams Class Diagrams • Central for OO modeling • Shows static structure of the system • Types (!) of objects • Static relationships (see next lecture) • Association (e.g.: a company has many employees) • Generalization (subtypes) (e.g.: an employee is a kind of person) • Dependencies (e.g.: a company is using trucks to ship products) Prof.Dr.Michael M. Richter

  21. Class • Set of objects • Defines • name • attributes(optional: type optional: initial value) • operations Task startDate: Date = default endDate: Date name setStartDate (d : Date) setEndDate (d : Date) getDuration () : Date Prof.Dr.Michael M. Richter

  22. Class Diagram Example association Actuator startUp( ) shutDown( ) generalization Light Heater Cooler Temperature off( ) 1 1 on( ) aggregation 0..* 1 1 1 Environmental Controller SystemLog define_climate( ) display( ) Prof.Dr.Michael M. Richter terminate_climate( ) recordEvent( )

  23. Three Perspectives We can look at classes from these perspectives: • Conceptual (OOAnalysis) • Shows concepts of the domain • Should be independent from implementation • Specification (OODesign) • General structure of the running system • Interfaces of software (types, not classes) • Often: Best perspective • Implementation (OOProgramming) • Structure of the implementation (classes) • Most often used Try to draw from a clear, single perspective Prof.Dr.Michael M. Richter

  24. Attributes • Conceptual: Indicates that customer have names • Specification: Customer can tell you the name and set it(short for get/set methods) • Implementation: An instance variable is available Customer name address creditRating Prof.Dr.Michael M. Richter

  25. Operations • Services that a class knows to carry out • Correspond to messages of the class (or IF) • Conceptual level • principal responsibilities • Specification level • public messages = interface of the class • Normally: Don’t show operations that manipulate attributes Prof.Dr.Michael M. Richter

  26. UML Syntax for Operations visibility name (parameter list) : return-type-expression + assignAgent (a : Agent) : Boolean • visibility: public (+), protected (#), private (-) • Interpretation is language dependent • Not needed on conceptual level • name: string • parameter list: arguments (syntax as in attributes) • return-type-expression: language-dependent specification Prof.Dr.Michael M. Richter

  27. number : String Operations vs. Responsibilities • Conceptual: Operations should specify responsibilities, not IF, e.g.: • The Customer specifies the Orders • The Orders list the Customer Order dateReceived Customer isPrepaid name address price : Money * 1 Responsibilities - specifies orders Responsibilities - lists the customer Prof.Dr.Michael M. Richter

  28. Class versus Type • Type • protocol understood by an object • set of operations that are used • Class • implementation oriented construct • implements one or more types • In Java a type is an interface, in C++ a type is an abstract class • UML 1.3 has the <<interface>> stereotype and the lollipop Prof.Dr.Michael M. Richter

  29. Relations between Classes in UML A A A B B B a) Generalization b) Undirectional Association c) Aggregation Prof.Dr.Michael M. Richter

  30. Product Dependencies Induced by Processes Java Test Driver Product Dependency Design Document (UML) implement in Java Product Dependency Java Implemen- tation Prof.Dr.Michael M. Richter

  31. <<interface>>DataInput close() Interfaces in UML (1) • Stereotype <<interface>> InputStream{abstract} OrderReader Dependency Generalization DataInputStream Realization Prof.Dr.Michael M. Richter

  32. Interfaces in UML (2) • Lollipops (“short-hand notation”) DataInput OrderReader Interface DataInputStream Dependency Prof.Dr.Michael M. Richter

  33. Systems and Subsystems (1) Prof.Dr.Michael M. Richter

  34. request for alarm notification periodic check-in require for configuration update Systems and Subsystems (2) Control Sensor request for status panel subsystem test status subsystem request for system status specification of type of alarm periodic status check Central communication subsystem Prof.Dr.Michael M. Richter

  35. How to Break a System into Smaller Subsystems? • Roman principle: Divide & conquer • Split up a large system into manageable parts • In structured methods: functional decomposition • In OO: Group classes into higher level units Packages (conceptual; at development time) Components (physical; at run time) Prof.Dr.Michael M. Richter

  36. ResourcePool Packages • General purpose mechanism for organizing elements into groups • Package forms a namespace • Names are unique within ONE package • UML assumes an anonymous root package Prof.Dr.Michael M. Richter

  37. Package vs. Component • Packages • Conceptual structuring of system model • Source code structure • Components • “Physical and replaceable part of the system that conforms to and provides the realization of a set of interfaces”,e.g.: • COM+ components, Java Beans, … • source code files • Documents Prof.Dr.Michael M. Richter

  38. Component Representation resourcePool.java buglist.dll Realizes: BugList FilteredList System::kernel.dll {version=1.23} path name Prof.Dr.Michael M. Richter

  39. Example Diagram Prof.Dr.Michael M. Richter

  40. Components vs. Classes • Both have names and realize interfaces • Class • logical abstraction • Attributes and operations • Component • Physical thing that exist on machines • Physical packaging of logical things (classes, interfaces, …) • Only has operations (only reachable thru its IF) Prof.Dr.Michael M. Richter

  41. ProjectMgt.java resourcePool.java Components and Interfaces • IFs used in all component-based OS-facilities (COM+, CORBA, EJB) Interface Realization Dependency ResourcePool ResourcePool = import interface for ProjectMgt.java ResourcePool = export interface for resourcePool.java Prof.Dr.Michael M. Richter

  42. <<interface>>ResourcePool addEmployee() ProjectMgt.java resourcePool.java Alternative Representation Dependency Realization ResourcePool = import interface for ProjectMgt.java ResourcePool = export interface for resourcePool.java Prof.Dr.Michael M. Richter

  43. Deployment Diagrams (1) • Show physical relationship among software & hardware components • Show where components of a distributed system are located Prof.Dr.Michael M. Richter

  44. Server Deployment Diagrams (2) • Nodes: Computational units (most often: Hardware) • Connections: Communication paths over which the system will interact Client TCP/IP Prof.Dr.Michael M. Richter

  45. AccountDB.java AccountMgt.java Account Server Deploys AccountDB.java AccountMgt.java Account Server Nodes and Components Prof.Dr.Michael M. Richter

  46. Account Server Kiosk Kiosk 1 0..* 1 0..* SalesTerminal Prof.Dr.Michael M. Richter

  47. Part 3 Software Engineering Prof.Dr.Michael M. Richter

  48. problem description used system user requirements usable system system requirements description developer requirements executable system products of software engineering is verified against is developed in is integrated in is validated against system design system design description products of software development component requirements executable component products of programming component design component code V - model for documentation of large software products

  49. Processes and Life-Cycle Models: Process: “connected series of actions” “series of operations deliberately undertaken” [A S Hornby: Oxford Advanced Learner’s Dictionary of Current English, Oxford University Press] • Work processes • Production processes • Development processes • Social processes Prof.Dr.Michael M. Richter

  50. tools methods process a quality focus Software Engineering Layers Prof.Dr.Michael M. Richter

More Related