General Modeling Patterns: Component Architecture, Communication, and Consolidation PA116 – L3 (c) Zdenko Staníček, Sept 2010 OPVK_MU_EN_stred_2.jpg Three parts: •Component architecture and component communication •Consolidation of components •An addition: Definition and Use of DM 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 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 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. Organization (business) physiology Physiology figurine 7 Inner financial management Information centre, GO HRM + Pay-rolls Procurement Monitoring and influencing business environment Primary process IS (Data Model) Components 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”, ... 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) 10 Schedule Students Lecturer Room Schedule item Time Time = ( day_of_week, hour_from, hour_to) Course 11 PPPM component State of world Event Partner Activity connection Kind of resource Resource Article Project Person Project connection Milestone Goal Planned activity Executed activity Result Warehouse component Issue slip Actual State 02 04 09 Store Warehouse Income slip Warehouse Sector Stock plan item 01 03 05 06 08 07 Article Issue slip item Varehouse release Issue delivery note item Issued amount Selling batch Class Category 10 A 15 B 20 13 16 B 19 18 17 Warehouse cell Income slip item Warehouse input Transfer Income delivery note item Stock price Input amount Season 11 A A 14 12 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) 14 What is implemented in which way Entities Connections Attributes Table Rows impl entity impl associative Table Columns impl values impl foreign keys keys > 15 Lecturer Subject Room Schedule #LC #SB #RO #LC #SB #RO TIME • object descriptions • connections reflection • usage of keys 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 17 Communication through interface X X EMPLOYEE EMPLOYMENT_CONTRACT HRM PRODUCTION X X DEVICE WORK-PLACE where is the given operating given of given X LICENCE (( of given X CAPABILITY )) for given Communication via “Deputies” X X EMPLOYEE EMPLOYMENT_CONTRACT HRM PRODUCTION X X DEVICE WORK_PLACE where is the given operating given of given X LICENCE (( of given X CAPABILITY )) for given X DEPUTY- EMPLOYEE Usually asynchronous update Mother component for EMPLOYEE 19 Practical implementation •data replication among components •on-line update •update on demand •etc. • •Important trick: descriptive attributes not existing in the mother component Consolidation of data model 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 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 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 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 negotiated deal Associative entities: results of Binarisation Principle Application 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 26 Categorization of DM objects The root of the Tree DM object Entity Relationship Artefact/Thing Process Event Semantic relationship Week Semantic relationship Supertype Subtype relationship Container 27 Classifications of connections •Semantic connections its meaning is given by its semantics •Weak semantic connections instance → type, item → associative entity (associative entity projection to its elements – binarization principle) •Generalization-Specialization supertype–subtype •Let's compare this approach with classification from Construction Patterns 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 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) 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. • 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 An Addition: Definition and use of data model 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. 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. 35 What do we have: conventional waterfall paradigm Goals and requirements Analysis Design Implementation Tests & Operation Definition of Data Model Use of Data Model 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! 37 What do we need: Cyclical Paradigm at work Find strategic direction Define Data Model Support Processes - Use Data Model Tune processes - Re-define DM Revise strategic direction