2014 Pre-MSc-IS-0 Information Systems Modelling and Design

Andreas Martin - Page 1

Master of Science in Business Information Systems FHNW Pre-Master Information Systems

Information Systems Modelling and Design

Andreas Martin


http://www.flickr.com/photos/dirk_hofmann/4200450207


Overview - Information Systems Modelling and Design



1. Process Modelling 1.1 Process Graph



1.1 Process Graph

To represent the targeting situation including all the stakeholders, a process model will be created.

The process graph is suited to model process with non IT- related people.

This means that IT related details are skipped.



1. Process Modelling Process Layering - Business, Workflow and Execution Graph



Business, Workflow and Execution Graph


Petzmann, A., Puncochar, M., Kuplich, C. and Orensanz, D., 2007. Applying MDA ® Concepts to Business Process Management. In: L. Fischer, ed., BPM AND Workflow Handbook. Future Strategies Inc., pp.103–116.


BP- Graphs and Technologies


Business Process Modelling Languages: e.g. EPK, Petri Net, BPMN

Extended Business Process Modelling Languages:

e.g. BPMN, etc.

Workflow Modelling Languages: e.g. BPMN, XPDL, BPEL

Executable Code: e.g. Java, Services, BPEL4WS, XPDL

Process Graph

Workflow Graph

Execution Graph

Adapted from: Petzmann, A., Puncochar, M., Kuplich, C. and Orensanz, D., 2007. Applying MDA ® Concepts to Business Process Management. In: L. Fischer, ed., BPM AND Workflow Handbook. Future Strategies Inc., pp.103–116.


1. Process Modelling 1.2 Workflow Graph



1.2 Workflow Graph

The process graph will be extended with IT- related information or activities.

It is often the case that the workflow graph will be modelled directly (without modelling a process graph).



2. Use Case Modelling



2. Use Case Modelling

A use case model can be derived from a workflow model.

The use case model shows clearly what a prospective system has to fulfil.

It is still a common practice, that the process modelling step is skipped (starting with use case modelling) – but this is not recommended.



3. Data / Domain Modelling 3.A.1. Conceptual Model



3.A.1. Conceptual Model

A conceptual model can be derived from use case model.

A good stating point is to represent the NOUNS of the use cases as concepts in the conceptual model.

The conceptual model contains entity names and entity relationships.



3. Data / Domain Modelling 3.A.2. Logical Model



3.A.2. Logical Model

A logical model can be derived from conceptual model.

The logical model extends the conceptual model with attributes, primary keys, foreign keys and it is normalized.



3. Data / Domain Modelling 3.A.3. Physical Model



3.A.3. Physical Model

A physical model can be derived from logical model.

The physical model extends the logical model with column data types.



3. Data / Domain Modelling 3.B. Domain Model



3.B. Domain Model

A domain model can be derived from physical model (and vice versa). It is often the case that both models can be synchronized in both ways.

The domain model is represented as UML class diagram and will be used as blueprint for the persistence layer.



3.B. Domain Model

Sometimes the domain model is derived directly from use case model. However, it is recommended to have a data model.

The domain model contains additionally technical information for implementing (or generating) the entity classes.



Domain Model – Persistence Layer

The domain model can be used as a blueprint to create the @Entity beans in a Java EE environment. There are two options to create the entities:

Writing (or even generate) @Entity beans as Java classes and let the persistence mechanism generate the database schema.

Create SQL scripts that modify the database schema according to the target model (use physical data model instead class diagram). The @Beans can be reverse engineered or mapped using the persistence mechanism.



4. Service / Business (Logic) Modelling



4. Service / Business (Logic) Modelling

A service / business (logic) model can be derived from use case model.

A good stating point is to represent the VERBS (incl. NOUNS) of the use cases as methods.

Sometimes the business (logic) and the services will be modelled in separated models – it depends on the size of the project and the chosen system layering.



Service / Business (Logic) Model – Business and Service Layer

The domain model can be used as a blueprint to create (or generate) business and service classes / interfaces in a Java EE environment.

The logic has to be crated by writing Java code in implementing classes.



5. Workflow Modelling & UI Design 5.1. User Interface



5.1. User Interface

The user interface (UI) can be derived from use case model in conjunction with the process model.



5. Workflow Modelling & UI Design 5.2. Execution Graph



5.2. Execution Graph

The execution graph will be derived from workflow graph – usually it has to be remodelled or if available transferred using a round- tripping mechanism.

The execution graph will be extended with technical items

variables,

interfaces to services and

user interfaces…



Execution Graph and UI – Process and Presentation Layer

The user interface can be used as a template to create (or extend) the user interface on presentation layer.

The execution graph model will be execution using a process engine on process layer.


Date post:	03-Aug-2015
Category:	Technology
Upload:	andreasmartin
View:	67 times
Download:	1 times

2014 Pre-MSc-IS-0 Information Systems Modelling and Design

Technology