SWA-1.1

CSE333

Software ArchitecturesSoftware ArchitecturesChapter 1: IntroductionChapter 1: Introduction

Prof. Steven A. Demurjian, Sr.Computer Science & Engineering Department

The University of Connecticut371 Fairfield Road, Box U-255

Storrs, CT 06269-2155

steve@engr.uconn.eduhttp://www.engr.uconn.edu/

~steve(860) 486 - 4818

Copyright © 2002 by S. Demurjian, Storrs, CT.

SWA-1.2

CSE333

OverviewOverview

Concept Overview and Sample ArchitecturesConcept Overview and Sample Architectures Augmenting Diagrammatic RepresentationsAugmenting Diagrammatic Representations What isWhat is

Science Engineering and Software Engineering?

Concluding RemarksConcluding Remarks

SWA-1.3

CSE333

Concepts of Software ArchitecturesConcepts of Software Architectures

Exceed Traditional Algorithm/Data Structure Exceed Traditional Algorithm/Data Structure PerspectivePerspective

Emphasize Componentwise Organization and Emphasize Componentwise Organization and System FunctionalitySystem Functionality

Focus on Global and Local InteractionsFocus on Global and Local Interactions Identify Communication/Synchronization Identify Communication/Synchronization

RequirementsRequirements Define Database Needs and DependenciesDefine Database Needs and Dependencies Consider Performance/Scaling IssuesConsider Performance/Scaling Issues Understand Potential Evolution DimensionsUnderstand Potential Evolution Dimensions

SWA-1.4

CSE333

The HTSS Software ArchitectureThe HTSS Software Architecture

ICICICIC

CRCRCRCR

CRCR

CRCR

ILILILIL

ILIL

SDOSDO

SDOSDO EDOEDO

EDOEDO

OrderOrder

PaymentPayment

ItemItemItemDBItemDBLocalLocalServerServer

Non-LocalClient Int.

InventoryInventoryControlControl

ItemDBItemDBGlobalGlobalServerServer

OrderDBOrderDB

SupplierDBSupplierDB

CreditCardDBCreditCardDB

ATM-BanKDBATM-BanKDB

IL: Item LocatorIL: Item LocatorCR: Cash RegisterCR: Cash RegisterIC: Invent. ControlIC: Invent. ControlDO: Deli Orderer forDO: Deli Orderer for Shopper/EmployeeShopper/Employee

SWA-1.5

CSE333

The Software Architecture for JavaOS for The Software Architecture for JavaOS for Business Operating System Business Operating System

JSD Manages Config. JSD Manages Config. Info. IncludingInfo. Including Present Devices Instl. System Services User/Group Attrs. Appl. Specific Info.

JSL Loads ServicesJSL Loads Services JDI Interfaces to Device JDI Interfaces to Device

DriversDrivers JPI Device Driver APIJPI Device Driver API JBI Interface for Startup JBI Interface for Startup

and Booting of and Booting of MicrokernelMicrokernel

Event System Similar to Event System Similar to Java EventsJava Events

SWA-1.6

CSE333

The JavaOS Software ArchitectureThe JavaOS Software Architecture

SWA-1.7

CSE333

Java Visualization Java Visualization

SWA-1.8

CSE333

The Multiple Backend Database System The Multiple Backend Database System (MBDS) Software Architecture(MBDS) Software Architecture

DatabaseController

BackendDatabase Processor

BackendDatabaseProcessor

BackendDatabase Processor

Host/User

SWA-1.9

CSE333

The MBDS ProcessesThe MBDS Processes

Get Msg.Put Msg.

RequestPreparation

Post Processing

Get Msg. Put Msg.

DirectoryManagement

Record Processing

ConcurrencyControl

Disk I/O

DatabaseController

BackendDatabase Processor

SWA-1.10

CSE333

Multiple Processes in MBDSMultiple Processes in MBDSWhat are MBDS Messages?What are MBDS Messages?

No. Type SRC DST1 New Request Host ReqP2 Results of Request PoPr Host3 Number of Reqs in Transaction ReqP PoPr4 Aggregate Operators (Sum, etc.) ReqP PoPr6 Parsed Request to Backends ReqP DM12 Backend Aggregate Operator Results RecP PoPr15 Ids for Accessing Database Indexes DM DMs16 Request and Disk Addresses DM RecP21 Ids for Accessing Database Records DM CC22 Locks Obtained: Okay to Execute CC RecP23 Request ID of Finished Request RecP CC

SWA-1.11

CSE333

Multiple Processes in MBDSMultiple Processes in MBDSSample Processing of Retrieve RequestSample Processing of Retrieve Request

Get Msg.Put Msg.

RequestPreparation

Post Processing

Get Msg. Put Msg.

DirectoryManagement

Record Processing

ConcurrencyControl Disk I/O

F15 FromOther

BackendE15 To Backend(s)

A1 B3

C4D6

D6,F15 E15

G21 H22

I16

J23

K12

K12

K12

SWA-1.12

CSE333

UML Diagrammatic RepresentationsUML Diagrammatic Representations

Component Diagram: Captures the Physical Component Diagram: Captures the Physical Structure of the ImplementationStructure of the Implementation

Deployment Diagram: Captures the Topology of a Deployment Diagram: Captures the Topology of a System’s HardwareSystem’s Hardware

Collaboration Diagram: Captures Dynamic Collaboration Diagram: Captures Dynamic Behavior (Message-Oriented)Behavior (Message-Oriented)

State Chart Diagram: Captures Dynamic Behavior State Chart Diagram: Captures Dynamic Behavior (Event-Oriented)(Event-Oriented)

Activity Diagram: Captures Dynamic Behavior Activity Diagram: Captures Dynamic Behavior (Activity-Oriented)(Activity-Oriented)

SWA-1.13

CSE333

Component DiagramComponent Diagram

SWA-1.14

CSE333

Deployment DiagramDeployment Diagram

SWA-1.15

CSE333

Collaboration DiagramCollaboration Diagram

SWA-1.16

CSE333

Statechart DiagramStatechart Diagram

SWA-1.17

CSE333

Activity DiagramActivity Diagram

SWA-1.18

CSE333

Augmenting Diagrammatic Augmenting Diagrammatic RepresentationsRepresentations

Diagrams are Not Standalone ArtifactsDiagrams are Not Standalone Artifacts Diagrams are Supplemental Tool Diagrams are Supplemental Tool Important Tool in Overall Specification of Important Tool in Overall Specification of

RequirementsRequirements Clear Mapping Between Diagram and SpecsClear Mapping Between Diagram and Specs Initial Diagrams Form Basis forInitial Diagrams Form Basis for

Understanding System Refining and Elaborating Detailing Lower Level Issues

Explanation and Communication Vehicle!Explanation and Communication Vehicle!

SWA-1.19

CSE333

Software Design LevelsSoftware Design Levels

Architecturally:Architecturally: Modules Interconnections Among Modules Decomposition into Subsystems

Code:Code: Algorithms/Data Structures Tasking/Control Threads

Executable:Executable: Memory Management Runtime Environment

Is this a Realistic/Accurate View?Is this a Realistic/Accurate View?

SWA-1.20

CSE333

Software Engineering - an Oxymoron?Software Engineering - an Oxymoron?

Is there any Engineering?Is there any Engineering? Is there any Science?Is there any Science? Collection of Disparate Techniques:Collection of Disparate Techniques:

Data-Flow Diagrams E-R Diagrams Finite State Machines Petri Nets UML Class, Object, Sequence, Etc.

What is being “Engineered”?What is being “Engineered”?

SWA-1.21

CSE333

What is Engineering?What is Engineering?

Practitioners Create Cost-Effective Solutions to Practitioners Create Cost-Effective Solutions to Problems at All Levels of ComplexityProblems at All Levels of Complexity

Some Key Issues: Some Key Issues: Reliability Utilization of Available Technologies Application of Scientific Knowledge Tangible System, Building, Process, etc. “Service of Mankind!”

Engineering might Result in New Scientific Engineering might Result in New Scientific Discoveries Which are then Fed-back into ProcessDiscoveries Which are then Fed-back into Process

SWA-1.22

CSE333

What about Software Engineering?What about Software Engineering?

What Classifies Successes?What Classifies Successes? What Identifies Failures?What Identifies Failures? Some Key Issues: Some Key Issues:

Does Feedback Occur to Benefit Subsequent Projects for Either Successes or Failures?

Have Successes Generated New Science (Software) that can be Reused?

Is there Enough “Engineering” in Software?Is there Enough “Engineering” in Software? How can we Increase the Rigor and Engineering of How can we Increase the Rigor and Engineering of

Software?Software?

SWA-1.23

CSE333

Engineering + ScienceEngineering + Science

Synergistic Relationship for SuccessSynergistic Relationship for Success Gains in One Benefit OtherGains in One Benefit Other Influenced by Management and ResourcesInfluenced by Management and Resources Engineering Generates Problems for ScienceEngineering Generates Problems for Science Science Provides Workable Solutions that can be Science Provides Workable Solutions that can be

EngineeredEngineered While Science can Exist in Vacuum, “Good” While Science can Exist in Vacuum, “Good”

Science Needs Application to Prove UtilityScience Needs Application to Prove Utility

SWA-1.24

CSE333

What's Available to Support Engineering What's Available to Support Engineering of Software?of Software?

Specification (Abstract Models, Algebraic Specification (Abstract Models, Algebraic Semantics)Semantics)

Software Structure (Bundling Representation with Software Structure (Bundling Representation with Algorithms)Algorithms)

Languages Issues (Models, Scope, User-Defined Languages Issues (Models, Scope, User-Defined Types)Types)

Information Hiding (Protect Integrity of Information Hiding (Protect Integrity of Information)Information)

Integrity Constraints (Invariants of Data Integrity Constraints (Invariants of Data Structures)Structures)

Is this up to date? Is this up to date? What else can be Added to List?What else can be Added to List?

SWA-1.25

CSE333

Engineering Success in ComputingEngineering Success in Computing

Compilers Have Had Great SuccessCompilers Have Had Great Success Originally by Hand Then Compiler Compilers Parser Generators - Lex/Yacc

Solid Science Behind CompilersSolid Science Behind Compilers Regular, Context Free, Context Sensitive

Languages FSAs, PDAs, CFGs, etc.

Science has Provided Engineering Success re. Ease Science has Provided Engineering Success re. Ease and Accuracy of Modern Compiler Writingand Accuracy of Modern Compiler Writing

SWA-1.26

CSE333

History of ProgrammingHistory of Programming

What have Been Successes?What have Been Successes? C - Still Remains Industry StronghorseC - Still Remains Industry Stronghorse

Separate Compilation Decomposition of System into Subsystems, etc. Shared Declarations

But, Lack of Language Support within Compiler!But, Lack of Language Support within Compiler! For Example, You Can do ADTs in C, But For Example, You Can do ADTs in C, But

Compiler won't Enforce ThemCompiler won't Enforce Them

SWA-1.27

CSE333

Next GenerationNext Generation

Modula-II and Ada 83 HadModula-II and Ada 83 Had Information Hiding Public/Private Paradigm Module/Package Concepts Import/Export Paradigm

Great Strides in Adding Rigor Enforced by Great Strides in Adding Rigor Enforced by CompilerCompiler

However, Lacking:However, Lacking: Bind/Group Modules into Subsystems Precisely Specify Interconnections and

Interactions Among Subsystems and Components

SWA-1.28

CSE333

Current GenerationCurrent Generation

C++, Ada95, JavaC++, Ada95, Java How do they Rate?How do they Rate? What Do they Offer that Hasn't been Offered What Do they Offer that Hasn't been Offered

Before?Before? What are Unique Benefits and Potential of Java?What are Unique Benefits and Potential of Java? However, They are notHowever, They are not

Module Interconnection Languages (MILs) Interface Definition Languages (IDLs)

SWA-1.29

CSE333

What's Next Step?What's Next Step?

Architectural Description LanguagesArchitectural Description Languages Go Beyond MILs to Provide Tools to Describe

Architectures Definition and Communication

Codification of Architectural ExpertiseCodification of Architectural Expertise Frameworks for Specific DomainsFrameworks for Specific Domains DB vs. GUI vs. Embedded vs. C/SDB vs. GUI vs. Embedded vs. C/S Formal Underpinning for Engineering RigorFormal Underpinning for Engineering Rigor

SWA-1.30

CSE333

Potential Development BenefitsPotential Development Benefits

Recognize Commonalities to Allow New Systems Recognize Commonalities to Allow New Systems to be Built as Variants of Existing Systemsto be Built as Variants of Existing Systems

A Correct SW Architecture Early Benefits Design A Correct SW Architecture Early Benefits Design by Allowing Key Areas to be Understood and by Allowing Key Areas to be Understood and AnalyzedAnalyzed

Leads to Better Designs by SW Engineers when Leads to Better Designs by SW Engineers when Faced with Design Alternatives (with Pros/Cons)Faced with Design Alternatives (with Pros/Cons)

Potential to Server as a Communication Medium Potential to Server as a Communication Medium Between Software Engineers and CustomerBetween Software Engineers and Customer

SWA-1.31

CSE333

Potential Reuse/Maintenance BenefitsPotential Reuse/Maintenance Benefits

Reuse- By Extending from MILs/IDLs to ADLs, Reuse- By Extending from MILs/IDLs to ADLs, Attempt to Focus on Next Level of Software Attempt to Focus on Next Level of Software ReuseReuse

Leads to Greater Potential for SW Factory Leads to Greater Potential for SW Factory ConceptsConcepts

Improvements During Specification and Design Improvements During Specification and Design Leads to Better Understanding of System, Leads to Better Understanding of System, Documentation, etc.Documentation, etc.

This Yields SW that Can be Learned and This Yields SW that Can be Learned and Understood for Maintenance and EvolutionUnderstood for Maintenance and Evolution

SWA-1.32

CSE333

Concluding RemarksConcluding Remarks

Successful SW Engineering Must Be Influenced Successful SW Engineering Must Be Influenced Very Strongly by Science/Engineering Interplay to Very Strongly by Science/Engineering Interplay to Upgrade DisciplineUpgrade Discipline

MILs/IDLs a First StepMILs/IDLs a First Step Must Transition to ADLs to Add Rigor to ProcessMust Transition to ADLs to Add Rigor to Process ADLs can Offer ADLs can Offer

Architectural Styles to Speed Development Matching of Problem Statement to Style Case Studies/Experiences of Prior Efforts