general modeling patterns: component architecture, communication, and consolidation pa116 – l3 (c)...
TRANSCRIPT
![Page 1: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/1.jpg)
General Modeling Patterns:
Component Architecture, Communication, and
Consolidation
PA116 – L3 (c) Zdenko Staníček, Sept 2010
![Page 2: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/2.jpg)
Three parts:
• Component architecture and component communication
• Consolidation of components
• An addition: Definition and Use of DM
![Page 3: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/3.jpg)
3
Content of the first part
• Principles of decomposition of CDM/IDM to components
• Component interface—Deputy/Prime-Entity• Mother component• Inherited properties of Deputy from Prime-Entity in
Mother component• Attributes of Deputy which are not attributes of
Prime-Entity in Mother component• Possible implementation
![Page 4: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/4.jpg)
4
Why decomposition
• Problem complexity vs. Time to solve it
• Constrained resource capacity to find solution
• Constrained budget and preference to build up system step-by-step – part-by-part
• Components made by “experts” are more effective
• Non-uniform further development of IS in time
• Non-uniform dynamics of usage
![Page 5: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/5.jpg)
5
Component Recognition Principle
Component is described by one data model, i.e. all information needed for its correct work are stored in its own data sets in such a structure that component as a whole provides expected information capability no matter what the current situation in surrounding environment is.The number of outer connections is minimal for every component and thus the need of communication with other components is minimized.The inner complexity of component should not exceed the acceptable scale, i.e. it should be implemented in an acceptable time and it should start to provide benefits.Import and export scheme, i.e. interface, of component is unambiguously specified.
![Page 6: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/6.jpg)
Organization (business) physiology
Physiology figurine
![Page 7: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/7.jpg)
7
Inner financialmanagement
Informationcentre, GO
HRM + Pay-rolls Procurement
Monitoring and influencing business environment Primary process
IS (Data Model)Components
![Page 8: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/8.jpg)
8
What is a Component?• Component: entities + relationships + attributes• entity: everything what is worthy of being separately
investigated and what is interesting enough to file some characteristics about it..., and what is possible to distinguish from everything else– ”house”, “faculty”, “student”, “subject”, “product”, “customer”
• relationship: relation, assignment, binding– semantics of relationship– ”courses taught at given faculty“, ...– special connections: generalization-specialization, whole-
part, …
• attribute: property, characteristics– attribute semantics– “name of student”, “number of ETCS”, “date of delivery”, ...
![Page 9: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/9.jpg)
9
Examples
• Schedule component– to draw its bubble chart (next slide)
• Study component• Pay-roll component• Production component• Marketing&Sales component• Program, Porfolio Project Management
component (will be demonstrated)
• Warehouse component (will be demonstrated)
![Page 10: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/10.jpg)
10
Schedule
Students
Lecturer
Room
Schedule item Time
Time = ( day_of_week, hour_from, hour_to)
Course
![Page 11: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/11.jpg)
11
PPPM component
State of world
Event
Partner
Activityconnection
Kind ofresource
Resource
Article
Project
Person
Projectconnection
Milestone
GoalPlannedactivity
Executedactivity
Result
![Page 12: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/12.jpg)
Warehouse component
Issue slip
Actual State0204
09
Store Warehouse
Income slip
Warehouse Sector
Stock planitem
01
0305
06
08
07
Article
Issue slipitem
Varehouserelease
Issue deliverynote item
Issuedamount
Selling batch
ClassCategory
10
A
15
B
20
13
16
B
19
1817
Warehouse cell
Income slipitem
Warehouseinput
Transfer
Income deliverynote item
Stock priceInput amount
Season
11
A
A
14
12
![Page 13: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/13.jpg)
13
Implementation• implementation:
– Files / Tables,
– Records / Rows,
– Items / Columns,
– Keys
• what is implemented in which way (bubble chart—next slide)
• Practical computer implementation—this is the USE form of Data Model
• tables for Schedule component example (will be demonstrated)
![Page 14: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/14.jpg)
14
What is implemented in which way
Entities
Connections
Attributes
Table Rows
impl
entity
impl
associativeTable Columns
impl
values
impl
foreign keys
keys
![Page 15: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/15.jpg)
15
Lecturer Subject
Room
Schedule#LC #SB
#RO
#LC #SB #RO TIME
• object descriptions• connections reflection• usage of keys
![Page 16: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/16.jpg)
16
Components communication
• „To answer a question arisen at one component it is often necessary to get several pieces of information from another component“
• Component interfaces – “Deputy”/”Prime Entity”• Mother component• Inherited properties of Deputy from Prime Entity
in Mother component• Attributes of Deputy which are not attributes of
Prime Entity in Mother component
![Page 17: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/17.jpg)
17
Communication through interface
XX
EMPLOYEEEMPLOYMENT_CONTRACT
HRM
PRODUCTION XX
DEVICEWORK-PLACE
where is the given
operating given
of given
XLICENCE
((
of given
XCAPABILITY
))for given
![Page 18: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/18.jpg)
Communication via “Deputies”
XX
EMPLOYEEEMPLOYMENT_CONTRACT
HRM
PRODUCTION XX
DEVICEWORK_PLACE
where is the given
operating given
of given
XLICENCE
((
of given
XCAPABILITY
))for given
X DEPUTY-EMPLOYEE
Usually asynchronous update
Mother component for EMPLOYEE
![Page 19: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/19.jpg)
19
Practical implementation
• data replication among components
• on-line update
• update on demand
• etc.
• Important trick: descriptive attributes not existing in the mother component
![Page 20: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/20.jpg)
Consolidation of data model
![Page 21: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/21.jpg)
21
Content of the second part
• Why to consolidate
• Consolidation process
• Systematization of entities
• Classification of entitites
• Classification of connections
• Consolidation issues
• Rules of well-created data models
![Page 22: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/22.jpg)
22
Why to consolidate
• Federative architecture -- Components– Domain complexity and extensiveness
• Components are designed by various teams of analysts – each of them focuses the reality in its own manner
• Synonymy and homonymy
• Different „handwritings“, inconsistency in the level of detail
![Page 23: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/23.jpg)
23
Consolidation Process
• Revision of Definitions of all Entity Sorts in all Components
• Revision is based on certain categorizations
• After execution of Consolidation Process the Component’s Bases of Sorts are consistent in the way they were created by single “data modeler” person
![Page 24: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/24.jpg)
What objects a model of a Component contains:
Entity sorts
Subtype – Supertype relationships„total“ or „partial decomposition“
Particular sub-entities
subject
dealer distributor
7:offered by Relationships of entity sorts
negotiateddeal
Associative entities: results of Binarisation Principle Application
![Page 25: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/25.jpg)
25
Systematization of Entities
• The CATEG Data Model• Generalization-Specialization Hierarchy
only (another one than the Fundamental Hierarchy !!)
• Basic semantic types– Artefact/Thing– Process– Event– Container
![Page 26: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/26.jpg)
26
Categorization of DM objectsThe root of the Tree
DM object
Entity
Relationship
Artefact/Thing Process Event
Semanticrelationship
WeekSemanticrelationship
SupertypeSubtyperelationship
Container
![Page 27: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/27.jpg)
27
Classifications of connections
• Semantic connectionsits meaning is given by its semantics
• Weak semantic connectionsinstance → type, item → associative entity(associative entity projection to its elements – binarization principle)
• Generalization-Specializationsupertype–subtype
• Let's compare this approach with classification from
Construction Patterns
![Page 28: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/28.jpg)
28
Classification of entities
• logical point of view– Concepts containers for concepts or categories
– Instances containers for items– Forms containers for shapes or configurations
• philosophical point of view– tangible/material– intangible/immaterial
• existence status– plan– prescription / specification– realization /implementation / execution
![Page 29: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/29.jpg)
29
Rules of well-designed data models
• Every two entities, which are differently classified or belong to different basic semantic types (A-P-E-C), cannot be connected by generalization-specialization connection
• It is not possible to connect an instance of thing to concept of process (type process) in the following meaning: Output (#Instance of Thing) from given (#Type Process)
![Page 30: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/30.jpg)
30
Rules of well-designed data models
• If there is no week semantic connection of a concept entity, maybe appropriate instance entity is missing or a connection instance-to-category is missing.
• Entity of a type instance-of-process is usually bound to entities of a type instance-of-artefact (input or output of the process). If not, the model could be incomplete.
![Page 31: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/31.jpg)
31
Consolidation issues
• concept of something versus container• physical containers and abstract ones
(constructions)• ambiguousness of ordering of entities by
categories (pragmatic stance: USE vs. MENTION)
• subjectivity of categorizations (analyst + agreements)
• principle of component consistency of single IDM
![Page 32: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/32.jpg)
An Addition: Definition and use of data
model
![Page 33: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/33.jpg)
33
What means a DEFINITION of data model
• Specification of conceptual system which will be used for mentioning (MENTION) within a given Domain.
• List of concepts used for structure, state, and behavior explication– Concepts identifying objects– Concepts identifying connections– Concepts identifying operations
• Exact determination of information capability needed for controlling and execution of processes in a given Domain.
![Page 34: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/34.jpg)
34
What means a USE of data model
• It is ensured that the given information capability (the one defined by the data model) is available in concrete controlling and execution of processes in a given Domain.
• This is done by using technical means (HW, SW).
• Examples:– Implementation of IS with a given data model,– Data model as a “technical dictionary” used to make
oneself understood to anybody and anything when controlling and executing processes in a given Domain.
![Page 35: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/35.jpg)
35
What do we have: conventional waterfall paradigm
Goals and requirements
Analysis
Design
Implementation
Tests &Operation
Definition of Data Model
Use of DataModel
![Page 36: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/36.jpg)
36
Pitfalls of Waterfall Paradigm
• Long time from requirement specification to its satisfaction
• Lasting of steps „Design “ and „Implementation“
• Adaptation of application logic to the changed DB scheme
• To implement IS means to preserve or conserve status quo!
![Page 37: General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010](https://reader036.vdocuments.net/reader036/viewer/2022081603/56649ea05503460f94ba2efb/html5/thumbnails/37.jpg)
37
What do we need: Cyclical Paradigm at workFind strategic
direction
Define DataModel
Support Processes -Use Data Model
Tune processes -Re-define DM
Revise strategic direction