UML tagged posts

Introducing Archi for EA ArchiMate Modeling

ArchiMate is an open and independent enterprise architecture modeling language to support the description, analysis and visualization of architecture within and across business domains in an unambiguous way. ArchiMate distinguishes itself from other languages such as Unified Modeling Language (UML) and Business Process Modeling Notation (BPMN) by its enterprise modelling scope.Archi2

There are quite a few tools which support ArchiMate specifications on the market, such as: IBM System Architect, Orbus iServer, Visual Paradigm ArchiMetric, Sparx Enterprise Architect, BiZZdesign Architect. Unfortunately these proprietary tools can be pricy.

So I would like to recommend to you a free, handy, open source and cross-platform ArchiMate tool called: Archi. It supports ArchiMate 2...

Read More

10 Best Practices in Database Schema Design

During past two decades, I have been working on many database design and migration projects. There are a lot of decisions to make in creating new database schema. Any database schema changes can be very expensive in a later date. Some may even result in rewriting the front end applications. So to understand a few best practices and apply them in your database schema design is vital important.

1. Take the advantages of UMLdb_schema

Most people use ERWin to create ERD, then use forward engineering to build up database schema. If we may move further and think about how to use object-oriented UML to describe the world, it might be very helpful. UML brings lots of benefits like composition relationship and inheritance (generalization relationship)...

Read More

Database Modeling in UML

ERWin is a long term standard database modeling tool for building up ERD. Usually data architect spends lots of time on handling the relationships among entities, then utilizes forward engineering function to generate database schema.

During database modeling practices, an outstanding issue has been noticed that some of our clients made mistakes in transaction design. All the transactions of all kinds of activities are kept in one transaction table, with fields createdby, createdon, createdusing, modifiedby, modifiedon and modifiedusing, etc. Initially, the system might work properly. But with time goes, e.g., after 3 years, the transaction table is very likely occupies more than half of the disk spaces of the entire database...

Read More