C C T B H P N

Lecture #3 - Software Architecture

More help with Projects

Synopsis:

Operational Concept Document and Projects #1 and #2:

Last time we discussed the notions of Software Architecture, the Operational Concept Document, packages and discussed a standard notation, UML, to be used throughout the course. We continue the discussion of the Operational Concept Document (OCD), used to document a system's architecture and provide some more help for Projects #1 and #2.

Lecture Content:

  1. The Syllabus describes topics to be covered, reading material for you to digest before coming to class, and due dates for the assigned projects.
  2. Help Session this Friday, Sept 7th at 9:00am in CST 4-201.
  3. Lecture and Help Videos
  4. Have you installed Visual Studio 2017? When you've installed VS2017 we will schedule a help session to demonstrate basic C# techniques.

  5. Help for Projects #1 and #2

    Thinking about and organizing Projects:

    More Help with Operational Concept Documents (OCDs)

    • Uses and Users:
      Project Center Use Cases, pptx
    • Organizing Principles:
      Software design, OO Design, OCD
    • Critical Issues:
      Project #2
      Toker invariant:
      • Each derived state enters getTok() with its char type at the beginning of the token source.
      • That happens because nextState() method returns the state matching the first chars in the source.
      • getTok() promises to remove only it's characters from the token source.
      • It ensures that by peeking into the token source before removing a character.
      • This requires a token source that can be peeked at least two characters deep without removing any of them.
      • Neither .Net nor C++ file streams support more that one character deep peeks, so we need to build a wrapper around them to provide this capability. That's what TokenFileSource does.
    • OCD Guide
      One major purpose of OCD preparation is to help you think critically about your architecture and top-level design

    Things to look at while you work on your OCD:

  6. Where are we?

    Structure:

    We've discussed software size and dependencies as motivation for studying architecture. So is defining a software architecture something that someone else does? Something that channels what we do as developers? No! Every time you develop a program you define an architecture, either consiously :-) or unconsiously :-(. That's determined by the way you build code in source files, the way you define classes and their relationships inside those files, the way you package the files as executables and dynamic link libraries. You can build an architecture that is:
    • Spaghetti:
      Stuff everything into one huge file with intricate dependencies like spaghetti in a bowl.
    • Baroque:
      So ornate and complicated that it is hard to understand how it functions.
    • Fragile:
      Uses no error handling, uses full path names welded to the development environment, attempts to open files without checking to see if they exist, uses fixed arrays to hold collected data so the storage is almost always used wastefully or insufficient causing exceptions to be thrown.
    • Well Crafted:
      • Avoids the defects listed above.
      • Has packages that are cohesive - do only one thing, but do it well - and are named to reflect their function.
      • Has an Executive that directs program flow without attempting to participate in processing.
      • Has a beginning, where processing inputs are gathered and stored, a middle where inputs are processed, and an end where data is converted to information for the user.
      You build a well crafted architecture by thinking about needs of users, the size and form of program inputs and outputs, deciding the tasks that are required, providing at least one package for each task, then building the task packages, avoiding spaghetti coding, using an editorial "red pencil" to simplify and remove baroque structure, and thinking about errors that could happen and how to avoid or handle them.

  7. Software Architecture:

    Review:

  8. C# versus C++

  9. C# Code Examples and Tutorials:

  10. Lecture Takeaway:

    The most important things we discussed today where: Next time we will be looking at C# code examples. Please look at these and bring printouts to class. Some of these examples are relevant to Project #2.
    • C# Demos
      Introduces classes, class relationships, generics, enumerable types, and extension methods.
    • C# Syntax Examples
      Demonstrates use of arrays, properties, indexers, simple reflection, and disposing.
    • Navigate Directory Trees
      Shows how to walk through a directory tree, using the services of the Directory and Path classes from the Framework Class Library (FCL).
    • Navigate with Delegates
      Shows how to make the Navigate module reusable by incorporating delegates.