The "Basic" STAGES

STAGE 1: Requirements

1. Requirements Analysis

2. Identify Business Objects --see design!

3. Diagram/Prototype GUI
   

STAGE 2: Design -- when no specific architecture to your system is indicated partition using the popular "Presentation-Busines-Data" 3 Layer Architecture

• presentation layer involves the interface,

• business layer has the main logic, computations, calculations of the application, sometimes called "business logic layer" or "domain logic layer"

• data layer involves the storage of data, this can be in files, databases or other forms of storage.

  Partial Example - Login App:
  

  
  
  

• Benefits of 3-layer Architecture Design:     

  • modularity - by have multiple layers you can have different code bases for each

  • speed of development - different people/teams can work on different layers (or parts of the layers) and the speed of development will increase

  • availability - depending on options at your company and the "kind of application" you are developing (i.e. mobile app versus web versus desktop,etc.) you may be able to move your 3 layered architecture into a 3 tiered architecutre and deploy each layer on different machines and have them be in essence separate sub-system that "talk to each other". You may even have multiple instances in each layer, and if one goes down the others are still available.

  • scalability - you can improve scalability because how you scale can be different for each layer allowing for more optimal scalability. Like mentioned in availability for some kinds of applications you can deploy each layer to different machines/systems which may have multiple instances --hence scaling. Think about the CLOUD and services for automatic scaling.

  • performance - by having multiple layers you can improve the performance of one layer independent potentially of other layers. Ways of improving performance (increased speed and reduced storage/memory) are many and can be different for each type of layer. Sometimes techniques like distributed computing, parallell computing, asynchronous communication, special techniques for caching (faster than normal storage retrieval) and many special ways to serve data faster (distributed data services) ----are used to improve performance.

    
    Partitioning into 3 (or more) layers like the traditional Presentation-Business-Data layers is a step towards achieving these benefits
    
    
    ------ CAUTION Is 3-layered the same as 3-tiered??????????
    
    In web and mobile systems, we talk about 3 Tiered Architecture and there we have the different layers running on totally different physical systems. Simply organizing your code into 3 different layers and running in the same program is not the same as creating a 3 tiered "system" architecture. However, it is a step towards this and the other steps necessary require more domain specific knowledge (like database or web or distributed systems or cloud or XXX).
    

    >>>>> VIDEO discussing difference between 3 layered architecture for a program and a 3 tiered system architecture.
    

     

STAGE 3: Implementation + STAGE 4:Document &Deploy- as normal

Think Object Oriented

Build hierarchies of classes.

Abstract the essence of related classes by identifying where they have common responsibilities -- where they do the same thing, but do it differently -- same "what", different "how".

Look for opportunities for the classes to use polymorphism to implement the same responsibility differently.

The new parent classes may be abstract classes. That is, no actual objects may ever exist of that type. The abstract class exists to link together similar concrete types of objects.

 

ATM example: Create an abstract class Transaction that is a superclass for Withdrawal, Deposit, etc. It can have an abstract responsibility "execute a financial transaction", that is implemented differently for each subclass.

Hierarchy Identification Tips

1. Explore is-a ("kind-of") relationships.

ATM example: Withdrawal is a (kind of) Transaction. Withdrawal is not "part of" Transaction.

2. Name key abstractions.

3. Place super/subclass sets in hierarchies.

4. Look for reusable behaviors

reuse existing patterns and frameworks

record new patterns and frameworks for reuse within project or in future