Click here to load reader

SOEN 6011 Software Engineering Processes Section SS Fall 2007 Dr Greg Butler gregb/home/soen6011-f2007.html

  • View
    214

  • Download
    1

Embed Size (px)

Text of SOEN 6011 Software Engineering Processes Section SS Fall 2007 Dr Greg Butler ...

  • Slide 1
  • SOEN 6011 Software Engineering Processes Section SS Fall 2007 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/soen6011-f2007.html
  • Slide 2
  • Week 11 Software Architecture 4+1 Views Siemens Approach
  • Slide 3
  • Software Architecture: Definitions for a system is the structure which consist of elements, their externally visible properties, and the relationships among them. The fundamental organization of a system [as] embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. (IEEE 1471-2000).
  • Slide 4
  • Architecture: Benefits? Contributes to elicitation of requirements. First design: can already assess / determine satisfaction of requirements. Work allocation / distribution (schedule). Instructional: useful to learn about system. Initial development & maintenance. Reuse of the architectural style / framework. Also
  • Slide 5
  • Conceptual Integrity is central to achieving product quality. Also called Architectural Integrity. Coherent conceptual (design) model makes product easier to understand, hence easier to Develop (e.g. Design, test), Learn to use: customer, I&C, sales & marketing Maintain. How to achieve conceptual integrity?
  • Slide 6
  • System Architect Custodian of product ensures Design coherence. Also, to some extent, Interface coherence (esp. UI).
  • Slide 7
  • System Architect Full-time job! Separation of architecture from implementation. Project size hierarchy of architects. Single mind Having a system architect is an effective means of achieving conceptual integrity.
  • Slide 8
  • Components S/W entities Systems (e.g. COTS), subsystems, frameworks, packages, layers, libraries, modules, classes, objects, executables, DLLs, plug-ins, Processes, tasks. Physical Network elements. Processing elements. Databases.
  • Slide 9
  • Interrelationships Static: Interface dependencies: e.g. uses/import. Containment, inheritance, subtype, Data dependencies (database applications). Dynamic: Thread of control. Dataflow.
  • Slide 10
  • Documentation: Putting it all together How best to capture all of these different kinds of components and their interrelationships? Consider
  • Slide 11
  • View Based Documentation of Architectures Architecture Document = View A + View B + View C + View X + Beyond Views
  • Slide 12
  • 4+1 View Model of Architecture By Philippe Kruchten [Kruchten95] (URL to paper given on web site.) Rational Unified Process.
  • Slide 13
  • 4+1 View Model Deployment/ Implementation/
  • Slide 14
  • References Kruchten95, becoming a bit dated. RUP documentation Available in lab. Also includes samples. To access RUP from lab machines Launch the Rational Unified Process. From the Overview page Select Analysis and Design At the top of this page select Artifacts Select Software Architecture Documents You will see links to the examples . Note that I do not consider the examples complete.
  • Slide 15
  • 4+1 VM (Alternate names)
  • Slide 16
  • 5+1 View Model = 4 + 1 + data view. Other combinations of views are possible.
  • Slide 17
  • 4+1: Let us look at each view Deployment/ Implementation/
  • Slide 18
  • Main goal: present architecturally significant use cases either: Duplicated from req. doc. Named and reference given to req. doc. These use cases are to help highlight main Architectural decisions / choices Use Case View
  • Slide 19
  • Logical View: Main Goals Convey Overall structure and Interfaces to the environment, in a manner that is conceptually as simple as possible Challenge: find right level of detail.
  • Slide 20
  • Logical View & Requirements Main focus: functional. It should be possible to assess (up to a certain level of detail) whether requirements will be satisfied by the proposed architectural design.
  • Slide 21
  • Logical View: Components & Components: active classes, classes, modules, packages, subsystems, Connectors (interrelationships): Usage. Containment, aggregation. Inheritance, instantiation.
  • Slide 22
  • Logical View: How Presented? Mainly UML class diagrams, including Package diagrams. Component structure (UML2) Explanatory text, including design rational
  • Slide 23
  • Logical View, Example You have seen many examples of class and package diagrams. UML 2 component diagrams you have seen as well
  • Slide 24
  • Logical View (e.g. Kruchten)
  • Slide 25
  • Process View Components: processes, tasks, group of tasks : single exec. unit. Control: start, shutdown, recover, restore Primary / secondary (redundancy) Interrelationships: Communication Allocation of Logical view components to processes/tasks. Synchronization mechanisms
  • Slide 26
  • Process View e.g. (Kruchten)
  • Slide 27
  • Process View ex. Logical View Components
  • Slide 28
  • Implementation (Development)View Actual S/W organization. Components: Libraries, subsystems, exec., object files, Most common top-level arch. style: layers Connectors: containment, dependencies, Allocate logical components to impl. comp. Reuse: Off-the-shelf. To-the-shelf: sharing with other projects.
  • Slide 29
  • Implementation View illustration
  • Slide 30
  • Deployment (Physical) View Components: processors, processing nodes, Network topology. Usually several topos are supported. S/W should be relatively independent of topo. Allocation of process view elements to H/W (processing nodes). Examples: Network elt: Process mapping into application cards. Network Mgmt: one or more NOCs.
  • Slide 31
  • Deployment View - illustration
  • Slide 32
  • Slide 33
  • Siemens Four View Model Reference: Applied Software Architecture by C. Hofmeister, R. Nord and D. Soni.
  • Slide 34
  • Siemens Four View Model: Overview S/W Architecture
  • Slide 35
  • Comparing the View Models 4+1 Logical Implementation (Development) Process Deployment (Physical) (Use Case) S4VM Conceptual Module Execution Code
  • Slide 36
  • S4VM Overview S4VM: in more detail. Notice activity groups in each view are the same
  • Slide 37
  • S4VM Activities Groups in each view For each view perform Global analysis (Mostly the same for each view.) Central design tasks. (Specific to each view.) Final design tasks. (Specific to each view.)
  • Slide 38
  • Overview
  • Slide 39
  • Global Analysis: Purpose To identify issues (early) so that strategies can be proposed to resolve them. (Architectural) Factors can be seen merely as a means of organizing (group) issues.
  • Slide 40
  • Global Analysis Activities: 1.Analyze Factors. 2.Identify Issues. 3.Develop Strategies.
  • Slide 41
  • 1. Analyze Factors - purpose Identify and describe factors that can influence the system architecture. Document the factors.
  • Slide 42
  • 1. Analyze Factors Use given factor categorization / list to kickoff. For each factor consider: How it relates to the project. Flexibility and changeability. Impact.
  • Slide 43
  • Factor Categorization (e.g. SFVM) Organizational Technological Product
  • Slide 44
  • Organizational Factors Top-level grouping of factors: O1: Management O2: Staff skills, interests, strengths, weaknesses. O3: Process and development environment. O4: Development schedule. O5: Development budget.
  • Slide 45
  • O1: Management, further refined Build vs. buy. Schedule vs. functionality. Environment. Business goals.
  • Slide 46
  • Ex. Project Factor Analysis Output O1: Management O1.1: Build vs. buy There is a mild preference to build. Flexibility & changeability: organization will consider buy if justified. Impact: moderate impact on meeting schedule. O1.2: Schedule vs. functionality Preference for meeting schedule over some features Flex.&chng: negotiable for some features
  • Slide 47
  • Technological Factors T1: General-purpose hardware E.g. processors, memory, network, disk, T2: Domain-specific hardware T3: Software technology E.g. OS, UI, prog. lang., design patterns, T4: Architecture technology E.g. arch. Styles, patterns, frameworks. T5: Standards
  • Slide 48
  • Product Factors P1: Functional features P2: User interface P3: Performance P4: Dependability P5: Failure detection, reporting, recover P6: Service P7: Product Cost
  • Slide 49
  • What is an Issue? A (potential) problem.
  • Slide 50
  • 2. Identify Issues Key issues influencing architectural design which are to be resolved. Consider influencing factors.
  • Slide 51
  • Issue: Skill Deficiencies Influencing factors: O2: Staff skills O2.3 (Experience with multithreading): only one developer has multithreading experience. O2.4 (Experience with multip

Search related