This is meant to be a class more about structure than it is about coding.

This class seems to be similar to last year were we will be using Visual Paradigm and Visual Studio (Not visual studio code.).

Were will be working with package diagrams which are what were went over at the end at last years class.

The use of a ASCII chart will be handy. An ASCII chart or ASCII table will allow me to work with UN-familiar characters.

One of the key function of this class is to keep it timeless and focus on I.T. in a less geeky way. The reason for this is a lot of I.T. foundational skills have been around for a long time but a lot of technology will become out-dated quickly.

The class has two main assessments a test which takes place first and a practical assessment. The test consists on refactoring and design patterns, theses are the focus for the first few weeks of the term.

We went over class diagrams which are representations of classes in our code, the contain variables operators which correspond to aspects in our code. Class diagram were meant to be an international standard but some places will use different methods. Most text, even if they don’t use the class diagram model will talk in similar terms.

Dependencies are represented by a dashed line with an arrow on the end, the arrow represent the first classed utilities part of the other class.

A soild line means that one object owns a copy of the other object. If the arrow is missing it means IDK which is normally used when we are doing a raught draft, it can also mean that i is not important at this level. How we have it set in VP is that the lake of arrow it represent a multi-directional dependency, which is wrong in terms of diagramming. Multi directional relationship are bad as they increase coupling and slow down compiling.

* Means that a relationship can have any number of a relationship.

In case of a circular relationship we can add an additional class which makes the codes more complex but resolves the circular issue.

Inheritance uses a full arrow which allow for a class to a modified version of another class. This allows us to both reuse code, work with different types of the same class and modified classes without breaking the code.

A package diagram breaks up the program into different domains

• Problem Domain(model)
• UI
• DATA Management
• Utilities