meljun cortes jedi slides-4.2 software architecture

7/29/2019 MELJUN CORTES JEDI Slides-4.2 Software Architecture

http://slidepdf.com/reader/full/meljun-cortes-jedi-slides-42-software-architecture 1/39

Software Engineering 1

Design Engineering

Software

Architecture

TOPIC TWO




Topics

● Software Architecture

● Package Diagram

● Developing the Architectural Design

● Software Validation Checklist




Software Architecture

● It is the overall structure of the software and the ways inwhich the structure provides conceptual integrity for asystem.

●

It is a layered structure of software components and itsmanner in which these components interact, and thestructure of data that are used by these components.

● It is a decision on how software will be built and how tocontrol the incremental development of the software.




Package Diagram

● It shows the breakdown of larger systems into logicalgroupings of smaller subsystems.

● It shows the group of classes and dependencies among

them.




Package Diagram

PackageCanonicalRepresentation

ClassRepresentation

Dependency Realizes




Subsystem and Interfaces

● Subsystem

– It is a combination of a package (it can contain other modelelements) and a class (it interacts with other model elements).

– It is used to partition the system into parts which can beindependently ordered, configured and delivered.

● Interface

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




Subsystem and Interfaces

Interface

X()w()

Class A1

X()

Class A2

w()

<<subsystem>>Subsystem A

Class B1w()y()

Class B2

X()

<<subsystem>>Subsystem B

Class B3

z()




Communication Styles of

Subsystems● Client-server Communication

– The client-subsystem needs to know the interface of the server-subsystem.

– It is a one-way communication.

– It is easier to implement and maintain.

● Peer-to-peer Communication

– Each subsystem knows the interface of the other subsystems.

– It is a two-way communication.




Communication Styles of

Subsystems<<client>>

Subsystem 1

<<peer>>

Subsystem 3

<<server>>

Subsystem 2

<<peer>>

Subsystem 4

The server subsystem doesnot depend on the clientsubsystem. Changes to theclient interface do not affect it.

Each peer subsystemdepends on the other. Theyare affected by changes ineach other's interface.




Approaches in Dividing

Software into Subsystems● Layering

– It focuses on subsystems as represented by different levels of abstraction or layers of services.

●

Partitioning – It focuses on the different aspects of the functionality of the system

as a whole.




General Structure of Layered

Architecture

Layer 1

Layer 2

Layer n-1

Layer n

. . .

Open Architecture

Layer 1

Layer 2

Layer n-1

Layer n

. . .

Closed Architecture

● Open Architecture

– Subsystems may requestservices from any layer below them.

● Closed Architecture

– Subsystems may onlyrequest services from thelayer directly below them.

– Subsystems are not allowed

to skip subsystems.




Sample Layering and

Partitioning Example

Athlete Database

Athlete Domain

AthleteMaintenance

subsystem

AthleteFindsubsystem

Athlete HCI

Maintenancesubsystem

Athlete HCI

Findsubsystem




Sample Layered Architecture

J2EE PlatformClient

Client

Client

Client

Firewall

Web Container

(Servlets, JSPPages, HTML,

XML)

Enterprise JavaBean(EJB)

Container

(Session Bean,Entity Bean,

Message-drive Bean)

JNDI,JMS,

JavaMail

EntepriseInformation

Systems

(RDBMS,ERP,

LegacyApplications)

Client Tier Middle Tier EIS Tier




Developing the Architectural

Design1. If the analysis model has not been validated yet, validate theit.

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




STEP 1: Validate the analysis

classes.● It ensures that attributes and responsibilities are distributedto classes.

● It ensures that a class defines a single logical abstraction.




STEP 2: Package related

analysis classes together.● It organizes classes together into packages which may bebased on configuration units, allocation of resources, user type groupings and representation of the existing productand services the system uses.

● It also identifies package visibility and package coupling.




Packaging Guidelines

● Packaging Boundary Classes

– If the system interfaces are likely to be changed or replaces, theboundary 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 withwhich they are functionally related.

– Mandatory boundary classes that are not functionally related on anyentity 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 thesaid service. In this way, when the subsystem is mapped onto anoptional component interface, it can provide that service using theboundary class.





● Packaging Functionally Related Classes

– If a change in one class affects a change to another class, they arefunctionally 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 impactedclasses.

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





● Packaging Functionally Related Classes

– Two classes are functionally related if they have a relationship withone 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 onthe same package.

– Optional and mandatory classes should not be placed in the sameclasses.




Package Visibility

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

V i s i b i l i t y S y m b o l s D e s c r i p t i o n s

+ I t r e p r e s e n t s a p u b l i c m o d e l

-I t r e p r e s e n t s a p r i v a t e m o d ep a c k a g e .

# I t r e p r e s e n t s p r o t e c t e d m o de l e m e n t o r b y i n h e r i t a n c e .




Package Visibility

Class A1 Class A2

Class A1

Package A

+ Class B1 - Class B2

Package B

X

Only public classes canbereferenced outside of theowning

package.




Package Coupling

● It defines how dependencies are defined betweenpackages.

– Packages should not be cross-coupled.

– Packages in lower layers should not be dependent on packages onupper layers.

– In general, packages should not skip layers.

– Packages should not be dependent on subsystems. They should bedependent on other packages or subsystem interfaces.




Package Coupling

X

X

X




Club Membership Packaging

Decision




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 bedesigned and implemented?




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 tobecome:

● 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




Subsystem Identification

Guidelines● Object Collaboration

– If objects of the classes collaborate only with themselves, and thecollaboration produces an observable result, they should be part of the subsystem.

● Optionality – It the associations of the classes are optional, or features which may

be removed, upgraded or replaced with alternatives, encapsulate theclasses within a subsystem.





Guidelines● User Interface

– Separating together boundary and related entity classes as onesubsystem is called horizontal subsystem while grouping themtogether 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 entityclass information, vertical subsystem is the choice.

● Actor

– If two different actors use the same functionality provided by the

class, model them as different subsystems since each actor mayindependently change requirements.

● Class coupling and cohesion.

– Organize highly coupled classes into subsystems. Separate alongthe lines of weak coupling.





Guidelines● Substitution

– Represent different service levels for a particular capability as separate subsystem each realizes the sameinterface.

● Distribution.

– If the particular functionality must reside on a particular node, ensurethat the subsystem functionality maps onto a single node.

● Volatility

– Encapsulate into one subsystem all classes that may change over aperiod of time.




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




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

– It defines a set of operations which are realized by a subsystem.

Club Membership




Club MembershipMaintenance Interface

Definition




STEP 5: Layer subsystems

and classes.● Design Elements need to be allocated to specific layers inthe architecture.

● In general, most boundary classes tend to appear at the toplayer, control classes tend to appear in the middle and entity

classes appear below.



Software Engineering34

Three Layer Architecture

Presentation

Business Logic

Database




Layering Guidelines

● Consider visibility.

– Dependencies among classes and subsystem occur only within thecurrent layer and the layer directly below it. If dependency skips, itshould be justified and documented.

● Consider volatility. – Normally, upper layers are affected by requirements change while

lower layers are affected by environment and technology change.

● Number of Layers.

–

Small systems should have 3 – 4 layers while larger systems shouldhave 5 – 7 layers.




Club Membership Layering

Decision





Validation Checklist● Layers

– For smaller systems, are there more than four layers?

– For larger systems, are there more than seven layers?

●

Subsystems and Interfaces – 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 withinthe entire system?

– Is the interface description concise and clear? – Are all operations that the subsystem needs to perform identified?

Are there any missing operations?

S f





Validation Checklist● Packages

– Are the name of the packages descriptive?

– Does the package description match the responsibilities?




Summary● Software Architecture

● Package Diagram

● Developing the Software Architecture

● Software Architecture Validation Checklist

meljun cortes jedi slides-4.2 software architecture

Documents