Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of Computer Science Technische Universität Darmstadt
What do we know already? Retroperspective 2 Use Cases Domain Modeling System Sequence Diagrams Repetition
Dr. Michael Eichberg Fachgebiet Software Engineering Department of Computer Science Technische Universität Darmstadt Introduction to Software Engineering Logical Architecture and UML Package Diagrams The following slides make extensive use of material from: Applying UML and Patterns, 3rd Edition; Craig Larman; Prentice Hall
Software Architecture 4 The Unified Modeling Language User Guide 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. structure + behavior G. Booch, J. Rumbaugh and I. Jacobsen; Addison-Wesley 1999
Software Architecture 5 Patterns Oriented Software Architecture A software architecture is a description of the subsystems and components of a software system and the relationships between them. structure Subsystems and components are typically specified in different views to show the relevant functional and non-functional properties of a software system. The software architecture of a system is an artifact. it s a document multiple views Buschmann et al.; Wiley 1996
Software Architecture 6 Patterns Oriented Software Architecture A view represents a partial aspect of a software architecture that shows specific properties of a software system. multiple views - Conceptual architecture: components, connectors - Module architecture: subsystems, modules, exports, imports, - Code architecture: files, directories, libraries, - Execution architecture: tasks, threads, processes Buschmann et al.; Wiley 1996
www.softwarearchitectureportal.org Software Architecture 7
The logical architecture is the large scale organization of the software classes into packages, subsystems and layers. Logical Architecture 8 The logical architecture is unrelated to the deployment of the software elements (That s why we call it logical architecture.) The prime input is the supplementary specification
The logical architecture is the large scale organization of the software classes into packages, subsystems and layers. Logical Architecture 9 The supplementary specification contains the specification of system-wide quality attributes (~ non-functional properties) hardware and software constraints other design and implementation constraints (e.g. the used programming language) operational concerns (e.g. how to handle errors) (other information not necessarily relevant w.r.t. the logical architecture)
The logical architecture is the large scale organization of the software classes into packages, subsystems and layers. Logical Architecture 10 Requirements... Supplementary Speci!cation Glossary Design UI package diagrams of the logical architecture Domain Tech Services
A layer is a very coarse-grained grouping of: classes, packages, or subsystems that has a cohesive responsibility for a major aspect of the system. Layered Architectures 11 Usually higher layers are allowed to depend on / to use lower layers but not vice versa Strict layered architecture: a layer is only allowed to depend on its immediate lower layer; often used in case of network protocol stacks. Examples layers: User Interface Application Logic and Domain Objects Usually implements the business logic. Technical Services Examples: database access, error logging,... Layer 4 Layer 3 Layer 2 Layer 1 x
A layered architecture can be applied for systems with a mix of low-level and high-level issues, where the high-level ones rely on the low-level ones. Layered Architectures 12 Forces that need to be balanced: late source code changes should not ripple through the system interfaces should be stable Layer 4 Layer 3 Layer 2 Layer 1 parts of the system should be exchangeable similar responsibilities should be grouped to help understandability and maintainability complex components need further decomposition crossing component boundaries may impede performance work has to be subdivided along clear boundaries
How to implement a layered architecture? Layered Architectures 13 Define the abstraction criterion The goal is to group tasks into layers; this criterion is often the conceptual distance from the platform. Determine the number of abstraction levels according to your abstraction criterion Name the layers and assign tasks to each of them a lower level is a helper to a higher level Specify the services layers have to be kept strictly separate from each other (no component may spread over more than one layer). Refine the layering.. (reconsider the previous steps)
How to implement a layered architecture? Layered Architectures 14 Specify an interface for each layer Consider if you want to apply a white-box or a black-box approach (the layer s interface does not reveal the layer s structure or working); prefer the latter. Structure individual layers Design an error-handling strategy (A rule of thumb: handle errors in the lowest layer possible.)
Layered Architectures 15 Every software problem, can be solved by introducing an extra layer of indirection. Layer n+1 Layer 3 Layer 2 Layer 1
Layered Architectures 16 Every performance problem can be solved by removing a layer of indirection. Layer n+1 Layer 3 Layer 2 Layer 1
Visualizing the Logical Architecture Using the UML Package Diagram Notation. Logical Architecture and Package Diagram Notation 17 A package can contain anything: classes, other packages, use cases; a package is a collection of elements that share the same namespace It is a more general concept than, e.g., a Java package. Packages can be nested Packages represent namespaces E.g. the fully-qualified name (in UML) of a Java class Date that belongs to a package util which is nested in java is: java::util::date Dependencies are shown using the standard UML dependency line
The UML supports different approach to show package nesting. Logical Architecture and Package Diagram Notation 18 1. Alternative UI Domain Swing Sales Web Here, the UI package has a dependency on the Sales package.
The UML supports different approach to show package nesting. Logical Architecture and Package Diagram Notation 19 2. Alternative UI::Swing Domain::Sales UI::Web
The UML supports different approach to show package nesting. Logical Architecture and Package Diagram Notation 20 3. Alternative UI Domain Swing Sales Web
Example UML Package Diagram for the POS System Logical Architecture and Package Diagram Notation 21 UI Swing Web Vertical Layers Domain Sales Payments Taxes Technical Services Persistence Logging RulesEngine Horizontal Partitions
Example UML Package Diagram for the POS System UI Domain Note, Java does not have Swing Sales Technical Services Persistence Payments Logical Architecture and Package Diagram Notation Web nested packages! Taxes Elements belonging to a parent package are not automatically accessible by elements belonging Logging RulesEngine to a child package. 22
Example UML Package Diagram for the POS System UI Logical Architecture and Package Diagram Notation 23 Swing Web Domain Note, Scala does have nested Sales packages! Payments Taxes Technical Services Persistence Logging RulesEngine
Importing elements from different packages. Logical Architecture and Package Diagram Notation 24 UI Domain «access» Swing Sales Web «access» models an import with private visibility.
Importing elements from different packages. Logical Architecture and Package Diagram Notation 25 UI Domain «import» Swing Sales Web «import» models an import with public visibility; i.e. the imported elements are transitively visible.
Some Advantages of Using Layers Logical Architecture and Package Diagram Notation 26 Source code changes (in higher layers) do not ripple throughout the system E.g. if the business logic is not implemented as part of the UI layer it is easier to provide an additional user interface. Reuse of the lower layers is facilitated Coupling and cohesion are improved Development of teams is aided because of the logical segmentation Repetition
Logical Architecture and Package Diagram Notation 27 General Guideline The responsibilities of the objects in a layer should be strongly related.
The Model-View Separation Principle Here, model means the domain layer objects and view relates to the UI objects. Logical Architecture 28 The model (domain objects) should not have direct knowledge of view Objects.
The Model-View Separation Principle Here, model means the domain layer objects and view relates to the UI objects. Logical Architecture 29 The model (domain objects) should not have direct knowledge of view Objects. This means: 1. Do not connect or couple non-ui objects directly to UI objects. 2. Do not put application logic in the UI object methods. UI objects only initialize UI elements, receive UI events (e.g. mouse click) and delegate requests.
The Model-View Separation Principle - Motivation Here, model means the domain layer objects and view relates to the UI objects. Logical Architecture 30 To support cohesive model definitions that focus on the domain process To separate the development of the model and user interface layers To allow new views to be easily connected to an existing layer without affecting the domain layer To allow multiple simultaneous views To support porting the model layer to another user interface framework
Connection between SSDs and Layers Logical Architecture 31 :Cashier Process Sale Scenario :System makenewsale enteritem(itemid, quantity) UI Swing... ProcessSaleFrame makenewsale() enteritem()... description, price, total endsale total with taxes Domain makenewsale() enteritem()... :Cashier makepayment (amount)... Register change due, receipt makenewsale()... The system operations handled by the system in an SSD represent the operation calls on the Application or Domain Layer from the UI Layer
Domain Model and Domain Layer Logical Architecture 32 Domain Model Payment amount Sale date time Inspiration Payment amount: Money getbalance():money Sale date: Date starttime: Time gettotal(): Money Domain Layer