New version page

Layers

Upgrade to remove ads

This preview shows page 1-2-3-4-5-6 out of 17 pages.

Save
View Full Document
Premium Document
Do you want full access? Go Premium and unlock all 17 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 17 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 17 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 17 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 17 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 17 pages.
Access to all documents
Download any document
Ad free experience

Upgrade to remove ads
Unformatted text preview:

LayersTypical Layering ApproachLAYERSOn LayersSystem Partitioning (layering)Large-Scale Element CollaborationSlide 7Advice: Multi-Tier Layered ArchitecturesA Simple Logical ArchitectureAdvice: An Application Coordination Layer – another twist?Package Dependencies* (a very good slide w/dependencies)Ordering WorkSlide 13Slide 14Slide 15Slide 16Slide 17© Lethbridge/Laganière 2001Chapter 9: Architecting and designing software 1LayersData from IBM-Rational and Craig Larman…© Lethbridge/Laganière 2001Chapter 9: Architecting and designing software 2Typical Layering ApproachGeneral functionalitySpecific functionalityThe layering principles originally described for packages also apply to subsystemsBut this is a very broad generalization. in practice, things will be considerably different and application dependent in many cases.Note: this is a general view; may/may not include a GUI layer; may not have one; may include UI in with the application…..© Lethbridge/Laganière 2001Chapter 9: Architecting and designing software 3LAYERSIn reality, there may be several layers…and certain packages may use services of layers directly beneath them; some may not.Going ‘down’ one layer does not necessarily mean that this layer shields one layer from another.•Some packages in layers may need some domain services – beneath them. Thus, for those packages, there is a domain services layer beneath them.•Other packages in the same upper layer may need technical services layer beneath them. Thus, for these packages, dependencies are on layers beneath them but skipping an intervening layer – e.g. may NOT include the domain layer (above); rather go directly to a middleware component.Application specific has components unique to the application.Business specific (domain layer) may have reusable subsystems…Middleware layer may likely have the DBController, Transaction dispatcher, Broker (pattern), persistency mechanisms; security mechanisms, ….© Lethbridge/Laganière 2001Chapter 9: Architecting and designing software 4On LayersMany (not all) layered approaches have a Presentation Layer on top of the Application Layer IF that is appropriate to the type of application!!!! As usual: this is DESIGN – which means these are design choices. These choices represent decisions as to how BEST to accommodate the requirements for the specific type of application, be it an information systems application or a scientific application, process-control application, manufacturing application…these applications and requirements may legislate for a different kind of layered approach. But, let’s consider these…© Lethbridge/Laganière 2001Chapter 9: Architecting and designing software 5System Partitioning (layering)Note: different author’s terminology. While his terminology should be clear in its context, if confusing, PLEASE ASK.The logical view of the architecture emphasizes large-scale elements (LSEs):•Layers, subsystems, modules, frameworks.Before considering detailed object design, which is often referred to as subsystem design, it is recommended to start with a draft design partitioning the system into LSEs.•1. The elements•2. Their interfaces •3. The inter-element collaborationsNote: this author uses LSEs for layers, subsystems, …Important to get used to different terminology….© Lethbridge/Laganière 2001Chapter 9: Architecting and designing software 6Large-Scale Element CollaborationIt is Good Thing to achieve early clarification of the interfaces of LSEs, and their collaborations.•Of course, mutable in the spirit of iterative development.•This effort helps to partition parallel design and implementation by workers.—“Stubs” can be defined for incomplete LSEs.Define the operations and parameters in detail.*Be mindful of coupling and cohesion.Avoid coupling into the internals of an LSE, or across several LSEs.* No algorithms, data structures here, please. Merely ‘cite’ the operations, parameters in general, returned types…© Lethbridge/Laganière 2001Chapter 9: Architecting and designing software 7Large-Scale Element Collaboration It is a common experience to “reasonably” design the static partitioning into LSEs without “too much” trouble or error, during early design. However, the early design of the LSE interfaces and collaborations (dynamics) is usually quite speculative, and unstable.•These will change. •They will become more detailed and correct during the detailed object design of individual LSEs; that is, our look at the details of each subsystem we identify.© Lethbridge/Laganière 2001Chapter 9: Architecting and designing software 8Advice: Multi-Tier Layered ArchitecturesSeparate presentation and application logic, and other areas of concern. ANOTHER ARCHITECTURE…Different names (in some cases). Can see the main idea!Discuss!UI Layer (or Presentation Layer)“Domain” or “Application Logic” LayerServices LayerPersistenceSubsystemLoggingSubsystemSecuritySubsystem(May/may not be graphical…)(May/may not need both…)© Lethbridge/Laganière 2001Chapter 9: Architecting and designing software 9UISummaries EditorsDomainCoreEval uationPoliciesServicesPersistence Logging ReportingSecurityA Simple Logical ArchitectureIn the UML, the logical partitioning is illustrated with package diagrams. The layers ‘might’ look like these….a design choice!Here, the User Interface is first.Some authors call this a Presentation Layer (makes sense…)These might be the only layers needed.© Lethbridge/Laganière 2001Chapter 9: Architecting and designing software 10Advice: An Application Coordination Layer – another twist?Consider an “application coordination layer” whose objects represent use cases. They may also hold session state.This is often (not always) a better design.UIS ummaries E ditorsAppCoordinationDomainCoreEva luationP olicie sRentingVideoUCHandlerPayingFinesUCHandlerThese look likeControl classes…© Lethbridge/Laganière 2001Chapter 9: Architecting and designing software 11Package Dependencies* (a very good slide w/dependencies)It is useful to show the coupling with UML dependency lines.Further, it is helpful to cite the purpose of each subsystem / package to show how these design elements cohere.UIMajorFunctionsEditorsAppCoordinationD omainC oreEvaluationPoliciesS ervicesP ersistence LoggingDiscuss the dependencies!!© Lethbridge/Laganière 2001Chapter 9: Architecting and designing


Download Layers
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Layers and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Layers 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?