Software Architectures. Lectures 8+9
|
|
- Madison Allison
- 5 years ago
- Views:
Transcription
1 Software Architectures Lectures 8+9
2 2 Roadmap of the course What is software architecture? Designing Software Architecture Requirements: quality attributes or qualities How to achieve requirements : tactics How do tactics lead to architectural styles Case studies on architectural styles, observed the achieved qualities The ADD method Evaluating an architecture Documenting software architecture Bass et al Hofmeister et al Today we wrap up: ADLs, PLs, COTS, SAr
3 Linguistic character of architectural description Idiomatic constructs in different architectures common kinds of elements common inter-module connection strategies Languages describe complex relations among primitive elements and combinations of these Semantic constructs => There is an appropriate linguistic basis in architectural descriptions
4 Common patterns of SW organization SA description often Box-and-line diagrams boxes major components lines communication, control, data relation Boxes and lines may mean different things For different described systems For different people Supplemented with prose, no precise meaning Informal terms Still useful
5 Common component classes (pure) Computation Simple input/output relations, no retained state Exp: Math functions, filters, transforms Memory Shared collection of persistent structured data Exp: Database, file system, symbol table, hypertext Manager State and closely related operations Exp: Abstract data type, servers Controller Governs time sequences of other s events Exp: Scheduler, synchronizer Link Transmits information between entities Exp: Communication link, user interface
6 Common interactions among components Procedure call Single thread of control passes among definitions Exp: Ordinary procedure call, remote procedure call Dataflow Independent processes interact through streams of data Exp: Unix pipes Implicit invocation Computation is invoked by the occurrence of an event; no explicit interactions among processes Exp: Event systems, automatic garbage collection Message passing Independent processes interact by explicit, discrete hand-off of data; may be synchronous or asynchronous Exp: TCP/IP Shared data Components operate concurrently (probably with provisions for atomicity) on the same data space Exp: Blackboard systems, multiuser databases Instantiation Instantiator uses capabilities of instantiated definition by providing space for state required by instance Exp: using abstract data types
7 Critical elements of a design language A (programming) language requires Components Primitive semantic elements and their values Exp: integers, floating-point numbers, strings, records, arrays Operators Functions that combine components Exp: iteration, conditional constructs, +,-,*,/ Abstraction Rules for naming expressions of components and operators Exp: definition of macros and procedures Closure Rules to determine which abstractions can be added to the classes of primitive components and operators Exp: procedures or user-defined types - first class entities Specification Association of semantics to the syntactic form Formal, informal (in reference manual)
8 The language problem for SA SA deals with Allocation of functionality to components Data and communication connectivity Quality attributes and system balance Quite different from the (conventional) programming language concerns Specific forms of the various language elements are also different
9 Critical elements of a SA design language Components Module-level elements; component classes listed before Operators Interaction mechanisms as listed before Patterns/ abstraction Compositions in which code elements are connected in a particular way; Exp: client-server relation Closure Conditions in which composition can serve as a subsystem in development of larger systems Specification Not only of functionality, but also of quality attributes
10 Implication of the critical elements Basis for designing ADLs provided by Identification of architectural components Identification of architectural techniques, for combining them into subsystems and systems Such a language would support Simple expressions of connections among simple modules, plus Subsystems Configurations of subsystems into systems Common paradigms for such combinations Expression of quality attributes and functional properties
11 Requirements for ADLs 1. To provide models, notations, tools to describe architectural components and their interactions 2. To handle large-scale, high-level designs 3. To support the adaptation of designs to specific implementations 4. To support user-defined abstractions 5. To support application-specific abstractions 6. To support the principled selection of architectural paradigms
12 ADL and environment Close relation between ADL and its environment ADL: precise descriptions Environment: (re)uses the descriptions Ideal ADL should support Composition Abstraction Reusability Configuration Heterogeneity Analysis
13 Composition Describe a system as composition of independent components and connections Aspects Divide a complex system (hierarchically) into smaller parts Assemble a large system from constituent elements Independent elements Can be understood in isolation from the system Separate issues of implementation-level from those of architectural level
14 Composition, 2 Another name: modularity Closure rule: can see entities as both primitives and composites At different levels of abstraction Independence rule: can reuse parts of a composite
15 Composition, 3 Need for explicit and abstract composition rules Pipe and filter Sequence of pipes and filters Layered systems Collection of abstract layers interacting according to certain rules Filter can internally be decomposed in Another pipe and filter system Instance of something else Filter may be used in any data stream transformation system Pipe may be used for any data transmission
16 Abstraction Allows to describe the abstract roles of elements and their interaction within SA at a level well understood by designers Clearly Explicitly Intuitively Suppress unneeded detail but reveal important properties high-level pgm languages: register usage suppressed, sequential control flow abstractions revealed Interface: suppresses implementation issues, reveals use dependencies
17 Abstraction, 2 Necessary to represent new architectural patterns and new forms of interaction between them as first class abstractions Architectural level of design Different form of abstraction, to reveal high-level structure Distinct roles of each element in the high-level structure are clear Example: client-server relationship
18 Reusability Reuse components, connectors, architectural styles in different architectural descriptions Reuse generic patterns of components and connectors Families of SA as open-ended sets of architectural elements Structural and semantic constraints Differs with respect to reusing components from libraries Those are completely closed / parameterized components, retain identities, are leaves of is-composed-of system structure Reusing generic patterns of components and connectors: further instantiation, indefinite replication of relations, reuse of structured collections of internal nodes
19 Reusability, 2 Systems rarely conceived in isolation Instances of a family of similar systems that share many architectural properties Shared properties Structural: specific topology of component and connectors Constraints on using certain architectural elements We need parameterized collections of modules Eg: pipeline architecture: has pipes, filters and constrains topology to be linear
20 Configuration Architectural descriptions should localize the description of system structure Independently of the elements being structured Dynamic reconfiguration permissible Evolvability Create/remove components, interactions initiated Allows to understand and change architectural structure Without examining individual components ADL: should separate descriptions of compositions from those of elements Reason about composition as a whole
21 Heterogeneity Combine multiple, heterogeneous architectural descriptions Ability to combine different architectural styles in a single system Component A communicates with component B via a pipe, but also accesses a shared database with a query Different levels of architectural description should be allowed to use different architectural idioms Ability to combine components written in different languages Architectural description is at a higher level of abstraction than the algorithms and data structures used for implementation
22 Analysis Possible to perform rich and varied analyses of architectural descriptions Each style facilitates a certain type of properties Pipe and filter: possible to analyze throughput, investigate deadlock and resource usage, deduce the system I/O behavior from that of the filters Should be possible to tailor special purpose analysis tools to architecture types Automated and non-automated reasoning about architectural descriptions
23 Analysis, 2 Important for architectural formalisms Many of the interesting architectural properties are dynamic Exp If connector associated with protocol, is the use of connector correct in its context? Timing, performance, resource usage may aid in reasoning if SA adequate Variety of analyses => no single semantic framework will be enough Should be possible to associate specifications with architectures as they become relevant to particular components, connectors, styles
24 First-class connectors: needed SA treats SW systems as composition of components Focus on components Description of interactions among components is implicit, distributed, hard to identify When interfaces explicit: import/export lists of data and procedures Implicit interactions: include files => Info organized around components, significance of interactions, connections is ignored
25 Problems with this practice 1. Inability to localize info about interactions 2. Poor abstractions 3. Lack of structure on interface definitions 4. Mixed concerns in programming language specification 5. Poor support for components with incompatible packaging 6. Poor support for multi-language or multiparadigm systems 7. Poor support for legacy systems
26 Fresh view of software system composition Systems composed of identifiable components of various distinct types These interact in identifiable, distinct ways Correspond to compilation units (roughly) Connectors mediate interactions among components Establish rules that govern component interaction Specify any auxiliary mechanisms required Do not correspond to compilation units
27 Connectors Manifest as Table entries Instructions to a linker Dynamic data structures System calls Initialization parameters Servers with multiple independent connections Define a set of roles that specific named entities of the components must play
28 Connectors, 2 Place of relations among components Mediate interactions Have protocol specifications defining their properties Rules about types of interfaces they are able to mediate for Assurances about properties of interactions Rules about order in which things happen Commitments about interaction (ordering, performance, etc) Are of some type/subtype Roles to be satisfied: specific, visible named entities in the protocol of a connector
29 Components Place of computation and state Have interfaces specifying their properties Signatures Functionality of resources Global relations Performance properties Are of some type/subtype Interface points: specific, visible named entities in the interface of a component
30 Primitive vs composite: components Primitive components coded in the programming language Composite components define configurations in independent notation Constituent components and connectors identified Match connection points of components with roles of connectors Check integrity of the above
31 Primitive vs composite: connectors Of different kinds Shared data representations Remote procedure calls Dataflow Document-exchange standards Standardized network protocols Rich enough set to require taxonomy to show relations among similar connector kinds
32 Primitive connectors Built-in mechanisms of programming languages System functions of the OS Shared data Entries in task/routing tables Interchange formats for static data Initialization parameters etc
33 Summing up principles for ADL Purpose: define roles and relationships instead of algorithms and data structures Must support System configuration Independence of entities (reusability) Abstraction Analysis of functional properties and QA Has syntax and Defines semantics for connectors and their compositions Generalize from import/export rules to rules with symmetry, multiplicity, abstraction, locality, naming Defines type structures for system organizations, components, connectors, primitive units of associations of these Sets out appropriate rules for architectural abstractions
34 Large grained structure of ADL Component Interface Component type Player Implementation Connector Protocol Connector type Role Implementation
35 On ADL structure Specify whether element primitive Not further defined at architectural level, but implemented in a programming language Non-primitive element Implementation: list of parts, composition instructions, related specs => no more name matching
36 Architecture Description Languages The positives ADLs provide a formal way of representing architecture ADLs are intended to be both human and machine readable ADLs support describing a system at a higher level than previously possible ADLs permit analysis of architectures completeness, consistency, ambiguity, and performance ADLs can support automatic generation of software systems The negatives There is no universal agreement on what ADLs should represent, particularly wrt the behavior of the architecture Representations currently in use are relatively difficult to parse and are not supported by commercial tools Most ADL work today has been undertaken with academic rather than commercial goals in mind Most ADLs tend to be very vertically optimized toward a particular kind of analysis 36
37 Software Architecture: ADL Perspective The ADL community generally agrees that Software Architecture is a set of components and the connections among them. components connectors configurations constraints
38 ADLs Leading candidates ACME (CMU/USC) Rapide (Stanford) Wright (CMU) Unicon (CMU) Secondary candidates Aesop (CMU) MetaH (Honeywell) C2 SADL (UCI) SADL (SRI) Others Lileanna UML Modechart
39 ACME Acme was developed jointly by Monroe, Garlan (CMU) and Wile (USC) Acme is a general purpose ADL originally designed to be a lowest common denominator interchange language Now common interchange format for architecture design tools foundation for developing new architectural design and analysis tools simple architectural descriptions Acme language and Acme Tool Developer's Library (AcmeLib) provide a generic, extensible infrastructure for describing, representing, generating, and analyzing software architecture descriptions
40 An ADL Example (in ACME) System simple_cs = { Component client = {Port send-request} Component server = {Port receive-request} Connector rpc = {Roles {caller, callee}} Attachments : {client.send-request to rpc.caller; server.receive-request to rpc.callee} } rpc client send-request caller callee server receive-request
41 Rapide Developed by David Luckham, Stanford General purpose ADL designed with an emphasis on simulation yielding partially ordered sets of events (posets) Fairly sophisticated, including data types and operations Rapide analysis tools focus on posets matching simulation results against patterns of allowed/prohibited behaviors some support for timing analysis focus on causality Rapide has some generation capability since Rapide specifications are executable Rapide has a fairly extensive toolset
42 The Rapide Model Concurrent, object-oriented, event-based simulation language Defines and simulates behavior of distributed object system architectures Produces a simulation represented by a set of events (poset) Events are ordered with respect to time and causality System requirements are expressed as constraints on time and concurrent patterns of events Posets enable visualization and analysis of an execution
43 Rapide Architectural Elements 43 Components components Architecture connections constraints Components interface Component interface architecture interface module
44 Rapide Architectural Elements, 2 Components Interface objects Architecture that implements an interface Module that implements an interface Connections Connects sending interfaces to receiving interfaces Components communicate through connections by calling actions or functions in their own interface Events generated by components trigger event pattern connections between their interfaces Three types of connections: Basic connections Pipe connections Agent connections
45 Architectural Elements (cont d) Interface Components provides part requires part Components action part service part Components behavior part functions objects types in actions out actions state state transitions constraint part Components private part pattern constraints interface with no private part
46 A Simple Specification in Rapide type Producer (Max : Positive) is interface action out Send (N: Integer); action in Reply(N : Integer); behavior Start => send(0); (?X in Integer) Reply(?X) where?x<max => Send(?X+1); end Producer; type Consumer is interface action in Receive(N: Integer); action out Ack(N : Integer); behavior (?X in Integer) Receive(?X) => Ack(?X); end Consumer architecture ProdCon() return SomeType is Prod : Producer(100); Cons : Consumer; connect (?n in Integer) Prod.Send(?n) => Cons.Receive(?n); Cons.Ack(?n) => Prod.Reply(?n); end architecture ProdCon;
47 Wright Developed by David Garlan at CMU Wright is a general purpose ADL designed with an emphasis on analysis of communication protocols Uses a variation of CSP to specify the behaviors of components, connectors, and systems CSP - Communicating Sequential Processes, process algebra developed by C. A. R. Hoare Focuses primarily on the basic component/connector/system paradigm Similar syntactically to ACME and Aesop Wright analysis focuses on analyzing the CSP behavior specifications. Any CSP analysis tool or technique could be used to analyze the behavior of a Wright specification Wright does not currently have a generation capability Wright has minimal native tool support (but CSP tools could be used)
48 A Simple Specification in Wright System simple_cs Component client = port send-request = [behavioral spec] spec = [behavioral spec] Component server = port receive-request= [behavioral spec] spec = [behavioral spec] Connector rpc = role caller = (request!x -> result?x ->caller) ^ STOP role callee = (invoke?x -> return!x -> callee) [] STOP glue = (caller.request?x -> callee.invoke!x -> callee.return?x -> callee.result!x -> glue) [] STOP Instances s : server c : client r : rpc Attachments : client.send-request as rpc.caller server.receive-request as rpc.callee end simple_cs.
49 UML as an ADL The Positive lowers entry barrier, mainstreams modeling, tools Shortcomings of UML as an ADL Weakly integrated models with inadequate semantics for (automated) analysis Connectors are not first class objects Visual notation with little generation support, hidden and ambiguous relationships between views, both too much and too little
50 Hence There is a rich body of research to draw upon Much has been learned about representing and analyzing architectures Effort is needed now to bring together the common knowledge and put it into practice
51 For More Information ACME: Rapide: Wright: ex.html Aesop: op_home.html Unicon: C2 SADL: SSEP: ADML:
52 Formalisms Formal models and techniques are cornerstones of a mature engineering discipline Engineering disciplines used models and techniques in different ways Provide precise, abstract models Provide analytical techniques based on models Provide design notations Provide basis for simulations
53 What to formalize? Architecture of a specific system Allow the architect to plan a specific system Becomes part of the specification of the system Augments the informal characteristics of the SA Permits specific analyses of the system
54 What to formalize? Architectural style Describe architectural abstractions for families of systems Purposes: Make common idioms, patterns and reference architectures precise Show precisely how different architectural representations can be treated as specializations of some common abstraction
55 What to formalize Theory of software architecture Clarify the meaning of generic architectural concepts Architectural connection, hierarchical architectural representation, architectural style Provide deductive basis for analyzing systems at an architectural level Might provide rules for determining when an architectural description is well formed Compositionality
56 What to formalize Formal semantics of ADL:s Architectural description is a language issue Apply traditional techniques for representing semantics of languages
57 Some takeaway SA has a linguistic character Programming languages are useful for comparison Connectors are needed in addition to components ADLs may grow in the future
58 58 SW Product line (SW PL) Set of SW-intensive systems sharing a common, managed set of features that satisfy specific needs of particular market segment or mission and that are developed from a common set of core assets in a prescribed way
59 59 Why Product Lines? SA significant investment in time and effort Senior experience Want to maximize the return on this investment Reuse SA across multiple systems SA valuable intellectual property Can be leveraged to produce additional revenue, reduce costs
60 60 What does PL involve? Vision: set of reusable assets that include Base architecture Common, tailorable elements that populate it Designs, their documentations, user manuals, budgets, schedules, test plans, test cases etc Achieving vision depends critically on establishing the correct scope for the PL
61 61 What does PL imply? Successfully established PL Each reusable asset saved in core asset base To be applied to more than one system Reusing it cheaper than reinventing it Core assets designed with variation points Places where they can be tailored in preplanned ways System building becomes Accessing appropriate assets Tailoring them as required for system at hand Assembling the system The needed new SW (if any) accounts for about 20% of the total SW Integration and testing replace design and coding as predominant activities
62 62 Who does it? Boeing, Ford, Dell, McDonalds, etc Nokia: models/year (up from 4) Cummins, Inc: SW for diesel engine in 1 week from 1 year Motorola: 400% productivity improvement in a family of one-way pagers HP: time-to-market reduced 7 times, increased productivity 6 times for a printer family Family of satellite ground control systems: 10% of usual number of developers and 90% fewer defects (US National Reconnaissance Office)
63 63 What does it take to do a PL? Coordinated strategy involving SW engineering Technical management Organization management We check the SA aspects of SW engineering All aspects must work together
64 64 Scoping Scope of a PL Defines what systems are in it and what are out of it Statement about what systems an organization is willing to build as part of this PL and what systems is not willing to build The organization s best prediction on the products to build in foreseeable future Strategic planners, marketing staff, domain analysts (can catalog similar things, existing and planned), technology experts Doughnut analogy
65 65 Scope is critical For success of that PL Too narrow: insufficient nr of products derived to justify the development investment Too broadly: effort required to develop individual products from core assets to big to lead to great savings Scope can be refined During initial establishment of PL Opportunistically depending on PL adoption strategy
66 66 Defining scope Finding commonality Not between two systems That leads to substantially reduce cost of constructing systems that an organization intends to build Consider Systems to be built Market segmentation Type of assumed customer interactions
67 67 SA for PL SA in core asset repository: most central role Essence of building successful SW PL: discriminating between what is constant across all family members and what is expected to vary SA ready made for this duality SA is an abstraction that admits plurality of instances In SW PL: SA is an expression of the nonvarying aspects
68 68 SA for PL, cont. PL SA beyond this dichotomy Set of explicitly allowed variations (conventional SA: any instance will do as long as functionality and qualities are respected) PL SA s responsibility Identifying variation points May be substantial Variations in behavior, qualities, platform, network, physical configuration, middleware, scale factors, etc Provide built-in mechanisms for achieving them
69 69 PL SArchitect needs to consider Identifying variation points Supporting variation points Evaluating the architecture for PL suitability
70 70 Identifying variation points Ongoing activity Products can vary in many ways => variants can be identified at any time in the development process During requirements process Features, platforms, UI, qualities, target markets -> some are interdependent During design process Options for implementing the variations identified during requirements process Normal variations during design Some decisions deferred until more info is available During implementation Also during implementation of second (subsequent) products
71 71 Supporting variation points Inclusion / omission of elements Inclusion of a different number of replicated elements Selection of version of elements that have the same interface but different behavior/qualities Selection can occur at compile/build/runtime
72 72 Supporting variation points more sophisticated techniques OO-systems write generalizations and specializations of classes Building extension points into the element s implementation Introducing build-time parameters to an element Reflection Ability of a program to manipulate data on itself, its execution environment, or state Reflective programs can adjust their behavior based on their context Overloading Reusing named functionality to operate on different types Promotes code reuse; cost of understandability and code complexity
73 73 Supporting variation points - documentation For the PL SA as it resides in the core asset base For each product s SA (to the extent that it varies from PL architecture) Should clearly show its variation points Should also show rationale for each Scope definition used as justification Should describe architecture s instantiation process How its variation points are exercised
74 74 Evaluating the architecture for PL suitability PL SA should be evaluated for fitness or purpose Typical SA evaluation techniques work PL SA should be evaluated For robustness and generality To make sure it can serve as basis for products in PL s scope To make sure it meets qualities of product
75 75 What makes PLs work? Potential for reuse is broad Requirements Architectural design Elements Modeling and analysis Testing Project planning Processes, methods, tools People Exemplar systems Defect elimination
76 76 Building systems from OTS components Off-the-shelf Architecture should respect quality attributes Control over system design = control over achieved qualities?? Not true with OTS components OTS components used Economical reasons Change design process, constrain SA Typically to achieve some functionality They also embody architectural (quality) assumptions We need to discover assemblies of components that will work in concert With each other With system that integrates them
77 77 Impact of OTS components to SA Use of components Essential in many cases Also introduces new challenges Component capabilities and liabilities are constraining SA Example Chemical plant monitoring
78 78 Architectural mismatch Not all components work together Some only appear to, but give wrong results (subtle errors) Components not developed for the system at hand may not work Discovered after buying and trying to use them Interfaces notoriously poor at specifying quality attributes Architectural mismatch Impediment to successfully integrating component-based systems Mismatch between assumptions embodied in separately developed components Exp: which component invokes the other Shows up at integration time System will not compile, link, run
79 79 Interface mismatch General case of architectural mismatch Interface: assumptions components can make about each other Not the Java interface specification Assumptions Provide assumptions: services provided by the component to its user/clients Require assumptions: detail the services / resources needed for the component for working correctly Mismatch: provide and require assumptions do not match
80 80 What to do about interface mismatch Avoid mismatch by specifying and inspecting components for the system Detect cases not avoided by qualifying components Repair detected cases by adapting the components
81 81 Techniques for repairing interface mismatch Little systematic attention One obvious method Change the code of offending component Not often possible, not desirable even The other methods: insert code for one or both components that reconciles their interaction to solve the mismatch Wrappers Bridges Mediators
82 82 Wrappers A form of encapsulation where some component is encased within an alternative abstraction Clients access wrapped component services through an alternative interface Provided by the wrapper Yielding an alternative interface to the component
83 83 Interface translation for wrappers Translation of an element of a component interface into an alternative element Hiding an element of a component interface Preserving an element of a component s interface unchanged
84 84 Bridges Translate some require assumptions of some component into provide assumptions of another component Difference wrt to wrapper Repair code of bridge independent of any particular component Bridge must be explicitly invoked by some external agent Possibly one of the components the bridge spans Specific translation done at the time of bridge construction Compile time Bridges usually transient
85 85 Bridges and wrappers Bridges focus on narrower range of interface translations than wrappers Bridges address specific assumptions More assumptions => fewer components it applies to Script could be written to execute bridge Need to address component-specific interface peculiarities for both components Not a wrapper then
86 86 Mediators Exhibit properties of both wrappers and bridges Mediators incorporate a planning function Runtime determination of the translation Bridges establish translation at construction Mediators become a more explicit component in the overall SA Semantically primitive bridges: incidental repair mechanisms, their role in design remains implicit Semantically more complex mediators: runtime autonomy to be more first class in SA
87 Mediator examples 1. Intelligent data fusion: sensor generates high volume of high-fidelity data At runtime: different information consumers arise that have different operating assumptions about data fidelity Low-fidelity consumer: some info needs to be stripped Similar fidelity but different throughput characteristics requiring temporary buffering of data In each case the mediator accommodates differences between the sensor and its customers 2. Runtime assembly of sequence of bridges Integrate components with integration requirements at runtime One component produces data in format D0, another consumes data in format D2; if there is no bridge D0->D2, but separate D0->D1, D1->D2, these could be chained by a mediator
88 88 Techniques for detecting interface mismatch Identifying mismatches Enhanced form of component qualification Component qualification Process of determining whether a commercial component satisfies various fit for use criteria Prototype integration of candidate component Can discover subtle forms of interface mismatch, exp. resource contention
89 89 Component qualification Observation For each service provided by a component, a set of require assumptions must be satisfied Service convenient way of describing how component functionality is packaged for use Qualification process of Discovering all require assumptions for each service to be provided Ensuring that each require assumption is satisfied by some provide assumptions in the system
90 90 Techniques for avoiding interface mismatch From earliest phase of design Disciplined approach to specifying as many assumptions about an interface as feasible Assumptions state assertions about Sufficiency of services provided Implementability of each service (identifying resources needed)
91 91 Interfaces Interface: set of assumptions Different interfaces advantageous Parameterized interfaces Provide and require assumptions can be changed by changing value of variable before component service is invoked Result in adaptation code, both external and internal Negotiated interface Parameterized interface with self-repair logic
92 92 Component-based design as search Component based system design Search for compatible ensembles of COTS that can meet system objectives Flexibility in system requirements Beneficial to integration of component-based systems Important to know when certain requirement is essential to system success => not allow its compromise
93 93 Model problems Description of design context, defining the constraints of the implementation Required quality attributes included in the design context Model solution Prototype situated in a specific design context Several solutions to a problem possible Used by design teams Evaluation of ensembles to ensure Components can successfully be integrated They can support quality attribute objectives
94 94 SArchitect: what does it take? Technical aspects of designing SA put in the context of the organizational structure Many interactions Managers, system architects, SW developers, other SArchitects, marketing personnel, customers Must understand, coordinate with, and listen to them, communicate the SA vision to them SArchitect Responsibility beyond currently designed product Advocate for the organization investing in SA
95 95 Roles of a SArchitect 1. Creating a vision 2. Key technical consultant 3. Decision maker 4. Coordinator 5. Implementer 6. Advocate
96 96 Creating a vision Successful SArchitect is visionary Must know in advance What the system will look like when done What will accomplish How it fits the company s technology and business
97 97 Creating a vision: application domain Knowing application domain and/or targeted product is a plus If not, need to learn about Business Market characteristics Capabilities of the company s products Competitors
98 98 Creating a vision: qualities/factors Need to understand global requirements and constraints of product Generate global view of system Reiterate Project with new technology, targeting new markets, fast time-to-market Care must be taken in crafting a healthy vision
99 99 Creating a vision: innovations Innovations in the field fuel creativity Company s technology What s new in marketplace Product users Application specialists Technical marketing Customers Visit user site (see how system is used in practice)
100 100 The vision influences the other roles Initial architecture is sketched on a paper Architect needs to communicate vision As coach Work with project manager and team during highlevel design and product development As coordinator, decision maker, and implementer Control key interfaces of architectural design Provide requirements and input about how SW fits overall product Verify agreed system interfaces can be met
101 101 Creating a vision: COTS and adjustments SA sketch determines What COTS components are needed What other existing SW can be reused to implement parts of the system Realizing vision May require new technology, organization changes Discovered defects and holes in vision should be corrected midcourse and communicated
102 102 Key technical consultant To project manager (PM) Close working relationship PM ultimate responsibility for project SArchitect technical authority needed by PM Small projects: PM=SArchitect Larger projects Control of interfaces essential Team of architects System design review board Formal authority for maintaining integrity of SA
103 Key technical consultant, 2 Topic Project manager SArchitect SW development Organize project; manage resources, budgets, schedules Organize team around design, manage dependencies Requirements Negotiate with marketing Review, negotiate requirements Personnel Hiring, salary, bonuses Interview candidates; technical capabilities of staff; motivate development team Technology Introduce new tech at SArchitect s recommendation Recommend technology, training, tools Quality Ensure quality of product Track design quality Metrics Measure productivity, size, quality Ensure design goals met
104 104 Decision maker High-level design team SAr + leaders of subsystems / technology experts / domain specialty areas Leader makes early design decisions Trade-off conflicting demands Enough domain knowledge to analyze design trade offs If not enough, rely on specialists
105 105 Decisions In a timely manner to meet deadlines Even if no team consensus Even if not all needed info is present Just-in-time decisions Delay as long as possible but no longer Advantage: flexible design, incorporates changes to requirements and factors easier Making no decision: worst case!
106 106 Perspective on decisions Decisions depend on scheduling dependencies Work forward from the resources and backward from the goals Order decisions Consider marketing priorities, project schedule, new technology impact SAr responsible for global decisions Delegate decisions to area experts Design and implementation decisions to development team, coaching if needed
107 107 Coach SAr and PM put together SMALL highlevel design team Additional staff added as lower-level design and implementation introduced SAr and PM assign team members to work pieces SAr ensures people understand the design SAr convinces people the design can be implemented Dialog with each team member, teaching important design aspects Listen to their feedback; tradeoff!
108 108 Team members and the coach Team needs to understand SA design wellenough to do detailed design of their subsystems Have each sub-team design decomposition of their subsystem and its interfaces to rest of system Have them estimate time and complexity of implementation => feedback to schedule This increases team s feeling of ownership in SA design and development schedule
109 109 Team members and the coach, 2 SAr needs to Do the overall structure of design Give team members responsibility and challenge for designing their piece of system SAr duties end when achieving appropriate level of detail Allow team members small mistakes Make sure they learn from them
110 110 Coordinator SA: unifying for product development PM may view SA as vehicle for decomposing complex effort into manageable tasks Technical marketing may use SA as to support new features over lifespan of product SW engineers may be concerned with performance, reusability, evolution SAr: keeper of SA Coordinates activities of all these people
111 111 SAr as coordinator Establishes and controls key interfaces Keeps track of SW process Makes sure important milestones met Design reviews ensure consistency and quality of SA and that teams understands the design Establishes team leader responsibilities Together with PM Team leaders should relate to each other; SAr ensures they coordinate Maintains integrity of design, ensures architecture is followed If not, rationale documented (special cases!)
112 112 Implementer SAr plays role in implementing system SAr needs to keep programming skills fresh Track technologies and standards High-risk parts of system (exp: unknown) SAr may step in and go into more detail Exp: design initial base classes, code initial implementation SAr may implement a vertical slice of system to minimize implementation risk Prototyping important Understand design tradeoff Predicting system performance Educating the team on how to begin implementation
113 113 Advocate for SA Perhaps most important role SA critical asset of the organization SAr should keep track of existing SAs in the organization To mine them for new SAs To combine them into a product line Does this investment make sense? SAr should look beyond product boundaries Reuse opportunies SAr must asses and advocate SA technologies New ones too
114 114 SA into the development process SAr should work to incorporate SA in the development process => SA design activities become part of the standard operating procedure of organization
115 115 SAr role Project usually have official SAr Must be position of authority This understood by PM and rest of team Otherwise When crises appear, SAr can be reduced to solve them with no time for the real job Without watchful SAr SA begins to drift from intended design SA more difficult to manage SA vision begins to disappear
116 116 SAr career Steps SW engineer Senior SW engineer Team leader Apprenticeship with experienced architect SAr In this way, technical skills are developed first, then Leadership, communication, people skills
117 117 SAr vision again SAr needs to have A vision of the product to be developed Determination to strive to achieve the vision Conviction and communication goals to influence entire team into believing that the vision can be achieved
118 118 Instead of conclusions Course gives pointers What is software architecture? Designing Software Architecture Requirements: quality attributes or qualities How to achieve requirements : tactics How do tactics lead to architectural styles Case studies on architectural styles The ADD method Evaluating an architecture Documenting software architecture Bass et al Hofmeister et al ADLs, PLs, COTS, SAr SA is about complexity, organization, details SAr ensures quality attributes will be respected
119 119 After conclusions Test dates (Register 7 days in advance to any test): Alpha Auditorium, during 12-16
120 120 What is in the test 5 questions (with sub-questions) The lectured material during all regular lectures There is not a question from each lecture there can be questions from the first, last and in between lectures Concepts that we emphasized over and over during the course Questions that ask you to compare and relate various concepts Exercise questions
Software Architectures. Lecture 8
Software Architectures Lecture 8 Roadmap of the course What is software architecture? Designing Software Architecture Requirements: quality attributes or qualities How to achieve requirements : tactics
More informationSoftware Architectures. Lecture 7 15 Oct 2014
Software Architectures Lecture 7 15 Oct 2014 2 14-Oct-14 Roadmap of the course What is software architecture? Designing Software Architecture Requirements: quality attributes or qualities How to achieve
More informationDescribing the architecture: Creating and Using Architectural Description Languages (ADLs): What are the attributes and R-forms?
Describing the architecture: Creating and Using Architectural Description Languages (ADLs): What are the attributes and R-forms? CIS 8690 Enterprise Architectures Duane Truex, 2013 Cognitive Map of 8090
More informationIntroduction. ADL Roles
Architecture Description Languages (ADLs) 1 Introduction Architecture is key to reducing development costs development focus shifts to coarse-grained elements Formal architectural models are needed ADLs
More informationSoftware Architectures
Software Architectures Richard N. Taylor Information and Computer Science University of California, Irvine Irvine, California 92697-3425 taylor@ics.uci.edu http://www.ics.uci.edu/~taylor +1-949-824-6429
More informationMinsoo Ryu. College of Information and Communications Hanyang University.
Software Reuse and Component-Based Software Engineering Minsoo Ryu College of Information and Communications Hanyang University msryu@hanyang.ac.kr Software Reuse Contents Components CBSE (Component-Based
More informationSoftware Reuse and Component-Based Software Engineering
Software Reuse and Component-Based Software Engineering Minsoo Ryu Hanyang University msryu@hanyang.ac.kr Contents Software Reuse Components CBSE (Component-Based Software Engineering) Domain Engineering
More informationSoftware Architecture
Software Architecture Does software architecture global design?, architect designer? Overview What is it, why bother? Architecture Design Viewpoints and view models Architectural styles Architecture asssessment
More informationSoftware Architectures. Lecture 6 (part 1)
Software Architectures Lecture 6 (part 1) 2 Roadmap of the course What is software architecture? Designing Software Architecture Requirements: quality attributes or qualities How to achieve requirements
More informationSoftware Architecture. Lecture 5
Software Architecture Lecture 5 Roadmap of the course What is software architecture? Designing Software Architecture Requirements: quality attributes or qualities How to achieve requirements : tactics
More informationComponent-Based Software Engineering TIP
Component-Based Software Engineering TIP X LIU, School of Computing, Napier University This chapter will present a complete picture of how to develop software systems with components and system integration.
More informationCh 1: The Architecture Business Cycle
Ch 1: The Architecture Business Cycle For decades, software designers have been taught to build systems based exclusively on the technical requirements. Software architecture encompasses the structures
More informationReview Sources of Architecture. Why Domain-Specific?
Domain-Specific Software Architectures (DSSA) 1 Review Sources of Architecture Main sources of architecture black magic architectural visions intuition theft method Routine design vs. innovative design
More informationSoftware Engineering
Software Engineering chap 4. Software Reuse 1 SuJin Choi, PhD. Sogang University Email: sujinchoi@sogang.ac.kr Slides modified, based on original slides by Ian Sommerville (Software Engineering 10 th Edition)
More informationCSSE 490 Model-Based Software Engineering: Architecture Description Languages (ADL)
CSSE 490 Model-Based Software Engineering: Architecture Description Languages (ADL) Shawn Bohner Office: Moench Room F212 Phone: (812) 877-8685 Email: bohner@rose-hulman.edu Learning Outcomes: MBE Discipline
More informationComponent-Based Software Engineering TIP
Component-Based Software Engineering TIP X LIU, School of Computing, Napier University This chapter will present a complete picture of how to develop software systems with components and system integration.
More informationGSAW Software Architectures: What are we Building? March 1999
GSAW 1999 Software Architectures: What are we Building? March 1999 Roger J. Dziegiel, Jr AFRL/IFTD 525 Brooks Rd Rome, NY 13441-4505 (315)330-2185 dziegielr@rl.af.mil Arch1 Architecture & Generation Parameterized
More informationChapter 6 Architectural Design
Chapter 6 Architectural Design Chapter 6 Architectural Design Slide 1 Topics covered The WHAT and WHY of architectural design Architectural design decisions Architectural views/perspectives Architectural
More informationWhat is Software Architecture
What is Software Architecture Is this diagram an architecture? (ATM Software) Control Card Interface Cash Dispenser Keyboard Interface What are ambiguities in the previous diagram? Nature of the elements
More information5/9/2014. Recall the design process. Lecture 1. Establishing the overall structureof a software system. Topics covered
Topics covered Chapter 6 Architectural Design Architectural design decisions Architectural views Architectural patterns Application architectures Lecture 1 1 2 Software architecture The design process
More informationAn Introduction to Software Architecture
An Introduction to Software Architecture Software Engineering Design Lecture 11 Motivation for studying SW architecture As the size of SW systems increases, the algorithms and data structures of the computation
More information6/20/2018 CS5386 SOFTWARE DESIGN & ARCHITECTURE LECTURE 5: ARCHITECTURAL VIEWS C&C STYLES. Outline for Today. Architecture views C&C Views
1 CS5386 SOFTWARE DESIGN & ARCHITECTURE LECTURE 5: ARCHITECTURAL VIEWS C&C STYLES Outline for Today 2 Architecture views C&C Views 1 Components and Connectors (C&C) Styles 3 Elements Relations Properties
More informationArchitectural Styles. Software Architecture Lecture 5. Copyright Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.
Architectural Styles Software Architecture Lecture 5 Copyright Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Object-Oriented Style Components are objects Data and associated
More informationWHAT IS SOFTWARE ARCHITECTURE?
WHAT IS SOFTWARE ARCHITECTURE? Chapter Outline What Software Architecture Is and What It Isn t Architectural Structures and Views Architectural Patterns What Makes a Good Architecture? Summary 1 What is
More informationAn Introduction to Software Architecture
An Introduction to Software Architecture Software Requirements and Design CITS 4401 Lecture 11 Motivation for studying SW architecture As the size of SW systems increase, the algorithms and data structures
More informationArchitectural Blueprint
IMPORTANT NOTICE TO STUDENTS These slides are NOT to be used as a replacement for student notes. These slides are sometimes vague and incomplete on purpose to spark a class discussion Architectural Blueprint
More informationCS 307: Software Engineering. Lecture 10: Software Design and Architecture
CS 307: Software Engineering Lecture 10: Software Design and Architecture Prof. Jeff Turkstra 2017 Dr. Jeffrey A. Turkstra 1 Announcements Discuss your product backlog in person or via email by Today Office
More informationSOFTWARE ARCHITECTURE INTRODUCTION TO SOFTWARE ENGINEERING PHILIPPE LALANDA
SOFTWARE ARCHITECTURE INTRODUCTION TO SOFTWARE ENGINEERING PHILIPPE LALANDA PURPOSE OF THIS CLASS An introduction to software architecture What is an architecture Why it is important How it is represented
More informationADD 3.0: Rethinking Drivers and Decisions in the Design Process
ADD 3.0: Rethinking Drivers and Decisions in the Design Process Rick Kazman Humberto Cervantes SATURN 2015 Outline Presentation Architectural design and types of drivers The Attribute Driven Design Method
More informationIntegration With the Business Modeler
Decision Framework, J. Duggan Research Note 11 September 2003 Evaluating OOA&D Functionality Criteria Looking at nine criteria will help you evaluate the functionality of object-oriented analysis and design
More informationSoberIT Software Business and Engineering Institute. SoberIT Software Business and Engineering Institute. Contents
Architecture Description Languages (ADLs): Introduction, Koala, UML as an ADL T-76.150 Software Architecture Timo Asikainen Contents Brief motivation for ADLs General features of ADLs Koala UML as an ADL
More informationChapter 6 Architectural Design. Lecture 1. Chapter 6 Architectural design
Chapter 6 Architectural Design Lecture 1 1 Topics covered ² Architectural design decisions ² Architectural views ² Architectural patterns ² Application architectures 2 Software architecture ² The design
More informationIntroduction to software architecture Revision : 732
Introduction to software architecture Revision : 732 Denis Conan Septembre 2018 Foreword The content of these slides is extracted from the following references: L. Bass, P. Clements, and R. Kazman. Software
More informationSOFTWARE ARCHITECTURE & DESIGN INTRODUCTION
SOFTWARE ARCHITECTURE & DESIGN INTRODUCTION http://www.tutorialspoint.com/software_architecture_design/introduction.htm Copyright tutorialspoint.com The architecture of a system describes its major components,
More informationICS 52: Introduction to Software Engineering
ICS 52: Introduction to Software Engineering Fall Quarter 2004 Professor Richard N. Taylor Lecture Notes Week 3: Architectures http://www.ics.uci.edu/~taylor/ics_52_fq04/syllabus.html Copyright 2004, Richard
More informationIn his paper of 1972, Parnas proposed the following problem [42]:
another part of its interface. (In fact, Unix pipe and filter systems do this, the file system playing the role of the repository and initialization switches playing the role of control.) Another example
More informationArchitectural Design
Architectural Design Topics i. Architectural design decisions ii. Architectural views iii. Architectural patterns iv. Application architectures Chapter 6 Architectural design 2 PART 1 ARCHITECTURAL DESIGN
More informationNick Rozanski Andy Longshaw Eoin Woods. Sold! How to Describe, Explain and Justify your Architecture
Nick Rozanski Andy Longshaw Eoin Woods Sold! How to Describe, Explain and Justify your Architecture Objectives of Today If you are an architect who has to produce an Architectural Description, then this
More informationChapter 6 Architectural Design. Chapter 6 Architectural design
Chapter 6 Architectural Design 1 Topics covered Architectural design decisions Architectural views Architectural patterns Application architectures 2 Software architecture The design process for identifying
More informationSoftware Design Patterns. Background 1. Background 2. Jonathan I. Maletic, Ph.D.
Software Design Patterns Jonathan I. Maletic, Ph.D. Department of Computer Science Kent State University J. Maletic 1 Background 1 Search for recurring successful designs emergent designs from practice
More informationImplementing Architectures
Implementing Architectures Software Architecture Lecture 15 Copyright Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Learning Objectives Formulate implementation as a mapping
More informationCh 1: The Architecture Business Cycle
Ch 1: The Architecture Business Cycle For decades, software designers have been taught to build systems based exclusively on the technical requirements. Software architecture encompasses the structures
More informationResearch Directions in Software Architecture
Research Directions in Software Architecture February 1998 Capt Mark J. Gerken, Ph.D. AFRL/IFTD 525 Brooks Road Rome NY 13441-4505 gerkenm@rl.af.mil Overview Vision General Research Areas: Architecture
More informationIntroduction to Software Engineering
Introduction to Software Engineering Gérald Monard Ecole GDR CORREL - April 16, 2013 www.monard.info Bibliography Software Engineering, 9th ed. (I. Sommerville, 2010, Pearson) Conduite de projets informatiques,
More informationUNIT II Requirements Analysis and Specification & Software Design
UNIT II Requirements Analysis and Specification & Software Design Requirements Analysis and Specification Many projects fail: because they start implementing the system: without determining whether they
More informationSoftware Development Chapter 1
Software Development Chapter 1 1. Introduction Software Applications are increasingly used to tackle problems that concern everyday life : Automatic Bank tellers Airline reservation systems Air traffic
More informationIntroduction to Modeling
Introduction to Modeling Software Architecture Lecture 9 Copyright Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Objectives Concepts What is modeling? How do we choose
More informationAn Introduction to Software Architecture. David Garlan & Mary Shaw 94
An Introduction to Software Architecture David Garlan & Mary Shaw 94 Motivation Motivation An increase in (system) size and complexity structural issues communication (type, protocol) synchronization data
More informationCurrent Issues and Future Trends. Architectural Interchange
Current Issues and Future Trends 1 Current Issues and Future Trends Architectural interchange Architectural toolkit Architectural refinement Architectural view integration Bringing architectures to the
More informationSub- PPL Unit-I Class-SE Comp
1. We describe the basic concepts for structuring large programs (encapsulation, interfaces, information hiding) and the mechanisms provided by languages to support it (packaging, separate compilation).
More informationSoftware Architecture. Lecture 4
Software Architecture Lecture 4 Last time We discussed tactics to achieve architecture qualities We briefly surveyed architectural styles 23-Jan-08 http://www.users.abo.fi/lpetre/sa08/ 2 Today We check
More informationDOMAIN ENGINEERING OF COMPONENTS
4-02-55 INFORMATION MANAGEMENT: STRATEGY, SYSTEMS, AND TECHNOLOGIES DOMAIN ENGINEERING OF COMPONENTS Carma McClure INSIDE Definition of Components; Component-Based Development; Reuse Processes; Domain
More informationEngr. M. Fahad Khan Lecturer Software Engineering Department University Of Engineering & Technology Taxila
Engr. M. Fahad Khan Lecturer Software Engineering Department University Of Engineering & Technology Taxila Software Design and Architecture Software Design Software design is a process of problem-solving
More informationChapter 18. Software Reuse
Chapter 18 Software Reuse Ian Sommerville Lutz Prechelt Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 1 Objectives To explain the benefits of software reuse and some
More informationDHANALAKSHMI COLLEGE OF ENGINEERING, CHENNAI
DHANALAKSHMI COLLEGE OF ENGINEERING, CHENNAI Department of Computer Science and Engineering IT6801 - SERVICE ORIENTED ARCHITECTURE Anna University 2 & 16 Mark Questions & Answers Year / Semester: IV /
More informationEnterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions
Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions Chapter 1: Solving Integration Problems Using Patterns 2 Introduction The Need for Integration Integration Challenges
More informationStudy of Component Based Software Engineering
Study of Based Software Ishita Verma House No.4, Village Dayalpur Karawal Nagar Road Delhi-110094, India ish.v.16@gmail.com Abstract based engineering is an approach of development that emphasizes the
More information10 Steps to Building an Architecture for Space Surveillance Projects. Eric A. Barnhart, M.S.
10 Steps to Building an Architecture for Space Surveillance Projects Eric A. Barnhart, M.S. Eric.Barnhart@harris.com Howard D. Gans, Ph.D. Howard.Gans@harris.com Harris Corporation, Space and Intelligence
More informationContemporary Design. Traditional Hardware Design. Traditional Hardware Design. HDL Based Hardware Design User Inputs. Requirements.
Contemporary Design We have been talking about design process Let s now take next steps into examining in some detail Increasing complexities of contemporary systems Demand the use of increasingly powerful
More informationLecture 1. Chapter 6 Architectural design
Chapter 6 Architectural Design Lecture 1 1 Topics covered Architectural design decisions Architectural views Architectural patterns Application architectures 2 Software architecture The design process
More informationEnterprise Data Architecture: Why, What and How
Tutorials, G. James, T. Friedman Research Note 3 February 2003 Enterprise Data Architecture: Why, What and How The goal of data architecture is to introduce structure, control and consistency to the fragmented
More informationICS 52: Introduction to Software Engineering
ICS 52: Introduction to Software Engineering Fall Quarter 2002 Professor Richard N. Taylor Lecture Notes Week 3: Architectures http://www.ics.uci.edu/~taylor/ics_52_fq02/syllabus.html Copyright 2002, Richard
More informationQuestion 1: What is a code walk-through, and how is it performed?
Question 1: What is a code walk-through, and how is it performed? Response: Code walk-throughs have traditionally been viewed as informal evaluations of code, but more attention is being given to this
More informationLecture Chapter 2 Software Development
Lecture Chapter 2 Software Development Large Software Projects Software Design o Team of programmers o Cost effective development Organization Communication Problem Solving Analysis of the problem Multiple
More informationCS 575: Software Design
CS 575: Software Design Introduction 1 Software Design A software design is a precise description of a system, using a variety of different perspectives Structural Behavioral Packaging Requirements, Test/Validation
More informationPart 5. Verification and Validation
Software Engineering Part 5. Verification and Validation - Verification and Validation - Software Testing Ver. 1.7 This lecture note is based on materials from Ian Sommerville 2006. Anyone can use this
More informationUnderstanding the Open Source Development Model. » The Linux Foundation. November 2011
» The Linux Foundation Understanding the Open Source Development Model November 2011 By Ibrahim Haddad (PhD) and Brian Warner, The Linux Foundation A White Paper By The Linux Foundation This paper presents
More informationInterface (API) Design
Interface (API) Design Architect s Perspective R. Kuehl/J. Scott Hawker p. 1 What is an API? Exposes the public facing functionality of a software component Operations, inputs, and outputs Exposes functionality
More informationInvestigation of System Timing Concerns in Embedded Systems: Tool-based Analysis of AADL Models
Investigation of System Timing Concerns in Embedded Systems: Tool-based Analysis of AADL Models Peter Feiler Software Engineering Institute phf@sei.cmu.edu 412-268-7790 2004 by Carnegie Mellon University
More informationSOFTWARE ARCHITECTURES UNIT I INTRODUCTION AND ARCHITECTURAL DRIVERS
IT6602 SOFTWARE ARCHITECTURES UNIT I INTRODUCTION AND ARCHITECTURAL DRIVERS SYLLABUS: Introduction What is software architecture? Standard Definitions Architectural structures Influence of software architecture
More informationXVIII. Software Architectures
XVIII. Software Architectures Software Architectures UML Packages Client-Server vs Peer-to-Peer 3-Tier and 4-Tier Architectures Horizontal Layers and Vertical Partitions The Model-View-Controller Architecture
More informationArchitectural Design. Architectural Design. Software Architecture. Architectural Models
Architectural Design Architectural Design Chapter 6 Architectural Design: -the design the desig process for identifying: - the subsystems making up a system and - the relationships between the subsystems
More informationWhy Consider Implementation-Level Decisions in Software Architectures?
1. Abstract Why Consider Implementation-Level Decisions in Software Architectures? Nikunj Mehta Nenad Medvidović Marija Rakić {mehta, neno, marija}@sunset.usc.edu Department of Computer Science University
More informationExamples. Object Orientated Analysis and Design. Benjamin Kenwright
Examples Object Orientated Analysis and Design Benjamin Kenwright Outline Revision Questions Group Project Review Deliverables Example System Problem Case Studey Group Project Case-Study Example Vision
More information1 Executive Overview The Benefits and Objectives of BPDM
1 Executive Overview The Benefits and Objectives of BPDM This is an excerpt from the Final Submission BPDM document posted to OMG members on November 13 th 2006. The full version of the specification will
More informationObject Oriented Programming
Binnur Kurt kurt@ce.itu.edu.tr Istanbul Technical University Computer Engineering Department 1 Version 0.1.2 About the Lecturer BSc İTÜ, Computer Engineering Department, 1995 MSc İTÜ, Computer Engineering
More informationSoftware Architecture
Software Architecture Architectural Design and Patterns. Standard Architectures. Dr. Philipp Leitner @xleitix University of Zurich, Switzerland software evolution & architecture lab Architecting, the planning
More informationBuilding the User Interface: The Case for Continuous Development in an Iterative Project Environment
Copyright Rational Software 2002 http://www.therationaledge.com/content/dec_02/m_uiiterativeenvironment_jc.jsp Building the User Interface: The Case for Continuous Development in an Iterative Project Environment
More informationNOTES ON OBJECT-ORIENTED MODELING AND DESIGN
NOTES ON OBJECT-ORIENTED MODELING AND DESIGN Stephen W. Clyde Brigham Young University Provo, UT 86402 Abstract: A review of the Object Modeling Technique (OMT) is presented. OMT is an object-oriented
More informationArchitectural Styles. Reid Holmes
Material and some slide content from: - Emerson Murphy-Hill - Software Architecture: Foundations, Theory, and Practice - Essential Software Architecture Architectural Styles Reid Holmes Lecture 5 - Tuesday,
More informationSoftware Architecture: A quick journey
Software Architecture: A quick journey Session 6 Course ICT Entrepreneurship Prof. dr. Sjaak Brinkkemper Dr. Slinger Jansen Motivation Software systems are rapidly and continously growing in size and complexity
More informationIncremental development A.Y. 2018/2019
Incremental development A.Y. 2018/2019 Incremental development Interleaves the activities of specification, development, and validation. The system is developed as a series of versions (increments), with
More informationProcess of Interaction Design and Design Languages
Process of Interaction Design and Design Languages Process of Interaction Design This week, we will explore how we can design and build interactive products What is different in interaction design compared
More informationAppendix A - Glossary(of OO software term s)
Appendix A - Glossary(of OO software term s) Abstract Class A class that does not supply an implementation for its entire interface, and so consequently, cannot be instantiated. ActiveX Microsoft s component
More informationObjectives. Architectural Design. Software architecture. Topics covered. Architectural design. Advantages of explicit architecture
Objectives Architectural Design To introduce architectural design and to discuss its importance To explain the architectural design decisions that have to be made To introduce three complementary architectural
More informationFundamentals to Creating Architectures using ISO/IEC/IEEE Standards
Fundamentals to Creating Architectures using ISO/IEC/IEEE Standards What to Architect? How to Architect? IEEE Goals and Objectives Chartered by IEEE Software Engineering Standards Committee to: Define
More informationEXIN BCS SIAM Foundation. Sample Exam. Edition
EXIN BCS SIAM Foundation Sample Exam Edition 201704 Copyright EXIN Holding B.V. and BCS, 2017. All rights reserved. EXIN is a registered trademark. SIAM is a registered trademark. ITIL is a registered
More informationAn Introduction to Software Architecture By David Garlan & Mary Shaw 94
IMPORTANT NOTICE TO STUDENTS These slides are NOT to be used as a replacement for student notes. These slides are sometimes vague and incomplete on purpose to spark a class discussion An Introduction to
More informationThe Analysis and Design of the Object-oriented System Li Xin 1, a
International Conference on Materials Engineering and Information Technology Applications (MEITA 2015) The Analysis and Design of the Object-oriented System Li Xin 1, a 1 Shijiazhuang Vocational Technology
More informationDesign Pattern. CMPSC 487 Lecture 10 Topics: Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, et al.)
Design Pattern CMPSC 487 Lecture 10 Topics: Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, et al.) A. Design Pattern Design patterns represent the best practices used by experienced
More informationSoftware Architecture. Definition of Software Architecture. The importance of software architecture. Contents of a good architectural model
Software Architecture Definition of Software Architecture Software architecture is process of designing g the global organization of a software system, including: Dividing software into subsystems. Deciding
More informationChapter 8. Achmad Benny Mutiara
Chapter 8 SOFTWARE-TESTING STRATEGIES Achmad Benny Mutiara amutiara@staff.gunadarma.ac.id 8.1 STATIC-TESTING STRATEGIES Static testing is the systematic examination of a program structure for the purpose
More informationSoftware Design Fundamentals. CSCE Lecture 11-09/27/2016
Software Design Fundamentals CSCE 740 - Lecture 11-09/27/2016 Today s Goals Define design Introduce the design process Overview of design criteria What results in a good design? Gregory Gay CSCE 740 -
More informationThe IDN Variant TLD Program: Updated Program Plan 23 August 2012
The IDN Variant TLD Program: Updated Program Plan 23 August 2012 Table of Contents Project Background... 2 The IDN Variant TLD Program... 2 Revised Program Plan, Projects and Timeline:... 3 Communication
More informationProfessional Services for Cloud Management Solutions
Professional Services for Cloud Management Solutions Accelerating Your Cloud Management Capabilities CEOs need people both internal staff and thirdparty providers who can help them think through their
More informationCoding and Unit Testing! The Coding Phase! Coding vs. Code! Coding! Overall Coding Language Trends!
Requirements Spec. Design Coding and Unit Testing Characteristics of System to be built must match required characteristics (high level) Architecture consistent views Software Engineering Computer Science
More informationOverview of the course. User-Centred Design. Group. Practical issue. Writting the report. Project work. Fang Chen
Overview of the course User-Centred Design Fang Chen 6 lectures, 3 hr each. L 1: April 6, 9-12, user-centered design concept L2: April 14, 9-12, usability concept L3. user-centered requirement study L4.
More informationChapter Outline. Chapter 2 Distributed Information Systems Architecture. Distributed transactions (quick refresh) Layers of an information system
Prof. Dr.-Ing. Stefan Deßloch AG Heterogene Informationssysteme Geb. 36, Raum 329 Tel. 0631/205 3275 dessloch@informatik.uni-kl.de Chapter 2 Distributed Information Systems Architecture Chapter Outline
More informationManager, Infrastructure Services. Position Number Community Division/Region Yellowknife Technology Service Centre
IDENTIFICATION Department Position Title Infrastructure Manager, Infrastructure Services Position Number Community Division/Region 32-11488 Yellowknife Technology Service Centre PURPOSE OF THE POSITION
More informationRequirements Validation and Negotiation
REQUIREMENTS ENGINEERING LECTURE 2015/2016 Eddy Groen Requirements Validation and Negotiation AGENDA Fundamentals of Requirements Validation Fundamentals of Requirements Negotiation Quality Aspects of
More information