What did we learn about the process of design in this course/project?
During our work on this project, we learned how important the communication with the shareholders is. Through interviews we learned about the requirements the different shareholders set and, almost as important, what they wished for. The requirements and wishes set by the different shareholders might overlap, so that is where our creativity for the design would have to come in. We also learned to extract the absolute necessities for the project from the interviews, which reduced the number of requirements, but also made the design more concrete.
An interview that was particularly interesting was the one with the administrator. She mentioned a lot of things that we had overlooked and that other stakeholders had overlooked. There were 2 key points that we overlooked. First, current systems are in place because they are secure. Grades are sensitive data that must be protected from hackers. Sure, we can have a lot of fancy features, but if the grades are not secure there’s no point. And second, Banner stores so much more than just grades. Banner is like your whole academic history, our project can’t replace that, but it could work together with it. The interview showed how important it is to choose your stakeholders, if chosen incorrectly, you can miss key requirements of your system.
Our use cases and ER diagram:
Here we have provided a video explaining the project:
As you might have read in our first post about this subject, team WordPressers has started on building ‘an interactive grading platform that is friendlier towards teachers and students than the current grading platforms.’ This time we continue therewith. First we focus on our own development during the interviews. Secondly we will discuss our updated use cases and our brand new ER diagram.
What did we learn about the project with these interviews?
By conducting these interviews we learned that there is more to consider than we thought at first. Our roles have up until now been limited to student, which did not provide us with a full view on the requirements through the eyes of the other actors. For example, an administrator reminded us of the importance of digital security, which is perhaps less a number one priority in the mind of a student or a teacher. Overall however, I think our first use case remains strong and doesn’t require large structural changes. We did get a more detailed image of the specific actor requirements which we already anticipated.
What did we learn about the process of interviewing?
We learned a few things about the process of interviewing. One of the most important things is to think well before the interview on what questions to ask. In other words, you need to know what you need to know. During the interview it is of course possible to ask for clarifying or broadening questions, but making sure that the essential information will be obtained is the number one priority. This prevents having to ask the questions later, or having to guess, which is worse. Another thing is that the answers from the people with the same role within the system had more overlap than the the answers from the people with a different role. This might indicate some necessities for each actor in the use cases and it is very important to get details at least about those basics in an interview, meaning it is good to ask on or more specific questions based on the actor role someone is in.
How did we change for the other interviews?
We think we prepared ourselves better for the other interviews. At the beginning we weren’t 100% clear on what question to ask and what answer to expect, but as long as we went through the project, our overview became clearer. It allowed us to better lead the interview, knowing where we wanted to go and understanding better what we were talking about.
If we did another interview now, what would we change about the process?
Globally, we would say that our interview process was quite successful as we gathered all the information we need. Nevertheless, I think we could have been more efficient, especially at the beginning, if we would arrive with all the questions to ask already written down. It hasn’t been a big problem here as the interviews were short enough, but for more complex and long interview it could have threatened our time management and the consistency of the interview process.
What do our use cases look like now?
Not much has changed since the last use case diagram, except that a new one has been added. After the interview with Angélica Ibarra, we learned of the reasons why Banner is used. We concluded that it might not be plausible for our project to replace Banner, or at least that’s how it is at the moment. Banner is just very secure. It has many security measures against hackers, back up of grades every few minutes and, most important of them all, Banner is so much more than just grades, it is your academic history and stores many types of data. It would be more plausible if our system is used by teachers, replacing what they use right now (Schoology, Classroom, or, in some cases, just an Excel file). After having the grades, the administrator can pass them to Banner.
We included our database ER diagram.
For the ER diagram, first, we have the general user and 4 types of users that inherit from it. Each type has different id, except for parent, since it uses the id of his/her child. The general user can check the grades because every user should be able to do so. Teachers can leave comments, create assignments and grade assignments. Students can check assignments and upload them. Parents can only check grades. The administrator can also only check grades, since she needs to upload them to Banner, and Banner is not part of this project.
Welcome back. It is time for another reflection post, which means, you guessed it, it includes the mandatory picture of a reflection. Here it is:
To start on this reflection, I scrolled all the way back to my first post of September 11th 2019. In ‘Permanent life cycles‘ I asked you and myself a few questions:
How do you plan writing code?
And what do you plan?
So let’s see if we can now answer these better than in my first post. In my first post I was talking about planning the life of the software project. The focus was on the project as a whole.
“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”
I read about these 7 steps, but I hadn’t really delved into them yet to fully understand what set them apart. When I delved into step 1 and 2 in the first part of this course (read my first reflection here), it opened the world of planning, use cases and requirements.
What I have learned since then is the design and implementation aspect of this cycle. In the design step I first heard of design patterns. They are templates of how to solve common problems. This saves time which can be dedicated to solving the more exotic problems.
After that I wrote about UML, which gave me much more insight on it than what I had in the first part of the course. The many possibilities of design became clear. And that was not all. Finally we could link the requirements of the project straight into the design. By showing the actors and their functions into the code by using, for example, a class diagram the structure of the whole project becomes more clear. It gives a picture of the program. This is a giant leap from, and using our preparations in step 1 and 2.
Now we are in the next phase. The implementation or coding was the step where I thought I would learn the least, since I had already coded before. It turned out it was there where I learned the most. The actual coding which I had been doing was only half of it. The other half was converting classes into tables, and converting that into code. The most important thing is getting the tables right here, the code will follow that lead strongly. Only in the tables to code translation is creativity required. There is always more than one way in coding.
I hope to learn more about the last 3 steps of the project life cycle in the coming weeks. With every step, I understand our grading system using WordPress project more, and I become more and more eager to start a project on my own.
Show your mastery of the taking design models to language specific code. How does language choice affect your process here? Can you bring an object-oriented design to a “non object-oriented” language?
So in the last topic you read, and hopefully liked, my explanation of how to convert classes to tables. Now we are going to check whether good diagrams make good code (they do).
The conversion from classes to code is not that hard, provided your language fits the project and the design model.
A short hint: don’t waste your time. Just use an object-oriented language if you did object-oriented design.
Another hint: KNOW YOUR PROGRAMMING LANGUAGE. It will save you a lot of time if you already understand the functions you might be using.
Here I found and easy example. It shows how to translate the c++ code from the class diagram:
That’s it! Provided your programming language fits your design and has all the functions you need, your code should flow onto your screen. Done! Just kidding, we will continue for a while.
It is time to take another step on our journey from designing and planning to coding. Today we are going to talk about the conversion from class diagrams to database tables.
In a previous post, about UML diagrams, I explained Class diagrams briefly. To quote myself:
“Class diagrams show the classes of the system (of course), their operations and attributes and the interrelations between these classes.”
There are many different methods of converting classes to tables. However today I will explain it using the ER-method. ER stands for Entity-Relationship. It is a model which can be implemented in a database, so into tables and their attributes, typically a relational database. Today we will only discuss relational databases, since they are easier than non-relational ones.
Using the ER-model we can get a graphical view of components of the project (enterprise) and how they are related. How the ER-model is displayed:
The relationships between the entities are the lines and diamonds between the rectangles. 1, M and N stand for the cardinality between the entities, or the number of the entity involved. The word in the diamond is always a verb which specifies the relationship. One faculty can teach multiple classes for example.
Now we have completed this ER-diagram it is time to convert it into tables. If you like a video-explanation, watch this. But here are the steps:
Convert all the entity sets to tables
Deal with composite and multi-value attributes by making them individual attributes
We, as team WordPressers, have started on a project called ‘Grading system using WordPress’. We want to build an interactive grading platform that is friendlier towards teachers and students than the current grading platforms. The problem now is that students and teachers sometimes use up to five different grading systems. We want to unify that into one grading platform, while taking into account the wishes of all the stakeholders.
Who are the stakeholders?
Parents
Students:
MiTec: Stephanie Pulido
Canvas: Abe Hendriks
Blackboard: Abe Hendriks
Teachers:
Visiocolle: Celine Laurent
Canvas: Simon Wittkamp
Administrators:
Banner: Angélica María Ibarra Aoki
These are our use cases so far:
These are most likely going to be modified after taking the interviews with the various stakeholders.
Let’s continue. You were reading about the reasons to use UML, as well as some of the important diagrams. Here are some more:
State diagrams visualise the behaviour of the system. They shows how objects and classes react to events and what events causes those reactions. A state diagram is a dynamic representation, so it portrays the various changes, of the elements of the system.
Package diagrams visualise the different packages and their interrelations, also called dependencies. A package itself can contain all different elements from UML, including other packages. The purpose is to group them and give them a namespace. The package diagram gives an overview of these packages.
Component diagrams show the division of the system into components, and their interconnections. Each component forms one or multiple classes. As pointed out on tallyfy.com, component diagrams enable for a simplified top-level view of a more complex system. This makes for documentation easier.
Did you grasp an understanding of the practical use of these diagrams? Then it is time to talk about GRASP:
General Responsibility Assignment Software Patterns
This is in my opinion the unmissable step between designing and coding. GRASP helps to think about the responsibilities of the objects in the system. Responsibilities are obligations to perform a task or know information. When these are known, they help create a flexible, coherent system. GRASP contains 9 responsibility patterns:
1. Information Expert 2. Creator 3. Controller 4. Low Coupling 5. High Cohesion 6. Indirection 7. Polymorphism 8. Pure Fabrication 9. Protected Variations
MVC stands for Model View Controller, the picture under this sentence explains it well.
But just in case, let’s explain it a bit more. Here is a good article about it, which I will summarise. Model stands for the representation of information or data that you want to display to user. View is all the front end code via which the system is presented in front of the user, and how the user interacts with the system. Controller acts as the interface between the Model and View. It contains all the logic (read: code) of your system.
It looks quite simple to use, and it partly is, because it is systematic. That also makes it a good platform for a scaling of the project. On the other hand, it is only simple to use if you are familiar with the project. So get familiar with it, because it is being widely used more and more!
As promised, this and the next post are fully dedicated to UML. We will find out why we use UML, as well as what the different major diagrams are useful for.
“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.”
UML itself is a modelling language for object-oriented analysis of a project. It is designed to be broadly applicable, which, next to the amount of users, explains the abundance of tools for UML.
So why are there so many users of UML? Well, to start and actually finish a project, you need some planning. As Deborah Kurata stated in 1998, a professional application must:
This makes a project a lot more robust, while keeping an eye on the requirements. Using UML means designing and planning your project. The pros of this approach are overwhelming, and this is why UML is so widely used.
A UML diagram is used to visually represent a system, with its main components. This can be used well to document, understand and maintain information about the system.
A picture says a thousand words, but a diagram says a million.
Sequence diagrams arranges the interactions between objects in time sequence. To put it differently: It shows in what order what interacts with what. Geeksforgeeks made a simple example:
Class diagrams show the classes of the system (of course), their operations and attributes and the interrelations between these classes. Here is an example:
Object diagrams depict objects of classes. These diagrams can be used to check whether the attributes- and class structures make sense.
I will answer the title question at the end of this post. Exciting!
Let’s start with another three questions and three answers:
What is software? A program which instructs the computer how to operate.
What is design? A plan of how something is built or what it’s specifications are.
What are patterns? Something whose elements repeat predictably.
Did you see the pattern in the last paragraph? Neat. Now let’s combine these words into software design patterns, whose definition is a combination of ‘software design’ and ‘patterns’. It represents repeatable solutions to common problems in object-oriented software development. This prevents programmers from having to re-invent the digital wheel. At least that is the idea. Not to be copied and pasted, but to give an idea, a template, of how to solve the problem.
The concept of patterns was first written about in 1977 by Christopher Alexander. The patterns in his articles were on architectural design! Software designers realised later that there are many similarities, listed here, between architecture and software design. The book Design patterns by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides from 1995 is the basic book for everyone who wants to learn software design patterns. After this book, the patterns became widely used in software design.
There are a few important software design patterns:
Singleton: If an application only needs one instance of an object, this pattern is useful. It works so that a class only has one instance. It makes sure that there is a global point of access to it. Singleton is one of the most important patterns.
Model-View-Controller: This design pattern was created initially for Smalltalk.
Proxy: This one is easier to understand, since it has a physical analogy. Credit cards are proxies for what is in your bank account. It is, as you could call it, a handle to your money.
To end, the answer to the question in the title is yes! Even though it didn’t have much to do with software, the pattern is still nice in my opinion.
All my posts up until now have been partly investigations, partly lessons and partly yes, reflections. Why? Well, as you already expected all these subjects that I have been writing about are actually useful. In your program planning, in your development career and maybe even in some other part of your life. At least that is the potential I see.
Even though this is only my eight week in the course Analysis and Modeling of Software Systems, I have noticed my progress in terms of an extra perspective on software. Not what the software is, but how the software came to be. Asking about this reveals the other dimension of the software, the actual project. Thinking about software not as a static product but as a project, just like the construction of a building, enables improving the software by planning ahead. The programmers are on the construction site, but you can’t just hand them some bricks and tell them to build something with 3 bedrooms. There is a lot more involved. Planners are the architects, consulting the stakeholders about their requirements for the project. They define the actors and then determine an outlay of the building meeting the requirements and the functions for the actors. Then they consult the engineers (the modelling language) to determine a more specific plan of the project.
As far as we are concerned the analogy stops here, but the point is clear. Every project needs planning, even the small one-person projects. For example, have you ever seen a shed that was built without any planning or design? It doesn’t look like this:
It looks more like this:
Every programmer has creative solutions to problems and for requirements that the stakeholders have. They don’t just flow into code. Planning a project using modelling languages with a list of use cases to achieve the goal, defining the necessary interactions, enables the programmer and everyone else to visualise the next step. The step from idea to action. The use cases are also useful for visualising the possibilities in the actual code. A diagram using for example UML states the requirements for the program clearly. It doesn’t state how the requirements are met, making the creative thinking still possible. For me this has been a big improvement in my view on projects.
Until the next topic! Improved UML understanding for you, and hopefully improved blog writing for me to come.
Zeger has a blog 