Download
1 / 38
380 likes | 525 Vues
Lecture 12. COMSATS Islamabad. E nterprise S ystems D evelopment ( CSC447 ). Muhammad Usman, Assistant Professor . SEI Architectural Viewtypes.
E N D
Lecture 12 COMSATS Islamabad Enterprise Systems Development ( CSC447) Muhammad Usman, Assistant Professor
SEI Architectural Viewtypes A viewtype defines the element types and relationship types used to describe the software architecture from a particular perspective. • Module Viewtypes describe how the system is to be structured as a set of units of implementation. • Component and Connector (C&C) Viewtypes describe how the system is to be structured as a set of interacting runtime elements. • Allocation Viewtypes describe how the system relates to non-software structures in its enviroment.
Architectural Views – RUP (2) • The Logical View supports the functional requirements. It decomposes the system into objects or object classes. • The Process View addresses concurrency and distribution, system integrity, and fault-tolerance. It contains the description of the tasks – processes and threads – involved. • The Development View focuses on the organization of the software modules in the software development environment. • The Physical View takes into account the system availability, reliability, performance and scalability. It maps the various elements identified in the logical, process and development views, onto the processing nodes. • The Use Case View contains a small set of scenarios to show that the elements of the four views work together seamlessly ( (unifying view, “+1”).
IEEE 1471 Recommendation (1) • IEEE Recommended Practice for the Architectural Description of Software-Intensive Systems. • Based on two key ideas: • A conceptual framework for architectural description • What information must be found in each 1471-compliant architectural description. • The conceptual framework ties together such concepts as system, architectural description, and view. • Views have a central role in documenting software architecture.
IEEE 1471 Recommendation (2) • A view is a representation of a whole system from the perspective of a related set of concerns. A view conforms to a viewpoint. • The architectural description of a system includes one or more views. • A viewpoint is a pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis. Viewpoints are defined with specific stakeholder concerns in mind.
IEEE 1471Recommendation (3) Excerpt from 1471 conceptual framework
Useful Concepts • Three stages that capture characteristics of an architecture, on the way from box-and-arrow to full software architectures: • Architectural Patterns • Reference Models • Reference Architectures Reference Model ReferenceArchitecture Software Architecture ArchitecturalPattern Figure 2.2
Architectural Patterns • A description of element & relation types together with a set of constraints on how they may be used. • These constraints on an architecture define a set or family of architectures. • For example, the client-server pattern has 2 element types; their relationship is a protocol that the server uses to communicate with each of its clients, the clients don’t communicate directly.
Value of Patterns • They exhibit known quality attributes, and are a reuse of experience. • Some patterns solve performance problems, others apply to high-security systems, or high-availability goals. • Often the architect’s first major design decision. • Also referred to as architecturalstyles.
Reference Models • A division of functionality together with data flow between the pieces. • A standard decomposition of a known problem into parts that cooperatively solve the problem. • They arise from experience, and are thus a characteristic of mature domains. • For example, the standard parts of a compiler or database management system & how they work together.
Reference Architectures • A reference model mapped onto software elements and the data flows between them. The elements must cooperatively implement the functionality defined in the reference model. • The mapping may be 1-1, but an element may implement a part of a function or several functions.
Architecture Documentation An Introduction
What is it used for? • Serves as a means of education • Primary Vehicle for communication among stakeholders. • Basis for system analysis • Quality attributes • Behavior • Evolution and extension
Architecture Documentation Documentation Beyond Views Documentation for Each View
Why Multiple? • Each exposes different quality attributes to different degrees • Each has different goals and uses • How to choose which ones? • Depends on what do you care about? • What is important for readers to understand?
Documentation Beyond Views • Introduction to the entire documentation package (“reader’s guide”) • Describe how views relate to one another • Overall constraints and rationale • Management and control information
View Components • Primary (graphical) presentation • Element catalog • Specification of element interfaces & behavior
Conceptually Speaking Views provide slices of system understanding…. …going beyond views produces the integrated picture of the whole system
Viewtypes and/or Structures • Module (Design/Functional Structure) • Component and Connector (Runtime) • Allocation (Deployment, Physical Structure, Team Structure)
Styles and/or Patterns • Style = Large scale pattern within a view type; common way of expressing the viewtype • Defines a family of architectures • Different areas of the system may use different styles • Layering of Styles • Nesting of Styles
7 Rules for Sound Documentation • Write for the Reader • One fact = one location • Avoid Ambiguity; Explain semantics • Use a standard organization • Record Rationale • Keep documentation current • Review for fitness of purpose
Software Architecture Quality Attributes Achieving Quality Attributes
Interesting Fact “Systems are frequently redesigned not because they are functionally deficient – the replacement are often functionally identical – but because they are difficult to maintain, port, or scale, or are too slow or have been compromised by network hackers.”
Relationship of Functionality and Quality Attributes Functionality Quality
Where Does Architecture Fit? • Architecture is critical to the realization of many qualities of interest • The architecture alone does not achieve the desired qualities • Attention must still be paid to the details throughout detailed design and implementation
Two Examples • Modifiability of the systems is determined by the module structure (Architectural) and by the coding techniques (not Architectural) • Usability of systems depends on screen layout and wigit styles (not Architectural) and whether there are undo/cancel (Arch)
Classes of Quality Attributes • Qualities of the system (e.g., availability) • Business Qualities (e.g., time to market) • Qualities about the architecture itself (meta-qualities) (e.g., conceptual integrity)
Scenarios • Scenarios are brief narratives of expected or anticipated use of a system from both development and end-user viewpoint • Quality attributes such as modifiability etc are abstract and vague • No universal measures for these attributes. Context dependent measures are possible • Scenarios are used to represent operational context for a system
Sample Availability Scenario Artifact: Process Stimulus: Unanticipated message Response: Inform Operator to Continue Source: External to System Response Measure: No Downtime Environment: Normal Operation
Reference • Bass, L., Clements, P. and Kazman, R., Software Architecture in Practice, Second Edition (2006), Addison-Wesley. • Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, j., Little, R., Nord, R. and Stafford, J., Documenting Software Architectures: Views and Beyond, 2002, Addison-Wesley.Documenting Software Architectures
