08-Logical_Architecture

Views:
 
Category: Education
     
 

Presentation Description

logical architecture - ooad

Comments

Presentation Transcript

OBJECT ORIENTED ANALYSIS AND DESIGN:

OBJECT ORIENTED ANALYSIS AND DESIGN Lecture : Logical Architecture 1

Learning Outcomes:

Learning Outcomes Logical Architecture and Layers What is the Logical Architecture? What are Layers Typically layers in an OO system What is Software Architecture? Applying UML: Package Diagrams, Notation and Nesting Design with Layers Problems that Layering Addresses Benefits of Using Layers Domain Layer vs. Application Logic Layer; Domain Objects What's the Relationship Between the Domain Layer and Domain Model? Tiers, Layers, and Partitions Model View Principle Model-View Separation Principle More on Layered Architecture What's the Connection Between SSDs, System Operations, and Layers? 2

LOGICAL ARCHITECTURE AND UML PACKAGE DIAGRAMS :

Chapter 13 :Craig Larman LOGICAL ARCHITECTURE AND UML PACKAGE DIAGRAMS 3

Objectives:

Objectives Introduce a logical architecture using layers. Illustrate the logical architecture using UML package diagrams. 4

RoadMap:

RoadMap 5

Sample UP artifact influence :

Sample UP artifact influence 6

LOGICAL ARCHITECTURE AND LAYERS:

LOGICAL ARCHITECTURE AND LAYERS 7

What is the Logical Architecture? :

What is the Logical Architecture? The logical architecture is the large-scale organization of the software classes into packages (or namespaces), subsystems, and layers. It's called the logical architecture because there's no decision about how these elements are deployed across different operating system processes or across physical computers in a network (these latter decisions are part of the deployment architecture). So architecture required many VIEWS* to fully describe it. 8

Applying UML: Package Diagrams:

Applying UML: Package Diagrams A UML package diagram provides a way to group elements. A UML package can group anything: classes, other packages, use cases, and so on. UML package diagrams are often used to illustrate the logical architecture of a system the layers, subsystems, packages (in the Java sense), etc. A layer can be modeled as a UML package; for example, the UI layer modeled as a package named UI. Nesting packages is very common. 9

Layers shown with UML package diagram notation :

Layers shown with UML package diagram notation 10

Layer:

Layer A layer is a very coarse-grained grouping of classes, packages, or subsystems that has cohesive responsibility for a major aspect of the system. Layers are organized such that "higher" layers (such as the UI layer) call upon services of "lower" layers, but not normally vice versa. Types of Layered Architectures 11

Typically layers in an OO system:

Typically layers in an OO system 12

What is Software Architecture?:

What is Software Architecture? An architecture is the set of significant decisions about: the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization these elements and their interfaces, their collaborations, and their composition. It has to do with the large scale, the Big Ideas in the motivations, constraints, organization, patterns, responsibilities, and connections of a system (or a system of systems). There are courses on Software Architecture and also one at NU-ISB, one being conducted these days by Dr. Arshad A. Shahid 13

UML Packages and Notation:

UML Packages and Notation UML package is a more general concept than simply a Java package or .NET namespace, though a UML package can represent those and more. The package name may be placed on the tab if the package shows inner members, or on the main folder, if not. It is common to want to show dependency (a coupling) between packages so that developers can see the large-scale coupling in the system. The UML dependency line is used for this, a dashed arrowed line with the arrow pointing towards the depended-on package. A UML package represents a namespace so that, for example, a Date class may be defined in two packages. If you need to provide fully-qualified names, the UML notation is, for example, java::util::Date in the case that there was an outer package named "java" with a nested package named "util" with a Date class. The UML provides alternate notations to illustrate outer and inner nested packages. Sometimes it is awkward to draw an outer package box around inner packages. 14

Package Nesting & Notation:

Package Nesting & Notation Alternate UML approaches to show package nesting, using embedded packages UML fully-qualified names and the circle-cross symbol 15

DESIGN WITH LAYERS:

DESIGN WITH LAYERS 16

Design with Layers:

Design with Layers The essential ideas of using layers [ BMRSS96 ] are simple: Organize the large-scale logical structure of a system into discrete layers distinct, related responsibilities, with a clean, cohesive separation of concerns such that the "lower" layers are low-level and general services, and the higher layers are more application specific. Collaboration and coupling is from higher to lower layers; lower-to-higher layer coupling is avoided. 17

Problems that Layering Addresses:

Problems that Layering Addresses Source code changes are rippling throughout the system many parts of the systems are highly coupled. Application logic is intertwined with the user interface, so it cannot be reused with a different interface or distributed to another processing node. Potentially general technical services or business logic is intertwined with more application-specific logic, so it cannot be reused, Cannot be distributed to another node, Cannot be easily replaced with a different implementation. There is high coupling across different areas of concern. Difficult to divide the work along clear boundaries for different developers. 18

PowerPoint Presentation:

The purpose and number of layers varies across applications and application domains (information Common layers in an information system logical architecture 19

Benefits of Using Layers:

Benefits of Using Layers In general, there is a separation of concerns a separation of high from low-level services and of application-specific from general services reduces coupling and dependencies improves cohesion increases reuse potential and increases clarity Related complexity is encapsulated and decomposable. Some layers can be replaced with new implementations. Generally not possible for lower-level Technical Service or Foundation layers (e.g., java.util) May be possible for UI, Application, and Domain layers Lower layers contain reusable functions Some layers (primarily the Domain and Technical Services) can be distributed Development by teams is aided because of the logical segmentation. 20

Cohesive Responsibilities; Maintain a Separation of Concerns:

Cohesive Responsibilities; Maintain a Separation of Concerns The responsibilities of the objects in a layer should be strongly related to each other and should not be mixed with responsibilities of other layers. For example, objects in the UI layer should focus on UI work, such as creating windows and widgets, capturing mouse and keyboard events, and so forth. Objects in the application logic or "domain" layer should focus on application logic, such as calculating a sales total or taxes, or moving a piece on a game board. UI objects should not do application logic. For example, a Java Swing JFrame (window) object should not contain logic to calculate taxes or move a game piece. And on the other hand, application logic classes should not trap UI mouse or keyboard events. Violate a clear separation of concerns and maintaining high cohesion basic architectural principles. 21

Domain Layer vs. Application Logic Layer; Domain Objects:

Domain Layer vs. Application Logic Layer; Domain Objects A typical software system has UI logic and application logic, such as GUI widget creation and tax calculations. Now, here's a key question: How do we design the application logic with objects? We could create one class called XYZ and put all the methods, for all the required logic, in that one class. It could technically work (though be a nightmare to understand and maintain), but it isn't the recommended approach in the spirit of OO thinking. So, what is the recommended approach? Answer: To create software objects with names and information similar to the real-world domain, and assign application logic responsibilities to them. For example, in the real world of POS, there are sales and payments. So, in software, we create a Sale and Payment class, and give them application logic responsibilities. This kind of software object is called a domain object. It represents a thing in the problem domain space, and has related application or business logic, for example, a Sale object being able to calculate its total. Designing objects this way leads to the application logic layer being more accurately called the domain layer of the architecture the layer that contains domain objects to handle application logic work. Self 22

What's the Relationship Between the Domain Layer and Domain Model?:

What's the Relationship Between the Domain Layer and Domain Model? Relationship between the domain model and the domain layer Domain model (which is a visualization of noteworthy domain concepts) Inspiration for the names of classes in the domain layer. Domain layer and domain model relationship The domain layer is part of the software and the domain model is part of the conceptual-perspective analysis they aren't the same thing. But by creating a domain layer with inspiration from the domain model, we achieve a lower representational gap, between the real-world domain, and our software design. For example, a Sale in the UP Domain Model helps inspire us to consider creating a software Sale class in the domain layer of the UP Design Model. Self 23

Domain layer and domain model relationship:

Domain layer and domain model relationship 24

Tiers, Layers, and Partitions:

Tiers, Layers, and Partitions The original notion of a tier in architecture was a logical layer, not a physical node, but the word has become widely used to mean a physical processing node (or cluster of nodes), such as the "client tier" (the client computer). The layers of an architecture are said to represent the vertical slices, while partitions represent a horizontal division of relatively parallel subsystems of a layer. For example, the Technical Services layer may be divided into partitions such as Security and Reporting 25

Layers and partitions. :

Layers and partitions. The layers of an architecture are said to represent the vertical slices, while partitions represent a horizontal division of relatively parallel subsystems of a layer. 26

MODEL VIEW PRINCIPLE:

MODEL VIEW PRINCIPLE 27

The Model-View Separation Principle:

The Model-View Separation Principle What kind of visibility should other packages have to the UI layer? How should non-window classes communicate with windows? 28

Model-View Separation Principle:

Model-View Separation Principle This principle has at least two parts: Do not connect or couple non-UI objects directly to UI objects. For example, don't let a Sale software object (a non-UI "domain" object) have a reference to a Java Swing JFrame window object. Why? Because the windows are related to a particular application, while (ideally) the non-windowing objects may be reused in new applications or attached to a new interface. Do not put application logic (such as a tax calculation) in the UI object methods. UI objects should only initialize UI elements, receive UI events (such as a mouse click on a button), and delegate requests for application logic on to non-UI objects (such as domain objects). 29

Model vs. Domain and View vs.UI:

Model vs. Domain and View vs.UI In this context, model is a synonym for the domain layer of objects (it's an old OO term from the late 1970s). View is a synonym for UI objects, such as windows, Web pages, applets, and reports. 30

Model-View Separation principle:

Model-View Separation principle The Model-View Separation principle [2] states that model (domain) objects should not have direct knowledge of view (UI) objects, at least as view objects. So, for example, a Register or Sale object should not directly send a message to a GUI window object ProcessSaleFrame, asking it to display something, change color, close, and so forth 31

MVC – Model View Controller:

MVC – Model View Controller This is a key principle in the pattern Model-View-Controller (MVC). MVC was originally a small-scale Smalltalk-80 pattern, and related data objects (models), GUI widgets (views), and mouse and keyboard event handlers (controllers). More recently, the term "MVC" has been coopted by the distributed design community to also apply on a large-scale architectural level. The Model is the Domain Layer, the View is the UI Layer, and the Controllers are the workflow objects in the Application layer. 32

Implications of MVC:

Implications of MVC A further part of this principle is that the domain classes encapsulate the information and behavior related to application logic. The window classes are relatively thin; they are responsible for input and output, and catching GUI events, but do not maintain application data or directly provide application logic. For example, a Java JFrame window should not have a method that does a tax calculation. A Web JSP page should not contain logic to calculate the tax. These UI elements should delegate to non-UI elements for such responsibilities. 33

The Motivation/Need for Model-View Separation :

The Motivation/Need for Model-View Separation To support cohesive model definitions that focus on the domain processes, rather than on user interfaces. To allow separate development of the model and user interface layers. To minimize the impact of requirements changes in the interface upon the domain layer. To allow new views to be easily connected to an existing domain layer, without affecting the domain layer. To allow multiple simultaneous views on the same model object, such as both a tabular and business chart view of sales information. To allow execution of the model layer independent of the user interface layer, such as in a message-processing or batch-mode system. To allow easy porting of the model layer to another user interface framework. 34

MORE ON LAYERED ARCHITECTURE:

Beyond the Scope of Lecture Refer to Chapter 34 of Craig Larman MORE ON LAYERED ARCHITECTURE 35

What's the Connection Between SSDs, System Operations, and Layers?:

What's the Connection Between SSDs, System Operations, and Layers? During analysis work, SSDs for use case scenarios. input events from external actors into the system calling upon system operations such as makeNewSale and enterItem. The SSDs illustrate these system operations, but hide the specific UI objects. Normally it will be objects in the UI layer of the system that capture these system operation requests, usually with a rich client GUI or Web page. In a well-designed layered architecture Supports High cohesion and separation of concerns The UI layer objects will then forward or delegate the request from the UI layer onto the domain layer for handling. 36

System operations in the SSDs and in terms of layers:

System operations in the SSDs and in terms of layers 37

Example: NextGen Logical Architecture and Package Diagram:

Example: NextGen Logical Architecture and Package Diagram 38

authorStream Live Help