Design Engineering

Software Architecture
TOPIC TWO
Software Engineering 1

Topics
● ● ● ●

Software Architecture Package Diagram Developing the Architectural Design Software Validation Checklist

Software Engineering

2

Software Architecture

It is the overall structure of the software and the ways in which the structure provides conceptual integrity for a system. It is a layered structure of software components and its manner in which these components interact, and the structure of data that are used by these components. It is a decision on how software will be built and how to control the incremental development of the software.

Software Engineering

3

Package Diagram

It shows the breakdown of larger systems into logical groupings of smaller subsystems. It shows the group of classes and dependencies among them.

Software Engineering

4

Package Diagram
Canonical Representation Package Class Representation

Dependency

Realizes

Software Engineering

5

Subsystem and Interfaces

Subsystem

It is a combination of a package (it can contain other model elements) and a class (it interacts with other model elements). It is used to partition the system into parts which can be independently ordered, configured and delivered. It defines a set of operations which are realized by a subsystem. It allows the separation of the declaration of behavior from the realization of the behavior.

Interface
– –

Software Engineering

6

Subsystem and Interfaces
<<subsystem>> Subsystem A Class A1 Class A2 X() w()

Interface X() w()

Class B1 w() y()

<<subsystem>> Subsystem B Class B2 X()

Class B3 z()

Software Engineering

7

Communication Styles of Subsystems

Client-server Communication

The client-subsystem needs to know the interface of the serversubsystem. It is a one-way communication. It is easier to implement and maintain. Each subsystem knows the interface of the other subsystems. It is a two-way communication.

– –

Peer-to-peer Communication
– –

Software Engineering

8

Communication Styles of Subsystems
<<client>> Subsystem 1 <<peer>> Subsystem 3

<<server>> Subsystem 2

<<peer>> Subsystem 4

The server subsystem does not depend on the client subsystem. Changes to the client interface do not affect it.

Each peer subsystem depends on the other. They are affected by changes in each other's interface.

Software Engineering

9

Approaches in Dividing Software into Subsystems

Layering

It focuses on subsystems as represented by different levels of abstraction or layers of services. It focuses on the different aspects of the functionality of the system as a whole.

Partitioning

Software Engineering

10

General Structure of Layered Architecture

Open Architecture

Layer n Layer n-1

Layer n Layer n-1

...
Layer 2 Layer 1

...
Layer 2 Layer 1

Subsystems may request services from any layer below them. Subsystems may only request services from the layer directly below them. Subsystems are not allowed to skip subsystems.

Closed Architecture

Open Architecture

Closed Architecture

Software Engineering

11

Sample Layering and Partitioning Example
Athlete HCI Maintenance subsystem Athlete Maintenance subsystem Athlete HCI Find subsystem Athlete Find subsystem

Athlete Domain

Athlete Database

Software Engineering

12

Sample Layered Architecture J2EE Platform
Firewall Client Web Container (Servlets, JSP Pages, HTML, XML) Client JNDI, JMS, JavaMail Enteprise Information Systems (RDBMS, ERP, Legacy Applications)

Client

Enterprise JavaBean (EJB) Container (Session Bean, Entity Bean, Message-drive Bean)

Client

Client Tier

Middle Tier

EIS Tier

Software Engineering

13

Developing the Architectural Design
1. If the analysis model has not been validated yet, validate the it. 2. Package related analysis classes together. 3. Identify design classes and subsystems. 4. Define the interface of the subsystem. 5. Organize subsystems and classes into layers for the architecture.

Software Engineering

14

STEP 1: Validate the analysis classes.

It ensures that attributes and responsibilities are distributed to classes. It ensures that a class defines a single logical abstraction.

Software Engineering

15

STEP 2: Package related analysis classes together.

It organizes classes together into packages which may be based on configuration units, allocation of resources, user type groupings and representation of the existing product and services the system uses. It also identifies package visibility and package coupling.

Software Engineering

16

Packaging Guidelines

Packaging Boundary Classes

If the system interfaces are likely to be changed or replaces, the boundary class should be separated from the rest of the design. If no major interface changes are planned, the boundary classes should be placed together with the entity and control classes with which they are functionally related. Mandatory boundary classes that are not functionally related on any entity or control classes are grouped together separately. If the boundary class is related on an optional service, group it in a separate subsystem with the classes that collaborate to provide the said service. In this way, when the subsystem is mapped onto an optional component interface, it can provide that service using the boundary class.

Software Engineering

17

Packaging Guidelines

Packaging Functionally Related Classes

If a change in one class affects a change to another class, they are functionally related. If the class is removed from the package and has a great impact to a group of classes, the class is functionally related to the impacted classes. Two classes are functionally related if they have a large number of messages that they can send to one another. Two classes are functionally related if they interact with the same actor, or are affected by the changes made by the same actor.

Software Engineering

18

Packaging Guidelines

Packaging Functionally Related Classes

Two classes are functionally related if they have a relationship with one another. A class is functionally related to the class that creates instances of it. Two class that are related to different actors should not be placed on the same package. Optional and mandatory classes should not be placed in the same classes.

– –

Software Engineering

19

Package Visibility

It defines what is and is not accessible within the package.

V is ib ilit y S y m b o ls D e s c r ip t io n s + # It r e p r e s e n t s a p u b lic m o d e l e le m e n It r e p r e s e n t s a p r iv a t e m o d e l e le m e package.

It r e p r e s e n t s p r o t e c t e d m o d e l e le m e e le m e n t o r b y in h e r it a n c e .
Software Engineering 20

Package Visibility
Package A Class A1 Class A2 Only public classes can be referenced outside of the owning package.

Class A1

X

Package B + Class B1 - Class B2

Software Engineering

21

Package Coupling

It defines how dependencies are defined between packages.
– –

Packages should not be cross-coupled. Packages in lower layers should not be dependent on packages on upper layers. In general, packages should not skip layers. Packages should not be dependent on subsystems. They should be dependent on other packages or subsystem interfaces.

– –

Software Engineering

22

Package Coupling

X
X X

Software Engineering

23

Club Membership Packaging Decision

Software Engineering

24

STEP 3: Identify design classes and subsystems.

It determines if the analysis classes are really classes or subsystems. It decides on:
– – –

Which analysis classes are really classes? Which are not? Which analysis classes are subsystems? Which components are existing? Which components need to be designed and implemented?

Software Engineering

25

Design Class Identification Guidelines

An analysis class is a design class if it is a simple class or it represents a single logical abstraction. If the analysis class is complex, it can be refined to become:
● ● ● ● ● ●

a part of another class an aggregate class a group of classes that inherits from the same class a package a subsystem an association or relationship between design elements
Software Engineering 26

Subsystem Identification Guidelines

Object Collaboration

If objects of the classes collaborate only with themselves, and the collaboration produces an observable result, they should be part of the subsystem. It the associations of the classes are optional, or features which may be removed, upgraded or replaced with alternatives, encapsulate the classes within a subsystem.

Optionality

Software Engineering

27

Subsystem Identification Guidelines

User Interface

Separating together boundary and related entity classes as one subsystem is called horizontal subsystem while grouping them together is called vertical subsystem. The decision to go for horizontal or vertical subsystem depends on the coupling of the user interface and entity. If the boundary class is used to display entity class information, vertical subsystem is the choice. If two different actors use the same functionality provided by the class, model them as different subsystems since each actor may independently change requirements. Organize highly coupled classes into subsystems. Separate along the lines of weak coupling.
Software Engineering 28

Actor

Class coupling and cohesion.

Subsystem Identification Guidelines

Substitution

different service levels for a particular capability as separate subsystem each realizes the same interface.
Represent If the particular functionality must reside on a particular node, ensure that the subsystem functionality maps onto a single node. Encapsulate into one subsystem all classes that may change over a period of time.

Distribution.

Volatility

Software Engineering

29

Possible Subsystem
● ● ●

Complex Analysis Classes that provide services and utilities Boundary Classes Existing products or external systems Club Membership Maintenance System Subsystems
– – –

AthleteRecordUI UpdateStatusUI ViewAthleteUI

Software Engineering

30

STEP 4: Define the interface of the subsystem.
● ●

It defines the interface of the subsystem. Interface
– –

It is a group of visible operation of a subsystem. It has no internal structure, attributes and operation implementation details. It defines a set of operations which are realized by a subsystem.

Software Engineering

31

Club Membership Maintenance Interface Definition

Software Engineering

32

STEP 5: Layer subsystems and classes.

Design Elements need to be allocated to specific layers in the architecture. In general, most boundary classes tend to appear at the top layer, control classes tend to appear in the middle and entity classes appear below.

Software Engineering

33

Three Layer Architecture
Presentation Business Logic Database

Software Engineering

34

Layering Guidelines

Consider visibility.

Dependencies among classes and subsystem occur only within the current layer and the layer directly below it. If dependency skips, it should be justified and documented. Normally, upper layers are affected by requirements change while lower layers are affected by environment and technology change. Small systems should have 3 – 4 layers while larger systems should have 5 – 7 layers.

Consider volatility.

Number of Layers.

Software Engineering

35

Club Membership Layering Decision

Software Engineering

36

Software Architecture Validation Checklist

Layers
– –

For smaller systems, are there more than four layers? For larger systems, are there more than seven layers? Are the subsystems partitioning done in a logically consistent way across the architecture? Is the name of the interface depict the role of the subsystem within the entire system? Is the interface description concise and clear? Are all operations that the subsystem needs to perform identified? Are there any missing operations?

Subsystems and Interfaces

– –

Software Engineering

37

Software Architecture Validation Checklist

Packages
– –

Are the name of the packages descriptive? Does the package description match the responsibilities?

Software Engineering

38

Summary
● ● ● ●

Software Architecture Package Diagram Developing the Software Architecture Software Architecture Validation Checklist

Software Engineering

39

Sign up to vote on this title
UsefulNot useful