Home on SWE 2410: Software Design

SWE 2410 Coding Standard

Mon, 01 Jan 0001 00:00:00 +0000

SWE 2410 Coding Standard

In addition to correctness, solutions will be graded for style and design. Additional detail is given below, but here are the key points:

Use meaningful names for identifiers except those with very limited scope (such as the parameter for a one-line function).
Format your programs consistently and nicely, including judicious use of spaces and blank lines. Keep line lengths to about 100 characters.
Ensure your files contain no hard tabs.
Include your name (prominently) in all source code files you edit. Note this does not include .fxml and similar files.
Document the responsiblities of the classes you write. For example, // Track owner, tenant, and number of apartment class Apartment { ... } // Record both available and unavailable apartments in a building class Building { Apartment[] available_apartments, open_apartments ... } // Track current floor and call destinations of the elevator // as well as its maintenance history class Elevator { ... } In general, the goal is to provide enough documentation that another person can understand the modules in your solution, without providing documentation that is blatently obvious from examining the code.
Follow standard design principles including small subroutines, minimal repeated code, and tightly scoped identifiers.
Use appropriate exception processing.
Fix your code so it builds without compilation warnings. Use only standard, documented libraries distributed with Java and JavaFX.
Use lower case for repository, file, and other names unless a tool (such as javac!) mandates a different convention.
Do not check build products into repositories, including third-party libraries.
Do not print extra output such as debugging output.
Do not include large amounts of dead code - code that has been commented out or otherwise disabled.
Do not introduce constructs that break abstractions: instanceof, package visibility, getters and setters for lots of data

Additional detail:

SWE 2410 Syllabus, Hasker

Mon, 01 Jan 0001 00:00:00 +0000

Instructor: Rob Hasker (414-277-7326)

Drop-in times (office hours): See my home page: https://faculty-web.msoe.edu/hasker/

Textbook:

Design Patterns Explained: A New Perspective on Object-Oriented Design, 2nd Ed., Shalloway and Trott, Addison-Wesley, 2005. ISBN: 978-0-321-24714-8

Optional reference:

Weekly Outcomes

Mon, 01 Jan 0001 00:00:00 +0000

Weekly, detailed outcomes for SWE 2410. See the course notes for additional detail. Week numbers are provided, but many topics will be the week before or a week later.

The overall structure of the course, with Bloom’s Taxonomic level in parentheses:

UML Standards

Mon, 01 Jan 0001 00:00:00 +0000

All Diagrams

This section gives the general requirements; requirements for specific types of diagrams are below.

Use CamelCase for class names, meaning use upper-case letters for the first word and all following words, lower case for all other letters. The exceptions would be class names in some libraries (for example, the C++ STL) and standard abbreviations (such as MSOE).
Avoid non-standard abbreviations. “App” is fine, but most other abbreviations are not. They make code hard to maintain because other developers have to remember which abbreviations you prefer. For the same reason, avoid spelling errors, especially for words within names.
All classes should be associated with at least one other class.
Avoid redundancy. For example, if class A relates to B and B relates to C, there is rarely any need for A to relate directly to C. As another example, avoid showing a relationship to another class and listing an instance of that class in the box. The relationship implies the instance.
Avoid the aggregation symbol (open diamond) on associations. Many people believe there is a strong distinction between this and other associations, but in fact the UML standard gives no meaning to this notation.
Avoid the uses symbol (dashed arrow) on associations. These are temporary associations related to a particular implementation of a method, and of limited value to understanding the structure of a system. They often capture a particular implementation, nothing They make a diagram hard to read without adding value.

In general, be careful on how you use UML notation. UML is very carefully designed to convey key information without unnecessary redundancy. Non-standard notation adds confusion, defeating the purposes of drawing diagrams in the first place. This is especially important in the core notation: using open triangles for generalization, open (v-shaped) arrows for direct association, solid lines for associations, etc. Learning to use the correct notation can be very important for interviews because it’s one way people sort out those who have learned basic software engineering concepts from those who have not.

Lab 2: Checkers and Strategies

Mon, 01 Jan 0001 00:00:00 +0000

As for many patterns, the Strategy Pattern improves cohesion by removing if statements in code. In this lab, you will refactor your Lab 1 solution to remove the if statements based on whether a piece is regular or a king. You may leave the if statements based on whether a piece is red or black, but if you prefer you can use the Strategy Pattern to remove those as well.

Enterprise Architect

Mon, 01 Jan 0001 00:00:00 +0000

Installing EA

Open Microsoft Store. Install Company Portal
Open Company Portal. Search for Enterprise Architect
Hit Install. Wait for the install to reach 100%. Wait a few more minutes for the reinstall button to appear, indicating the install is complete
Open Enterprise Architect by searching for it in the Start menu/search bar

Creating classes and relationships in EA

Creating a class diagram in EA

On the welcome screen, in the main window, below Open and Personal Project, click Create New. In the process, you choose where you will save it
In the Browser on the left, right-click Model. Select Add View. Keep the default option Create Diagram. Click the OK button. Keep the default option of a UML Structural Class diagram. Click the OK button
In the central pane of the document, above the great blanks space where you want to draw, right above where it says “Start Page” with a small blue logo, click on the » symbol to open the toolbox

Note that the little three boxes icon represents a diagram. As you create objects, they will sit beside the diagram, not in it. If you find yourself deleting extra stuff after trying the next few steps, be careful not to delete your diagram at the same time. If you do, you can recreate it by right-clicking on the view and selecting Add Diagram