asst.prof. dr. surasak mungsing. the role of software our civilization runs on software innovation...
TRANSCRIPT
The role of softwareThe role of softwareOur civilization runs on software
Innovation to capture new valueImproving productivity of resources deployed
The privilege and responsibility of the software professional
Number of software professional worldwideNumber of software professional worldwide
Number of IT professionals worldwide
y = -128.47x3 + 12800x2 - 59294x + 146623
0
2,000,000
4,000,000
6,000,000
8,000,000
10,000,000
12,000,000
14,000,000
16,000,000
Number of IT professionals worldwide(assumptions)
Poly. (Number of IT professionalsworldwide (assumptions))
(Source: Grady Booch, IBM Fellow)
SLOC/developer/yearSLOC/developer/yearNew or modified source lines of code per year per developer
y = -0.0328x3 + 4.8392x2 - 67.596x + 1062.8
0
1,000
2,000
3,000
4,000
5,000
6,000
7,000
8,000
1945
1947
1949
1951
1953
1955
1957
1959
1961
1963
1965
1967
1969
1971
1973
1975
1977
1979
1981
1983
1985
1987
1989
1991
1993
1995
1997
1999
2001
2003
2005
New or modified source lines of code per year( per developer)assumptions
Poly. (New or modified source lines of code per(( year per developer)assumptions
(Source: Grady Booch, IBM Fellow)
New or modified SLOC/year and cumulativeNew or modified SLOC/year and cumulativeNew or modified source lines of code per year per developer & cumulative
0
100,000,000,000
200,000,000,000
300,000,000,000
400,000,000,000
500,000,000,000
600,000,000,000
700,000,000,000
800,000,000,000
New or modified source lines of code peryear
Cumulative source lines of code
(Source: Grady Booch, IBM Fellow)
Dimensions of software complexityDimensions of software complexityHigher technical complexity - Embedded, real-time, distributed, fault-tolerant - Custom, unprecedented, architecture reengineering - High performance
Lower technical complexity - Mostly 4GL, or component-based - Application reengineering - Interactive performance
Highermanagement complexity - Large scale - Contractual - Many stake holders - “Projects”
Lowermanagement complexity - Small scale - Informal - Single stakeholder - “Products”
Defense MIS System
Defense Weapon SystemTelecom
Switch
CASE Tool
National Air TrafficControl System
Enterprise IS(Family of ISApplications)
CommercialCompiler
BusinessSpreadsheet
IS ApplicationDistributed Objects
(Order Entry)
Small ScientificSimulation
Large-ScaleOrganization/Entity
Simulation
An average software project - 5-10 people - 3-9 month duration - 3-5 external interfaces - Some unknowns & risks
EmbeddedAutomotive
Software
IS ApplicationGUI/RDB
(Order Entry)
(Source: Grady Booch, IBM Fellow)
Creating the illusion of simplicityCreating the illusion of simplicity
(Source: Grady Booch, IBM Fellow)
Architecting a dog house Architecting a dog house
Can be built by one personRequires
Minimal modelingSimple processSimple tools
Kruchten
Architecting a house
Built most efficiently and timely by a teamRequires
ModelingWell-defined processPower tools
Kruchten
DDifferencesifferencesScaleProcessCostScheduleSkills and development teamsMaterials and technologiesStakeholders Risks
Architecture is EarlyArchitecture is EarlyArchitecture represents the set of earliest
design decisionsHardest to changeMost critical to get right
Architecture is the first design artifact where a system’s quality attributes are addressed
Architecture DrivesArchitecture DrivesArchitecture serves as the blueprint for the
system but also the project:Team structureDocumentation organizationWork breakdown structureScheduling, planning, budgetingUnit testing, integration
Architecture establishes the communication and coordination mechanisms among components
Software ArchitectureSoftware ArchitectureSoftware architecture is what software architects
doAnother GoSoftware architecture encompasses the set of
significant decisions about the organization of a software systemSelection of the structural elements and their interfaces by
which a system is composedBehavior as specified in collaborations among those elementsComposition of these structural and behavioral elements into
larger subsystemsArchitectural style that guides this organization
Beck
Formal DefinitionIEEE 1471-2000
Software architecture is the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution
IEEE 1471-2000
Software Architecture DefinitionSoftware Architecture DefinitionDefinition
A software system’s architecture is the set of principal design decisions about the system.
Software architecture is the blueprint for a software system’s construction and evolution.
Design decisions encompass every aspect of the system under development. This includes design decisions related to Structure Behavior Interaction Non-functional properties
Other Definitions of Software ArchitectureOther Definitions of Software Architecture
Perry and WolfSoftware Architecture = { Elements, Form, Rationale }
what how whyShaw and Garlan
Software architecture [is a level of design that] involves the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on these patterns.
KruchtenSoftware architecture deals with the design and
implementation of the high-level structure of software.Architecture deals with abstraction, decomposition,
composition, style, and aesthetics.
Prescriptive vs. Descriptive ArchitecturePrescriptive vs. Descriptive Architecture A system’s prescriptive architecture captures
the design decisions made prior to the system’s construction. It is the as-designed or as-intended architecture.
A system’s descriptive architecture describes how the system has been built. It is the as-implemented or as-realized architecture.
“… about the structure of the system”
Why prescriptive architecture?Why prescriptive architecture?Act as the set of rules by which all
stakeholders have to play“rules of the road” for various projects within
organization to align well with business goalsAct as the technology product blueprint
for intranet application: list of products to buyReduces deployment risk for organization
tried and tested models“…architecture is about principles and
guidelines”
Architectural EvolutionArchitectural Evolution When a system evolves, ideally its prescriptive
architecture is modified first. Unfortunately often the system and thus its
descriptive architecture is often directly modified.
This failure of update happens because of Developer sloppiness Perception of short deadlines which prevent thinking
through and documenting Lack of documented prescriptive architecture Need or desire for code optimizations Inadequate techniques or tool support
Architectural Drift and Architectural ErosionArchitectural Drift and Architectural Erosion
Definition. Architectural drift involves architectural design decisions that are applied directly to a system’s descriptive architecture, but are not properly reflected in the system’s prescriptive architecture.
Leads to inadaptability; results in lack of coherence
Definition. Architectural erosion involves architectural design decisions that are applied directly to a system’s descriptive architecture, and that violate design decisions captured by the system’s prescriptive architecture. E.g., “load bearing walls”
Leads to disastrous results
Architectural RecoveryArchitectural Recovery
If drift or erosion are allowed to occur, the development organization is likely to be forced to recover the system’s architecture sooner or later.
Definition. Architectural recovery is the process of determining a software system’s architecture from its implementation-level artifacts.
Implementation-level artifacts can be Source code Executable files Java .class files
DeploymentDeployment
A software system cannot fulfill its purpose until it is deployed, that is, until its executable modules are physically placed on the hardware devices on which they are supposed to run.
The deployment view of an architecture can be critical in assessing whether the system will be able to satisfy its requirements.
Possible assessment dimensions Sufficient memory Power consumption Available and required bandwidth
Software Architecture’s ElementsSoftware Architecture’s Elements
A software system’s architecture typically is not (and should not be) a uniform monolith.
A software system’s architecture should be a composition and interplay of different elements
Processing Data, also referred as information or state Interaction
ComponentComponent
Elements that encapsulate processing and data in a system’s architecture are referred to as software components.
Definition. A software component is an architectural building block that encapsulates a subset of the system’s functionality and/or data, and restricts access to them via an explicitly defined interface.
ConnectorConnector
In complex systems interaction might become more important and challenging than the functionality of the individual components.
Definition. A software connector is an architectural building block tasked with regulating interactions among components.
In traditional, desktop software systems, connectors would have usually manifested themselves as simple procedure calls or shared data accesses.
Connector ExamplesConnector Examples Connector Examples
Procedure call connectors Shared memory connectors Message passing connectors Streaming connectors (e.g.. stream music from
devices) Distribution connectors (distribute s/w to
clients) Wrapper connectors (data, object wrapper)
Components provide application-specific services.
Connectors are application-independent.
ConfigurationConfiguration
Components and connectors are composed in a specific way in a given system’s architecture to accomplish that system’s objective.
Definition. Architectural configurations, or topologies, capture architectural structure via graphs whose nodes represent components and connectors, and whose edges represent their interconnectivity that describes architectural structure.
Architectural StyleArchitectural Style Observation
Certain design choices regularly result in solutions with superior properties.
Compared to other possible alternatives, solutions such as this are more elegant, effective, efficient, dependable, evolvable, scalable, and so on.
Definition. An architectural style is a named collection of architectural design decisions that
are applicable in a given development context constrain architectural design decisions that are
specific to a particular system within that context elicit beneficial qualities in each resulting system.
Architectural PatternArchitectural Pattern
Definition. An architectural pattern is a set of architectural design decisions that are applicable to a recurring design problem, and parameterized to account for different software development contexts in which that problem appears.
An example pattern that is used widely in modern distributed systems is the three-tiered system pattern.
Three-tiered system applications science, banking, e-commerce, reservation
systems
Three-tiered architectural patternThree-tiered architectural pattern
Front Tier: functionality to access the system’s services
Middle Tier: contains the application’s major functionality
Back Tier: contains the application’s data access and storage functionality.
Architectural Models, Views, and VisualizationsArchitectural Models, Views, and Visualizations Architecture Model
An artifact documenting some or all of the architectural design decisions about a system (structural, process, interface, and deployment)
Architecture Visualization A way of depicting some or all of the
architectural design decisions about a system to a stakeholder. E.g. Structure101
Architecture View A set of elements and the relations among them;
module, components and connectors, allocation view.
Architectural ProcessesArchitectural Processes
Architectural Analysis encompasses activities such as:
Determining whether the set of design decisions comprising an architecture are consistent
Determining whether an implemented system conforms to the set of design decisions in the architecture
Architectural Evolution: The process of modifying the architectural
design decisions for a system.
Scope of Software ArchitectureScope of Software ArchitectureEvery system has an architectureDetails of the architecture are a reflection of
system requirements and trade-offs made to satisfy them
Possible decision factorsPerformanceCompatibility with legacy softwarePlanning for reuseDistribution profile
Current and futureSafety, security, fault tolerance requirementsEvolvability needs
Changes to processing algorithms Changes to data representation Modifications to the structure/functionality
What Makes a “Good” Architecture?What Makes a “Good” Architecture?Process observations:
Product of architect(s)List of quality attributes and functional
requirementsArchitecture is well-documentedCirculated to stakeholdersAnalyzed for quantitative measure and evaluate
for quality attributesResults in a specific set of resource contention
areas (e.g. network utilization)
Product observations:Well-defined modules with well-defined
interfaceAchieve quality attributes using architectural
strategyShould not depend on particular version of a
commercial productAllows modifiabilityFeature well-defined processes or tasks
What Makes a “Good” Architecture?What Makes a “Good” Architecture?
Why is SA Important?Communication among stakeholdersEarly design decisionsTransferable abstraction of a system
Every interesting software-intensive system has an architecture
The most successful software architectures are intentional, manifest, and visible - and beautiful
SummarySummary
Commercial softwareCommercial softwareless commonly, payware, is computer
software that is produced for sale or that serves commercial purposes.
is most often proprietary software, but free software packages may also be commercial software
All or parts of software packages and services that support commerce are increasingly made available as free software
Commercial off-the-shelf
Selecting off-the shelf componentsSelecting off-the shelf componentsThe high-level selection process begins with the practice of
locating candidates.
Selecting off-the-shelf components that fit well together in a new system requires evaluating each candidate off-the-shelf component to ensure the component not only meets functional and quality requirements but also is compatible with other components in the system.
Application integrators manage processes and knowledge to ensure successful component selection, component integration, and component maintenance.
For systems designed using off-the-shelf component types, with known cost, reliability, and weight, system design and component selection becomes a combinatorial optimization problem.
ERPERP
Enterprise resource planning (ERP) integrates internal and external management information across an entire organization, embracing finance/accounting, manufacturing, sales and service, customer relationship management, etc. ERP systems automate this activity with an integrated software application. Its purpose is to facilitate the flow of information between all business functions inside the boundaries of the organization and manage the connections to outside stakeholders.[
SAP System ArchitectureSAP System ArchitectureDivide into three layers, which make up the basic services of a business application system:
Presentation layer enables the user to interact with the relevant application
Applications are executed in the application layer
Data to be processed is managed by the database layer
SAP R/3 : Basis SystemSAP R/3 : Basis System
SAP R/3 ในส่�วนของ Basis (คำ��ว�� Basis
ในระบบ SAP ก็�คำ�อส่�วน System
Administration ในระบบ SAP R/3 ) ส่��งแรก็ที่��ต้�องร� �คำ�อ SID ของระบบ SAP ซึ่��งใน SID
ของระบบ SAP R/3 จะประก็อบไปด้�วย 3 ส่�วน ส่�วนแรก็ คำ�อ Presentation Server ซึ่��ง
ก็�คำ�อในส่�วนของหน��จอ GUI
ส่�วนที่��ส่องคำ�อ Application Server
หร�อส่�วนของ SAP R/3 Instance ส่�วนน�#คำ�อ Kernel ในระบบ SAP เป%นส่�วนที่��ที่��ง�นในด้��น Application Logic ของโปรแก็รม ABAP
ส่�วนส่(ด้ที่��ยคำ�อ Database Server ซึ่��งเป%นส่�วนที่��เก็�บข�อม�ลที่*#งหมด้ในระบบ SAP R/3
Architecture of the SAP Web Application ServerArchitecture of the SAP Web Application Server
Installation Options
• SAP Web Application Server ABAP System. In the graphic these are the components in the yellow box on the left.• SAP Web Application Server Java System. In the graphic these are the components in the green box on the right.• SAP Web Application Server ABAP+Java System. These are all the components of the graphic.