4+1 View Models of Software Architecture 25 Years Later

25 years ago Philippe Krutchen published an article in the IEEE Software magazine describing a different way to interpret and communicate software architecture. He used complex systems like air traffic control systems and phone systems in his example because those were the big, complex systems that needed this understanding at that time.

For some context, in 1995…

Netscape introduced JavaScript.
Netscape Navigator completely dominated the web browser market.
Microsoft launched Internet Explorer 1.
Microsoft released Windows 95. Most people were using Win 3.1 or 3.11 at the time.
Sun announced Java.
Linus Torvalds released version 1.2.0 of the Linux kernel (a.k.a. Linux 95).

Today, thanks to cloud computing and the internet any system can be a complex system and it’s import that we find good ways to understand and communicate our systems.

Why care about the 4+1 view model of software architecture?

It is hard to design and it is hard to describe many computer programmer-y things because they are more than just physical things. Many of the most difficult things to learn and to design are just abstract things that can be understood differently by different people.

We will consider an example using 3 programmers. We have Skylar who is new to programming, Bailey who is a little more experienced then Skylar and Nika who has the most experience. Nika never goes by Nik and these 3 people characters are in no way representative of people who I may know or be.

Skylar’s understanding of a Concept looks like a circle and Skylar is having a really tough time understanding and using the Concept. Skylar goes to Bailey for help. Bailey’s understanding of the Concept comes from a completely different approach but it’s definitely the same concept that Skylar is struggling with.

Bailey understands the concept as a rectangle and tells Skylar to consider the corners when using the Concept. This does not help Skylar at all because circles do not have corners and Skylar’s understanding of the Concept is a circle. They go a few rounds, getting more agitated and annoyed until Nika notices and joins the conversation.

Nika knows the concept very well and listens to both of the other developers describe their understanding and problems with the Concept. Then Nika tells Bailey and Skylar that both of their understandings are correct but their inability to see the Concept from each other’s point of view is what is making things difficult because the Concept is obviously represented as a cylinder that appears as a rectangle from one view and as a circle from another view.

Having a bit more of an understanding of the Concept, Bailey is intrigued by the idea that the rectangle is actually a cylinder and feels appreciation for Nika’s insight. However Skylar was barely confident in the circle representation and confused by the rectangle conversation and now Skylar’s brain has exploded because Skylar didn’t even have half a clue that the Concept could be 3D.

What does this have to do with the “4+1” View Model of Software Architecture? Being able to understand a thing one way is the sign of a good developer. Being able to understand a thing from more than one point of view is a sign of a good mid/senior developer. Being able to understand and describe a thing from multiple views is an ability held by senior developers in leadership positions.

Most systems that we build and maintain are much more complex than a cylinder and require much thinking to design, describe, build and maintain.

What is the 4+1 View Model of Software Architecture?

It is a way of thinking that is based on the use of multiple, concurrent views to address the separate concerns of various stakeholders of the architecture. It’s finding a way to look at the cylinder as a rectangle and as a circle but still understanding that the thing we’re looking at is a cylinder. One of the things that makes this still relevant is that the views are designed using a scenario driven, iterative process just like the current popular agile thinking.

The 4+1 views are the Logical View, the Process View, the Development View, the Physical View and the Scenarios.

Logical View (“What Do?”, “What Data?”)

The Logical View is solely concerned with the rules, or logic, of the system.

In object-oriented thinking this is represented by class diagrams and class templates. In data-driven systems this can also be represented by entity-relationship diagrams. This is our domain knowledge and interactions. This is the view we use when describing what our system does.

Process View (“How Do?”)

The Process View is solely concerned with the way things will happen in the system and is informed by the Logical View.

This view considers performance and availability. It deals with different “processes” and handles independent tasks. This is the view that most people think of when they think of Software Architecture.

Development View (“How Make?”)

The Development View is concerned with the way things will be built and maintained and is informed by the Logical View.

This is the view that is most comfortable with many web developers and project managers. This is 3 layered “architecture” of Presentation, Business and Data layers. This is DDD and TDD and BDD. This is branching strategies and Agile and scrum and project management and version control and CI/CD and all the other various thoughts and ideas that come with making software because making software is difficult.

Physical View (“Where Do?”)

The Physical View is concerned with the physical aspects of the system and is informed by both the Development View and the Process View.

This is all the computer and internet things that make up a system. This is servers and switches and ports and networks. For systems hosted in “the cloud” this is various cloud services that act like physical things.

Scenarios (Use cases)

The elements in the four views are shown to work together seamlessly by the use of a small set of important scenarios. Scenarios serve two main purposes:

As a driver to discover the architectural elements during the architecture.
As a validation and illustration role after the architecture design is complete.

These are the use cases for our MVPs and the use cases of our UX and DX designs. They allow us to consider the four other views when thinking through a scenario. I’d argue that this is the most important part of this model and it should be called the 1+4 View Model of Software Architecture.

Ways to use the 4+1 View Model of Software Architecture

Knowing things is one thing, knowing how to use the things we know is a whole other thing. So now that we know about the 4+1 View Model of Software Architecture, what can we do with it?

Better communication with stakeholders

Thanks to common terminology and different contexts, it’s easy to use the same words and talk completely past each other. Knowing about these views allows us to align our views with the stakeholders to talk about the same thing at the same time.

Better clarity in design

There is a lot to consider when designing a system and while we need to consider everything from memory usage to project management to network latency to user experience and it’s difficult to plan, communicate and consider all these things.

So don’t do that. Thinking of our designs in relation to these views allows us to slightly simplify our thinking when considering the design of a system.

Better understanding of systems and processes

The same complexities in design also exist when attempting to understand a system. Mixing concerns from differing views may result in lots of confusion. It’s difficult to understand everything about a system. By considering the different view models we can concentrate on understand a system from a certain view then work to understand how things from different views relate to each other.

Better combat of impostor syndrome

It is VERY difficult to understand systems by considering every view all the time. It is also VERY difficult to change our view of a system when we are taught to look at a system from one specific view.

It is more likely that we will not need to understand our systems from every view and that we will find that we enjoy and are stronger at relating to our systems from certain views. We should consider these strengths when we attempt to consider systems from different views.

Someone who is good at looking at systems while considering the Hardware View may not be good at looking at a system while considering the Logical View.

When we find ourselves looking at system from a different point of view, have confidence in our strengths in one view while acknowledging our weaknesses in the other view. This gives us a way to appreciate all the things we know while acknowledging all the things we don’t know without judgement.

Lessons I Learned My First Year As A Software Developer That Have Very Little To Do With Coding

December 4th marked my one year anniversary as a software engineer/developer/programmer/coder and after a year I have learned a few things. One of those things is that job titles mean very little, especially in a startup but I’m getting ahead of myself. So here are some of the non-technical lessons I have learned about being a developer in the past year in no particular order.

Being a software developer means being constantly overwhelmed but productive in spite of it

https://workingwomenoffaith.com/a-word-for-the-overwhelmed/

About 2 weeks into my job I had a bad day. Well I had a lot of bad days in my first year but this day I complained about it and the advice I got was that consistently succeeding at this job is hard. It’s true! Technology is constantly changing. Business logic is fuzzy and evolving. Algorithms are hard to track and predict how they’ll interact with other code.

It’s overwhelming. It’s more whelms than anyone can handle every day and it doesn’t get any better which is comforting in a weird way. Hearing that experienced developers struggle is a reminder that programming is hard regardless of how much experience we have.

Programmers are constantly being told we’re wrong. It’s a big part of our jobs and that’s OK

https://www.stilldrinking.org/programming-sucks

The afternoon of my first Friday at my new job I got a message from my lead developer, Nicholas. It was something along the lines of “We need to talk about a mistake in your code on Monday” and I started to worry. “What is he going to say? How will I deal with this criticism? He’s going to tell me I’m wrong!!” Then I started to panic a little. Then I thought about what I had been doing all week. Then I chuckled at myself.

When I run my code that doesn’t work correctly, my compiler tells me I’m wrong. When my code works, but not the way I intended, the results tell me I’m wrong. This happens multiple times a day. I am told constantly that I’m wrong by my computer so why should it be any different when the criticism comes from a person? Being able to take criticisms at face value is a good skill to have in this career. We are wrong and we are wrong a lot. And that’s ok. It’s just part of the job.

Questions are just questions

http://chasetechconsultants.com/featured/do-you-have-any-questions-for-me-what-to-ask-your-interviewer-intelligent-inquiries-to-stand-out-end-of-interview/

One big thing about working in a team is that other people are required to read and understand the code that you write. At Infinicept, this is the primary reason behind pull requests. I had never worked on a team before so initially I got very defensive when another developer would ask me why I did something a certain way and I would assume that I did the thing wrong and that they were passive aggressively letting me know that I was dumb. This is a lot to assume from someone asking a simple question.

Engineers like solving problems and we like finding different ways to solve the same problems. The kind of engineers I work with (and like to work with) like to help each other do this. This should be assumed to be the reason for questions until proven otherwise.

Equal parts pride and humility are required for this career

Being new to professional software development, my humility was unbound. No one was more humble than I was (that’s my favorite humility joke)! For months, my impostor syndrome was a huge part of how I saw myself even though I was aware that impostor syndrome makes no sense especially when I had the job and I was helping to hire more developers and I was contributing code and it was working. Too much humility makes you miserable.

As I took on more tasks, I found that I had to have a certain amount of pride to start the new task. I had to tell myself “I can do this thing I’ve never done” or “I can learn this thing I didn’t know existed til just now” or “This new idea is worth trying even though I came up with it.” We need to be proud of our work and our ideas to write code! However we can all picture working with someone with too much pride. That one person who doesn’t accept feedback and listen because they know all the things? I don’t want to be that person.

Being a software developer requires being proud of your ideas and your work and being accepting and proud of others’ ideas and work!

It’s VERY important to take care of yourself!

https://astepaheadfoundation.tumblr.com/post/163187257644/its-so-important-to-take-care-of-yourself-do

In March I started to feel like I should be more competent. I had been a professional coder for 4 WHOLE MONTHS. Instead of feeling accomplished, I felt stressed that I should be able to do more. Our company was delivering our first real big-deal deliverable to an important client at the end of the month and my daughter was struggling with a strange issue with her elbow that was very painful and required surgery. All employees were working 10+ hour days and weekends. Oh, and I was finishing up my last Computer Science courses for my degree.

For the whole month I didn’t go to the gym once and survived almost solely on caffeine and alcohol. Then at the end of the month, after I had served in the Marine Corps and spent 12 years as a 9-1-1 dispatcher, I had my first real anxiety attack. I never want to do that again. My coworkers, managers and founders never want to have a month like that again. So we all resolved to take better care of ourselves and each other as people.

We do not do good work when we are too tired and/or too stressed. This is why it’s important to take care of our mind and body. Also it just makes the job and life more enjoyable!

Programming knowledge is not linear

https://stackoverflow.blog/2017/02/07/what-programming-languages-weekends/

Working for a brand new startup meant that I got the opportunity to help hire more developers which meant I got to talk with a few developers who had more experience and it makes sense that someone with 5 years of experience as a programmer would have 5 years more knowledge about programming. It turns out this is not true.

First of all, “experience” is a very vague term. Two years of being pigeonholed in doing small repetitive tasks is way different than spending two years building and designing new things. You can have two years of experience or you can have one year of experience twice and it’s hard to tell at a glance what kind of experience someone has.

Then there’s the ever changing world of languages and frameworks. Did you know all the things about JavaScript four years ago but haven’t used it since? Did you switch from a back-end role to a dev-ops role? What knowledge did you or can you retain from the work you did 3 jobs ago?

It is impossible to assume that another programmer knows more or less about a specific technology just by looking at their years of experience.

You’re going to encounter bad code

https://heartbeat.fritz.ai/how-great-data-scientists-can-stop-writing-bad-code-9b054eb62b75

Learning to code involves starting from “Project -> New” and all the code you write is very small in scope, structured properly and efficiently and checked by someone who knows better. Then that project is quickly discarded for another project that highlights another concept.

Writing code as a professional developer involves working on the nth iteration of a code-base using libraries, tools and concepts that may or may not work well together. At first the code won’t make sense because you’re new to all this but sometimes code won’t make sense because it goes against best practices or just doesn’t work and no one really noticed yet.

It’s VERY hard to tell the difference between the two starting out but I found it very liberating to find out that some of the code I didn’t understand was code that didn’t make sense.

It’s also very important to consider why the bad code happened. There are tons of reasons other than “This person is teh stupidz!” for bad code. It’s important to have empathy for that prior developer because that prior developer is going to be you one day.

These are just a few of the things I’ve learned in my first year as a software developer. I look forward to all the things I get to learn in the next year!

Denver Startup Week 2018 Review

Want to write easy content for your blog? Take one subject and write 4 blog posts about that one subject. Want to squeeze one more blog out of that onion of an idea? Take that idea and those 4 blog posts and put them all into one post to make it easier for people to find all the posts related to that one idea.

In this case, that one idea is the 2018 Denver Startup Week which was my first startup week. It was fun and felt like a good use of my time. Want to know more about my 2018 Denver Startup Week experience? Check out the posts here:

A Guideline for Unit Testing After Development: Only Test Your Code

In a perfect world, specifications are clear and concise. Developers take those clear and concise specifications to write unit tests before writing the code that does the work. Then it’s red -> green -> refactor -> Bob’s your uncle you have good code!

In the real world, you could end up writing tests after the code has been written for whatever reason. After doing this poorly recently, I’ve come up with some of my own guidelines for unit testing:

If you’re doing too much setup, you’re testing the wrong thing: The first sign of too much setup is that you’re hooking your test code up to outside services. Do not test outside services in unit tests. Someone else already unit tested that service. You don’t have to do it.
Find the code that does the work, put it in its own method if needed and test that method: You’re testing code that likely was not written with testing in mind. Code that uses another library or service may be intertwined in the logic of the code you’re writing. Separate the unique logic that you (or the original developer) wrote into its own method then you only have to worry about testing that method.
If the method you’re testing must use an outside resource, abstract the outside resource into an interface: Let’s say the code your testing reads from a file or connects to an API or listens for an event. It’s impossible to test this code without that outside resource, but it’s also unwise to assume that the outside resource will always be available when the test is run. Abstract that outside resource into an interface. Then your implementation of that interface for your tests can point to a local resource that will always be there! Now your tests can run anywhere and your working code can still do its thing!

It all boils down to 2 main points. Make sure you are only testing your unique code and make sure the resources you need for testing will be always available no matter where your tests are running.

What are your tips for writing (or refactoring) code to make it easy and consistent to test?

Four Principles of Object-Oriented Programming with Examples in Java

I enjoy object-oriented programming. I understand the concepts, but I’ve found that when asked to define or show an example of the basic principles my brain blanks. This especially happens in pressure situations like interviews. So this post gets to act as my memory until the four principles of object-oriented programming (encapsulation, inheritance, polymorphism and abstraction).

Encapsulation

Encapsulation is the idea that the attributes of an entity are enclosed in that entity. This gives context to attributes. This also allows the programmer to restrict access to those attributes so that those attributes are modified and/or used only in ways that the programmer intends to use them.

Inheritance

Inheritance is the idea that an entity can inherit attributes from another entity. It allows the programmer to create similar entities without needing to redefine similar attributes over and over.

This means every Dog, Cat and Bird (subclasses) will have a name and age attributes as well as an Identify method because they are Animals (superclass).

Polymorphism

Polymorphism means “having many forms” which honestly doesn’t really help too much as a definition. I like to call it a way to have the same method, only different. There are two ways to do this:

Overloading: The method name stays the same, but the parameters, the return type and the number of parameters can all change.
Overriding: This is when a subclass method has the same name, parameters and return type as a method in a superclass but has a different implementation.

A few rules about method overriding in Java…
- Subclass methods should have the same return type and arguments
- The access level of the subclass method cannot be more restrictive than the superclass method.
- A method declared final or static cannot be overridden.
- If a method cannot be inherited, it cannot be overridden.

Abstraction

Abstraction is the process of hiding all but the relevant information about a thing to make things less complex and more efficient for the user. For example, we don’t need to know how a clock works in order to use it to tell time. Abstraction lets you focus on what the thing does instead of how it does it.

As much as I tried to keep thins post brief, I failed. If I got something wrong, or if something doesn’t make sense please reach out and let me know.

Here are a few of the resources I used:

Four Principles of Object-Oriented Programming with Examples in C#

Encapsulation

Inheritance

Inheritance is the idea that an entity can inherit attributes from another entity. It allows the programmer to create similar entities without needing to redefine similar attributes over and over.

This means every Dog, Cat and Bird (derived classes) will have a name and age variable as well as a Identify method because they are Animals (base class).

Polymorphism

Overloading: The method name stays the same, but the parameters, the return type and the number of parameters can all change.
Overriding: This is when a derived class method has the same name, parameters and return type as a method in a base class but has a different implementation.

Overriding can get a bit wonky depending on how you instantiate a object of a derived class. I suggest reading Knowing When to Use Override and New Keywords slowly.

Abstraction

As much as I tried to keep thins post brief, I failed. If I got something wrong, or if something doesn’t make sense please reach out and let me know.

Here are a few of the resources I used:

Design your own Entry-Level Developer – Which CS Electives Should I Choose?

Imagine that you knew someone who was going to graduate with their Computer Science Bachelor’s Degree in the spring of 2018 (*waves*). Now imagine you could help choose which Computer Science elective courses they chose (*waves and jumps*). What courses would you choose?

This fall I need to choose 2 Computer Science elective courses to complete my degree. I looked through the Regis University course catalog and found 18 electives that I could choose from. I was pretty excited at my choices. Since I only need 2 courses, I decided to narrow my choices down to 4 courses. I new there were likely going to be unavailable courses as well as changes to the Regis University course catalog. I chose:

Object-Oriented Programming using C++

Mobile and Enterprise Programming

Web and Database Programming

Enterprise Software Development

Then I emailed my advisor to see what was available. Reality and availability are cruel things. None of the courses I chose are available this fall. My options this fall are…

Computer Systems Security OR Database Management

THEN

UNIX Operating Systems OR Artificial Intelligence

Let’s take a look at how I feel about these courses to see if I can make up my mind…

Computer Systems Security

Everyone would like a security-minded entry-level developer, right? Having a background in the military and law enforcement I’m all for making sure the applications I create are secure. However that’s where my interest ends. I want to be a software developer, not an IT technician.

Database Management

I feel like I still remember much of what I learned about databases when I went to Westwood College. I like looking at the design of databases. This course would honestly be easier for me than the Computer Security course and I feel like I would get more out of it. OK, I convinced me. I’m signing up for this course.

UNIX Operating Systems

I have taught myself how to use UNIX at least 4 times in the past 15 years. I even used Ubuntu as my primary operating system for a while before my appetite for games and college courses convinced me to move back into the Windows universe so this would be a fairly easy course for me. This course is taught by the same instructor who taught one of my first CS courses at Regis so it would be nice to have my last CS course with her. However I think the best way to learn UNIX is the same way to learn any OS and that is by just using it consistently.

Artificial Intelligence

If you’ve paid attention at all to technology news in the past 5 years, artificial intelligence (AI) is one of the premier buzzwords being used. AI and machine learning are credited for systems like Alexa and Siri and chatbots and, of course, the imminent takeover of the world by robots. Do I want to be one of the people who is ultimately responsible for the rise of our robot overlords? Well when I put it like that, how can i say “no”? Seriously though, it sounds more challenging, and fun, than a UNIX course and the applications for AI are fun and constantly growing.

So after talking to myself, I’ve decided I’d like to take the Database Management and Artificial Intelligence courses. What do you think of my choices?

Go Code Colorado 2017 Kick-Off showcases the tech startup community

Wednesday, February 1st was the Kick-Off for the 2017 Go Code Colorado Challenge at Galvanize in Denver. I went because I might like the idea of participating again, but I mainly went because I like what the Go Code Colorado Challenge says about the Colorado technology community.

Before the kick-off event, Scott Yates hosted a panel of technology and entrepreneur advocates from around Colorado to talk about the Colorado technology community. The panel included Andrea Young, CEO of the Colorado Technology Association, Josh Hudnall, co-founder and co-director of LAUNCH West CO in Grand Junction, Jim Mackay, Cofounder of Scape in Durango, Jon Wilker, founder of Ignite Denver and 360Conferences in Denver, Aari Loftipour, CEO of Jalapeno Inventive in Fort Collins and Michelle Parvinrough, Executive Director of Peak Startup in Colorado Springs.

I will tell anyone repeatedly that if you are involved in Colorado tech startups you are part of a community more than you are part of an industry. It was great to hear this sentiment from the panel. Our supportive community is what makes people want to stay involved. The mountains and the craft beers and the “Colorado lifestyle” are great, but it’s the fact that those involved in the Colorado tech community enjoy working and working together that keeps us here. We’re still competitive, but we’re supportive.

The Go Code Colorado Challenge reflects this ideal. It’s definitely a competition. Each of the 3 finalist team gets $25,000 to keep their app idea going but, like the Colorado tech community, it’s not a cutthroat competition. It is a fun, challenging way to stretch your tech and entrepreneurial muscles and you get the chance to win $25,000 and all you have to do is show up.

About the 2017 Go Code Colorado Challenge

Challenge Statement: Build an app that uses public data to solve a problem for a business decision-maker.
How to participate:
What’s next? Challenge Weekend is April 7-9 hosted in Colorado Springs, Denver, Durango, Fort Collins and Grand Junction
Want more Information? Go to GoCode.co

Sphero SPRK Lightning Lab Cheat Sheet

If you, or your students, are like me and want to know every possible tool that can be used to program your Sphero SPRK with the Lightning Lab app, then you want to check out the printable Lightning Lab Cheat Sheet PDF in the link below. If you have any thoughts, ideas or questions please let me know.

Lightning Lab Cheat Sheet – PDF

(Re)learning Linux with Lynda and VirtualBox

Last week I had my first phone interview for a job in software development. It was for a DevOps position that required comfort with git, continuous integration, CentOS and the yum package manager. I was 2 for 4. I can use git. I am familiar with continuous integration but my Linux knowledge was admittedly rusty. In 2003 I ordered my laptop with Ubuntu as the OS so I had used Linux before but it has been a long time. I eventually had to switch the OS to Windows so I could complete my college schoolwork.

This meant I could not be considered for the job because the job requires the candidate to be able to navigate CentOS easily. So what does a motivated, internet-enabled self-learner do? I go learn about CentOS!

Resource List

My main computer is my Windows 10 laptop so I needed a few things in order to re-learn Linux…

Oracle VM VirtualBox – “I hear you like computers, so I put a computer in your computer.” This allowed me to have a Linux computer to work in without needing a separate physical computer.
CentOS operating system – I was able to easily download an ISO of CentOS and install it on my virtual machine.
Git Bash – This allowed me to treat my CentOS VM as if it was another computer on a network and connect to it via SSH.
Up and Running with CentOS – Lynda.com – I found a great tutorial on Lynda.com, so I signed up for their free 10 day trial. This tutorial was easy to follow even with rusty Linux knowledge. It helped me get familiar with the basics of CentOS, Linux, SSH, yum and vi.
(Optional Resource) Amazon Web Services – Pretending that my VM was actually on a network made things even more unnecessarily complicated sometimes so I learned how to set up an AWS instance with CentOS to complete the CentOS tutorial.

After I completed the CentOS tutorial, I felt OK with my CentOS knowledge but not comfortable enough so I needed more practice. Since I still have time in my free 10 day Lynda.com trial I decided to check out the Become a Programmer learning path to get more familiar with CentOS, Linux in general and vi specifically. The learning path explores simple programming concepts and gave me an opportunity to use vi. I found this great vi cheat sheet (PDF) and got to work.

Unnecessarily Complicated JavaScripting

The Becoming a Programmer learning path only requires an HTML file and a JavaScript file but I’m not doing this to learn JavaScript or basic programming, I’m doing this to learn how to use Linux and vi so here’s my setup:

I have Lynda.com up in my browser on my laptop (left side of screen). I have a VM running CentOS after I used the yum package manager to install the GNOME desktop (lower right corner of my screen). Then to make it more complicated I am using GIt Bash to connect to my VM using SSH so I can use vi as my editor for the tutorial (upper right corner or screen). All this just to type some simple JavaScript. Crazy!

My plan is to use vi in my CentOS virtual machine as my code editor for a while to get comfortable with it, then in about a month I will check to see if that DevOps position, or a similar position, is available. Wish me luck!

If you have any issues or ideas with the resources I shared, let me know. I would love to talk about them. Sometimes being an online-learner can be lonely.