Be Expert with us in .NET and SQL Server

ALM….?

ALM Architecture and Modeling Features

• Diagrams that comply with Unified Modeling Language (UML) 2.1.2: sequence, class, component, activity, and use case
• Layer diagrams
• Code-generated sequence diagrams and dependency graphs
• Architecture Explorer
• Architectural validation
• Integration with work items in Microsoft Visual Studio Team Foundation Server
• Extensibility for UML diagrams

Brainstorming a project using Visual Studio 2010

Business Context

•Introducing Tailspin Toys

 –Small Brick and Mortar hobby shop that sells model airplanes

–Want an online store front to supplement there in store sales

Brainstorming Session – Scoping  it out

• Define the solutions boundaries
• Identify who will be impacted by the solution
• Discover what valuable activities will be automated
• Uncover Constraints that will limit the solution
• Kick Start Requirements Gathering Process

Demo – Brainstorming

• Create Empty Solution
• Create Modeling Project
• Add Use Case Diagram
• Add Subsystem
• Change Color
• Add Vision Statement
• Add Actors
• Add Functional Requirements
• Add Constraints
• Iterate

Tips

• Limit workshops to 1 hour each
• Always start with a vision of the solution
• Clearly identify who lives inside and outside the system
• Describe goals from user’s point of view (business value)
• Generate lots of ideas and capture everything

Organizing Features into Use Case Models

Use Case Diagrams

• Discuss  and Communicate

–The scenarios in which your system or application interacts with people, organizations, or external systems.

–The goals that it helps those actors achieve.

_The scope of your system

• No Detail, only summarizes some of the relationships between use cases, actors, and systems
• Helpful in discovering scope -> which functional requirements are part of our system
• Lists only functional requirements, all others must be recorded separately

Guidelines

• Breakup user goals and tasks into separate digestible diagrams
• Use those diagrams as a structural guide for writing requirements as Use Case documents

A Few Words About Actors

• Actors are always external participants
• Actors Interact Directly with the system
• Actors represent roles
• Use Cases are always initiated by an Actor

Actions

• Create use cases
• Add actors
• Add subsystems
• Add Use cases
• Define association
• Add Actor Generalization
• Link to Artifacts
• Structure your use cases
• Define subsystems

Tips

• Think of actors as roles and not job titles
• Use business domain terminology
• Focus on actors goals not implementation details
• Always use strong active verbs in the names
• Focus on only one Feature area in a single diagram
• Stack cases in diagram to show relative order
• Use color and notes to document important details
• Avoid decomposing the use cases into too much detail. Use cases are about the users’ experience of your system, instead of its internal workings

 

Model Business Domains Using Conceptual Class Diagram

Conceptual Class Diagram
aka domain model or analysis class model

• Explore domain concepts and assign responsibilities
• Develop a consistent vocabulary of business concepts and terms
• –Used throughout the requirements modelUsed when communication between application and users
• Describe the types of information used within the system and exchanged with other systems
• Independent of requirements gathering method

Analysis Steps

• Identify the key terms used as data or data type elements
• Use the classes as nouns when writing requirements
• Use enumerations to define literal values or states used in business processes
• Iterate and refine this model as new requirements are captured

Tips – Domain Modeling

• Use friendly names (spaces, no abbrevations)
• Show just those classes needed in description of the requirements
• Focus on names and simple relationships (associations)Don’t worry about aggregation or composition – that comes later in detailed design
• Capture multiplicity to clarify the relationships
• •Add attributes and types only if they are needed to clarify the requirements –Stick with standard primitives for attribute types: boolean, int, stringAdd doman specific types if they add clarity (Temprature:Celcius, Duration:weeks)
• Stay implementation independent –Don’t assign visibilities – that comes later in detailed design –Avoid Modeling Keys or id’s – they are an implementation  detailsAvoid modeling verbs/actions/operations/functions

Activity Diagrams

• Next Generation Flow Charts
• Used to show processes –Business Processes –Work flows-Algorithms
• Compliment to Use Cases-Show task flow instead of structure

Actions

• Create Activity Diagram
• Add Activities
• Describing Control Flow –Describe decisions and Loops –Starting the activity –Ending the activity –Interrupting activity
• Describing Data Flow –With Object Nodes –With input and output pins
• Define action in more detail –Call Behavior Action –Call Operation Action
• Concurrent Flows

Tips

• Use them to capture and validate business processes
• Think in terms of the users actions
• Focus on actions that are visible from outside the system
• Use to show flow of actions that span multiple use cases
• Best diagram to show parallel operations
• Focus on only one activity in each diagram

Sketching out an Application using a Layer Diagram

Purpose of Layer Diagram

• Used to describe structure of an application at a High Level
• Identify the major components or functional units of the design and their interdependencies
• Each Layer represents a logical group of namespaces, projects or other artifacts
• You can make sure that code adheres to your layers by using layer diagram as a part of build process

Design a Projects Physical Structure using component diagram

Component Diagram

• Visualize the physical structure of a system
• Focus on the components of a system, their relationships, interfaces and ports
• Highlight the service behavior that they provide and consume through interfaces

Design Steps

• Create a Component Diagram to show the major parts of your system
• Draw Dependencies between the components or their interfaces to show the structure of the system
• Use interfaces on the components to show the services that each component provides or requires
• In large design, you can draw separate diagrams to decompose components into smaller parts

 

Sketch Interactions with Sequence Diagrams

Sequence Diagram

• Capture Dynamic Behavior –The lifecycles of objects and how they collaborate together to deliver the required system functionalitySequential Flow of time
• Show Interactions between nouns in your system –Actors –Classes –ComponentsSubsystems
• Interactions consists of messages between typical instances during run time

Revealing Responsibilities with Class Diagrams

Class Diagrams

• Shows Logical and structural aspects of the system –Data Types used to store and exchange dataRelationships between those types
• Implementation Independent –Can Represent many things •Language specific software objects •XML NodesDatabase Tables