Applying 4 1 View Architecture With UML 2

Applying 4 1 View Architecture with UML 2White Paper

Copyright 2007 FCGSS, all rights reserved.www.fcgss.com

IntroductionUnified Modeling Language (UML) has been available since 1997, and UML 2 wasreleased in 2004, building on an already successful UML 1.x standard. UML 2 comeswith 13 basic diagram types to support Model Driven Architecture (MDA) and ModelDriven Development (MDD).Philippe Kruchten originally presented the 4 1 View Model to describe the architecture ofsoftware-intensive systems. This approach uses multiple views to separate stakeholders’concerns. The 4 1 View Approach is widely accepted by the software industry torepresent application architecture blueprints. However, the industry has not yetcompletely embraced UML 2. IT architects are continuing with UML 1.x artifacts torepresent architecture and are consequently missing out on the powerful benefits of theimprovements made in UML 2.This article presents the approach for 4 1 View Architecture using UML 2 diagrams. Itenhances the original concept of the approach using the current modeling standards andtechniques, and aims to encourage Application Architects to adapt relevant UML 2artifacts. This article discusses each of the views and allocates the UML 2 diagrams tothese views. It does not, however, teach semantics and modeling using UML 2 notations.The audience is expected to have a basic understanding of UML and to be able to refer toUML 2 for further details.UML 2 DiagramsLet us briefly review the diagrams available in UML 2 Specification.UML 2 Superstructure Specification divides the 13 basic diagram types into two keycategories: Part I – Structural Diagrams: These diagrams are used to define static architecture.They comprise static constructs such as classes, objects, and components, and therelationships between these elements. There are six structural diagrams: PackageDiagrams, Class Diagrams, Object Diagrams, Composite Structure Diagrams,Component Diagrams and Deployment Diagrams. Part II – Behavioral Diagrams: These diagrams are used to represent dynamicarchitecture. They comprise behavioral constructs such as activities, states, timelinesand the messages that run between different objects. These diagrams are used torepresent the interactions among various model elements and instantaneous states overa time period. There are seven behavioral diagrams: Use Case Diagrams, ActivityDiagrams, State Machine Diagrams, Communication Diagrams, Sequence Diagrams,Timing Diagrams and Interaction Overview Diagrams.UML 2 has introduced Composite Structure, Object, Timing and Interaction Overviewdiagrams. The remaining diagrams were borrowed from UML 1.x, although some of themwere changed significantly.4 1 View ArchitectureThe fundamental organization of a software system can be represented by: Structural elements and their interfaces that comprise or form a system Behavior represented by collaboration among the structural elements Composition of Structural and Behavioral elements into larger subsystemsSuch compositions are guided by desired abilities (non-functional requirements) likeusability, resilience, performance, re-use, comprehensibility, economic and technologyconstraints and trade-offs etc. Also, there are cross-cutting concerns (like security andtransaction management) that apply across all the functional elements1

Architecture also means different things to different stakeholders. For example, aNetwork Engineer would only be interested in the hardware and network configuration ofthe system; a Project Manager in the key components to be developed and theirtimelines; a Developer in classes that make up a component; and a Tester in scenarios.So we need multiple view points for distinct stakeholders’ needs, showing what is relevantwhile masking the details that are irrelevant.The 4 1 View Approach is an ‘architecture style’ to organize an application’s architecturerepresentations into views to meet individual stakeholder’s needs. Figure 1 shows theviews in the 4 1 View Architecture.CONCEPTUALPHYSICALLogical ViewImplementation ViewConfigurationManagementFunctionalityUse Case ViewScenariosProcess ViewDeployment ViewPerformanceScalabilityThroughputFigure 1: 4 1 View ModelLogical View (Object Oriented Decomposition)This view focuses on realizing an application’s functionality in terms of structuralelements, key abstractions and mechanisms, separation of concerns and distribution ofresponsibilities. Architects use this view for functional analysis.“Software Architecture is thefundamental organization ofa system, embodied in itscomponents, theirrelationships to each otherand the environment, andthe principles governing itsdesign and evolution.— The definition ofSoftware Architecture asper IEEE RecommendedPractice for ArchitecturalDescription of SoftwareIntensive Systems (IEEE1471-2000)”The logical architecture is represented at different levels of abstraction and progressivelyevolves in iterations.1. Vertical and horizontal divisions– The application can be vertically divided into significant functional areas (i.e.,order capture subsystems, order processing subsystems).– Or, it can be horizontally divided into a layered architecture distributingresponsibilities among these layers (i.e., presentation layers, services layers,business logic layers, and data access layers).2. Representation of structural elements as classes or objects and their relationships.2

UML 2 provides an elaborate set of diagrams to create a Logical View:1. Class Diagrams or Structural Diagrams: These diagrams define the basic buildingblocks of a model. They focus on each individual class, the main operations andrelationships to other classes’ associations, usage, composition, inheritance etc.2. Object Diagrams: These diagrams show how instances of structural elements arerelated. They help understand the class diagrams when the relationships are complex.The object diagrams were informally used in the UML 1.x world; in UML 2 they areformal artifacts.3. Package Diagrams: These diagrams are used to divide the model into logical containersor ‘packages’. They can be used to represent vertical and horizontal divisions aspackages.4. Composite Structure Diagrams: These diagrams help in modeling the parts containedby a class and the relationships between the parts. When parts are related, suchdiagrams significantly simplify the relationships between the classes. Ports are used torepresent how a class hooks into the environment. These diagrams supportcollaborations that can be used to represent design patterns of cooperating objects.UML 2 has introduced these diagrams as a major improvement over earlier structuralconstructs.5. State Machine Diagrams: These diagrams are necessary to understand the instantstates of an object defined by a class. These diagrams are optionally used when thereis a need to understand the possible states of a class.The diagram notations are intentionally kept out of the scope of this document.Please refer to Sparx Systems’ online tutorial to understand the notations(http://sparxsystems.com/resources/uml2 tutorial/).While modeling for the Logical View, start with the Class and Package diagrams andexpand as necessary. Figure 2 shows the modeling approach for the Logical View.UML also provides profiles for data modeling using Entity Relationship (ER) Diagrams.ER Diagrams can also be considered as another form of Logical View. Some Architectsprefer to capture ER Diagrams in a separate view called Data View.MODELING LOGICAL VIEW WITH DiagramsObjectDiagramsStateDiagrams1. Start with class diagrams to model the system2. Use package diagrams to logically group diagramsOptional use3. Object diagrams when relationships betweenclasses need to be explained through instances4. State Charts when internal states of a specificclass are to be explained5. Composite Structures when parts of a class andrelationships between parts are to be modeledFigure 2: Modeling Logical View3

Process View (Process Decomposition)This view considers non-functional aspects such as performance, scalability andthroughput. It addresses the issues of concurrency, distribution and fault tolerance. Itshows the main abstractions from the Logical View executing over a thread as anoperation. A process is a group of tasks that form an executable unit; a software systemis partitioned into sets of tasks. Each task is a thread of control that executes withcollaboration among different structural elements (from the Logical View). Process Viewalso encompasses re-usable interaction patterns to solve recurring problems and to meetnon-functional service levels.The process architecture can be represented at various levels of abstraction such asinteractions between systems, subsystems and objects etc. based on the need.The Process view can be represented by the following UML 2 diagrams:1. Sequence Diagrams: These diagrams show the sequence of messages passed betweenthe objects on a vertical timeline. UML 2 has made significant improvements onSequence diagram notations to aid Model Driven Development. The fragment typessuch as loop, assert, break and alt help in diagramming to the level of detail that keepscode and models in sync – not just in terms of structure, but also in behavior. Today’smodeling tools are yet to catch up on utilizing the power of UML 2 Sequence diagrams.2. Communication Diagrams: These diagrams show communications between objects atruntime during a collaboration instance. These diagrams are closely related toSequence diagrams. While Sequence diagrams are focused on the flow of messagesthroughout an interaction over a timeline, the Communication diagrams focus on thelinks between the participants; they were previously called Collaboration diagrams. Inaddition to changing the name, UML 2 has made improvements relative to Sequencediagrams.3. Activity Diagrams: These diagrams are similar to flowcharts and have a wide range ofuses in different view points. In the process view, they can be used to depict theprogram flows and complex business logic with actions, decision points, branching,merging and parallel processing. UML 2 has made several improvements andstandardized the Activity Diagram constructs. Now you can also represent the timeevents, external sending and receiving signals in the Activity Diagrams.4. Timing Diagrams: Timing Diagrams specifically address modeling for performance.They depict the amount of time allowed for a participant to receive events and switchbetween the states, and how long a participant can stay in a specific state. Thesediagrams were introduced in UML 2 and can be used for performance design.5. Interaction Overview Diagrams: These diagrams provide an overview of how severalinteractions work together to implement a system concern. They are a fusion ofActivity, Sequence and Timing Diagrams. Each part of an interaction could berepresented by a distinct diagram type. UML 2 introduces these diagrams and theycan be used to aid high-level overviews and understand the overall system behavior.While modeling for Process View, you can start with either Sequence or Communicationdiagrams. Both these diagrams can be created from each other, so it is merely apersonal preference on which one to use. As the scenarios get complex, you can useother diagrams. Figure 3 shows the order of modeling for Process View withUML 2 diagrams.4