BON Business Object Notation Largely based on slides by Prof. Paige

Size: px

Start display at page:

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

Alfred Lee
5 years ago
Views:

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

2 What is it? Notation for modelling object oriented software Two versions» graphical» textual Static notations for specifying classes, relationships and behavioural properties A method» rules and guidelines to be used when producing specifications and descriptions 17-2

3 What is it? 2 Concentrate on design aspects of the method Guiding concepts» seamlessness» reversibility» simplicity Does not include "standard" notational concepts» ER models» finite state machines 17-3

4 Characteristics of the Notation Generality» not restricted to application domains 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 size designs 17-4

5 Characteristics of the Notation 2 Typed interfaces Support for software contracting» Supports require and ensure clauses by default Simplicity Space economy Tool support 17-5

6 Typed Class Interface Restricted features are produced during detail design Early phases concentrate on public features 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 of underscore to make longer names NAME Inherits: parent classes Public features A, B, C Restricted features Invariant Class invariants 17-6

7 Compression and Class Hierarchy Use of compressed views when drawing specifications with lots of classes Use detail when you know more about the class Very useful in early stages of design NAME NAME * NAME Shortest form Reused library Deferred NAME [G, H] Parameterized + NAME Implemented NAME Root Instances may be separate processes NAME NAME Persistent Interfaces with outside world 17-7

8 Class Features Any number of features sections, each listing the set of classes permitted to use them Each feature name is listed with an optional mark showing status as follows» name* deferred name unimplemented feature» name + effective name implemented feature» name ++ redefine name redefined feature» name : TYPE result type» name : { TYPE aggregation result type» name : TYPE input argument» { ^ CLASS_NAME. name } rename clause 17-8

9 Class Features 2 Each feature has a signature» attributes: name : TYPE» functions: name ( arg : ARG_TYPE;... ) : RESULT_TYPE Types may be expanded, other classes, reused classes, et cetera 17-9

10 Example of Part of a Design PAPER Inherits: PRESENTATION copyright_transferred : BOOLEAN reviews : SET [ REVIEW ] final_score : VALUE award_best_paper : PAPER transfer_copyright : PERSON accept + reject + PRESENTATION code : VALUE title : VALUE authors : SET [ PERSON ] status : STATUS speakers : SET [ PERSON ] accept + reject

11 Assertion Language Each query and command can be documented with a precondition and a postcondition Classes obey the Eiffel language laws w.r.t. the effect of assertions, inheritance and redefinition Documentation may be written using the full predicate calculus, as well as set theory Graphical Form Textual Form?! precondition postcondition require precondition ensure postcondition the_invariant invariant the_invariant 17-11

12 Example Graphical BON Class CITIZEN 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-12

13 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-13

14 Assertion Language 2 Boolean operators & logic» and or xor not Predicate logic» for_all exists Aritmetic operators» + * / ^ (exponent) // (integer division) \\ (modulus) Relational operators» = ε < > Set operators» {... } 17-14

15 Assertion Language 3 old expr value of expr before a routine was called Special keywords & symbols» Result result of a function but only in ensure» Current current object» Void not attached» name attribute name may current object, void reference» : TYPE type operator 17-15

16 Assertion Language 4 BON assertions can be full-blown predicates and set expressions Part of design involves refining BON predicate assertions into Eiffel assertions 17-16

17 Quantifier Notation Main difference between BON and Eiffel assertions is the use of quantifiers 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 member range each member in a set c CHILDREN it holds / it is the case that 17-17

18 Quantifier Notation 2»Quantifier Range_Expr [ Restriction ] Property >Restrictions boolean expression a, b : INTEGER a 0 ^ b 0 some_property >Property boolean expression 17-18

19 Clusters A 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 Drawn as a dashed box with rounded corners, with name of the cluster in a separate rounded box 17-19

20 Clusters Example SORTING DATA_STRUCTURES LINEAR_SORT QUICKSORT INSERT_SORT GRAPH DIRECTED_GRAPH WEIGHTED_GRAPH GRAPHS ARRAY RECORD 17-20

21 Clusters 2 Clusters can be shrunk to hide their contents Every class in a system belongs to exactly one cluster Not a language construct, simply a mechanism for dealing with abstraction Implement in Eiffel with directory structure» Each cluster is a directory 17-21

22 Inheritance Relations PEOPLE YOUNG_PEOPLE OLD_PEOPLE TODDLERS PUPILS UNDERGRADS Can draw between uncompressed classes Can involve clusters» Either component or entire cluster Question: what are the rules for writing an inheritance relationship between a class and a cluster? 17-22

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

24 Client Supplier Relations A uses the services supplied by B» Basic client supplier relations > Association some instance of the client class may be attached to one or more instances of the supplier class has a has a PERSON ADDRESS CITY Note should be only one arrowhead problem with double lines and single arrow head in slides 17-24

25 Client Supplier Relations 2 A uses the services supplied by B» Basic client supplier relations > Aggregation each client instance is attached to one or more supplier instances which represent "integral parts" of the client instance part of part of VEHICLE MOTOR CYLINDER propulsion combustion_chamber What's the difference between association and aggregation? Consider expanded vs reference use. Consider what happens when the client gets deleted

26 Bidirectional Links shoppers : set [... ] CUSTOMER SHOPPING_CENTER preferred_mall Put each label closer to the supplier side Generic classes can be used in labels» Leave parameter unspecified Useful for recursive structures» trees 17-26

27 BON Process ( The Method ) Precise process for analysis and development Idealized» In practice it is subject to variation, iteration, reversibility 17-27

28 Development Steps Gathering Delineate the system boundary > System chart, scenario charts» Identify what the system will include and what it will exclude. Determine» Determine the major subsystems» Determine user metaphors List candidate classes > Cluster charts» Produce a first pass list of classes 17-28

29 Gathering cont'd Select classes and groups > System chart, cluster charts, static architecture, class dictionary» Organise classes into logical groups / clusters» Determine status of classes > Deferred, effective, reused, et cetera 17-29

30 Development Steps Describing Define classes > Class charts» Give queries, commands, attributes, constraints > See slides on abstract data types Sketch system behaviour» Event charts, scenario charts, creation charts, object scenarios» Dynamic object model Define public features > class interfaces, static architecture» Give final class interfaces 17-30

31 Development Steps Designing Refine system > Class interfaces, static architecture, class dictionary, event charts, object scenarios» Find new design classes, add new features Generalize > Class interface, static architecture, class dictionary» Factor out common behaviour Complete and review system > Final static and dynamic models. All BON deliverables complete» Produce final static architecture with dynamic system behaviour 17-31

32 Modelling Charts First two steps of BON process : determine boundary, list candidate classes Informal charts are very useful for communicating basic ideas to non-technical people Very 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-32

33 Types of Modelling Charts 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 each class. > What information and services can other classes ask from the class? > What rules must be obeyed by the class? 17-33

34 Example System Chart SYSTEM Conference Management System Part # Purpose General 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 17-34

35 Example Cluster Chart CLUSTER Conference Management System Part # Purpose General conference administration support Indexing Cluster components COMPONENT_ 1 Description Component 1 description COMPONENT_2 COMPONENT_3 Component 3 description Component 3 description Similar to the System Chart 17-35

36 Example Class Chart CLASS Type of Object CITIZEN Person born or resident in a country Part # Indexing Queries Commands Name, Sex, Age, Single, Spouse, Children, Parents Marry, Divorce Constraints 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-36

37 Example Class Chart 2 Short description of purpose of class» Can add version control information Can add inherits from clause Constraints may be translated into formal assertions» Though some may never become formal 17-37

38 BON Dynamic Diagrams Diagrams we have seen so far are used to specify the static relationships among classes When executing such a system the static relationships will not change from execution to execution Contracts for class routines do not contain details of their implementation 17-38

39 BON Dynamic Diagrams 2 Analysis and design should not focus on implementation» However, it is 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 rough specification of how the classes can fulfil their specifications by calling routines of other classes» This is the purpose of the BON Dynamic Model 17-39

40 Dynamic Model What makes up a dynamic model in BON?» Feature calls In some methods you'll see it called message passing or object communication.» It all boils down to feature calls Using feature calls in our dynamic model supports seamlessness» They map directly to a programming language Some methods use finite state machines to specify what an object does in reaction to a message» Difficult to translate all but simple machines into programs lack of seamlessness 17-40

41 BON Dynamic Notations Diagrams are useful» One of the advantages of using finite state machines Event charts» Describe incoming and outgoing system events Scenario charts» Describe selected object communication scenarios > typically used with other notations Object creation chart» which classes create instances of other classes 17-41

42 Event Charts Definitions 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 An event chart lists selected external events that may trigger object communication 17-42

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

44 Objects and Communication Dynamic models are all about objects and their interactions How do we describe objects in BON?» Use rectangles containing their class with an object qualifier (e.g. a name) CONFERENCE FLIGHT STACK ( type ) More than one instance possible 17-44

45 Objects and Communication 2 Passing or sending a message» calling a feature, invoking an operation are all synonymous A message is indicated by a dashed arrow from calling to receiving object INVOICE_SYSTEM STOCK 17-45

46 Objects and Communication 3 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 Objects and Communication 4 Message are always potential» They do not have to occur > Flat battery Bidirectional messages are also possible Can specify concurrency» send receive to many objects Group as for clusters BRAIN 1 LEG Scenario: Get coffee 1 Step forward LEG 17-47

48 Scenario Charts Previous slides showed scenario charts combined with diagrams. In that case the scenario charts are simplified as portrayed. In general, scenario and event charts are similar in structure when diagrams are not involved

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

50 Creation Charts 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-50

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

52 Software Development Methods Much effort put into producing recipes for construction software Lots of good ideas» 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-52

53 Understand Method 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-53

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