GrTeam4

Property Power

Architecture Report

Version 1.0

Architecture Report / Version: 1.0
Architecture Report / Date: 02/11/2008
GrTeam4.ArchitectureReport.doc

Revision History

Date / Version / Description / Author
02/11/2008 / 0.1 / Initial document submission / Brian Roberts
02/11/2008 / 1.0 / Reviewed by QA / Angela Bedel

Table of Contents

1.Introduction

2.Model-View-Controller (MVC) Architectural Pattern

2.1Presentation Layer

2.2Business Logic Layer

2.3Data Access Layer

2.4Data Layer

3.Design Principles

Architecture Report

1.Introduction

GrTeam4 has chosen a layered architecture based on the Model-View-Controller (MVC) pattern for user interfaces. This application architecture will enable us to adhere to the design principles (Divide & Conquer, increase cohesion, reduce coupling, increase reuse, design for flexibility, and design for testability). The following outline discusses the distinct MVC layers from top to bottom for the Property Power Application. The classes are grouped into packages (and subsystems for the Business Logic Layer) that identify common functionality.

2.Model-View-Controller (MVC) Architectural Pattern

2.1Presentation Layer

This layer contains the objects dealing with the user interface. The boundary classes were separated into five distinct packages (Maintenance, Profiles, Administration, New Business, and Finance) that are based on similar type user forms.

  • Initially, potential clients (tenants and property owners) need to fill out an application form. The NewBusiness package represents the similar nature of the application process.
  • Once the applications are approved, further information about the clients needs to be gathered before services can be rendered. This is accomplished by the Profile Package which contains all boundary classes that require information about the clients and properties.
  • Managing maintenance requests is a major functional requirement of the system; therefore, the Maintenance Package contains the user interface classes pertaining to maintenance.
  • The Finance Package represents all boundary classes that have to deal with financial user interfaces.
  • The Admin Package groups all boundary classes that allow the client to have access to the appropriate areas of Property Power.

2.2Business Logic Layer

This layer contains the objects dealing with the application logic such as validation, business rules, and workflow. The controller classes from the Use Cases are located in this layer. Four distinct subsystems were defined in our architectural model (Client, Property, Finance, and System). The interface classes for the subsystems are labeled as manager classes. The Engine controller encapsulates a specific volatile activity that provides the service as directed by the Manager class.

  • The Client Subsystem encapsulates the services provided about the client (tenants and property owners), which is grouped into a tenant package, property package, and clientscreening package.
  • The Property Subsystem contains the control classes that pertain to handling property functionality. This subsystem contains two packages that handle different aspects of the property; (1) Property Package and (2) Maintenance Package.
  • The Finance Subsystem handles all control of invoicing and payment transactions.
  • All control classes that manage the user rights to Property Power are located in this System subsystem.

2.3Data Access Layer

This layer contains the objects that support the functionality of the application. The data is access from the layer below, manipulated, and sent back to the requesting object in the Business Logic Layer. Entity classes are found in this layer.

  • The individual data access classes only retrieve data that it is responsible for.
  • All data needed by the Business Logic Layer can be supplied by the six classes shown in the model.

2.4Data Layer

This layer contains the persistent data for the application such as the database. Five data repositories are defined (Client, Accounting, Property, System, and Maintenance).

3.Design Principles

The architecture, as laid-out in the MVC model, will allow us to adhere to the following design principles.

  • The division of each layer into their respective packages/subsystems will allow concurrent development of the system by various software engineering groups (Divide & Conquer).
  • The separation of the concerns (subsystem handlers) accommodates high functional cohesion.
  • With the separation of architectural layers into Presentation, Business Logic, Data Access, and Data gives us a system that presents high layer cohesion.
  • The dependencies are minimized with this architectural layout as a change in the TenantProfileEngine (in the Business Logic Layer) doesn’t require any other changes to the subsystem/system for example.
  • Flexibility of the system is enhanced because of the modular architecture set forth and the ability to abstract the higher levels in the design.
  • Increasing reuse and testability is accomplished by designing a modular architecture that supports high cohesion.

Confidential / GrTeam4, 2018 / Page 1