BON Business Object Notation Based on slides by Prof. Paige

Size: px

Start display at page:

Download "BON Business Object Notation Based on slides by Prof. Paige"

Lucy Sanders
5 years ago
Views:

1 BON Business Object Notation Based on slides by Prof. Paige 17-1

2 What is it? Notation for modeling object oriented software» Static: specifies classes, class relationships» Dynamic: behavioural properties Method» Guidelines to be used when producing specifications and descriptions Does not include» Entity-Relation models» Finite state machines 17-2

3 Characteristics of the Notation Simplicity» Concentrate on design aspects of the method Generality» Not restricted to application domains Design by Contract» Assertions for classes and features Two views» Graphical» Textual fi Eiffel 17-3

4 Characteristics of the Notation 2 Seamlessness» Smooth transition from requirements through design to implementation all in one form of model Reversibility» Direct mapping of design concepts to and from implementation concepts Scalability» Scales up to large designs 17-4

5 Tool Support Bon tools Eiffel diagrams 17-5

6 Compressed Classes Use to draw views with lots of classes bird's eye view early stages of design NAME NAME Shortest form Reused library * NAME Deferred NAME [G, H] Parameterized + NAME Implemented NAME Root Instances may be separate processes NAME Persistent NAME Interfaces with outside world 17-6

7 Inheritance Relations * PEOPLE + YOUNG_PEOPLE + OLD_PEOPLE ++ TODDLERS ++ PRE_TEEN ++ TEEN_AGERS 17-7

8 Client Supplier Association Client A uses the services of supplier B Each client instance may be attached to one or more supplier instances has a has a PERSON ADDRESS CITY 17-8

9 Client Supplier Aggregation Client A uses the services of supplier B Each client instance is attached to one or more supplier instances that represent integral parts of the client instance part of part of VEHICLE MOTOR CYLINDER propulsion combustion_chamber Difference between association and aggregation? Consider expanded vs reference use. Consider what happens when the client gets deleted. 17-9

10 Bidirectional Uses Links CUSTOMER shoppers : set [... ] preferred_mall SHOPPING_CENTER Client feature label is at the supplier side Generic classes can be used in labels Leave parameter unspecified Useful for recursive structures lists, trees, graphs 17-10

11 Cluster Represents a group of classes, and possibly other clusters, according to some point of view Classes may be grouped differently depending on the characteristics of the specification one wants to highlight» Subsystem functionality, user categories, abstraction level, et cetera 17-11

12 Cluster Example SORTING DATA_STRUCTURES LINEAR_SORT QUICKSORT INSERT_SORT GRAPH DIRECTED_GRAPH WEIGHTED_GRAPH GRAPHS ARRAY RECORD 17-12

13 Cluster Properties Clusters can be shrunk to hide their contents» Keep only the cluster name Every class belongs to exactly one cluster Not a language construct; just a mechanism for dealing with abstraction Implement in Eiffel with directory structure» Each cluster is a directory 17-13

14 Inheritance & Clusters SORTING LINEAR_SORT INSERT_SORT DIRECTED_GRAPH WEIGHTED_GRAPH GRAPHS ARRAY All classes in sorting inherit from ARRAY Only DIRECTED_GRAPH inherits from ARRAY 17-14

15 Graphical BON Class (Uncompressed) CITIZEN No need to show all features, just those of interest for the view name, sex, age : VALUE spouse : CITIZEN children, parents : SET [ CITIZEN ] single : BOOLEAN! Result ( spouse = Void ) divorce? not single! single and ( old spouse ).single invariant single or spouse.spouse parents.count = 2 " c Œ children ($ p Œ c.parents p 17-15

16 Equivalent Textual Notation class CITIZEN feature name, sex, age : VALUE spouse : CITIZEN single : BOOLEAN ensure Result iff ( spouse = Void ) end divorce require not single ensure single and ( old spouse ). single end invariant single or spouse.spouse = Current parents.count = 2 for_all c member_of children it_holds ( exists p member_of c.parents it_holds p = Current) end -- class CITIZEN 17-16

17 Typed Class Interface Early phases concentrate on public features Restricted features produced during detail design Arbitrary number of sections, each with export list Each feature has a signature and optionally a behavioural specification Conventions» Classes all in upper case» features all in lower case» use underscore for longer names NAME Inherits: parent classes Public features A, B, C Restricted features Invariant Class invariant 17-17

18 Class Feature Decorators Feature names have an optional decorator showing status name* deferred name + effective name ++ redefined name : TYPE result type New_name { ^ CLASS_NAME. old_name } rename clause name : { TYPE aggregation result type Æ name : TYPE input argument 17-18

19 Class Feature Signatures Each feature has a signature attributes name : TYPE queries name ( arg : ARG_TYPE;... ) : RESULT_TYPE commands name ( arg : ARG_TYPE;... ) Types may be expanded 17-19

20 Graphical View Rule Graphical view is not used for just one class Always have two or more classes with inheritance and/or uses relations among them 17-20

21 Views Show Part of a Design PAPER Inherits: REVIEW final_score : VALUE award_best_paper : BOOLEAN accept + reject + PRESENTATION code : VALUE title : VALUE authors : SET [ PERSON ] status : STATUS speakers : SET [ PERSON ] accept * reject * PAPER has other features not important for this view 17-21

22 Assertion Language Queries and commands can be documented with a precondition and a postcondition Follow Eiffel language with respect to inheritance and redefinition of assertions Use predicate calculus and set theory Graphical Form? precondition! postcondition the_invariant Textual Form require precondition ensure postcondition invariant the_invariant 17-22

23 Assertion Language Symbols Arithmetic operators + * / ^ (exponent) // (integer division) \\ (modulus) Relational operators = < > Boolean operators & logic ^ and or xor not Æ implies iff Predicate logic " for_all $ exists such_that it_holds Set operators {... } Œ œ 17-23

24 Assertion Language Special Symbols old expr value of expr before a routine was called Result result of a query but only in ensure current object Void not attached D name name may change void reference : TYPE type operator 17-24

25 Quantifier Notation 1 Difference between BON and Eiffel assertions is the use of quantifiers in Eiffel use agents Used to express properties about groups of objects General syntax such that Quantifier Range_Expr [ Restriction ] Property Quantifier " $ Range_Expr type range each value of a given type " v : VEHICLE sequence range each member in a sequence " k : low.. High member range each member in a set " c Œ CHILDREN it holds / it is the case that 17-25

26 Quantifier Notation 2 Quantifier Range_Expr [ Restriction ] Property Restrictions boolean expression or, recursively, any quantified expression Property boolean expression or, recursively, any quantified expression Example see previous slide "Graphical BON class" 17-26

27 BON Process ( The Method ) Process for analysis and development Idealized» In practice it is subject to variation, iteration, reversibility Three phases» Gathering collaboration with users» Designing initial working system» Refining improve design, refactor 17-27

28 BON deliverables & dependencies People create Auto (semi) generate Class dictionary Class chart Cluster chart Class Interface Class text System chart Static Model Dynamic Model Event chart Static architecture Object scenario Scenario chart Creation chart 17-28

29 Gathering Phase Steps 1 & 2 Delineate the system boundary» Determine what the system includes and excludes» Determine user metaphors» Determine the major subsystems > Charts: system, event, scenario List candidate classes» Produce first pass list of classes > Charts: class 17-29

30 Gathering Phase Step 3 Select classes and groups» Organize classes into logical groups / clusters > Charts: cluster, class > class dictionary» Determine status of classes > Deferred, effective, reused, 17-30

31 Example System Chart System Conference Management System Part # Purpose Conference administration support Indexing Cluster ORGANIZATION TECHNICAL_EVENTS REGISTRATION Description Handles major events occurring during the conference from initial decisions through to conclusion Responsible for putting together the programme, recording status of contributions, checking in reviews and following a precise timetable of what is to be done Collect registration data, produce lists, print badges, send form letters. Store data relevant to whatever may change the cost/benefit of the conference One per system 17-31

32 Example Cluster Chart CLUSTER REGISTRATION Purpose: Track conference participants Part # Indexing Cluster components REGISTRATION ATTENDEE REFEREE CONTRIBUTOR Description Track participant status Track fees and events Track papers and results Track papers from initial offer to presentation Similar to the System Chart 17-32

33 Example Class Chart CLASS Type of Object CITIZEN Born or resident in a country Part # Indexing Queries Commands Constraints Name, Sex, Age, Single, Spouse, Children, Parents Marry, Divorce Each citizen has two parents At most one spouse is allowed May not marry children or parents Spouse's spouse must be this person All children, if any, must have this person as their parent 17-33

34 Modeling Chart Uses Informal charts are useful for exchanging ideas with non-technical people Useful for serving as high-level documentation and as a scratch pad for ideas and thoughts Idea is to provide medium for social communication and discussing their ideas 17-34

35 Modeling Chart Contents System chart» Exactly one per system» Contains a brief description of each top level cluster in the system Cluster chart» Brief description of a cluster, each class and subcluster within it Class chart» Informally specify class interface. > What information and services can other classes ask from the class? > What rules must be obeyed by the class? 17-35

36 Designing Phase Define class interfaces» Use graphical and/or textual descriptions Develop static architecture Sketch system behaviour dynamic properties» Event charts, scenario charts, object scenarios, creation charts» Develop dynamic object model 17-36

37 Purpose of Dynamic Model Analysis and design should not focus on implementation» Static relationships & contracts do not change, minimize implementation dependence Reasonable to want to ensure implementation is possible» For other considerations see... Swartout, W., Balzer, R., On the Inevitable Intertwining of Specification and Implementation, Communications of the ACM, July 1982, Vol 25, No 7, pp Need a specification of how the classes can fulfill their specifications by calling routines of other classes 17-37

38 Dynamic Model What makes up a dynamic model in BON?» Feature calls object communication» also known as message passing or object communication Using feature calls in a dynamic model supports seamlessness» Feature calls map directly to a programming language Some design methods use finite state machines to specify what an object does in reaction to a message» Difficult to translate, in all but simple machines, into programs lack of seamlessness 17-38

39 Definition of events A system is a black box with behaviour described by responses to stimuli system events An external event is triggered by something in the outside world over which the system has no control» terminal input, interrupts An internal event is triggered by the system itself 17-39

40 Dynamic Model Charts Event chart» Lists selected external events that may trigger object communication Scenario chart» Describes a sequence of events for communicating objects Object creation chart» Describes which classes create instances of other classes 17-40

41 Event Chart Example EVENTS CONFERENCE_SUPPORT Part # Comment External Selected external events triggering representative types of behaviour Involved object types Indexing Request to register a submitted paper CONFERENCE, PROGRAM_COMMITTEE, PAPER 17-41

42 Scenario Chart Example SCENARIO DRIVING_SYSTEM Part # Comment Borrow car and go for a drive Indexing Step 1: Driver gets keys from owner DRIVER calls OWNER : send request receive keys Step 2: Driver turns ignition DRIVER calls IGNITION : send turn_on receive NIL Step 3: Engine starts IGNITION calls ENGINE : send turn_on receive NIL 17-42

43 Creation Chart Example CREATION MATRIX_SYSTEM Part # Comment Class Only those classes dealing with the CIRCUS cluster Creates instances of Indexing SPARSE_MATRIX ARRAY, MATRIX_ELEMENT MATRIX_ELEMENT STACK [ ELEPHANT ] MINIMUM_TEST SPARSE_MATRIX, MATRIX_ELEMENT, STRING, ELEPHANT 17-43

44 Object Representation How do we describe objects in BON? Use rectangles containing their class name with an optional qualifier (e.g. a name) CONFERENCE STACK ( parse ) FLIGHT STACK ( washing ) More than one instance possible 17-44

45 Communication Between Objects Pass or send a message, call a feature, invoke an operation are all synonymous A message is indicated by a dashed arrow from the calling to the receiving object INVOICE_SYSTEM STOCK 17-45

46 Scenario with Object Communication Message links may be annotated with sequence numbers representing order of calls.» Cross reference to entries in a scenario box DRIVER 1,6 OWNER 2,4 3,5 IGNITION ENGINE Scenario: Borrow car and go for a drive 1 Driver gets keys from owner 2 Driver turns ignition 3 Engine starts 4 Driver removes key 5 Engine stops 6 Driver returns keys to owner 17-46

47 Communication Properties 1 Message are always potential» They do not have to occur Flat battery Bidirectional messages are possible Group as for clusters 17-47

48 Communication Properties 2 Can specify concurrency» send/receive to many objects broadcast, or to one instance only (differentiate with note, if not obvious) BRAIN 2 1 LEG 1 LEG Scenario: Get coffee 1 Step forward alternate legs 2 Bump door Scenario: Jump 1 Step forward both legs 2 Land 17-48

49 Refining Phase Refine system» Find new design classes, add new features > Modify: Class interfaces, static architecture, class dictionary, event charts, object scenarios Generalize» Factor out common behaviour > Modify: class interfaces, static architecture, class dictionary Complete and review system» Produce final static architecture with dynamic system behaviour > All deliverables complete 17-49

50 Software Development Methods Many good ideas and much effort put into producing recipes for constructing software» But no sure fire method No easy path to producing quality software» F.P. Brooks Jr., No Silver Bullet, Computer, Vol. 20, No. 4, April 1987, pp » Replies in Computer, Vol. 20, No. 7, July 1987, pp As our knowledge and experience have increased so has our reach 17-50

51 Understand Limitations and Benefits General principles for constructing software can be taught» But no teaching can guarantee success This is not to say methods are worthless» If you restrict their domain of applicability, you can have success Many method creators are unwilling to do this» They want to sell their method and its tools All relies on invention, creativity and expertise of the individual developers 17-51

BON Business Object Notation Based on slides by Prof. Paige

BON Business Object Notation Based on slides by Prof. Paige 17-1 What is it? Notation for modeling object oriented software» Static: specifies classes, class relationships» Dynamic: behavioural properties