strife

FrontPage|FindPage|TitleIndex|RecentChanges| UserPreferences P RSS
[edit]

새로운 시작, 이런저런 얘기


이제 시작하는 Wikizen 입니다.

좀 어리둥절하지만 새로운 세계를 접할때는 항상 두려움과 호기심이 공존하는거 같네요.

[edit]

Software Product Lines

많은 조직에서 소프트웨어에 대한 긴 투자 회수 기간과 소프트웨어 생산예측 때문에 어려움을 겪고 있다.
Product lines은 비용절감과 복잡한 소프트웨어 생산 시간을 줄이기 위한 중요한 접근방식으로 부각되고 있다.
{{|
software product line은 정해진 방식으로 핵심 자산의 공통집합으로부터 개발되거나 특별한 시장 영역 또는 임무에 대한 특수한 요구를 만족시키는 공통적인 특징을 공유하는 소프트웨어 중심의 시스템 집합이다.
|}}

[edit]

Overview of Software Architecture


[edit]
Definition of Software Architecture
A software architecture for a system is the structure or structures of the system, which comprise elements, their externally-visible behavior, and the relationships among them.

[edit]
Issues addressed by an Architectural Design
  • Gross decomposition of a system into interacting components
    • using rich abstractions for component interaction
    • often using common design idioms/styles

  • Emergent system properties
    • performance, throughput, latencies
    • reliability, security, fault tolerance, evolvability

  • Rationale and assignment of function to components
    • relates requirements and implementations

  • Envelope of allowed change
    • load-bearing walls, limits of scalability and adaptation
    • design idioms and styles

[edit]
Many views (perspectives) of Architecture
  • There are many possible views of software systems
    • Module structures : code/implementation structures
      e.g., class diagrams, work breakdown structures, "def-use" graph
    • Deployment structures: physical/resources structures
      e.g., processors, networks
    • Run-time structures: system structure and behavior at run time
      e.g., clients, servers, databases, instances of objects

  • Each has its purpose in understanding the overall nature of a system
    • Modules good for reasoning about maintenance
    • Deployment good for reasoning about resources
    • Run-time good for reasoning about system behavior

[edit]
Why care about Software Architecture?
  • Understanding
    • Precise definition of system
    • Clarification of requirements
  • Analysis
    • System-level analysis of critical properties (Performance, security, ...)
  • Construction - How to implement
    • Blueprint for construction; basis for code generation
    • Identify opportunities for reuse
  • Evolution
    • Define allowable envelope of change, ensure that system invariants are not violated

[edit]
Elements of Architectural Descriptions: Systems
  • Components: define the locus of computation
    • Examples: filters, databases, objects, ADTs
  • Connectors: mediate interactions of components
    • Examples: procedure call, pipes, event broadcast
  • Properties: specify information for construction & analysis
    • Examples: signatures, pre/post conditions, RT specs, procotols, performance attributes

[edit]
Elements of Architectural Descriptions: Styles
  • An architectural style defines a family of architecture instances including
    • Component/connector types
      • the vacabulary of architectural building blocks
    • Constraints on how the building blocks can be used, including
      • topological rules
      • interface standards
      • required properties

[edit]
Taxonomy of Architectural Styles
  • Data Flow
    • Batch sequential
    • Dataflow network (pipes&filters)
      acyclic, fanout, pipeline, Unix
    • Closed loop control

  • Call-and-Return
    • Main program/subroutines
    • Information hiding
      ADT, object naive client/server

  • Interacting processes
    • Communicating processes
      LW processes, distributed objects
    • Event systems
      implicit invocation, pure events

  • Data-oriented repository
    • Transactional databases
    • Blackboard

  • Data-sharing
    • Compound documents
    • Hypertext

  • Hierarchical
    • Layered Interpreter

[edit]
Styles: Questions to address
  • System Model
    • What is the overall organizational pattern?
  • Structure
    • What are the basic components and connectors?
  • Computation
    • What is the underlying computational model?
    • How is control and data transferred between components?
  • Properties
    • Why is this style useful?
    • What kinds of properties are exposed?
  • Analyses
    • What kinds of analysis does the style support?

[edit]
Software Architectures & Recent Trends
  • Product lines
    • One architecture, many products
    • Large-scale economies through reuse
  • Component-integration standards and frameworks
    • e.g., Corba, COM, J2EE
    • Defines an architecture
  • Systems of systems (put together systems, many other systems)
    • Integrate many systems built by many organizations
    • Requires an architecture to have effective integration
  • Ubiquitous Computing
    • Heterogeneous devices and services
    • Requires architecture for service discovery, naming, invocation (e.g., .NET)

[edit]
What should Software Architecture Engineers know?
  • Architectural Sytles ( know common styles -> how to use them )
    • What are the main styles, and how to specialize/combine them.
  • Product Lines
    • What a product lines, and how to define one
  • Architectural Tradeoff Analysis (security/resource limitation)
    • How to make tradeoffs between architectural alternatives.
  • Architectural Design Reviews
    • How to conduct a design review to determine if an architecture will satisfy its requirements
  • Documentation
    • How to specify ana architecture accurately.
    • The difference between different architectural viewtypes.

[edit]

Software Architecture in Practice


[edit]
Product Line Frameworks
  • Observation: most products are similar to others built before and to be built in the future
  • Can achieve huge economies of production by
    • defining the common, shared aspects
    • providing reusable infrastructure to support these common aspects
    • defining a way to specialize the framework for a particular product
  • At the core of this effort one typically finds an architecture that establishes a common vision for the structure, content, and variability of products in the family

[edit]
Component Integration Standards
  • The Problem: it is hard to make components developed by different parties work together
  • One way to alleviate the problem is to get the parties to agree on certain standards of interoperability
  • Often these are called component integration standards (or component frameworks)
  • State of practice is to define this in terms of API conformance
  • But "signature" conformance is not enough. Also care about
    • orders of invocation
    • assumptions about locus of control
    • data representations
    • synchronization conditions
    • lookup/discovery/naming
    • failure handling

[edit]
Elements of Component Integration Standards
  • Rules about interfaces of components
    • structure, content, required capabilities
  • Rules of engagement
    • the connectors: ways components interact
  • Run time infrastructure to support interoperability
    • often as an API to lower level communication services
  • Naming/discovery conventions
    • often via a name registry
  • Base of reusable assets
    • component building blocks
  • System generation tools
    • create running systems from descriptions of the parts

[edit]
From Requirements to Architectures
  • The problem: develop an architecture for a system or product family that satisfies critical system requirements
  • Impediments
    • Requirements specification is not a mature discipline
    • Requirements may change frequently
    • Requirements may not be fully known independently of a solution
    • The need to develop a product line changes requires new processes for relating requirements and architectures
  • Caveats
    • This is an area of active research and change
    • What we know represents only a partial solution
    • Your mileage may vary

[edit]
Technique
  1. Architectural Design Reviews
    bring stakeholders together to determine feasibility of an architectural design to solve a particular problem
  2. Product-line Engineering/Commonality Analysis
    identify common requirements of a group products
  3. Rules-of-thumb and Automated Design Guidance
    codify criteria and guidance for choosing appropriate architectural designs
  4. Problem Frames
    identify recurring structures of problems that lend themselves to methodological solutions
  5. Architecture-based Analysis
    use analytic techniques to decide whether an architectural design will lead to a system that meets its requirements

[edit]
Architectural Review
  • Complements normal design review process
  • Prescribe guidelines for architectural description and rationale
  • Define a process of formal airing of architecture that leads to list of issues that must be resolved
  • May be done using corporate "design review boards" or by a product group itself
  • Can be used to produce corporate architectural assets
    • Checklists of issues that an architecture must consider
    • Standard solutions to common domain-specific problems
    • Case studies and examples
    • Measurement of costs/benefits

[edit]
Tradeoff Analysis
  • Determining whether an architecture satisfies its requirements often involves
    • Being very explicit about what the requirements really are
    • Understanding where one has to make tradeoffs between different designs
    • Applying formal analysis where possible to determine the consequences of an architectural choice
    • Mediating between desires of different stakeholders
  • These goals can be achieved by an architectural evaluation process

[edit]

Tools and Techniques


[edit]
Architecture Description Languages
  • Each language and supporting tool set
    • emphasizes different aspect of architecture
    • is good for some things; bad for others
  • Examples
    • Rapide events with simulation and animation
    • Unicon emphasizing heterogeneity and compilation
    • Wright formal specification of connector interactions
    • Aesop style-specific arch design language
    • Darwin service-oriented architectures
    • SADL SRI language emphasizing refinement
    • Meta-H arch description for avionics domain
    • C-2 arch style using implicit invocation

[edit]
Frontier 1 : Ubiquitous
  • Computers and information potentially everywhere
    • Heterogeneous universe
      • Desktops, mainframes, PDAs
      • Smart appliances, Wearable computers, Sensors and actuators
    • Not just keyboards: voice/gesture interfaces
  • Increasingly, systems must
    • be composed of parts built by many organizations
    • run continuously
    • operate in environments where resources change frequently
    • be usable by mobile users

[edit]
Frontier 2 : Mobility
  • Use a variety of devices, with significant resource constraints
  • We must do a better job of reducing user distraction, while enabling continuity of computation across environments

[edit]
Frontier 3 : From Architecture to Code
  • How bridge the gap from Architecture to Code?
  • Make sure the architecture is consistent with the implementation?
  • Past approaches
    • Formal refinement theory
      • Not practical for most industrial developers
    • Code generation
      • Not feasible for most systems
    • Build and check
      • Hard to reverse-architect a system from code
  • New approach: provide user with 2-tiered model
    • Top tier captures abstract functionality
    • Bottom tier captures implemenation dependencies
    • Various manifestations

[edit]

strife 를 위한 추천 페이지

[edit]

Dear strife

"; if (isset($options[timer])) print $menu.$banner."
".$options[timer]->Write()."
"; else print $menu.$banner."
".$timer; ?> # # ?>