1 / 67

SOEN 6011 Software Engineering Processes

SOEN 6011 Software Engineering Processes. Section SS Fall 2007 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/soen6011-f2007.html. Week 11. Software Architecture 4+1 Views Siemen’s Approach. Software Architecture: Definitions.

arnav
Download Presentation

SOEN 6011 Software Engineering Processes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SOEN 6011Software Engineering Processes Section SS Fall 2007 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/soen6011-f2007.html

  2. Week 11 • Software Architecture • 4+1 Views • Siemen’s Approach

  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).

  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 …

  5. Conceptual Integrity … • … is central to achieving product quality. • Also called Architectural Integrity. • Coherent conceptual (design) modelmakes 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? …

  6. System Architect • Custodian of product ensures • Design coherence. • Also, to some extent, Interface coherence (esp. UI).

  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.

  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.

  9. Interrelationships • Static: • Interface dependencies: e.g. uses/import. • Containment, inheritance, subtype, … • Data dependencies (database applications). • … • Dynamic: • Thread of control. • Dataflow. • …

  10. Documentation: Putting it all together • How best to capture all of these different kinds of components and their interrelationships? • Consider …

  11. View Based Documentation of Architectures • Architecture Document = View A + View B + View C + … View X + “Beyond Views”

  12. “4+1” View Model of Architecture • By Philippe Kruchten [Kruchten95](URL to paper given on web site.) • Rational Unified Process.

  13. “4+1” View Model Implementation/ Deployment/

  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.

  15. “4+1” VM (Alternate names)

  16. “5+1” View Model • = 4 + 1 + data view. • Other combinations of views are possible.

  17. “4+1”: Let us look at each view Implementation/ Deployment/

  18. Use Case View • 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

  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.

  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.

  21. Logical View: Components & … • Components: • active classes, classes, • modules, • packages, • subsystems, … • Connectors (interrelationships): • Usage. • Containment, aggregation. • Inheritance, instantiation.

  22. Logical View: How Presented? • Mainly UML “class” diagrams, including • Package diagrams. • Component structure (UML2) • Explanatory text, including design rational

  23. Logical View, Example • You have seen many examples of class and package diagrams. • UML 2 component diagrams you have seen as well …

  24. Logical View (e.g. Kruchten)

  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

  26. Process View – e.g. (Kruchten)

  27. Logical View Components Process View – ex.

  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.

  29. Implementation View – illustration

  30. Deployment (Physical) View • Components: processors, processing nodes, … • Network topology. • Usually several topo’s 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.

  31. Deployment View - illustration

  32. Deployment View - illustration

  33. Siemens Four View Model • Reference: Applied Software Architecture by C. Hofmeister, R. Nord and D. Soni.

  34. Siemens Four View Model: Overview S/W Architecture

  35. 4+1 Logical Implementation (Development) Process Deployment (Physical) (Use Case) S4VM Conceptual Module Execution Code Comparing the View Models

  36. S4VM: in more detail. Notice activity groups in each view are the same … S4VM Overview

  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.)

  38. Overview

  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.

  40. Global Analysis Activities: • Analyze Factors. • Identify Issues. • Develop Strategies.

  41. 1. Analyze Factors - purpose • Identify and describe factors that can influence the system architecture. • Document the factors.

  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.

  43. Factor Categorization (e.g. SFVM) • Organizational • Technological • Product

  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.

  45. O1: Management, further refined … • Build vs. buy. • Schedule vs. functionality. • Environment. • Business goals.

  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 … • …

  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

  48. Product Factors • P1: Functional features • P2: User interface • P3: Performance • P4: Dependability • P5: Failure detection, reporting, recover • P6: Service • P7: Product Cost

  49. What is an Issue? • A (potential) problem.

  50. 2. Identify Issues • Key issues influencing architectural design which are to be resolved. • Consider influencing factors.

More Related