Lecture 7: Domain Modelling: Mgt. & Org. and Rules & Regs. · ⋆ strategic, tactical and...
Transcript of Lecture 7: Domain Modelling: Mgt. & Org. and Rules & Regs. · ⋆ strategic, tactical and...
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Lecture: 7. Slide: 318 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
Lecture 7: Domain Modelling: Mgt. & Org. and Rules & Regs.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1 Lecture: 7. Slide: 319 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling ]
Management and Organisation
Management
• Management is an elusive term.
• Business schools and private consultancy firms excel in offering degrees and 2–3day courses in ‘management’.
• In the mind of your author most of what is being taught — and even researched— is a lot of “hot air”.
• Well, the problem here, is, of course, that your author was educated at a science& technology university.
• In the following we shall repeat some of this ‘hot air ’.
• And after that we shall speculate on how to properly describe the outlined (“coldair”) management concepts.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1 Lecture: 7. Slide: 320 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management ]
Characterisation 65 (Domain Management) By domain managementwe mean people
• (i) who determine, formulate and thus set standards (cf. rules and regulations, alater lecture topic) concerning
⋆ strategic, tactical and operational decisions;
• (ii) who ensure that these decisions are passed on to (lower) levels ofmanagement, and to “floor” staff;
• (iii) who make sure that such orders, as they were, are indeed carried out;
• (iv) who handle undesirable deviations in the carrying out of these orders cumdecisions;
• and (v) who “backstop” complaints from lower management levels and from floorstaff
.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 1 Lecture: 7. Slide: 321 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management ]
• Management Issues •
• Management in simple terms means the act of getting people together toaccomplish desired goals.
• Management comprises
⋆ (vi) planning,
⋆ (vii) organizing,
⋆ (viii) resourcing,
⋆ (ix) leading or directing, and
⋆ (x) controlling an organization
⋆ (a group of one or more people orentities)
or effort
• for the purpose of accomplishing a goal.
• Resourcing encompasses the
⋆ (xi) deployment and manipulation ofhuman resources,
⋆ (xii) financial resources,
⋆ (xiii) technological resources, and
⋆ (xiv) natural resources
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 2 Lecture: 7. Slide: 322 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management ]
• Basic Functions of Management •
These are normally seen as management issues:
• Planning:⋆ (xv) deciding what needs to happen in the future
⋆ (today, next week, next month, next year, over the next 5 years, etc.)
⋆ (xvi) and generating plans for action.
• Organizing:
⋆ (xvii) making optimum use of the resources
⋆ (xix) required to enable the successful carrying out of plans.
• Leading/Motivating:
⋆ (xx) exhibiting skills in these areas
⋆ (xxi) for getting others to play an effective part in achieving plans.
• Controlling:
⋆ (xxii) monitoring –
⋆ (xxiii) checking progress against plans,
⋆ (xxiv) which may need modification based on feedback.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 3 Lecture: 7. Slide: 323 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management ]
• Formation of Business Policy •
• (xxvi) The mission of a business seems to be its most obviouspurpose – which may be, for example, to make soap.
• (xxvii) The vision of a business is seen as reflecting its aspirationsand specifies its intended direction or future destination.
• (xxviii) The objectives of a business refers to the ends or activityat which a certain task is aimed.
• The business policy is a guide that stipulates
⋆ (xix) rules, regulations and objectives,
⋆ (xxx) and may be used in the managers’ decision-making.
⋆ (xxxi) It must be flexible and easily interpreted and understoodby all employees.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 3 Lecture: 7. Slide: 324 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management, Formation of Business Policy ]
• The business strategy refers to
⋆ (xxxii) the coordinated plan of action that it is going to take,
⋄ (xxxiii) as well as the resources that it will use, to realize itsvision and long-term objectives.
⋄ (xxxiv) It is a guideline to managers, stipulating how theyought to allocate and utilize the factors of production to thebusiness’s advantage.
⋄ (xxxv) Initially, it could help the managers decide on whattype of business they want to form.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 4 Lecture: 7. Slide: 325 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management ]
• Implementation of Policies and Strategies •
• (xxxvi) All policies and strategies are normally discussed withmanagerial personnel and staff.
• (xxxvii) Managers usually understand where and how they canimplement their policies and strategies.
• (xxxviii) A plan of action is normally devised for the entirecompany as well as for each department.
• (xxxix) Policies and strategies are normally reviewed regularly.
• (xxxvii) Contingency plans are normally devised in case theenvironment changes.
• (xl) Assessments of progress are normally and regularly carried outby top-level managers.
• (xli) A good environment is seen as required within the business.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 5 Lecture: 7. Slide: 326 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management ]
• Development of Policies and Strategies •
• (xlii) The missions, objectives, strengths and weaknesses of eachdepartment or normally analysed to determine their roles inachieving the business mission.
• (xliii) Forecasting develops a picture of the business’s futureenvironment.
• (xliv) Planning unit are often created to ensure that all plans areconsistent and that policies and strategies are aimed at achievingthe same mission and objectives.
• (xlv) Contingency plans are developed — just in case !
• (xlvi) Policies are normally discussed with all managerial personneland staff that is required in the execution of any departmentalpolicy.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 6 Lecture: 7. Slide: 327 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management ]
• Management Levels •
• A careful analysis has to be made by the domain engineer of how management isstructured in the domain being described.
• One view, but not necessarily the most adequate view for a given domain is thatmanagement can be seen as composed from
⋆ the board of directors (representing owners, private or public, or both),
⋆ the senior level or strategic (or top, upper or executive) management,
⋆ the mid level or tactical management,
⋆ the low level or operational management, and
⋆ supervisors and team leaders.
• Other views, other “management theories” may apply.
• We shall briefly pursue the above view.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 7 Lecture: 7. Slide: 328 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management ]
• Resources •
• Management is about resources.
• A resource is any physical or virtual entity of limited availabilitysuch as, for example,
⋆ time and (office, factory, etc.) space,
⋆ people (staff, consultants, etc.),
⋆ equipment (tools, machines, computers, etc.),
⋆ capital (cash, goodwill, stocks, etc.), etcetera.
• Resources have to be managed
⋆ allocated (to [factory, sales, etc.] processes, projects, etc.), and
⋆ scheduled (to time slots).
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 8 Lecture: 7. Slide: 329 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management ]
• Resource Conversion •
• Resources can be traded for other resources:
⋆ capital funds can be spent on acquiring space, staff andequipment,
⋆ services and products can be traded for other such or for monies,
⋆ etc.
• The decisions as to who schedules, allocates and converts resources
• are made by strategic and tactical management.
• Operational management transforms abstract, general schedulesand allocations into concrete, specific such.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 9 Lecture: 7. Slide: 330 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management ]
• Strategic Management •
• A strategy is a long term plan of action designed to achieve a particular goal.
• Strategy is differentiated from
⋆ tactics or
⋆ immediate actions with resources
at hand
• by its nature of being
⋆ extensively premeditated,
⋆ and often practically rehearsed.
• Strategies are used to make business problems easier to understand and solve.
• Strategic management deals
⋆ with conversion of long term resources involving financial issues
⋆ and with long term scheduling issues.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 9 Lecture: 7. Slide: 331 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management, Strategic Management ]
• Among examples of strategic management issues (in supply chain management)we find:
⋆ (xlvii) strategic network optimization, including the number, location, and sizeof warehouses, distribution centers and facilities;
⋆ (xlviii) strategic partnership with suppliers, distributors, and customers,creating communication channels for critical information and operationalimprovements such as cross docking, direct shipping, and third-party logistics;
⋆ (xlix) product design coordination, so that new and existing products can beoptimally integrated into the supply chain, load management;
⋆ (l) information technology infrastructure, to support supply chain operations;
⋆ (li) where-to-make and what-to-make-or-buy decisions; and
⋆ (lii) aligning overall organizational strategy with supply strategy.
• The problem, in domain modelling, is to find suitable abstractions of thesemundane activities.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 9 Lecture: 7. Slide: 332 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management, Strategic Management ]
• Strategic management
⋆ requires knowledge of management roles and skills;
⋆ have to be aware of external factors such as markets;
⋆ decisions are generally of a long-term nature;
⋆ decision are made using analytic, directive, conceptual and/orbehavioral/participative processes;
⋆ are responsible for strategic decisions;
⋆ have to chalk out the plan and see that plan may be effective inthe future; and
⋆ is executive in nature.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 10 Lecture: 7. Slide: 333 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management ]
• Tactical Management •
• Tactical management deals with
⋆ shorter term issues than strategic management, but
⋆ longer term issues than operational management.
• Tactical management deals with
⋆ allocation and
⋆ short term scheduling.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 10 Lecture: 7. Slide: 334 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management, Tactical Management ]
• Among examples of tactical management issues (in supply chain management)we find:
⋆ (lx) sourcing contracts and other purchasing decisions;
⋆ (lxi) production decisions, including contracting, locations, scheduling, andplanning process definition;
⋆ (lxii) inventory decisions, including quantity, location, and quality ofinventory;
⋆ (lxiii) transportation strategy, including frequency, routes, and contracting;
⋆ (lxiv) benchmarking of all operations against competitors and implementationof best practices throughout the enterprise;
⋆ (lxv) milestone payments; and
⋆ (lxvi) focus on customer demand.
• The problem, in domain modelling, is to find suitable abstractions of thesemundane activities.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 11 Lecture: 7. Slide: 335 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management ]
• Operational Management •
• Operational management
⋆ deals with day-to-day and week-to-week issues
⋆ where tactical management deals with month-to-month andquarter-to-quarter issues and
⋆ strategic management deals with year-to-year and longer termissues.
• (Operational management is
⋆ not to be confused with the concept of operational research
⋆ and operational analysis
⋆ which deals with optimising resource usage
⋆ (allocation and scheduling).
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 11 Lecture: 7. Slide: 336 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management, Operational Management ]
• Among examples of operational management issues (in supply chainmanagement) we find:
⋆ (lxviii) daily production and distribution planning, including all nodes in thesupply chain;
⋆ (lxix) production scheduling for each manufacturing facility in the supplychain (minute by minute);
⋆ (lxx) demand planning and forecasting, coordinating the demand forecast ofall customers and sharing the forecast with all suppliers;
⋆ (lxxi) sourcing planning, including current inventory and forecast demand, incollaboration with all suppliers;
⋆ (lxxii) inbound operations, including transportation from suppliers andreceiving inventory;
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 11 Lecture: 7. Slide: 337 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management, Operational Management ]
⋆ (lxxiii) production operations, including the consumption ofmaterials and flow of finished goods;
⋆ (lxxiv) outbound operations, including all fulfillment activitiesand transportation to customers;
⋆ (lxxv) order promising, accounting for all constraints in thesupply chain, including all suppliers, manufacturing facilities,distribution centers, and other customers.
• The problem, in domain modelling, is to find suitable abstractions of thesemundane activities.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 12 Lecture: 7. Slide: 338 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management ]
• Supervisors and Team Leaders •
• We make here a distinction
⋆ between managers, “on one side”, and
⋆ supervisors and team leaders, “on the other side”.
• The distinction is based on
⋆ managers being able to make own decisions without necessarily having toconfer or discuss these beforehand or to report these afterwards, while
⋆ supervisors and team leaders normally are not expected to make owndecisions:
⋄ if they have to make decisions then such are considered to be of “urgency”,
⋄ must normally be approved of beforehand, or,
⋄ at the very least, reported on afterwards.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 12 Lecture: 7. Slide: 339 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management, Supervisors and Team Leaders ]
• Supervisors basically
⋆ monitor that work processes are carried out as planned
⋆ and report other than minor discrepancies.
• Team leaders
⋆ coordinate work in a group (“the team”)
⋆ while participating in that work themselves;
⋆ additionally they are also supervisors.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 13 Lecture: 7. Slide: 340 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management ]
• Description of ‘Management’ •
• On the last several slides (320–339) we have outlined conventionalissues of management.
• The problems confronting us now are:
⋆ Which aspects of domain management are we to describe ?
⋆ How are we describe, especially formally, the chosen issues ?
• The reason why these two “leading questions” questions are posedis that the management issues mentioned on slides 320–339
⋆ are generally “too lofty”, “too woolly”,
⋆ that is, are more about “feelings”
⋆ than about “hard, observable facts”.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 13 Lecture: 7. Slide: 341 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management, Description of ‘Management’ ]
• We, for example, consider the following issues for “too lofty”, “too woolly”:
⋆ Item (xix) Slide 322;
⋆ Item (xx) Slide 322;
⋆ Item (xxi) Slide 322;
⋆ Item (xxvii) Slide 323;
⋆ Item (xxviii) Slide 323;
⋆ Item (xxxi) Slide 323;
⋆ Item (xxxiii) Slide 324;
⋆ Item (xxxiv) Slide 324;
⋆ Item (xxxv) Slide 324;
⋆ Item (xxxvi) Slide 325;
⋆ Item (xxxvii) Slide 325;
⋆ Item (xxxix) Slide 325;
⋆ Item (xli) Slide 325;
⋆ Item (xlii) Slide 326;
⋆ Item (xliii) Slide 326;
⋆ etcetera.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 13 Lecture: 7. Slide: 342 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management, Description of ‘Management’ ]
• As we see from the above “quick” analysis
⋆ the problems hinge on our [in]ability to
⋄ formally,
⋄ let alone informally
describe many management issues.
⋆ In a sense that is acceptable
⋄ in as much as ‘management’ is clearly accepted as anon-mechanisable process,
⋄ one that requires subjective evaluations: “feelings”, “hunches”,
⋄ and one that requires informal contacts with other managerialpersonnel and staff.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 13 Lecture: 7. Slide: 343 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management, Description of ‘Management’ ]
• But still we are left with the problems:
⋆ Which aspects of domain management are we to describe ?
⋆ How are we describe, especially formally, the chosen issues ?
• Our simplifying and hence simple answer is:
⋆ the domain engineer shall describe
⋄ what is objectively observable
⋄ or concepts that are precisely defined
◦ in terms of objectively observable phenomena
◦ and concepts defined from these and such defined concepts.
• This makes the domain description task a reasonable one,
⋆ one that can be objectively validated
⋆ and one where domain description evaluators can objectively judge
⋄ whether (projected) requirements involving these descriptions
⋄ may be feasible and satisfactory.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 14 Lecture: 7. Slide: 344 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management ]
• Review of Support Examples •
• There are three examples
⋆ (i) a grossly simplifying abstraction:
⋄ the enterprise function,
⋄ which focuses on the abstract
⋄ interplay between management groups, workers, etc.; and
the formal model is expressed in a recursive function style;
⋆ (ii) a grossly simplifying abstraction
⋄ the enterprise processes,
⋄ which focuses on the sequential, non-deterministic
⋄ processes with input/output messages that
⋄ communicate between management groups, workers, etc.;
the formal model is expressed in the CSP style.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 14 Lecture: 7. Slide: 345 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management, Review of Support Examples ]
⋆ The Enterprise Function ⋆
• The enterprise function is
⋆ narrated on Slides 882–885,
⋆ and formalised on Slide 886;
⋆ the formalisation is explained and commented upon onSlides 887–895.
• Here we shall just briefly discuss meta-issues of domain
⋆ description,
⋆ modelling and
⋆ abstraction.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 14 Lecture: 7. Slide: 346 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management, Review of Support Examples, The Enterprise Function ]
• The description is grossly ‘abstracted’:
⋆ it leaves out any modelling of what distinguishes
⋄ strategic management,
⋄ tactic management,
⋄ operations management,
⋄ supervisors,
⋄ team leaders and
⋄ workers.
⋆ Emphasis has been put solely on
⋄ abstractions of their intercommunication
⋄ in order to achieve a “next step” state.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 14 Lecture: 7. Slide: 347 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management, Review of Support Examples, The Enterprise Function ]
• The formalisation of enterprise is, formally speaking, doubtful.
⋆ The semantics of the formal specification language, RSL, does notallow such recursions,
⋆ or rather, put far too severe restrictions on the state space Σ,
⋆ for the definition to be of even pragmatic interest.
⋆ Thus the definition is really a fake: at most it hints at what goeson, such as outlined on Slides 887–895.
• Why is the definition a fake?
⋆ Or rather: Why do we show this “definition”?
⋆ The next slide will discuss this.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 14 Lecture: 7. Slide: 348 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management, Review of Support Examples, The Enterprise Function ]
• In order for a recursive function definition, enterprise, (as here overstates Σ) to make sense
⋆ the type Σ must satisfy some ordering properties
⋆ and so must the component types whose values are involved inany of the auxiliary functions invoked by enterprise.
⋆ Since we have not specified any of these types
⋆ we take the position that function definition, enterprise, is just apseudo function.
• It is indicative of “what is going on”, and that is why we bring it!
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 14 Lecture: 7. Slide: 349 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management, Review of Support Examples ]
⋆ The Enterprise Processes ⋆
• The enterprise processes are
⋆ narrated and formalised, alternatively, on Slides 896–928,
• Here we shall just briefly discuss meta-issues of domain
⋆ description,
⋆ modelling and
⋆ abstraction.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 14 Lecture: 7. Slide: 350 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management, Review of Support Examples, The Enterprise Processes ]
•
• to be written
•
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 1, § 14 Lecture: 7. Slide: 351 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Management, Review of Support Examples, The Enterprise Processes ]
•
• to be written
•
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 2 Lecture: 7. Slide: 352 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
Domain Modelling, Management and Organisation
Organisation
Characterisation 66 (Domain Organisation) By domainorganisation we mean
• the structuring of management and non-management staff levels;
• the allocation of
⋆ strategic, tactical and operational concerns
⋆ to within management and non-management staff levels;
• and hence the “lines of command”:
⋆ who does what and
⋆ who reports to whom —
⋄ administratively and
⋄ functionally
.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 2 Lecture: 7. Slide: 353 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Organisation ]
•
• to be written
•
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 5, Subsubsect. 2 Lecture: 7. Slide: 354 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Management and Organisation, Organisation ]
.
Director
Board
Staff bStaff a Manager
Staff 1 Staff 2 Staff 3
Unit
A Matrix OrganisationA Hierarchical Organisation
Board
Director
Unit
Unit Unit
UnitUnit
Unit
Unit
Manager Manager Manager
Functional
Functional
Functional
Admin. Admin. Admin.
Manager
Manager
Manager
.....
.....
.......... .....
Figure 2.2: Two organisational structures
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 6 Lecture: 7. Slide: 355 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling ]
Rules and Regulations
• Human stakeholders act in the domain, whether
⋆ clients,
⋆ workers,
⋆ managers,
⋆ suppliers,
⋆ regulatory authorities,
⋆ or other.
• Their actions are guided and constrained by rules and regulations.
• These are sometimes implicit, that is, not “written down”.
• But we can talk about rules and regulations as if they wereexplicitly formulated.
For examples of narratives of domain rules and regulations we refer toappendix Examples 1–2 (Slides 957–958).
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 6 Lecture: 7. Slide: 356 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Rules and Regulations ]
• The main difference between rules and regulations is that
⋆ rules express properties that must hold and
⋆ regulations express state changes that must be effected if rules are observedbroken.
• Rules and regulations are directed
⋆ not only at human behaviour
⋆ but also at expected behaviours of support technologies.
• Rules and regulations are formulated
⋆ by enterprise staff, management or workers,
⋆ and/or by business and industry associations,
⋄ for example in the form of binding or guiding
⋄ national, regional or international standards,
⋆ and/or by public regulatory agencies.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 6, Subsubsect. 1 Lecture: 7. Slide: 357 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
Domain Modelling, Rules and Regulations
Domain Rules
For examples of narratives of domain rules we refer to appendixExamples 1–2 (Slides 957–958).
Characterisation 67 (Domain Rule) By a domain rule wemean
• some text
• which prescribes how people or equipment
• are expected to behave when dispatching their duty,
• respectively when performing their functions
.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 6, Subsubsect. 1 Lecture: 7. Slide: 358 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Rules and Regulations, Domain Rules ]
• Usually the rule text, when written down, appears in some, notnecessarily public documents.
⋆ It is not our intention to formalise these rule texts,
⋆ but to formally define the crucial predicates
⋆ and, if not already formalised, then also the domain entities overwhich the predicate ranges.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 6, Subsubsect. 2 Lecture: 7. Slide: 359 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
Domain Modelling, Rules and Regulations
Domain Regulations
For examples of narratives of domain regulations we refer to appendixExamples 1–2 (Slides 957–958).
Characterisation 68 (Domain Regulation) By a domainregulation we mean
• some text
• which prescribes what remedial actions are to be taken
• when it is decided that a rule has not been followed according to itsintention
.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 6, Subsubsect. 3 Lecture: 7. Slide: 360 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Rules and Regulations, Domain Regulations ]
• Usually the regulation text, when written down, appears in some,not necessarily public documents.
⋆ It is not our intention to formalise these rule texts,
⋆ but to formally define the crucial functions
⋆ and, if not already formalised, then also the domain entities overwhich these functions range.
Formalisation of the Rules and Regulations Concepts
• Rules, as already mentioned, express predicates, and regulationsexpress state changes.
• In the following we shall review a semantics of rules and regulations.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 6, Subsubsect. 3 Lecture: 7. Slide: 361 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Rules and Regulations, Formalisation of the Rules and Regulations Concepts ]
• There are, abstractly speaking, usually three kinds of languagesinvolved wrt. (i.e., when expressing) rules and regulations(respectively when invoking actions that are subject to rules andregulations).
⋆ Two languages, Rules and Reg, exist for describing rules,respectively regulations; and
⋆ one, Stimulus, exists for describing the form of the [alwayscurrent] domain action stimuli.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 6, Subsubsect. 3 Lecture: 7. Slide: 362 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Rules and Regulations, Formalisation of the Rule and Regulation Concepts ]
• A syntactic stimulus, sy sti, denotes a function, se sti:STI: Θ → Θ,from any configuration to a next configuration
• A syntactic rule, sy rul:Rule, has as its semantics, its meaning,rul:RUL,
⋆ a predicate over current and next configurations, (Θ × Θ) →Bool,
⋆ where these next configurations have been caused, by thestimuli. These stimuli express:
⋆ If the predicate holds then the stimulus will result in a valid nextconfiguration.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 6, Subsubsect. 3 Lecture: 7. Slide: 363 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Rules and Regulations, Formalisation of the Rule and Regulation Concepts ]
typeStimulus, Rule, ΘSTI = Θ → ΘRUL = (Θ × Θ) → Bool
valuemeaning: Stimulus → STImeaning: Rule → RUL
valid: Stimulus × Rule → Θ → Boolvalid(sy sti,sy rul)(θ) ≡ meaning(sy rul)(θ,(meaning(sy sti))(θ))
valid: Stimulus × RUL → Θ → Boolvalid(sy sti,se rul)(θ) ≡ se rul(θ,(meaning(sy sti))(θ))
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 6, Subsubsect. 3 Lecture: 7. Slide: 364 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Rules and Regulations, Formalisation of the Rule and Regulation Concepts ]
• A syntactic regulation, sy reg:Reg (related to a specific rule), standsfor, i.e., has as its semantics, its meaning,
⋆ a semantic regulation, se reg:REG,
⋆ which is a pair.
⋆ This pair consists of
⋄ a predicate, pre reg:Pre REG, where Pre REG = (Θ × Θ) →Bool,
⋄ and a domain configuration-changing function,act reg:Act REG, where Act REG = Θ → Θ,
⋄ that is, both involving current and next domain configurations.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 6, Subsubsect. 3 Lecture: 7. Slide: 365 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Rules and Regulations, Formalisation of the Rule and Regulation Concepts ]
⋆ The two kinds of functions express:
⋄ If the predicate holds,
⋄ then the action can be applied.
• The predicate is almost the inverse of the rules functions.
• The action function serves to undo the stimulus function.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 6, Subsubsect. 3 Lecture: 7. Slide: 366 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Rules and Regulations, Formalisation of the Rule and Regulation Concepts ]
typeRegRul and Reg = Rule × RegREG = Pre REG × Act REGPre REG = Θ × Θ → BoolAct REG = Θ → Θ
valueinterpret: Reg → REG
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 6, Subsubsect. 3 Lecture: 7. Slide: 367 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Rules and Regulations, Formalisation of the Rule and Regulation Concepts ]
• The idea is now the following:
⋆ Any action of the system, i.e., the application of any stimulus,
⋄ may be an action in accordance with the rules,
⋄ or it may not.
⋆ Rules therefore express whether stimuli are valid or not in thecurrent configuration.
⋆ And regulations therefore express whether they should beapplied, and, if so, with what effort.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 6, Subsubsect. 3 Lecture: 7. Slide: 368 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Rules and Regulations, Formalisation of the Rule and Regulation Concepts ]
• More specifically,
⋆ there is usually, in any current system configuration, given a set of pairs ofrules and regulations.
⋆ Let (sy rul,sy reg) be any such pair.
⋆ Let sy sti be any possible stimulus.
⋆ And let θ be the current configuration.
⋆ Let the stimulus, sy sti, applied in that configuration result in a nextconfiguration, θ
′, where θ′ = (meaning(sy sti))(θ).
⋆ Let θ′ violate the rule, ∼valid(sy sti,sy rul)(θ),
⋆ then if predicate part, pre reg, of the meaning of the regulation, sy reg, holdsin that violating next configuration, pre reg(θ,(meaning(sy sti))(θ)),
⋆ then the action part, act reg, of the meaning of the regulation, sy reg, must beapplied, act reg(θ), to remedy the situation.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 6, Subsubsect. 3 Lecture: 7. Slide: 369 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Rules and Regulations, Formalisation of the Rule and Regulation Concepts ]
axiom∀ (sy rul,sy reg):Rul and Regs •
let se rul = meaning(sy rul),(pre reg,act reg) = meaning(sy reg) in
∀ sy sti:Stimulus, θ:Θ •
∼valid(sy sti,se rul)(θ)⇒ pre reg(θ,(meaning(sy sti))(θ))⇒ ∃ nθ:Θ • act reg(θ)=nθ ∧ se rul(θ,nθ)
end
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 6, Subsubsect. 4 Lecture: 7. Slide: 370 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Rules and Regulations, Formalisation of the Rule and Regulation Concepts ]
• It may be that the regulation predicate fails to detect applicabilityof regulations actions.
• That is, the interpretation of a rule differs, in that respect, from theinterpretation of a regulation.
• Such is life in the domain, i.e., in actual reality
On Modelling Rules and Regulations
• Usually rules (as well as regulations) are expressed in terms ofdomain
⋆ entities, including those grouped into “the state”,
⋆ functions,
⋆ events, and
⋆ behaviours.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 6, Subsubsect. 4 Lecture: 7. Slide: 371 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
/home/db/tseb/kap2/kap2-2-2.tex Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
[ Domain Modelling, Rules and Regulations, On Modelling Rules and Regulations ]
• Thus the full spectrum of modelling techniques and notations may be needed.
• Since rules usually express properties one often uses some combination of
⋆ axioms and
⋆ well-formedness predicates.
• Properties sometimes include temporality and hence
⋆ temporal notations (like Duration Calculus or Temporal Logic of Actions )
are used.
• And since regulations usually express state (restoration) changes one often uses
⋆ state changing notations (such as found in B, RSL, VDM-SL, and Z).
• In some cases it may be relevant to model using some constraint satisfactionnotation or some Fuzzy Logic notations.
invi
sibl
e
Din
es B
jorn
er: 8
th D
RA
FT: O
ctob
er 1
4, 2
008
SOFTWARE ENGINEERING: The Essentials Nov. 2008 Lectures: TU Graz
Chap. 2, Sect. 9, Subsect. 6, Subsubsect. 4 Lecture: 7. Slide: 372 of 1334
c© Dines Bjørner, 2008Fredsvej 11DK-2840 HolteDenmark October 31, 2008, 15:20
Phone: +45 4542 2141, E-mail: [email protected], URL: www.imm.dtu.dk/˜db
End of Lecture 7