Modelling Notation

Using Sparx Enterprise Architect

I’m a week off starting a new Metastorm project that takes an existing system that has had its fair share of issues and we are essentially re-architecting it to be more stable and provide a whole load more usability.  This project is not the subject of my post however, it’s the tool we’re using to model it… Sparx Enterprise Architect.  This is my number 1 tool for creating models when I’m in the planning stage of a development project and in fact at the end of a project when I need to model a database that is at final release or re-engineer types for release documentation.

In my opinion, Sparx EA is the best modelling tool I have used to date, because it does everything I need and miles more.  For me personally I tend to draw up mostly Use Case, Class/Object/Component, Activity and Sequence Diagrams and EA is great for this.  Not only that, it’s a great tool for representing your entity/data models using the UML class diagram.  I use EA to reverse engineer my data tier objects (including procedures) because it’s literally as simple as selecting your ODBC data provider, the db objects you wish to model and then blam, EA reads your database object structures and loads the selected objects into a nice class diagram that illustrates PK-FK relationships, column default values and of course data types.  I use the EA boundary element to group together my tables into logical groups or schemas. I modelled the data model from my current project and grouped the tables in 20 minutes:

As for your diagrams, you can organise them into projects and packages within those projects so handy for keeping all of your project diagrams in an easy to understand structure. Diagrams are available for UML (structural, behavioural etc), Archimate, BPMN , Mind Mapping, SOMF, SPEM, Flow Chart, Org Chart and SoaML so if you can’t decide on a particular modelling framework, you have a choice.  I do use UML and BPMN (for process modelling) the most.

The coolest feature in my opinion is the model driven development/architecture (MDA). You can use forward and reverse engineering of code for popular languages like C#, VB.NET, Java and C++ (even WSDL and XSD Schemas).  I’m using 7.5 and its more than enough for my modelling needs. Version 8 is the current release and you can download a trial from the Sparx website – here.

Honestly between Sparx EA and Notepad++, in terms of tools for supporting software and process development, I don’t need much more.


Jargon Explained (Quickly!) : Frameworks, Methodologies, Models.

So not too long ago, someone asked me what I know about the ‘Zachman Methodology’ and the ‘UML Framework’?! – It got me thinking that all of these enterprise architecture terms and their respective ‘technologies’ can confuse a person; what exactly is a methodology or a framework and what approaches are classified as what?

Each time some new group of companies comes up with a new approach to software / process modelling, IT project management and their position in the overall enterprise architecture model it gets even more confusing for the man in the street.  Acronyms such as RUP, UML, TOGAF and SCRUM (well, this one isn’t really an acronym) can be found on CV’s the world over and are closely tied with IT infrastructure and software development projects.  What I’m attempting to offer in this quick article is some separation and understanding of some of the common frameworks, notations and methodologies relating to both business process and software development in an enterprise. I don’t claim to know them all, but I’ve experienced ZACHMAN, AGILE and UML via projects I’ve worked on which sparked my interest in the more pragmatic and structured view of BPM/EAI and Software planning and development.

What’s what?

What we mean by Framework, Methodology and Models/Notation. I’ve nicked what I feel is the most comprehensive definitions from one or two well known ‘wiki’ 😉 sites (plus my additional comments):

Framework : A basic structure of support. Basic indeed!? – In terms of traditional building architecture, the framework is the mechanical structure of the building.  In software design its more of a conceptional foundation for solving a particular software problem.  The .NET framework for example is named so as it forms the basic class structure and rules that allow software to be rapidly built and executed in a secure way on the Windows platform.  Zachman is the framework for the architecture of an enterprise (more on this in future articles).

Model:  A diagram representation of a physical or conceptual ‘real word’ object. Frameworks (structures) of all kinds can be broken down and described in detail.  Physical or conceptual idea’s are best described through images with descriptive notation or ‘Metadata’ (data describing data).  In traditional building architecture, blue prints are the model used to convey what conceptually needs to be built – it contains detailed information about sizes, materials and relative positioning (the model’s metadata).  In terms of the structure of the world, maps provide the model to getting around and understanding distances etc and in software development, models describe the classes, objects and information that make up the desired software solution. It’s important to note that models not only describe the framework / structure of something but the way parts of that thing interacts (the behaviour).  Creation of models (or modelling) pays a large part in the planning of anything and in terms of an enterprise, the planning of business processes and software development amongst others.  UML (Unified Modelling Language) is one of the more well respected, widely used and popular modelling styles (albeit not without its share of criticism) and is used to model software behaviour and structure and business processes.

Methodology: A system of principles, practices, and procedures applied to a specific branch of knowledge. In terms of enterprise architecture, this describes the principles, practices and rules to delivering an enterprise project which ultimately supports the enterprise architecture model and the business model in general.  It’s an approach on how parts of the enterprise architecture should be planned, developed and monitored.  All projects tend to follow a particular type of ‘methodology’ that best fits with the desired results. Agile and Six Sigma are applied methodologies for software development and business process projects.

UML : The 4+1 View of a System

UML Title

A little about UML

UML is a Standard Modelling Language for system design. It allows for the visual modelling of business processes, software and systems and is made up of:

– Notation (Symbols, Connectors, Notes and Values)
– Diagrams (The visual make up of a system).

UML is a set of specifications managed by the Object Management Group ( UML is extensible and it has been designed to be flexible and scalable (UML can be used to model a huge system or a quick business process sketch). UML can be used to model the following:

– Business Processes
– Application Structure
– Software behaviour (workflow)
– Model data structures
– Sketch out general structured idea’s
– Communication workflow
– Deployment workflow

The technology evolved from object orientated system design using classes and objects as the basis for components of the workflows. This concept is not only applied to programming however, business processes are made up of components that can be represented as objects. Lets cover some Object Orientation basics…

What is a system?

A related set of objects and instructions that together provide a working process.

What is an object?

Something (a component) that exists in the context of a system. An object is an instance of a class. A repeat product of a prototype / template idea (Class).

What is a Class?

Classes are templates that can create objects.
Classes have attributes (properties) and Methods (how it operates) associated with them that allow object instances to use.
Classes can inherit properties and methods from other classes, this is called class inheritence.

Relationships : Object Orientation

Created Objects do not always exist in isolation. They have relationships with other objects (ARE ASSOCIATED). For example, a speaker object and cd player object are working in associated to provide you with music. In the example of a fish bowl, The bowl object has a relationship with each individual fish object.

Class:Basketball Player
SubClasses:Center, Forward, Guard
Methods: Dribble the ball, take a 3 point shot.
Properties:Black Shorts, White Shoes.

Each object created from the subclasses hold a relationship with other objects in that they work together as a basketball team.

The 4+1 approach to modelling systems

When looking at an entire system as a whole, it can seem complicated at first and a good starting point if to create a 4+1 model diagram by breaking it down into 5 parts or Views. This model ensures you have considered and documented these 5 high level important aspects of any system. This approach breaks down the modelling of any system into the following views (inclusive of a use case view):

UML - 4 plus 1 System View

Each segment of the above offers its own perspective on the system architecture. Each of these views are clearly offering different information and so each view has a different UML diagram associated with it.  As you can see its made up of 4+1 parts:

Logical View : The logical objects (parts) of the system.
Process View: The process (workflow) of operation of these objects.
Physical View: The physical hardware and software the systems runs on.
Development View : The packages, run-time environments and class libraries used.
Use Case View : What the system does (functionality) from the perspective of a user (scenarios). Used in combination with requirement / specification documents.

Lets break these 5 system views down some more:

Logical View (The Systems Objects)

This view shows the components (objects) of the system as well as their interactions / relationships.  So effectively is the object model layout. It comprises the classes and objects within the system. UML diagrams that illustrate a systems logical view include :

– Class Diagrams (Most common UML diagram)
– State Diagrams
– Object Diagrams
– Sequence Diagrams
– Communication Diagrams

Process View (The Systems Workflow)

The process view shows the processes / workflow rules of a system and how those processes communicate with each other. It explores ‘what needs to happen’ in a system. UML diagrams that illustrate a systems process view include :

– Activity Diagram

Physical View (The System Environment)

This view shows the systems execution environment (hardware / software platforms). UML diagrams that illustrate a systems physical view include :

– Deployment Diagram

Development View (The Systems Software Hierarchy)

This view shows the parts of a system used in its operation (its layers of operation). It gives a building block view of the system. For example Packages Used, Execution Environments (i.e JVM or .NET), Class Libraries and Sub systems utilized. UML Diagrams that illustrate a systems process view include :

– Component Diagrams
– Package Diagrams

Use Case View (What the System is supposed to do)

This view offers an outside users perspective of the system. It captures the goals of the system and looks at the desired functionality of the system. Used along with use cases (user requirements / specification documents that the business analysts generally write) to understand the systems required use / functionality. UML diagrams that illustrate a systems process view include :

– Use Case Diagrams