Data and Process Modelling 2. Information System Development Marco Montali KRDB Research Centre for Knowledge and Data Faculty of Computer Science Free University of Bozen-Bolzano A.Y. 2015/2016 Marco Montali (unibz) DPM - 2.IS Development A.Y. 2015/2016 1 / 21
IS Engineering Development of an IS: problem-solving. 1. Analysis (includes conceptual modeling): what the IS is about, what are the requirements. 2. Design (includes logical modeling): how to accomplish the requirements. 3. Implementation: coding of the design under specific architectural/technological choices. 4. Testing: check if the implementation works and meets the requirements. 5. Maintenance: assist users after release, keep the IS working. Marco Montali (unibz) DPM - 2.IS Development A.Y. 2015/2016 2 / 21
IS Engineering Processes Iterative XP Waterfall Analysis Analysis Design Design Implementation Analysis Test Implementation Maintenance Analysis Design Test Implementation Design Test Maintenance Maintenance Analysis Analysis Design Design Implementation Test Implementation Implementation Maintenance Analysis Design Test Implementation Maintenance Test Maintenance Test Analysis Analysis Design Implementation Design Test Maintenance Implementation Analysis Maintenance Design Test Implementation Test Maintenance Maintenance Marco Montali (unibz) DPM - 2.IS Development A.Y. 2015/2016 3 / 21
Incremental Iterative Approach Divide et impera. UoD Marco Montali (unibz) DPM - 2.IS Development A.Y. 2015/2016 4 / 21
Incremental Iterative Approach Divide et impera. UoD Marco Montali (unibz) DPM - 2.IS Development A.Y. 2015/2016 4 / 21
Incremental Iterative Approach Divide et impera. UoD Analysis Analysis Design Design Implementation Implementation Analysis Test Test Design Maintenance Maintenance Implementation Analysis Test Design Maintenance Implementation Test Maintenance Marco Montali (unibz) DPM - 2.IS Development A.Y. 2015/2016 4 / 21
Refined Steps 1. Feasibility study: is the idea implementable? 2. Requirements analysis : what should the system do? 3. Conceptual design - data, processes : what is the conceptual schema modeling the UoD? 4. Logical design - data, processes : how can the conceptual schema be translated into a logical schema? 5. Basic physical design - data and processes: how can the logical schema be represented in a concrete management system? 6. Basic external design - data and processes: which information can be accessed by users, and how? 7. Prototyping: how does the IS look like? 8. Completion of design. 9. Implementation of production version. 10. Testing and validation: does the IS work well and satisfy the requirements? 11. Release of software, documentation, training. 12. Maintenance. Marco Montali (unibz) DPM - 2.IS Development A.Y. 2015/2016 5 / 21
Requirements analysis First delineation of the IS to be . Domain (UoD) • Relevant documentation examined. • Meetings with domain experts, Joint sessions intended users, policy makers, with domain experts Requirements and stakeholders stakeholders. Initial elicitation & UoD analysis analysis • Prioritization of the next steps. • Output: requirements specifications document that Risk analysis clearly describes Requirements specification Partial conceptual schema functional/non-functional (use cases, scenarios,...) requirements, and sketches an initial conceptual schema of the Initial conceptual schema IS to be. ◮ Contract! To conceptual design... Requirements specifications document Marco Montali (unibz) DPM - 2.IS Development A.Y. 2015/2016 6 / 21
Interaction with Domain Experts Umberto Boccioni - Visioni simultanee M. C. Escher - Up and down Marco Montali (unibz) DPM - 2.IS Development A.Y. 2015/2016 7 / 21
Structural Conceptual Modeling - Phases Global conceptual Development of the structural conceptual schema. structural schema • Continuous involvement of domain experts. ◮ Definition of a glossary of terms. Divide the UoD • Incremental iterative approach. in sub-areas ◮ Start from the initial structural conceptual schema. Model/refine ◮ Iterate. . . each area 1. Split UoD into (overlapping) sub-areas, with priority. 2. Generate/refine the conceptual schema of Integrate each area. 3. Integrate the sub-schemas into a global conceptual schema. To logical/physical/external design... Marco Montali (unibz) DPM - 2.IS Development A.Y. 2015/2016 8 / 21
Logical/Physical Design without Explicit Processes Application layer Presentation logic Development of a typical 4-tier architecture. • Mirrors in the physical Application logic design. • Processes embedded in the application logic. Data logic (transient) • Two similar logical object-oriented mapping information schemas, two logical schema meta-data Object-relational mapping similar physical databases: Global conceptual ◮ transient - data logic of schema the application Data logic (persistent) (typically: OO). relational logical ◮ persistent - data logic of schema the persistence layer (typically: relational). Persistence layer Marco Montali (unibz) DPM - 2.IS Development A.Y. 2015/2016 9 / 21
Zachman’s Framework Partitioning of the IS abstract architecture. • Vertical partitioning: levels of abstraction. • Horizontal partitioning: aspects/concerns. Why What How When Who Where (Motivation) (Data) (Function) (Time) (People) (Network) Contextual goal list material list process list event list organizational geographical unit&role list locations list Conceptual goal structural process model event model organizational locations model relationship conc. model unit&role model Logical rules diagram data model process diagram event diagram role relationship locations diagram diagram diagram Physical rules data entity process function role location event specification specification spec. specification specification specification Detailed rules details data details process details event details role details location details • Logical and physical layers can be split into transient and persistent. • Mappings between levels to be considered. Marco Montali (unibz) DPM - 2.IS Development A.Y. 2015/2016 10 / 21
Which Languages??? conceptual structural schema O-R mapping logical relational logical OO schema schema ? ? ? Marco Montali (unibz) DPM - 2.IS Development A.Y. 2015/2016 11 / 21
Conceptual Modeling Languages: Criteria Expressibility: the measure of what can be modeled. 100% principle The language should be able to express all the relevant static and dynamic aspects of the UoD. • Remember: the conceptual schema is the knowledge component of the IS. • 100% principle → completeness: the conceptual schema captures all the required knowledge. • Completeness → quality. • Correctness: ◮ Syntactic: conformance to the language meta-model. ◮ Semantic: knowledge of conceptual schema is relevant and true in the domain. • Completeness is a goal, correctness is a requirement! Marco Montali (unibz) DPM - 2.IS Development A.Y. 2015/2016 12 / 21
Conceptual Modeling Languages: Criteria Clarity: how easy the language can be understood and used (by different stakeholders). • Graphical vs textual notations. • The language must be unambiguous: formal foundation. • The more expressive the language, the more difficult is to retain clarity. • Less expressive languages require complex combinations of their few constructs. • Abstraction: remove unnecessary details. Use requirements to drive abstraction. • Simplicity: Prefer simple schemas. Follow Occam’s razor with a critical approach. • Orthogonality: minimization of the overlapping of language constructs. Their (in)dependence must reflect the one of the corresponding domain aspects. Marco Montali (unibz) DPM - 2.IS Development A.Y. 2015/2016 13 / 21
Conceptual Modeling Languages: Criteria Semantic relevance: modeling of conceptually relevant aspects only. Conceptualization principle A conceptual model should only include conceptually relevant aspects of the UoD, excluding all aspects of external/internal data representation, physical data organization and access as well as aspects of particular external user representation such as message formats, data structures, etc. • Again, simplicity! • Semantic stability: how well the model retains its original intent in the face of domain or requirements changes. • Design-independence. ◮ Design aspects are tackled during the design phase! ◮ No architectural/design patterns. Marco Montali (unibz) DPM - 2.IS Development A.Y. 2015/2016 14 / 21
Trade-Offs Trade-offs between contrasting desiderata. • Expressivity vs tractability: the more expressive the language, the harder it is to compute with it. • Parsimony vs convenience: fewer concepts vs compact models. ◮ Would you use Assembler to implement a web server? Marco Montali (unibz) DPM - 2.IS Development A.Y. 2015/2016 15 / 21
Modeling Languages and Frameworks conceptual structural schema O-R mapping logical relational logical OO schema schema Marco Montali (unibz) DPM - 2.IS Development A.Y. 2015/2016 16 / 21
Modeling Languages and Frameworks conceptual structural schema O-R mapping logical relational logical OO schema schema ORM Object-Role Modeling UML E-R Unified Modeling Entity-Relationship Language Modeling Marco Montali (unibz) DPM - 2.IS Development A.Y. 2015/2016 16 / 21
Recommend
More recommend
