Zeger has a blog

Modeling Languages and Tools

Do you remember that post where I mentioned UML very briefly?

Okay, actually it was on the 18th. Anyway, in that post I mentioned how due to its use of the UML, Unified Modelling Language, UP is easier to understand for everyone who already understands UML.

So now the time has come to actually understand UML? Well two of my next posts will be completely dedicated to that. First we try to understand what a modelling language is.

A modelling language is an artificially formal language, which means it has been designed in a way in which form and meaning are stuck. It can be used to show definitions of terms and information, knowledge or requirements of products, systems or processes. Now the link with software processes becomes clearer. The software processes are built using modelling languages because they are to be followed and edited within a company by people with different roles over a possibly long time period. We want the language to state the process clearly, independent of the person who writing the process for the software system and independently of time.

Modelling languages can be textual or graphical computer languages. They have a set of rules and components which can be used to describe the software during the process. This is why using modelling languages is vastly superior over just coding with an idea in your head. You want to have a clear overview of what you want your software to be able to do, how you want the software to interact with different actors. This clear overview is not just for you, the single programmer, but for everyone involved in the program.

We have different categories of modelling languages: object, system, virtual reality, data modeling languages and a few more.

So now we have the language, but how to portray all the language? For this often modelling tools are used. The tools may be capable of automatically translating the models to code. There are tools for different purposes. For UML for example, here is a list of all the different tools, ranging from diagramming applications to business process modelling applications.

#Mastery04

Useful in case you want to use cases

“Everything is an object here” – Ken Bauer on Smalltalk

Use cases in object-oriented design focus on the real goal, not the mechanism to achieve it. That sounds straight-forward, because it is. You don’t focus on concrete actions, what a lot of people tend to do. You only focus on user intentions and system responsibilities.

But what is a use case? Good question, I should have started with that one. Remember Unified Software Process? Read my previous post on it. A use case is a list of events/actions in UP defining the interactions between an actor and a system to achieve a goal. Here the goal achieving returns.

An actor is something with behaviour, like a person (with a role of course), an organisation or a computer system. In object-oriented design, you are the architect of the software using UML as your pencil and ruler. The pro of this is that everyone who understands UML will understand how you designed it. This comes in handy when no one who started a project is still at the company at the time of needed maintenance. Use cases are an analysis of the requirements, giving you a story, which size varies greatly between different life cycle variations. The story, which describes the set of interactions, is highly valuable in the future, when all the original designers already left the company. Now you still have the story of why they started this project or that application in the first place, it was for the user all along!

The con is that you don’t think about concrete actions in use cases in object-oriented design. Goals may later turn out to be impractical, but you don’t know that when using use cases. When we take the example of logging in:

Object oriented:

-Administrator identifies self, system authenticates identity

This is a lot vaguer than Concrete actions:

-Administrator enters user id and password in dialog box, system authenticates identity.

Here’s a good other explanation from Genjuro on Stackoverflow:

Use case diagram is meant to shed light on the main functionalities of the system, and emphasis the perspective presenting the latter as a black box merely existing for a sole mission; deliver to the actor the promised service.

Object-oriented is analysis and design methodology, while use case is requirements methodology.

The stick-men are the actors. The balloons are the actual use cases. See that the use cases state what to do, but not how to do it? The arrows shed light on what each actor can do.

#Mastery03

Power to the process!

The Unified Software Process (UP) is a framework for the process of executing software projects. It is unified, meaning it is based on the Unified Modelling Language (UML), a modelling language designed to be broadly applicable. So UP is broadly applicable too, right? How broadly? Across different types of software systems, management systems and project sizes. The technical complexity also doesn’t really matter. If it is so broadly applicable, how does it stand out? Well, it is the industry standard. But that’s not all. UP is an effective tool to plan and organise a project, due to its use of the UML, which makes it easier to understand for everyone who already understands UML. The other pro is that everything in the UP is optional, making it essentially applicable to ANY project. However, the executers of the UP still need to know that even within the framework, there needs to be some degree of flexibility. Just like in a skeleton. You know the parts, but everything can still move around, depending on your project.

Now let’s talk about RUP!

RUP is an adaptable, iterative UP. It stands for “Rational Unified Process.” The four phases are as mentioned here:

Inception – The idea for the project is stated. The development team determines if the project is worth pursuing and what resources will be needed.

Elaboration – The project’s architecture and required resources are further evaluated. Developers consider possible applications of the software and costs associated with the development.

Construction – The project is developed and completed. The software is designed, written, and tested.

Transition – The software is released to the public. Final adjustments or updates are made based on feedback from end users.

But why should you care? Excellent question. You should care because implementing this framework into yoursmall business will greatly improve it. The first reason is the fact that RUP is housed on a server, so your work team can be as far away from you as you want. Your colleagues can edit the framework, making the project moving forward. Secondly, RUP enables different levels of quality assurance. Do you want an approval every time someone wants to edit the plan? Possible. Do you want everyone to be able to edit it quickly? Also possible. Thirdly, RUP unifies the project languages spoken throughout the company, by only focussing on what the goal is, what to do, but not HOW to do it. This way the manager and the programmer can talk to each other and actually understand what the other one is talking about. An utopia.

#Mastery02

Permanent life cycles

“You don’t have to know what is in the code to write the test. The test is the collection of specifications” – Ken Bauer, 2019

Here’s my first post. It will be the start of the journey called Analysis and Modelling of Software Systems, hopefully enabling you and me to plan writing code in the end. Let’s begin.

The approach of planning a software system is vastly superior when embarking on a medium to large scale project. Superior to the approach of just typing away and hoping your mind works the same as a computer.

But how do you plan writing code? And what do you plan? You could just plan the life of the software, from start to the software being given to the end user. But no software is perfect at the first, second or third try. Let’s make the it a life cycle, so you can make changes based on the feedback given by the end users.

Software development life cycles (SDLC) exist in many different forms, but they generally have 6 or 7 steps, something like:

1: Requirement gathering and analysis

2: Planning

3: Design

4: Implementation or coding

5: Testing

6: Deployment

7: Maintenance

There’s more information on each step here

Now let’s look at different life cycles.

Agile Model: This method revolves around the goal of delivering software as quickly as possible and adapt to change. This is encouraged if the end users and project stakeholders should or want to provide much feedback and are willing to accept flexible software requirements.

Waterfall model: This is a popular method in which every step is finished before continuing to the next step. This is ideal for projects with fixed requirements and scarce resources. The downside is that steps don’t overlap, which possibly reduces efficiency.

Other models are the V-Shaped, Big Bang, Spiral and Iterative Model. Read more about them here https://www.roberthalf.com.au/blog/employers/6-basic-sdlc-methodologies-which-one-best

Personally, I do not think the extremes of waterfall or iterative model are the solution. In every project, you have to come back after a few tries and change the original design based on the input you got from trying the product out in the real world. No one can know beforehand how all the variables will behave and when dealing with end users, meaning humans, the chances are they change their mind after seeing the first product. ‘No actually, it was fine the way it was’, is an often heard expression.

On the other hand, the iterative model can ramp up the costs of a project by a mindless continuation of the cycles, without thinking ahead. Programmer time is expensive, as governments have experienced multiple times.

The solution in my eyes is thoroughly planning, while trying to execute the most feasible parts of the design on the way, thus providing feedback for further planning and improvement. So in short, the perfect solution is somewhere in the middle. It depends on the type of project where in the middle, though.

#Mastery01