SOEN 6011 Software Engineering Processes

  • View

  • Download

Embed Size (px)


SOEN 6011 Software Engineering Processes. Section SS Fall 2007 Dr Greg Butler Week 11. Software Architecture 4+1 Views Siemen’s Approach. Software Architecture: Definitions. - PowerPoint PPT Presentation

Text of SOEN 6011 Software Engineering Processes

  • SOEN 6011Software Engineering ProcessesSection SS Fall 2007Dr Greg Butler

  • Week 11Software Architecture

    4+1 Views

    Siemens Approach

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

  • Architecture: Benefits?Contributes to elicitation of requirements.First design: can already assess / determinesatisfaction of requirements.Work allocation / distribution (schedule).Instructional: useful to learn about system.Initial development & maintenance.Reuse of the architectural style / framework.Also

  • 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 & marketingMaintain.How to achieve conceptual integrity?

  • System Architect

    Custodian of product ensuresDesign coherence.Also, to some extent, Interface coherence (esp. UI).

  • System ArchitectFull-time job!Separation of architecture from implementation.Project size hierarchy of architects.Single mindHaving a system architect is an effective means of achieving conceptual integrity.

  • ComponentsS/W entities Systems (e.g. COTS), subsystems, frameworks, packages, layers, libraries, modules, classes, objects, executables, DLLs, plug-ins, Processes, tasks.PhysicalNetwork elements.Processing elements.Databases.

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

  • Documentation: Putting it all togetherHow best to capture all of these different kinds of components and their interrelationships?


  • View Based Documentation of ArchitecturesArchitecture Document =View A +View B +View C + View X +Beyond Views

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

  • 4+1 View ModelDeployment/Implementation/

  • ReferencesKruchten95, becoming a bit dated.RUP documentationAvailable in lab.Also includes samples.To access RUP from lab machinesLaunch the Rational Unified Process.From the Overview page Select Analysis and DesignAt the top of this page select ArtifactsSelect Software Architecture DocumentsYou will see links to the examples . Note that I do not consider the examples complete.

  • 4+1 VM (Alternate names)

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

  • 4+1: Let us look at each viewDeployment/Implementation/

  • Use Case ViewMain 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 mainArchitectural decisions / choices

  • Logical View: Main GoalsConvey Overall structure and Interfaces to the environment, in a manner that isconceptually as simple as possibleChallenge: find right level of detail.

  • Logical View & RequirementsMain 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.

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

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

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

  • Logical View (e.g. Kruchten)

  • Process ViewComponents: processes, tasks, group of tasks : single exec. unit.Control: start, shutdown, recover, restorePrimary / secondary (redundancy)Interrelationships:CommunicationAllocation of Logical view components to processes/tasks.Synchronization mechanisms

  • Process View e.g. (Kruchten)

  • Process View ex.

  • Implementation (Development)ViewActual S/W organization.Components:Libraries, subsystems, exec., object files, Most common top-level arch. style: layersConnectors: containment, dependencies, Allocate logical components to impl. comp.Reuse:Off-the-shelf.To-the-shelf: sharing with other projects.

  • Implementation View illustration

  • Deployment (Physical) ViewComponents: 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.

  • Deployment View - illustration

  • Deployment View - illustration

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

  • Siemens Four View Model: OverviewS/W Architecture

    Conceptual View

    Module View

    Code View

    Execu-tion View

    Source Code


  • Comparing the View Models4+1LogicalImplementation (Development)ProcessDeployment (Physical)(Use Case)


  • S4VM OverviewS4VM: in more detail. Notice activity groups in each view are the same

  • S4VM Activities Groups in each viewFor each view performGlobal analysis(Mostly the same for each view.)Central design tasks.(Specific to each view.)Final design tasks.(Specific to each view.)

  • Overview

  • Global Analysis: PurposeTo 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.

  • Global AnalysisActivities:Analyze Factors.Identify Issues.Develop Strategies.

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

  • 1. Analyze FactorsUse given factor categorization / list to kickoff.For each factor consider:How it relates to the project.Flexibility and changeability.Impact.

  • Factor Categorization (e.g. SFVM)OrganizationalTechnologicalProduct

  • Organizational FactorsTop-level grouping of factors:O1: ManagementO2: Staff skills, interests, strengths, weaknesses.O3: Process and development environment.O4: Development schedule.O5: Development budget.

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

  • Ex. Project Factor Analysis OutputO1: ManagementO1.1: Build vs. buyThere is a mild preference to build.Flexibility & changeability: organization will consider buy if justified.Impact: moderate impact on meeting schedule.O1.2: Schedule vs. functionalityPreference for meeting schedule over some featuresFlex.&chng: negotiable for some features

  • Technological FactorsT1: General-purpose hardwareE.g. processors, memory, network, disk, T2: Domain-specific hardwareT3: Software technologyE.g. OS, UI, prog. lang., design patterns, T4: Architecture technologyE.g. arch. Styles, patterns, frameworks.T5: Standards

  • Product FactorsP1: Functional featuresP2: User interfaceP3: PerformanceP4: DependabilityP5: Failure detection, reporting, recoverP6: ServiceP7: Product Cost

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

  • 2. Identify IssuesKey issues influencing architectural design which are to be resolved.Consider influencing factors.

  • Issue: Skill DeficienciesInfluencing factors:O2: Staff skillsO2.3 (Experience with multithreading): only one developer has multithreading experience.O2.4 (Experience with multiprocessor systems): only two developers

  • 3. Develop StrategiesWhat is a strategy?

  • What is a Strategy?A means by which one or more issues are to be resolved, partially or totally.

  • 3. Develop StrategiesFor each issue:Develop strategies to address issue.Identify related strategies.

  • Ex. Issue: Changes in HardwareChanges in both general-purpose and domain-specific hardware are anticipated on a regular basis. The challenge is to reduce the effort and time involved in adapting the product to the new hardware.Influencing factors: T1 (General-purpose H/W), T2 (Domain-specific H/W).Solutions: ?

  • Ex. StrategiesEncapsulate hardware

  • S4VM: Conceptual View

  • Conceptual View DocumentationStructureConfigurations of: components, connectors, ports, roles, protocols.BehaviorState diagrams.Sequence diagrams.Natural language.

  • Conceptual View ActivitiesGlobal analysis.Central design tasks.Final design task.

  • Conceptual V.: Central Design TasksCreate conceptualComponents, Connectors (and ports, roles, protocols)Configuration.Global evaluation

  • Conceptual V.: Final Design TasksResource budgetingResources used by the software, but Resources themselves can be H/W or S/W.Examples of resources include:Memory, CPU time,Bandwidth, .

  • Global EvaluationEvaluate design decisionsContinually, relative to results of global analysis.Periodically, w.r.t. intera