UML in A Sequence of Learning Events

Lately, I’ve been having trouble with UML Sequence Diagrams. So, I decided to do further research to better understand the subject.

Due to learning about it in class, I have some prior knowledge about the subject. First, there’s the actor which is usually represented by a stick figure. The actor essentially acts as a user stand in. The rest of the classes are participants. Think of them as a path the actor has to walk across. The diagram shows the path that the code takes when the user executes the code.

I used this article for reference: Sequence Diagrams – Unified Modeling Language (UML) – GeeksforGeeks

It’s a beginner’s guide to UML sequence diagrams. It defines an UML sequence diagram and all vocabulary associated with it. It then informs how to one and the pros and cons of using one.

The first thing I started to better grasp was lifelines. I used to think lifelines were the solid lines but they depict an individual participant. Lifelines represent each instance in a sequence diagram. They are displayed in rectangles and go by their name and type. They are similar to actors but portrays objects internal to the system.

I also learned more about the messages. I knew that solid lines output messages and dashed lines returned them. I didn’t know that a solid line and a dotted represent synchronous messages and a single dotted line represent asynchronous ones. Synchronous messages wait for a reply before the interaction can move forward. Imagine if to people were moving boxes to a truck. Person A hands a box to Person B who puts it the truck. Person A must wait until Person B signals that they are done with their task. On the other hand, asynchronous messages don’t need to wait for a reply so Person A would just hand Person B the box without waiting for a signal.

So, to summarize what I learned. the diagrams are just a different way to demonstrate the code. It’s a communication tool between developers, managers, stakeholders, project managers and clients. It’s like a blueprint that anyone can look over. Clients can look over the plans without getting confused and make edits if necessary. Developers can take the blueprint and convert it into actual code. UML diagrams contain an actor that takes the role of a user engaging with the code. The participants represent the rest of the classes. The vertical rectangles represent the duration of a class’s execution. The arrows, not participants as previously mentioned, represent the path the code takes. Think about everything as components of a map.

Overall, this further research deepened my understanding of UML sequence diagrams. I feel like this would help me with the homework assignment but unfortunately it didn’t answer all my questions.

From the blog CS@Worcester – My Journey through Comp Sci by Joanna Presume and used with permission of the author. All other rights reserved by the author.

It’s An AI Problem

AI has grown to become one of the most useful and powerful tools in the world of technology. To the point where even schools and universities are taking advantage of it and implementing AI into their curriculum, with restrictions of course. Although artificial intelligence continues to evolve, it is not what it’s cracked up to be. Reports have shown that generative AI has been having issues in quality production. It is a hurdle that puts great limits on itself according to Harvard Business Review.

According to their article “Addressing Gen AI’s Quality-Control Problem”, AI has had issues with their output. This type of technology has tendencies of creating problems like making things up, leaving certain answers out and producing limitless possibilities, making difficulties of finding efficient solutions. While companies have found different alternatives to address this matter, it has become very expensive to do. 

By bringing this topic to the forefront, we get to see the reality of how AI isn’t always the solution in terms of finding the answers to different situations. This is why I personally chose this to begin with. A vast majority of this current generation uses this tool on a daily basis, but we don’t truly understand the efficiency of it. Especially in the workplace, where problem solving is crucial. 

Amazon, for instance, uses Catalog AI as a better approach to avoid quality issues. It detects and blocks unreliable data, produce ideas for new product pages, run tests and uses feedback as a method to keep improving. The upside of this is while various organizations struggle to recieve positive results from gen AI, specifically a financial investment return, eight percent of Amazon’s suggestions recieved positive impact from sale revenue, considering it “measurable value”. 

Reviewing this information, it didn’t quite surprise me that different groups of people are using alternative methods to get results like this. Even just in using AI myself, if I notice that I’m not getting accurate answers from one AI assistant, then I turn to others like Microsoft Copilot, ChatGPT, Google AI, etc. It’s also useful for when you want to see different outputs and compare them to each other. The point of performing all these tests is to test the effectiveness of this tool.

This especially applies to companies, who use very similar process to see if their methods work. Going back to Amazon, eighty percent of their outputted data was very unreliable. After going back and reviewing the progress and performance, they were able to make vast improvements. Now approaching to hopefully start in the computer science work field very soon, I pretty much know the do’s and don’ts of using gen AI. And having a process to heighten company data.

Article Source: Addressing Gen AI’s Quality-Control Problem

From the blog CS@Worcester – theJCBlog by Jancarlos Ferreira and used with permission of the author. All other rights reserved by the author.

Blog 1 Version Control

 Version Control in Software Process Management 

I am Dipesh Bhatta, and I am writing this blog entry for CS-348 Software Process Management for Blog Quarter 1. I chose to write about version control and how it is applied in software process management. My chosen resource is an article entitled “What is Version Control?” by Atlassian’s Git tutorials ( https://www.atlassian.com/git/tutorials/what-is-version-control ). This passage explains what version control is, why software projects require it, and how developers use it in practice. 

The passage defines version control as a process that records file changes over time. It allows several people to work on the same project simultaneously without losing work or overwriting each other’s work. Another important advantage is that version control has a complete history of the project, and developers can go back to an earlier version or reverse mistakes when necessary. The article also explains how the older systems, like the centralized ones such as Subversion (SVN), differ from newer distributed systems such as Git. Git has risen to be the most widely used version control system because it offers each developer a full copy of the project; thus, it is reliable and flexible. Apart from this, the article captures the workflows like branching, merging, and pull requests, which make collaboration safer and more structured. 

I used this resource because version control is associated with managing the software process, the subject of CS-348. The course is all about managing software development in an organized fashion, and version control is one of the most important tools used to facilitate this process. I also wanted to understand the reason why version control is crucial and not just how to use it, since understanding its purpose makes me aware of its application in professional software development. 

This article made me realize version control is not just saving code—it is a process of keeping collaboration and advancement. Without it, projects quickly become unmanageable, and you can’t even know who did what to the code. The explanation of Git branches was most helpful because it mirrors what we do in CS-348. Branches allow developers to experiment with new functionality without affecting the original codebase, and this is a clear demonstration of process management in action. 

The article also got me to think about my own working habits. Writing good commitment messages, responsible use of branches, and adherence to a process-based workflow are all habits that enhance collaboration and project quality. These habits will benefit me in group projects from now on and later in professional work. 

In short, version control is an essential part of software process management. It facilitates collaboration, organization, and accountability—all major themes in CS-348. By performing these routines throughout Blog Quarter 1, I am creating technical skills as well as professional routines that will benefit me throughout my career. 

From the blog CS@Worcester – dipeshbhattaprofile by Dipesh Bhatta and used with permission of the author. All other rights reserved by the author.

Using Github Codespaces in Class

Github in the classroom

While I have used github before in previous projects, this semester I have begun to dig deeper into it’s uses. Codespaces is one such use, and is an important tool to learn and use properly. While we have gone over github codespaces and git command line use in class, sometimes looking around online can help streamline the experience. Github themselves post their own blogs relating to their site’s recourses, and codespaces is no exception.

10 things you didn’t know you could do with GitHub Codespaces

This github blog details all of the various uses of their codespaces, and offers good suggestions, background, and description of both what it is, and why you should be using it. Mostly, this blog details the features that are both useful but not often utilized, as well as details why these features are helpful tools.

I chose to talk about this blog post (with my blog post, haha) because this is a tool that I personally have used, but didn’t really know too much about. I was told to use it in class for x y and z, but never really thought about how valuable it actually is. I only have experience with VS code and other Microsoft IDEs, but it’s cool to know that codespaces supports much more than just that one IDE. as well as this, I think it is extremely convenient to have access to a workspace without setting up everything locally, and am excited to try to learn how it better utilize this feature, as I realized that this feature has directly impacted my class experience; The professor only needed to give us a repository, and we were ready to work on our assignment, with no setup or install hassle!

Another feature of that I am now excited to try is live sharing. Live sharing allows you and other people to work in the same code file at the same time, similar to having multiple people in one google doc. It even shows where their cursor is and everything! I think this feature could significantly improve the group project experience, as previous years I’ve been frustrated with how annoying it is to work on the same code together with my group.

Lastly, codespaces allows you to easily manage all of your working areas, and makes file management easier to, well, manage! In my previous classes, I’ve found the most difficulty in the storage and file layout of my projects, which impacts how/if it runs at all on my local device. Being able to manage this and keep everything more separated with codespaces should, in my opinion, help with these troubles.

This concludes my mandatory blog post of Quarter 1 for the semester.

Till the next one,

— Will Crosby

From the blog CS@Worcester – ELITE Computer Science by William Crosby and used with permission of the author. All other rights reserved by the author.

Blog 1 – How to manage and improve software processing.

Improving your software processing is crucial, especially when working on a group project, managing time pressure, and leading a team, among other responsibilities. Here is a great resource that I found invaluable for beginners and interns. “https://axify.io/blog/software-process-improvement“

According to Pierre Gilbert, a software delivery expert, he highlighted the “7 steps” to implement software process improvement, or SPI. I will break down those steps to get a better understanding.

Step 1: Make the problem visible – Use historical data to show where delays, defects, process inefficiencies are happening

Step 2: Get the Team’s Buy in – Don’t just impose changes. Use data to show why improvements are needed so your team member see the value.

Step 3: Track essential metrics – Use DORA metrics + value stream mapping to find bottlenecks

However, this step still gets me confusing, so feel free to checkout the link to have a better understanding.

Step 4: See where improvements would be most effective – Prioritize high-impact areas rather than trying to change everything at once.

Step 5: Make a plan – Clear responsibilities; tools; define which existing processes are targeted; pilot projects before roll-out; ensure feedback loops.

Step 6: Implement the plan – Execute carefully; monitor; allow for adjustment; don’t force changes that slow things down without justification; use continuous feedback.

Step 7: Adjust as needed – SPI is never “done” – measure progress via KPIs, adapt if cultural or resource issues arise, keep refining.

After reading those steps, I can’t imagine the environment of software engineering is not as simple as I thought. Understanding the steps could help me preparing of what’s coming next.

Before improving SPI, we need to understand the common challenges people usually face when it comes to working on project.

Time pressure – in high-pressure environments, it’s easy to prioritize delivery over process improvement.

Poor management or lack of ownership – improvements can be fragmented without clear responsibility

Team maturity – less mature teams may struggle with discipline & consistent adoption.

Overall, reading this could help you get ahead of what’s upcoming in the software engineering environment. For further information, check out the link above.

#CS-348, #SPI

From the blog CS@Worcester – Nguyen Technique by Nguyen Vuong and used with permission of the author. All other rights reserved by the author.

GitHub workflow vulnerabilities

https://github.blog/security/vulnerability-research/how-to-catch-github-actions-workflow-injections-before-attackers-do/ , https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project

Today I want to talk about a blog post I found on GitHub own blog site that details the proper measures to protect repositories against malicious action injections to further protect our repositories and properly enforce standards to safe guard our intellectual property and information.

But first I want to go into detail about what the consequences of a action injection are and what this attack does and how this attack works. The main goal of the attack is for the attacker to have a command ran through one of the workflows in in the repository. This can be done by the attacker creating a branch or issue and this being ran and through this it is executed through a run portion of the workflow. So if you have a automation for when someone creates a issue, the bad actor can put a piece of malicious code in the title and because this title is ran through the workflow and executed which can give a bad actor permissions that they shouldn’t have under normal circumstances, this can even get to the point of them approving their own pull requests.

So the question remains is how to stop this? The answer is environment variables which allows the inputted data like the title of the issue to become untrusted and prevent the run in the workflow being ran with the malicious code. Using the proper standards like environment variables for API’s and other pieces of information is crucial as well to maintain proper change control standards. If these standards aren’t followed this can desecrate the integrity of the repo itself since if a malicious change goes unnoticed early on in development this can lead to the branches later one and other contributors repos and branches becoming compromised as well.

I chose this blog post due to my own internship mainly using automated systems for workflows and we have our own GitHub workflow that documents change control requests for the reason we can see when a push that might compromise information or other systems will be made. Furthermore we can reverse these changes and have workflows that try to detect attacks similar to this where a title through machine learning is detected. This is also important to understand in the class when working with a public repositories where these attacks might be botted to be more educated on when to properly test branches and the proper use of environment variables in a project to further protect the repo.

From the blog CS@Worcester – Aidan's Cybersection by Aidan Novia and used with permission of the author. All other rights reserved by the author.

Understanding GitHub

Quarter One Blog

The video I watched is a basic tutorial for GitHub. Corbin, the creator, explains that GitHub is essential for version control and organization, and how important it is when your code becomes more complex. He starts off by explaining what a repository is and how to make one in GitHub. Then, he shows one of his repositories for a project with a working program. He says if he wants to start making changes and adding to the code, he would create a branch to prevent the code from breaking and save a lot of time if he needed to backtrack and fix it. He shows how to make a branch, as well. He provides the basics for what we went over in class and in GitKit chapters and explains how to do it in a slightly different way than what was said in class. I chose this video because I find it useful when I have multiple ways to explain a topic and I can understand it better.

The process for creating a repository is not something that we went in depth on in class, so having Corbin explain how to go through that process was helpful. He touches on what the difference between public and private repositories are. In class and in FOSS applications, they would all be public repositories, but if you were just using GitHub to put your private code in the cloud and for your own version control, a private repository would be more useful.

Corbin provides a visual and explanation for what branches and forks do, but it is not as clear as what was shown in class. Having the different explanations of both is helpful for a deeper understanding. He goes over having a completed branch, how to merge it back to main, and explains what the version control deletions and additions look like. 

Outside of the Software Process Management class, understanding GitHub is super useful in the real world. Other classes, like the Software Development Capstone, will require the understanding of GitHub to complete the final project. A lot of companies use Git for version control and collaboration, and look for those skills on applicants’ resumes. I feel confident and comfortable that I can navigate and use GitHub in my life going forward. 

Last year, I took Software Testing before understanding Git. While I was able to figure it out and get through the class, having the knowledge I do now with the actual process and reasonings of it, I feel like I would’ve spent less time troubleshooting silly issues.

From the blog CS@Worcester – ALIDA NORDQUIST by alidanordquist and used with permission of the author. All other rights reserved by the author.

DESIGN PATTERNS

Software Design Patterns 101: A Beginner’s Guide, a Medium essay, introduces readers to software design patterns and discusses how they help create systems that are effective, scalable, and manageable. According to the article, design patterns are reusable templates that help programmers produce cleaner, more structured code by resolving common programming problems. The three primary types of design patterns, structural, behavioral, and creational are explained. Object generation is the main emphasis of creational patterns like Factory Method and Singleton. Adapter and Composite are two examples of structural patterns that explain how classes and objects can be merged to create more expansive, adaptable systems. Observer and Strategy are two behavioral patterns that emphasize direct communication and responsibility delegation. Teams can create a common language by employing these patterns, which enhances cooperation and lowers misunderstandings.

I chose this article because it clearly relates to the concepts of object-oriented design and code organization that we have been studying in class. In a recent exercise, for instance, we examined a Duck class hierarchy dilemma in which some subclasses, such as RubberDuck and DecoyDuck, were compelled to inherit unnecessary methods, such quack() and fly(). Because of this design, we had to override methods with “do nothing” implementations because these ducks either didn’t fly or quack. My understanding of why this is a typical example of a design issue that can be fixed using patterns like the Strategy Pattern, Which is under the behavioral category covered in the reading. 

I came to understand how inheritance, although helpful, may become problematic when it compels subclasses to adopt behavior that isn’t appropriate for them through the article and our class discussion. Depending on the type of duck, the quack() and fly() methods in the Duck superclass in our example have different actions. We may dynamically assign these behaviors to various ducks at runtime by classifying them into distinct classes, such as FlyBehavior and QuackBehavior. This method reduced superfluous overrides and increased the design’s adaptability. Here, the Strategy Pattern was essential since it let us alter a duck’s behavior without explicitly changing its class.The way that design patterns like Strategy prioritize composition over inheritance struck resonated with me. By mixing smaller, reusable components instead of depending only on strict class hierarchies, this idea promotes the development of systems. In the Duck example, we can simply construct new behavior classes and mix them in as needed, rather than adding extra subclasses each time a new type of duck is created. I intend to incorporate these ideas into my upcoming work. For instance, I could use behavior classes for activities like jumping, running, and attacking if I were creating a game with many character kinds. This would eliminate the need to rewrite significant portions of code in order to add new characters or change current ones.

From the blog CS@Worcester – A Bostonians Blogs by Abdulhafeedh Sotunbo and used with permission of the author. All other rights reserved by the author.

Understanding Git Collaboration: Communities, Upstreaming, and Merge Conflicts

Hello everyone! Welcome back to my blog posts. Today I would be delivering my first Quarter blog post.

For this week’s blog, I decided to read “Git Forks and Upstreams: How-to and a cool tip” from Atlassian Git Tutorials. I picked this article because it connects directly with what we’ve been practicing in class—working locally, pushing changes upstream, staying synchronized, and handling merge conflicts. I also wanted a guide that explained the actual Git commands rather than just high-level concepts, since I’ve been moving away from relying only on graphical interfaces.

Summary of the Resource

The article explains the difference between origin (your fork) and upstream (the original repository you forked from). It walks through how to set up your fork so you can keep it synchronized with the upstream repo, which is especially important when multiple people are contributing. Commands like git remote add upstream <url>, git fetch upstream, and git merge upstream/main are introduced step by step. The tutorial also shares a useful tip for checking how many commits your branch is ahead or behind the upstream, which makes it easier to stay in sync.

Why I Chose This Resource

I chose this article because it fills a gap in my own Git knowledge. Until recently, I mainly used the graphical interface on the side to commit, push, and sync my changes. That worked for basic assignments, but I often felt like I didn’t really understand what was happening behind the scenes. This tutorial helped me connect the dots by showing me the exact commands and explaining why they matter, especially in collaborative projects.

Reflection and Takeaways

This resource helped me see Git as more than just a tool for saving code. it’s really about teamwork. Understanding how to add and pull from upstream makes me feel much more prepared to collaborate on group projects or open-source contributions. I no longer see merge conflicts as something to fear, but as a natural part of multiple people working on the same code.

One big realization for me was how important it is to stay synchronized with upstream. In one project I did before, I once ignored updates for too long, and the merge that followed was messy and stressful. Now I understand that frequent git fetch upstream and git merge calls prevent bigger problems down the road.

Another personal shift was moving away from the GUI. While the interface made Git feel easier at first, I see now that the terminal gives me more power and clarity. Running git status, git log, or checking how far ahead/behind my branch is compared to upstream makes me feel more in control. It’s like going from driving an automatic car to learning manual, I finally understand how things actually work under the hood.

Looking ahead, I know these lessons will help me not only in this class but also in internships and my future career. Whether I’m working on an open-source project or contributing to a company’s codebase, being comfortable with upstream workflows and conflict resolution will make me a stronger and more reliable teammate.

Citation / Link

From the blog CS@Worcester – Rick’s Software Journal by RickDjouwe1 and used with permission of the author. All other rights reserved by the author.

Understanding Git: The Key to Safe Team Collaboration

In class we are learning about Git. Git is a version control system that allows multiple developers to make changes to a program and still control the commits if needed. The reason why I think this is because there will be times where developers make a mistake and cause a whole list of issues but with git they can go back to the previous commit and fix it there. This allows developers to be able to work on major projects without causing the main program to break. 

Another important aspect we need to consider is that it allows larger teams to be able to work on the same program at once. Which can save the company time and money. We also need to consider how developers from all over the world could help with open source projects without working on a fork of the repository so that they can make changes locally and not impact the upstream of the project. 

In my perspective git divides upstream, clone, local, online repo, branch so developers are able to make these changes safely and there can be people to double check their work. That is what organizations can have reviewers and maintainers trying to review changes so that the upstream does not break. In addition, it allows developers to be able to know when changes are made and what type of scale a change it is. When a company’s upstream goes down it can cause the company to lose a lot of money and reputation with clients and the public. 

From the blog CS@Worcester – Site Title by Ben Santos and used with permission of the author. All other rights reserved by the author.