Software Architecture is the structure, or structures, of the system that comprise of software components, the externally visible properties of the components, and the relationships among them.

Architecture is not operational software, rather it is representative to allow you to see how effective your design is and consider alternatives.

It focuses on components. It may be as simple as a Class or as complicated at a middle-ware components, databases, etc that can be configured and managed.

Why is architecture important?

  • Software architecture provides a representation that facilitates communication among all stakeholders.
  • The architecture highlights early design decisions that will have a profound impact on all software engineering work that follows.
  • Architecture “constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together” [Bas03].

Reasons for Software Architecture was originally found on Access 2 Learn

Assistant Professor

Walter Wimberly is an Assistant Professor at a regional college in Tennessee, teaching Computer Science in the Software Engineering track. He works as a student advisor, oversees curriculum changes, develops new courses, and manages the advisory panel.
Walter taught full time for about 7 years, before going back into “industry” as a full stack Software Developer for a dozen years. There he focused on web based projects coding in JavaScript/jQuery and utilizing the Bootstrap CSS Framework on the front-end, and coding in PHP, ASP/ASP.Net, SQL on the back-end.

Since he loves teaching, he taught as an adjunct web and digital media classes for eight (8) years, while working in industry, and has since returned to teaching full time.

He has been married for over 25 years, and is father to several special needs boys. As such, he is working on some projects to help others who have special needs to be self-sufficient, and support the care givers of those with special needs. Check out his Autism blog for more info.

Similar Posts

Conducting Component-Level Design

ByWalter Wimberly

Step 1. Identify all design classes that correspond to the problem domain. Step 2. Identify all design classes that correspond to the infrastructure domain. Step 3. Elaborate all design classes that are not acquired as reusable components. Elaboration requires that all interfaces, attributes, and operations necessary to implement the class be described in detail. Design…

Prescriptive Process Models

ByWalter Wimberly

Prescriptive Process Models strive for structure and order in software development. They tend to occur sequentially with defined guidelines, however they may not be the most effective for changing systems. Waterfall The waterfall method, sometimes called the classic life cycle, is one of the best known prescriptive process models. Each step move you forward and…

Requirements Analysis

ByWalter Wimberly

Chapter 9 will focus on scenario bases modeling. Throughout analysis modeling, your focus should be on what, not how. While everything may not be known, we can approach this in an iterative method refining the model until everything is uncovered. The requirements model should have 3 primary objectives: Elements of an analysis modeling: Requirements Analysis…

Component Level Design

ByWalter Wimberly

Component-level design occurs after the first iteration of architectural design has been completed. At this stage, the overall data and program structure of the software has been established. A component is defined in UML as: “a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.” However, different…

Process Assessment and Improvement

ByWalter Wimberly

The existence of a process is no guarantee that the software will be delivered on time, meet the needs of the customer, or be of long-term quality. Process patterns must be coupled with Software Engineering practice (Part 2 of the textbook) There are several methods to assess software: Standard CMMI Assessment Method for Process Improvement…