OU blog

Personal Blogs

Christopher Douce

Figuring out Visual Paradigm

Visible to anyone in the world

One of the tools (or languages) I learnt as a graduate student was UML; the unified-modelling language. UML is a standard that describes a group of related diagrams. Different diagrams describe different aspects of a software system. UML is used for design, but it can also be used to document requirements, and can help with communication between developers and engineers. If you are able to use UML, you’re able to share ideas about code and software with others more fluently.

One of the tools that I learnt about was a graduate student was Rational Rose, which is now called . At the time I thought it was witchcraft. You could sketch out a diagram using a drawing tool and it would be able to generate some computer code for you.

The postgraduate module M813 Software Development introduces students to a tool called Visual Paradigm which is a tool that I’ve never heard about before. This said, it does bear some similarities with other graphical software design tools that I’ve had the opportunity to have a play with.

The aim of this post is to share some notes and weblink that I’ve collated about Visual Paradigm and other related tools.

Looking at Visual Paradigm

After installing a trial version of Visual Paradigm, I’m taken to a training page: Visual Paradigm Essentials.

From here, I’m taken to an Udemy course, Visual Paradigm essentials where apparently there are 27 hours’ worth of video lectures to attend. The introductory course is intended to help users to “learn all essential skills of software design and modeling including, UML, BPMN and SysML”.

I picked up the following points from the introduction: it can be used to create use cases, business process diagrams, user stories, and a whole host of other diagrams. It also links to agile software development practices, and can play a role in user experience and customer experience design. 

Here is an abbreviated list of diagram types it supports: user experience diagrams (wireframes and sequence visualisation), customer experience maps, software system design diagrams (UML and cloud architecture design diagrams), entity relationship diagrams (database designs) and business design diagram diagrams (such as business process tools and organization chart tools).

It was also mentioned that it could generate and reverse source code from diagrams, and could be used to generate basic code. Database creation scripts could be generated from entity relationship diagrams.

Other tools and environments

In TM354 Software Engineering students use a tool called NetBeans, a Java integrated development environment. 

After a bit of internet searching about NetBeans and UML, I found there was a NetBeans plugin called easyUML. EasyUML makes it possible to convert Java code into class diagrams. 

Whilst digging around, I found a related bit of software called PlantUMLRelated to this project, there is also a NetBeans plugin called PlantUML-NB. The interesting thing about PlantUML is that is can generate UML diagrams from relatively small bits of text which is not too dissimilar to code. The textual basis of this utility reminds me of a tool called UMLet  which I’ve written about previously

It wasn’t too long until I discovered this page: Visual Paradigm IDE integrationThis page suggests it is possible to connect Visual Paradigm and NetBeans together; potentially facilitating that bit of witchcraft that I alluded to earlier. To substantiate this suspicion, I found an accompanying video clip called Perform UML Modeling in NetBeans with Visual Paradigm (YouTube).

Whilst looking at UMLet, I noticed that there was a reference to a Microsoft product called Visual Studio Code. When I was a developer working in industry, I used Microsoft Visual Studio every day. It turns out that Microsoft Visual Studio (Wikipedia)Microsoft Visual Studio (Wikipedia) is different to Microsoft Visual Studio Code (Wikipedia)Microsoft Visual Studio Code (Wikipedia) despite having a very similar name. Clearly things have moved on since I was a full time developer. There are a few things I need to catch up on.

Whilst reminding myself about bits of the Microsoft developer toolset, I found this article, which was all about Visual Studio and Visual Paradigm Integration.

Reflections

Different modules use different bits of software. Across the computing curriculum, computing students will be exposed to Python, Java and JavaScript. This will mean that they will be exposed to different programming environments and toolsets. Getting to grips with different environments and tools is a necessary graduate skill. What I will say is that when it comes to software engineering, graphical tools are likely to be important, along with other tools. The exact make up will, of course, depend on the context of software, and the problems that they are required to solve.

Permalink
Share post
Christopher Douce

Book review: Two novels about DevOps

Visible to anyone in the world

When I started to do some background reading into how TM354 Software Engineering might need to be updated, I was guided towards two curious novels. 

From October 23 I start to study A233 Telling stories: the novel and beyond, as a part of my gradual journey through a literature degree. For quite a while, I have been thinking there have been very little to connect novels and software engineering, other than obvious: the development of Word processing tools that can be used to write novels, and the Amazon cloud infrastructure used to distribute eBooks.

What follows is a very short (and not very through) review of two books that are all about DevOps: The Phoenix Project, by Gene Kim (and others), and The Unicorn Project, which is also by Kim. 

The Phoenix Project

I shall begin by sharing an honest perspective: the idea of a novel about software development did not excite me in the least. The text has a subheading that seemed to strengthen my prejudices: “a novel about IT, DevOps, and Helping Your Business win”. This is no crime drama or historical novel. The closest genre that one could attribute to The Phoenix Project is: thriller. I feel it occupies a genre all of its own, which could be labelled: IT business thriller.

The main protagonist is Bill Palmer, who has the unenviable job title of “Director of Midrange Technology Operations”. Bill works for a mysterious American company called Parts Unlimited. A lot happens in the early chapters: Bill is invited in to have a chat with a manager, who gives him a promotion. He is then asked to take a lead in getting the Phoenix Project, a new mission critical software system to work. Failure means the business would lose any potential competitive advantage, and the IT infrastructure might be outsourced, which means that people would lose their jobs.

Before Bill can get settled, he is hit by a payroll outage, which means the employees and unions are angry. He also quickly realises that the whole IT setup is in a complete state. Kim and his co-writers do a good job at attempting to convey a sense of paralysis and panic. The reason for this is expressed through the notion of ‘technical debt’, which means that existing IT infrastructure has become increasing complicated over time. Quick fixes now can, of course, lead to further problems down the line. Parts Unlimited has not been ‘paying down’ their technical debt.

An important element of the novel is the division between the Ops (operations) bit of IT, and the development division. There are other competing teams, which also play a role: there is the QA (quality assurance), and the security team. Security is important, since if an organisation doesn’t keep its auditors happy, the directors may face legal consequences.

I think I would be mean to describe the characters as one dimensional, since plot clearly takes precedence over characterisation. The main protagonist Bill is the most richly described. His organisational skills and sense of calm in the face of chaos is explained through his military background. 

Ubergeek Brent plays an important role, but I really wanted to know what made him tick. Erik Reid, an unofficial mentor to Bill plays the role of a Yoda-like mystic who provides insightful advice, who draws on his extensive knowledge of lean manufacturing. A notable character is Sarah Moulton, the Senior Vice President of Retail Operations, who takes on the unenviable role of the villain.

What struck me was the amount of technical detail that exists within the text. There are references to services, languages, and source code management. There is also the important notion of the ‘release’, which is a persistent problem, which pervades both this text, and its follow-up. Whilst I enjoyed the detail, I’m unsure about the extent to which the lay reader would grasp the main point that the book was making: to gain efficient business value from IT, it is best to combine together operations and development. Doing this enables the creation of tighter feedback loops, and reduces operational risk. Along the journey, there are these moments which raise an eyebrow. An example of this is where there is unambiguous contrition from a security manager once he sees an error in his thinking.

Bill identifies barriers and instigates change. After a “challenging” release of Phoenix, he ultimately prevails. During the updates, there is the emergence of a ‘side project’, which makes use of new fangled cloud technology to deliver value to the business. In turn, this generates income that makes shareholders happy. Political battles ensue, and Bill then gets on a fast track to a further promotion.

Apparently, The Phoenix project was popular amongst developers when it first came out, but I’ve been peripherally distant from the domain of software engineering, which means I’ve been a bit late to the party. Before providing further comment, I’ll move onto the sequel: The Unicorn Project.

The Unicorn Project

When I read The Phoenix Project, one of my criticisms was about the identity of the main protagonist. Novelists can not only use their craft to share a particular reality, but they can also have the potential to effect change. Whilst I liked Bill and the positive role that he took within the novel, given the clear and persistent gender disparities in the sector, I did feel that a female protagonist would have been more welcome. This unarticulated request was answered through The Unicorn Project in the form of Maxine Chambers, the lead protagonist in Kim’s follow up novel. 

Maxine is collateral damage from the payroll failure. Despite being hugely talented, she is side-lined; temporarily reassigned to The Phoenix Project. Her starting point was to try to get a build of all the software that was being developed, but faced persistent complexity, not just in terms of software, but in terms of finding out who to speak with to get things done.

Whilst the main project was saturated with bureaucratic burden, Maxine gradually found “her people”; smart like minded people who were also frustrated by the status quo. She also spoke with the business mystic and mentor, Erik Reid, who was very happy to share his words of wisdom. Ubergeek Brent also makes an appearance, but his backstory continued to remain opaque.

A really interesting part of the text is where Maxine ‘goes into the field’ to learn what happens in the Parts Unlimited stores. Drawing on the notion of ethnographic observations, she learns first-hand of the difficulties experienced by the store workers. Another interesting element which occurs towards the end of the novel is the movement towards embedding institutional learning, and drawing upon the creativity that exists within the workforce. In comparison to The Phoenix Project, there is more emphasis about culture, specifically, developing a no blame culture.

A key theme of The Unicorn Project is shared with The Phoenix Project: it is important to combine development and operations together, and it is helpful to perform continually integration since users can gain access to the new features more readily. A notable section highlighted the challenge of carrying out code merges during marathon meetings. If code is continually integrated, then there isn’t the need for all those uncomfortable meetings. Significantly, the Unicorn project also goes further than The Phoenix Project, since it is also about the power of teamwork, collaboration and the potential of smaller projects positively affecting and influencing others. Like Bill, the formidable Maxine is successful. 

Reflections

My initial scepticism of these novels comes from my view that novels are made from story and character, not technology. What is very clear is that although technology plays an important role, people are, by far, the most important. The novels foreground the role of teams and their organisation, the importance of sharing knowledge, and the importance of collaboration and leadership. It is clear that soft skills matter for the simple reason that software is something that is invisible; developers must be able to talk about it, and to each other. This is also why organisational culture is so important.

An important reflection is that both Bill and Maxine have difficult and very stressful jobs. They are both shown to work ridiculously long hours, often over the weekend. In the novels, IT is depicted as a difficult occupation, and one that is far from being family friendly. The families of both protagonists are featured, and they both suffer.

Although both of these novels are stories about the success of heroes battling against impossible odds, the hyperreality of the chaos within Parts Unlimited makes their success difficult to believe. Conversely, the hyperreality that is expressed through the impossible administrative burdens of the ticketing systems offers a warning to those who have to work with these systems on a daily basis.

The mystical mentor Erik is, of course, difficult to believe. He is a device use to share the pragmatic business and manufacturing theories that are central to the themes that are common to both books. I didn’t mind Erik. Like with Brent, I wanted to know more of his backstory, but with a limited work count and a lot of themes to work through, I understand why creative trade-offs were made to foreground more pressing technical topics.

Whilst I found the broader context, automotive spares, mildly interesting, I found myself becoming bored by the theme of IT being used to gain ever increasing amounts of money through the persistent and relentless pursuit of the customer. Although I accept that IT can be thought of a product of capitalism, there are more interesting ways that IT can be used and applied. Technology can be used to reflect humanity, just as humanity is reflected in technology. Whilst capital is important, there are other subjects that are more interesting. I think I would like to read an IT business thriller about cyber security, as opposed to one about a business that has found a new way to sell engine monitoring apps.

To conclude, these two novels were fun. They were also informative without being overly didactic. Although IT business thriller books is not my favourite genre, I can say that I enjoyed reading them. I’m more a fan of Victorian romances.

Epilogue

In 2004, I was working as a Software Engineer in a small company that designed and manufactured educational equipment used to teach the principles of electrical engineering and computing. 

One day in April, the manager director bounded into the office where I worked.

“We’re selling our e-learning division! This means that we won’t be able to sell our flagship learning management system anymore. We need to find a solution. We had been working on an earlier project, but that didn’t work out. So, we need you to head up the development of a new learning management system”.

That new learning management system was given an internal codename. It wasn’t very original. 

We called it Project Phoenix.

References

Kim, G. et al. (2014) The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win. 1st edition. Place of publication not identified: IT Revolution Press.

Kim, G. (2019) The Unicorn Project. IT Revolution Press.

Permalink Add your comment
Share post
Christopher Douce

TM354 Software Engineering: briefing

Visible to anyone in the world
Edited by Christopher Douce, Monday, 11 Sep 2023, 16:27

On Saturday 27 September I went to a briefing for a new OU module, TM354 Software Engineering.   I have to secretly confess that I was quite looking forward to this event for a number of reasons: I haven’t studied software engineering with the OU (which meant that I was curious), I have good memories of my software engineering classes from my undergraduate days and I also used to do what was loosely called software engineering when I had a job in industry.  A big question that I had was: ‘to what extent is it different to the stuff that I studied as an undergrad?’  The answer was: ‘quite a bit was different, but then again, there was quite a bit that was the same too’.

I remember my old undergrad lecturer introducing software engineering by saying something like, ‘this module covers all the important computer stuff that isn’t in any of the other modules’.   It seemed like an incredibly simple description (and one that is also a bit controversial), but it is one that has stuck in my mind.  In my mind, software engineering is a whole lot more than just being other stuff.

This blog post summary of the event is mostly intended for the tutors who came along to the day, but I hope it might be useful for anyone else who might be interested in either studying or tutoring the module.  There’s information about the module structure, something about the software that we use, and also something about the scheduling of the tutorials.

Module structure

TM354 has three blocks, which are also printed books.  These are: Block 1 – from domain to requirements, Block 2 – from analysis to design, and Block 3 – from architecture to product.  An important aspect to the module is a set of case studies.  The module is also supported by a module website and, interestingly, a software tool called ShareSpace that enables students to share different sketches or designs.  (This is a version of a tool that has been used in other modules such as U101, the undergraduate design module, and T174, an introduction to engineering module).

Block 1 : from domain to requirements

Each block contains a bunch of units.  The first unit is entitled ‘approaches to software development’, which, I believe, draws a distinction between plan driven software development and agile software development.  I’ve also noted down the phrase ‘modelling with software engineering’.  It’s great to see agile mentioned in this block, as well as modelling.  When I worked in industry as a developer, we used bits of both.

The second unit is called requirements concepts.  This covers functional requirements, non-functional (I’m guessing this is things like ‘compatibility with existing systems’ and ‘maintainability’ – but I could be wrong, since I’ve not been through the module materials yet), testing, and what and how to document.  Another note I’ve made is: ‘perspectives on agile documentation’.

Unit three is from domain modelling to requirements.  Apparently this is all about business rules and processes, and capturing requirements with use cases.  Prototyping is also mentioned.  (These are both terms that would be familiar with students who have taken the M364 Interaction Design module).  Unit four is all about the case study (of which I have to confess that I don’t know anything about!)

Block 2: from analysis to design

Unit five is about structural modelling of domain versus the solution.  Unit six is about dynamic modelling, which includes design by contract.  Unfortunately, my notes were getting a bit weak at this point, but I seem to remember thinking, ‘ahh… I wonder if this relates to the way that I used to put assertions in my code when I was a coder’.  This introduction was piquing my interest.

Unit seven was entitled, ‘more dynamic modelling’, specifically covering states and activities, and capturing complex interactions.  Apparently the black art of ‘state machines’ are also covered in this bit.  (In my undergrad days, state machine were only covered in the completely baffling programming languages course) .  Unit eight then moves onto the second part of the case study which might contain domain modelling, analysis and design.

Block 3: from architecture to product

This block jumped out at me as being the most interesting (but this reflects my own interests).  Unit nine was about ‘architecture, patterns and reuse’.  Architecture and requirements, I’ve noted, ‘go hand in hand’.  In this section there’s something about architectural views and reuse in the small and reuse in the large.  During the briefing there was a discussion about architectural styles, frameworks and software design patterns.

When I was an undergrad, software patterns hadn’t been discovered yet.  It’s great to see them in this module, since they are a really important subject.  I used to tell people that patterns are like sets of abstractions that allow people to talk about software.  I think everyone who is a serious software developer should know something about patterns.

Unit ten seems to take a wider perspective, talking about ‘building blocks and enterprise architectures’.  Other topics include component based development, services and service oriented architectures (which is a topic that is touched upon in another module, and also potentially the forthcoming TM352 module that covers cloud computing).

Unit eleven is about quality, verification, metrics and testing.  My undergrad module contained loads of material on metrics and reliability, and testing was covered only in a fairly theoretical way, but I understand that test-driven development is covered in this module (which is a topic that is linked to agile methods).  I’ll be interested to look at the metrics bit when this bit of the module is finalised.

The final unit takes us back to the case study.  Apparently we look at architectural views and patterns.  Apparently there are also a set of further topics that are looked.  I’m guessing that students might well have to go digging for papers in the OU’s huge on-line library.

Software

I’ve mentioned ShareSpace, which is all about sharing of software models with other students (modelling is an important skill), to enable students to gain experience of group work and to see what other students are doing and creating: software development invariably happens in teams.  Another important bit of software is an open source IDE (integrated development environment) called NetBeans.  I’m not sure how NetBeans is going to be used in this module, but it is used across a number of different OU modules, so it should be familiar to some TM354 students.

Assessment

TM354 comprises of three tutor marked assignments, a formative quiz at the end of every unit (that students are strongly encouraged to complete), and an end of module exam.  The exam comprises of two parts: a part that has questions about concepts, and a second bit that contains longer questions (I can’t say any more than this, since I don’t know what the exam looks like!)

Tutorials

Each tutor is required to deliver two hours of face to face tuition, and eight hours of on-line sessions through OU Live (as far as I understand).  In the London region, we have three tutors, so what we’re doing is we’re having all the groups come to the same events and we’re having each tutor deliver a face to face session to support students through every block and every TMA. 

We’re also planning on explicitly scheduling six hours of OU Live time, leaving two hours that the tutor can use at his or her discretion throughout the module (so, if there are a group of students who struggle with concepts such as metrics, design by contract, or patterns, a couple of short ad-hoc sessions can be scheduled). 

All the OU Live sessions will be presented through a regional OU Live room.  This means that students in one tutor group can visit a session that is delivered by another London tutor.  The benefit of explicitly scheduling these sessions in advance is that all these events are presented within the student’s module calendar (so they can’t say that they didn’t know about them!)  All these plans are roughly in line with the new tuition strategy policy that is coming from the higher levels of the university.  A final thought regarding the on-line sessions is that it is recommended that tutors record them, so students can listen to the events (and potentially go through subjects that they find difficult) after an event has taken place.

A final note that I’ve made in my notebook is ‘tutorial resources sharing (thread to share)’.  This is connected to a tutor’s forum that all TM354 tutors should have access to.  I think there should be a thread somewhere that is all about the sharing of both on-line and off-line (face to face) tutorial resources.

Permalink Add your comment
Share post

This blog might contain posts that are only visible to logged-in users, or where only logged-in users can comment. If you have an account on the system, please log in for full access.

Total visits to this blog: 1876460