Mar 24, 2007

Introduction to Software Architecture for Games and Simulations - Part II

Views / Models

    In order to meet the needs of the various roles involved with the software system, we introduce the notion of “views”. Each view reflects a specific set of concerns for a given group of stakeholders. Each view abstracts away model details that are independent of the associated concerns. A view can be simply defined as the following:
A view is a model of the system that has purpose, context, and a viewpoint.
This short definition is made up of four parts:
  • Is a Model of the system – A view is a model. It must be human graspable, and allow the stakeholder to quickly and easily understand some aspect of the system.
  • Has a Viewpoint – Every view will show the system from a specific perspective.
  • Has Purpose – Every view must have a specific purpose. The view should be created to provide a necessary understanding of the system required by the stakeholders.
  • Has Context – As a model of a single software system, view artifacts are often interrelated. The view must provide the context, allowing stakeholders to understand those interrelations.

    The field of software engineering has developed a hefty list of software model views that have proven valuable in a variety of software systems. As with any domain, architects in the games domain may benefit from using a subset of these views. Below are a few of the view types game architects may find useful.

Use Case View

    The use case view is intended to show the functional requirements of a system. Although many stakeholder may find the view useful, the use case model is typically employed to help the customers and developers agree on how the system will be used.
    Games and game functionality are traditionally described using an artifact called a design document. Often filling hundreds of pages using a combination of concept sketches, graphics and descriptive text, the design document describes the content and play of the game. The design document includes just about every possible human interaction with the game, and arguably supersedes the need for a use case model.
    A use case model, however, does have several benefits that may make it worthwhile to model, at least for an important subset of functionality. First, it is simple. Functionality that may span dozens of pages in a design document due to illustrations and other descriptions may be shown cleanly on a single diagram. As the software architect, it is important to abstract away the details that can obscure your design process. Consider the example use case diagram presented in Figure 2. As an architect tasked with defining the structure and communication of your game’s software modules, it is often easier to work from a simple diagram than a complex document.
Figure 2 - Example Game Use Case Diagram

    The second and most important reason to consider modeling a subset of your game’s functionality in a use case model is that views are interrelated. Artifacts in one view will affect the creation and priorities of artifacts in another view. Suppose your task were to create an architecture that supports the functionality of the game presented Figure 2. The architecture must also, however, support all the major game console platforms including the PC, and allow the end user to script their own object behavior. As you continue the design, it will be possible to relate this functional behavior to the static structures and behavior modeling artifacts (sequence diagrams, etc.) of the overall architectural model. The combination of views and the mapping presents a complete and traceable picture of the system being modeled.

Logical View

    The logical view shows the static structure of the system at the logical or conceptual level. This view will show the relationships between classes/objects such as associations and dependencies. Depending on the complexity of the project domain, the logical model can be further refined into the domain and class models, domain models being high level and class models being closer to the actual software structure.
    Typically the architect and developers are the major stakeholders who would use this view. The architect uses this view to define the logical and physical separation of functionality. This separation will not only have a tremendous impact on many of the system’s quality attributes (covered later), but is needed by the developers to understand how they will structure their code.

Domain View
    Domain models are useful when the domain is outside the scope of the developers range of knowledge. For example, if I were designing a battlefield command and control (C2) system for the military I might begin with a domain model simply because the subject matter is so complex. Before I could even begin to understand how to model the software class structure, I would need to thoroughly understand the subject matter. Figure 3 shows an example of a very simple domain model diagram that might be used to help developers understand military platforms and their weapons systems.
Figure 3 - Example Domain Model Diagram
Class View
    The class model is probably the most commonly used form of logical model. It is used to show the structure of the system from a software perspective and really is the core of object-oriented development and design. The class model allows for a great deal of analysis, and it directly transferable to software.
Hybrid Logical View
    While the subject of games can branch into some very complex subjects, it may not be necessary to create separate domain and class models. When the subject matter is small or simple enough, it is usually sufficient to combine the domain and class models into the same logical model. For example a game developer may create a diagram similar to Figure 3 showing the domain objects and a diagram similar to Figure 4 showing the class structure in the same logical model.
Figure 4 - Example Class Model Diagram
    By combing the domain and class views into a single logical view may result in a more complex view, but the benefit is it eliminates the need to map the domain view to the class view. For example, if the architect wants to modify an attribute of the M1A1 tank, modifying the class in the class diagram automatically updates the domain object as well.

Dynamic View

    The dynamic or process view is designed to show the system’s dynamic or run-time behaviors. The dynamic view is primarily of interest to the architect and developers, but can be used by any stakeholder that needs to understand how the system operates. The dynamic view can offer a variety of ways to demonstrate behavior, however the most common are sequence diagrams, activity models, and state machines.
Sequence Diagrams
    Sequence diagrams are used to show control flow through the system. Sequence diagrams are particularly useful because they can be used at different levels of fidelity. Architects may create diagrams that show control flow between system components, as shown in Figure 5, while a software developer may create sequence diagrams at the class / method level of granularity.
Figure 5 – Example Select Object Sequence Diagram
    Sequence diagrams are often used to document software because they are usually simpler to read than pouring through source code. From a software architecture standpoint, however, sequence diagrams are excellent prototyping and analysis tools. Architects can quickly model how components will communicate, and quickly uncover important issues with their design.
Activity Diagrams
    Activity diagrams show the different work flows that occur in a system. They show the many decision paths that can be taken from start to finish and where parallel processing may occur during execution. The game designers and developers may find this a useful way to facilitate communication about the game logic. From an architectural standpoint, activity diagrams offer the same benefits as sequence diagrams, making their use more of a style choice.
Figure 6 - Example Select Object Activity Diagram
State Diagrams
    State diagrams are designed to show the behavior of an entity in the software system. As with activity diagrams, game designers and developers may find this a useful way to communicate game logic. Figure 7 shows and example state machine for the behavior of a some non-player character (NPC) of a made up game. The diagram syntax is simple enough that people with a wide variety of skillsets can understand an entities behavior.
Figure 7 - Example State Diagram of a Friendly NPC
    Software architects are probably less concerned with individual game objects, and more concerned with the state behavior of system components and other high level abstractions. For example, the architect may use state machines to describe the load balancing behavior for the network management system in a massively multiplayer game.

Other Views

    There are potentially an infinite number of views that could be constructed to model a software system. Some developers may be comfortable with the 4+1 set of views specified as part of the Rational Unified Process. Others may pick and choose views that seem relevant to their needs. While this book will tend to focus on the most common views, here are some of the more useful viewtypes and styles the reader may wish to further research.
Viewtypes and Styles
The Module Viewtype
    The module viewtype is used to model the modular structure of a software system. This viewtype contains several styles.
· Decomposition Style
· Uses Style
· Generalization Style
· Layered Style
Component – and – Connector Viewtype
· Pipe-and-Filter Style
· Shared-Data Style
· Publish-Subscribe Style
· Client-Server Style
· Peer-to-Peer Style
· Communicating-Processes Style
Allocation Viewtype
· Deployment Style
· Implementation Style
· Work Assignment Style

Relating Views

    One of the most important aspects of models and views is the fact they are all interrelated. Each view is a simply a perspective look into the same software system, and it stands to reason that many views would overlap, atleast at the conceptual level. This notion of overlapping views is one of the greatest strengths of creating an integrated software model because it allows the architect to analyze and validate the views against each other.
Figure 8 – Select Unit Functionality

Figure 9 - System Component Structure

Figure 10 - How System Implements Select Unit Functionality
    Consider the three views presented in figures 8, 9, and 10. Figure 8 demonstrates through a use case view that the system is required to support a “select unit” piece of functionality. Figure 9 shows the structure of the system, but provides no insight as to whether the system supports the necessary functionality. By creating a dynamic/behavioral view, as in figure 10, it is possible to show the mapping of the required functionality in the use case view to the structural components of the logical view.

    That's it for this week. The next post will wrap up this introduction to software architecture by discussing quality attributes.


Hua Cai said...

mulberry handbags
tory burch outlet online
tiffany jewelry
swarovski crystal
mulberry outlet
true religion uk
tiffany and co jewelry
prada outlet online
burberry outlet store
adidas trainers
nike air max
longchamp handbags
beats by dr dre
kobe shoes
nike air max 90
ferragamo outlet
true religion jeans
oakley sunglasses
ray ban sunglasses
camisetas futbol baratas
basketball shoes,basketball sneakers,lebron james shoes,sports shoes,kobe bryant shoes,kobe sneakers,nike basketball shoes,running shoes,mens sport shoes,nike shoes
timberland boots
michael kors handbags
mulberry handbags sale
tiffany jewelry
true religion sale
michael kors online outlet
christian louboutin outlet
true religion outlet
true religion jeans outlet
true religion jeans
air jordan shoes
christian louboutin online
jordan pas cher
michael kors uk outlet

xumeiqing said...

sac longchamp pliage
coach factory outlet
coach outlet
coach factory outlet
adidas nmd runner
converse shoes
burberry outlet
fitflops sale clearance
nike roshe run women
gucci handbags
burberry outlet
ray ban outlet
cheap oakley sunglasses
ray ban sunglasses
louis vuitton outlet
burberry outlet
asics outlet
yeezy boost 350
reebok uk
ray bans
hermes belt
kate spade outlet
canada goose
holliste sale
cartier watches
yeezy boost 350 black
michael kors outlet
nike trainers
chaussure louboutin
kate spade outlet
christian louboutin shoes
louis vuitton factory outlet
nike free flyknit 4.0
bottega veneta handbags
running shoes
reebok pump said...

discount jordans
air jordans
coach factory outlet
retro 11
louboutin shoes
ray ban sunglasses
kobe 8
rolex watches
giuseppe zanotti
oakley sunglasses
adidas running shoes
tiffany jewelry
adidas superstar trainers
gucci handbags
louis vuitton purses
lebron 12
louis vuitton outlet
burberry handbags
air jordan femme
timberland outlet
michael kors outlet online
michael kors outlet
nike store
coach outlet online
ray ban sunglasses
fit flops
coach factory outlet online
louis vuitton handbags
supra for sale
coach outlet online

dong dong23 said...

christian louboutin shoes
michael kors outlet
chicago bulls jerseys
hermes outlet
ray ban sunglasses
adidas superstar
longchamp outlet
coach factory outlet
fitflops sale clearance
cheap jordans

raybanoutlet001 said...

toms outlet
michael kors outlet
michael kors handbags clearance
nike blazer pas cher
air force 1 shoes
adidas nmd r1
cheap nike shoes sale
nike trainers
cheap oakley sunglasses
michael kors outlet online

raybanoutlet001 said...

yeezy boost 350 white
patriots jerseys
cowboys jerseys
the north face outlet
michael kors outlet
gucci borse
ravens jerseys
converse shoes
hugo boss outlet
air jordan uk

dada24 Xu said...

kate spade outlet
michael kors outlet canada
timberland shoes
christian louboutin shoes
chaussure louboutin
cheap jordan shoes
true religion jeans outlet
polo ralph lauren outlet online
nike air huarache

dong dong23 said...

gucci outlet
ralph lauren outlet
moncler uk
coach outlet store online
ralph lauren outlet
beats by dre
michael kors outlet
ugg boots
ralph lauren uk
seattle seahawks jerseys

Meiqing Xu said...

levis outlet online
louis vuitton handbags
coach factory outlet
true religion
red bottoms shoes
christian louboutin shoes
fake rolex
toms outlet

LCc 03 said...

cheap jordans
nike air force 1
adidas neo
adidas nmd
nike air force
nike air force 1
links of london
lebron james shoes
air jordan shoes
longchamp le pliage

John said...

longchamp handbags
gucci borse
red bottom
adidas yeezy boost
yeezy boost 350 v2
cheap nike sneakers
oakley vault
ralph lauren sale clearance uk

adidas nmd said...

ugg boots
browns jerseys
michael kors outlet
mont blanc outlet
michael kors purses
nike outlet
nike outlet
coach outlet
cheap ugg boots
new york knicks jersey

aaa kitty20101122 said...

cheap jordans
michael jordan shoes
true religion outlet
adidas ultra boost uncaged
michael kors
longchamp bags
michael kors handbags
harden shoes
adidas stan smith

ninest123 said...

canada goose outlet
coach outlet
yeezy boost
pandora charms
hermens bags
coach outlet store online clearances
oakley sunglasses
adidas yeezy
pandora charms sale
fred perry polo