introduction to software engineering · software engineering (2+1 sws) winter term 2009 / 2010 dr....

Introduction to Software Engineering (2+1 SWS)Winter Term 2009 / 2010 Dr. Michael EichbergVertretungsprofessur Software EngineeringDepartment of Computer ScienceTechnische Universität Darmstadt

|

Repetition

Retroperspective

What do we know already?

•Use Cases•Domain Modeling•System Sequence Diagrams

2

Introduction to Software Engineering

Dr. Michael EichbergFachgebiet Software EngineeringDepartment of Computer ScienceTechnische Universität Darmstadt

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

The Unified Modeling Language User Guide

G. Booch, J. Rumbaugh and I. Jacobsen; Addison-Wesley 1999

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.

4

structure

+

behavior


Patterns Oriented Software Architecture

Buschmann et al.; Wiley 1996

A software architecture is a description of the subsystems and components of a software system and the relationships between them.

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….

5

structure

multiple views

it’s a document


Patterns Oriented Software Architecture

Buschmann et al.; Wiley 1996

A view represents a partial aspect of a software architecture that shows specific properties of a software system.

- Conceptual architecture: components, connectors

- Module architecture: subsystems, modules, exports, imports,…

- Code architecture: files, directories, libraries,…

- Execution architecture: tasks, threads, processes…

6

multiple views

|Software Architecture 7

www.softwarearchitectureportal.org

|Logical Architecture

The logical architecture is the large scale organization of the software classes into packages, subsystems and layers.

• 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

8



• 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)

9



10

Supplementary Speci!cation

Requirements

Glossary...

UI

Domain

Tech Services

Design package diagrams of the logical architecture

|Layered Architectures

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.

•Usually higher layers are allowed to depend on / to use lower layers but not vice versaStrict 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 ServicesExamples: database access, error logging,...

11

Layer 4

Layer 3

Layer 2

Layer 1x


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.

• Forces that need to be balanced:• late source code changes should not ripple through

the system• interfaces should be stable• 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

12

Layer 4Layer 3Layer 2Layer 1


How to implement a layered architecture?

‣“Define” the abstraction criterionThe 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)

13


How to implement a layered architecture?

‣Specify an interface for each layerConsider 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.)

14


Every software problem, can be solved by introducing an extralayer of indirection.

15

Layer n+1

Layer 3

Layer 2

Layer 1


Every performance problem can be solved by removing a layer of indirection.

16

Layer n+1

Layer 3

Layer 2

Layer 1

|Logical Architecture and Package Diagram Notation 17

Visualizing the Logical Architecture Using the UML Package Diagram Notation.

•A package can contain anything: classes, other packages, use cases; a package is a collection of elements that share the same namespaceIt 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.

1. Alternative

Swing

Web

UI

Sales

Domain

Here, the UI package has a dependency on the Sales package.



2. Alternative

UI::Swing

UI::Web

Domain::Sales



3. Alternative

UI

Swing

Web

Domain

Sales

|Logical Architecture and Package Diagram Notation

Example UML Package Diagram for the POS System

21

Swing Web

UI

Sales Payments

Domain

Taxes

Persistence Logging

Technical Services

RulesEngine

Horizontal Partitions

Vert

ical

Lay

ers



22

Swing Web

UI

Sales Payments

Domain

Taxes

Persistence Logging

Technical Services

RulesEngine

Note, Java does not have

nested packages!

Elements belonging to a “parent

package” are not automatically

accessible by elements belonging

to a “child package”.



23

Swing Web

UI

Sales Payments

Domain

Taxes

Persistence Logging

Technical Services

RulesEngine

Note, Scala does have nested packages!


Importing elements from different packages.

Swing

Web

UI

Sales

Domain

«access» models an import with private visibility.

«access»


Importing elements from different packages.

Swing

Web

UI

Sales

Domain

«import» models an import with public visibility; i.e. the imported elements are transitively visible.

«import»

|

Repetition

Logical Architecture and Package Diagram Notation

Some Advantages of Using Layers

•Source code changes (in higher layers) do not ripple throughout the systemE.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

26


General Guideline

The responsibilities of the objects in a layer should be strongly related.


The Model-View Separation PrincipleHere, model means the domain layer objects and view relates to the UI objects.

28

The model (domain objects) should not have direct knowledge of view Objects.


The Model-View Separation PrincipleHere, model means the domain layer objects and view relates to the UI objects.

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 - MotivationHere, model means the domain layer objects and view relates to the UI objects.

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

|Logical ArchitectureConnection between SSDs and Layers

31

UI

...makeNewSale()

...

Domain

Swing

Register

... ProcessSaleFrame

:System:Cashier

Process Sale Scenario

enterItem(itemId, quantity)

makeNewSale

description, price, total

endSale

makePayment (amount)

total with taxes

change due, receipt

:CashiermakeNewSale()enterItem()...

makeNewSale()enterItem()...

The system operations handled by the system in an SSD represent the operation calls on the Application or Domain

Layer from the UI Layer

|Logical Architecture 32

Domain Model and Domain Layer

datetime

SaleamountPayment

getBalance():Moneyamount: Money

Payment

getTotal(): Money

date: DatestartTime: Time

Sale

Domain Model

Domain Layer

Inspiration

introduction to software engineering · software engineering (2+1 sws) winter term 2009 / 2010 dr....

Documents