This repository contains selected coursework and project artifacts from CS 230: Operating Platforms.
The course focused on software architecture, operating systems, Java development, memory and storage management, distributed systems, networking, security, and software design.
Throughout the course, I worked with a client scenario involving The Gaming Room and its game, Draw It or Lose It.
The main goal was to help The Gaming Room expand its application so it could support multiple operating platforms while remaining reliable, secure, scalable, and maintainable.
| Technology | Purpose |
|---|---|
| Java / OpenJDK | Object-oriented programming and application development |
| Eclipse IDE | Java development, testing, and debugging |
| Apache Maven | Java project and dependency management |
| Git | Local version control |
| GitHub | Repository hosting and portfolio management |
| Visual Studio Code | Repository management and Markdown editing |
| Linux | Recommended server operating platform |
| Microsoft Word | Technical documentation |
| macOS | Development environment |
| OpenSSH | Secure GitHub authentication and remote access |
The repository is organized by course module.
CS230-Program
│
├── Module-1
├── Module-2
├── Module-3
├── Module-4
├── Module-5
├── Module-6
├── Module-7
├── .gitignore
└── README.md
Module 1 introduced Java inheritance, object-oriented programming, and UML class diagrams.
The Java project demonstrates inheritance relationships between vehicles and two-wheeled vehicles.
Module-1
├── CS 230 Module One Assignment.docx
├── CS 230 Module One UML Class Diagram.png
└── src
└── com
└── three19
├── Bicycle.java
├── Driver.java
├── TwoWheeled.java
└── Vehicle.java
- Java programming
- Classes and objects
- Inheritance
- Object-oriented programming
- UML class diagrams
- Program structure
Module 2 introduced software design patterns and continued development of the Gaming Room application.
The project worked with the Singleton design pattern and several Java classes used to represent the game environment.
Module-2
├── CS 230 Module Two Assignment Software Design.docx
├── CS 230 Project One Milestone FIXME Text Version.docx
├── CS 230 Project One Milestone UML Diagram.png
└── src
└── com
└── gamingroom
├── Game.java
├── GameService.java
├── Player.java
├── ProgramDriver.java
├── SingletonTester.java
└── Team.java
- Singleton design pattern
- Object-oriented programming
- Java collections
- Software design
- UML modeling
- Class relationships
Module 3 expanded the Gaming Room application and improved its object-oriented design.
An Entity base class was introduced to provide shared functionality for several application objects.
Entity
├── Game
├── Team
└── Player
The Module 3 Java project contains:
Module-3
├── CS 230 Project One UML Diagram Text Version.docx
├── CS 230 Project Software Design.docx
└── src
└── com
└── gamingroom
├── Entity.java
├── Game.java
├── GameService.java
├── Player.java
├── ProgramDriver.java
├── SingletonTester.java
└── Team.java
- Inheritance
- Encapsulation
- Base classes
- Class relationships
- Singleton design
- Object management
- Software architecture
Module 4 introduced distributed application development using Java, Maven, Dropwizard, REST APIs, authentication, and authorization.
The gameauth project includes:
- HTTP Basic authentication
- User authentication
- Role-based authorization
- REST controllers
- Application health checks
- User data management
- Maven dependency management
- Application configuration
Module-4
├── CS 230 Module Four Journal.docx
├── CS230_Project_Software_Design.docx
└── gameauth
├── README.md
├── config.yml
├── pom.xml
└── src
└── main
├── java
│ └── com
│ └── gamingroom
│ └── gameauth
└── resources
└── banner.txt
One of the most important lessons from this module was that security should not exist only at the login screen.
Security checks should also exist inside the application so protected features cannot be accessed through an alternate path.
Module 5 focused on evaluating operating platforms for The Gaming Room.
Topics included:
- Linux server architecture
- Operating system security
- Operating system protection
- Client-server communication
- Cross-platform support
- Software scalability
- Application compatibility
Project Two focused on analyzing the needs of The Gaming Room and evaluating operating platforms for the Draw It or Lose It application.
The software design document discusses:
- Operating platforms
- Operating system architecture
- Client-server architecture
- Memory management
- Storage management
- Distributed systems
- Networking
- Application security
- Scalability
- Platform compatibility
The project helped demonstrate how client requirements influence operating system and software architecture decisions.
Module 6 focused on how operating systems manage memory and storage resources.
Topics included:
- Physical memory
- Virtual memory
- Storage requirements
- Persistent storage
- Image storage
- Memory allocation
- Application resource management
- Storage capacity planning
For the Gaming Room scenario, approximately 200 high-definition images at about 8 MB each would require approximately 1.6 GB of storage before accounting for backups, application data, or future growth.
Module 7 brought the major concepts from the course together into final software design recommendations for The Gaming Room.
The final recommendations included:
- Linux as the primary server platform
- Java application support
- Browser-based clients
- REST API communication
- SSD and cloud-based storage
- Virtual memory and resource management
- Distributed client-server architecture
- Load balancing
- Monitoring
- HTTPS and TLS
- Authentication
- Role-based authorization
- Least privilege
- Internal application permission checks
- Firewalls
- Software updates
- Backups
Project Three contains my final architecture recommendations for Draw It or Lose It.
The project required me to evaluate six major areas:
- Operating Platform
- Operating Systems Architectures
- Storage Management
- Memory Management
- Distributed Systems and Networks
- Security
My recommendation was to use Linux as the primary production server platform while allowing clients using Windows, macOS, Linux, Android, and iOS to communicate with the application through a browser-based REST architecture.
One of the most important lessons from CS 230 was that security should be designed into an application from the beginning.
Security should not exist only at the login screen or network boundary.
The application should also perform internal authorization and permission checks when users attempt to access protected functionality.
A layered security model can include:
User
│
▼
Authentication
│
▼
Authorization
│
▼
Role-Based Access Control
│
▼
Internal Permission Checks
│
▼
Application Resources
│
▼
Encrypted Communication
│
▼
Monitoring + Backups + Updates
This defense-in-depth approach provides stronger protection than depending on a single security control.
Important security concepts covered during the course included:
- Authentication
- Authorization
- Role-based access control
- Least privilege
- HTTPS
- TLS
- Internal permission checks
- Firewalls
- Software updates
- Monitoring
- Backups
The Gaming Room can use a client-server architecture similar to the following:
Windows Client ──────┐
macOS Client ────────┤
Linux Client ────────┤
Android Client ──────┤
iOS Client ──────────┤
▼
REST API
│
▼
Linux Server
│
┌──────────┼──────────┐
▼ ▼ ▼
Authentication Game Data Storage
Service Logic
This architecture allows multiple client platforms to communicate with the same centralized application server.
One of the biggest lessons I learned in CS 230 was that choosing an operating system affects many other parts of software design.
The server platform can affect:
- Performance
- Memory management
- File storage
- Networking
- Security
- Scalability
- Application compatibility
I also learned how Linux can be used as a server platform for Java applications and how a REST-based client-server design can allow Windows, macOS, Linux, Android, and iOS clients to communicate with the same server.
Another important lesson was security.
Security should be designed into an application from the beginning rather than added after development is complete.
Using several security controls together provides stronger protection than depending on only one security layer.
Skills demonstrated throughout the course include:
- Java programming
- Object-oriented programming
- Inheritance
- Encapsulation
- UML class diagrams
- Singleton design pattern
- Maven
- Dropwizard
- REST APIs
- Authentication
- Authorization
- Role-based access control
- Linux server concepts
- Operating system architecture
- Memory management
- Storage management
- Distributed systems
- Networking
- Application security
- Technical documentation
- Software design recommendations
- Git version control
- GitHub repository management
- SSH authentication
- Cloud computing
- Serverless computing
Java was used throughout the course for object-oriented programming, application development, REST services, and software design exercises.
Eclipse was used to create, edit, run, test, and debug Java projects.
Maven was used in the Module 4 gameauth project to manage dependencies and build the Java application.
Git is used to track changes throughout this repository.
GitHub is used to maintain the CS 230 portfolio and preserve the development history of the coursework.
Visual Studio Code is used for Git repository management, Markdown editing, file organization, and source code review.
Microsoft Word was used to prepare software design documents, journal assignments, and technical recommendations.
Linux was evaluated as the recommended production server platform for The Gaming Room application.
macOS was used as one of my primary development environments for Git, GitHub, Java, Eclipse, Visual Studio Code, and SSH.
SSH authentication is used to securely connect this development environment to GitHub without entering a GitHub password for every push.
This repository uses Git for local version control and GitHub for remote repository hosting.
A typical workflow used during this portfolio setup was:
git status
git add .
git commit -m "Commit message"
git push
The repository uses SSH authentication with GitHub.
Example GitHub SSH remote:
git@github.com:rpratts1/CS230-Program.git
Briefly summarize The Gaming Room client and their software requirements. Who was the client? What type of software did they want you to design?
The client for this project was The Gaming Room. The company had an existing Android game called Draw It or Lose It and wanted to expand the application so it could support additional operating platforms.
The game needed to support multiple games, teams, and players while making sure that each game, team, and player had a unique name. The Gaming Room also needed the application to be reliable, secure, scalable, and accessible from different types of devices.
My role was to help design a software solution that could support Windows, macOS, Linux, Android, and iOS clients while using a centralized server architecture.
One area I believe I did particularly well was connecting the client's software requirements to specific technical recommendations.
Instead of only describing different technologies, I explained how they could be used for Draw It or Lose It. For example, I recommended Linux as the main server platform because of its stability, security, Java support, and ability to scale.
I also connected the security recommendations to the work I completed in the Module 4 gameauth project. That included authentication, authorization, role-based access control, and the use of @RolesAllowed to protect application resources.
I also believe I did well explaining memory management, storage, networking, distributed systems, and security in relation to the actual needs of The Gaming Room.
What about the process of working through a design document did you find helpful when developing the code?
Working through the software design document helped me think about the entire application before focusing only on the Java code.
The design document made me consider questions such as:
- Which operating system should host the application?
- How will users communicate with the server?
- How will memory and storage be managed?
- How will the application scale?
- How will users be authenticated and authorized?
- How will the application remain secure?
This helped me better understand why classes, inheritance, design patterns, REST APIs, authentication, and authorization were being used in the programming assignments.
Instead of seeing each programming task as a separate assignment, I could see how the different parts worked together as one complete software system.
If you could choose one part of your work on these documents to revise, what would you pick? How would you improve it?
If I could revise one part of my work, I would add more specific technical details to the operating system architecture, storage management, memory management, and security sections.
For the Linux architecture section, I would add information about Linux using a monolithic kernel with loadable modules, the Completely Fair Scheduler, and its POSIX-based user environment.
For storage management, I would identify a specific Linux file system such as ext4 and explain how journaling, RAID, backups, and replication could improve reliability.
For memory management, I would add more information about demand paging, swap space, page cache, copy-on-write, and Linux out-of-memory management.
I would also strengthen the security section by discussing Linux-specific security controls such as SELinux or AppArmor, certificate management, input validation, and rate limiting.
These additions would make the recommendations more specific and provide more technical detail about how the Linux server would actually operate.
How did you interpret the user's needs and implement them into your software design? Why is it so important to consider the user's needs when designing?
I interpreted the client's needs by first identifying what the application needed to accomplish from the user's point of view.
The Gaming Room wanted Draw It or Lose It to support multiple games, teams, and players while preventing duplicate names. The company also wanted the application to work across several platforms instead of being limited to Android.
These requirements influenced the software design. The Java application used unique identifiers and checks to prevent duplicate games, teams, and players. I also recommended a REST-based client-server architecture so different client devices could communicate with the same centralized server.
Considering the user's needs is important because software should solve the client's actual problem. A technically advanced application is not useful if it does not meet the requirements of the people or organization that will use it.
Understanding user requirements also helps developers make better decisions about performance, security, compatibility, scalability, and usability.
How did you approach designing software? What techniques or strategies would you use in the future to analyze and design a similar software application?
My approach was to begin with the client's requirements and then break the application into smaller technical areas.
I looked at:
- Class structure
- Operating platform
- Memory management
- Storage management
- Networking
- Distributed systems
- Security
- Scalability
I examined each area separately and then considered how they would work together as one complete application.
I also used object-oriented programming concepts such as inheritance and encapsulation, the Singleton design pattern, UML class diagrams, REST APIs, authentication, and role-based security.
In the future, I would continue using a requirements-first approach. I would begin by identifying the business and user requirements, create diagrams of the system, determine the responsibilities of each component, evaluate possible platforms, and identify security and scalability requirements before development begins.
I would also compare traditional servers, cloud services, containers, and serverless technologies to determine which approach is best for each part of an application.
Instead of automatically choosing one technology for the entire system, I would consider a hybrid design when it could provide better performance, scalability, security, reliability, or cost control.
CS 230 changed the way I think about software development.
Before this course, I mainly focused on whether the code worked. I now understand that application development also involves operating systems, memory, storage, networking, security, scalability, and the environment where the application will run.
The Gaming Room project helped me understand how software requirements can be translated into a complete system architecture. It also showed me that there is not always one correct technology for every situation.
Traditional operating systems, cloud platforms, containers, and serverless computing all have strengths and limitations. I learned that good software design means selecting technologies based on the needs of each part of the application. Some workloads may work best on a traditional or cloud-hosted server, while event-driven tasks may be better suited for serverless computing.
I also learned that moving an application to the cloud does not remove the need for security, monitoring, or good software design. Developers still have responsibilities for areas such as authentication, authorization, data protection, and secure application configuration.
Going forward, I will use what I learned in CS 230 to think about software as a complete system instead of focusing only on the source code. I will also consider performance, security, scalability, cost, and the needs of the user when deciding which architecture is the best fit for an application.
CS 230 - Operating Platforms
Computer Programming Portfolio
