Artifact: Analysis Class
var backPath = './../../';
var imgPath = './../../images/';
var nodeInfo=[{view: "view:_LVCagP5WEdmAzesbYywanQ", path: ["_LVCagP5WEdmAzesbYywanQ", "_zRigkAILEdq-_NKqZM1EhA", "_qwxC8N7YEdmjRZts2c4ZjQ", "{DB21F5EF-810B-4994-B120-79FA8774FA9D}", "{1E20603F-A5B8-42D5-BDBC-69DCE9C0FCDB}"]}, {view: "view:_LVCagP5WEdmAzesbYywanQ", path: ["_LVCagP5WEdmAzesbYywanQ", "_zRigkAILEdq-_NKqZM1EhA", "_QV4x0AISEdqTna4sZVFRow", "_kjFBYN7HEdm8G6yT7-Wdqw", "{98EA224C-36F6-46E6-AB36-2999382B58B3}", "{1E20603F-A5B8-42D5-BDBC-69DCE9C0FCDB}"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_f6_YwN7DEdmsEI4YDGX2ag", "_qwxC8N7YEdmjRZts2c4ZjQ", "{DB21F5EF-810B-4994-B120-79FA8774FA9D}", "{1E20603F-A5B8-42D5-BDBC-69DCE9C0FCDB}"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_Jvt1cAIaEdqEutyfYo0quQ", "_EOvXUN7HEdm8G6yT7-Wdqw", "_kjFBYN7HEdm8G6yT7-Wdqw", "{98EA224C-36F6-46E6-AB36-2999382B58B3}", "{1E20603F-A5B8-42D5-BDBC-69DCE9C0FCDB}"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_Jvt1cAIaEdqEutyfYo0quQ", "_jijhYAIaEdqEutyfYo0quQ", "_mTMIkN7REdmjRZts2c4ZjQ", "{98EA224C-36F6-46E6-AB36-2999382B58B3}", "{1E20603F-A5B8-42D5-BDBC-69DCE9C0FCDB}"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_Jvt1cAIaEdqEutyfYo0quQ", "_jijhYAIaEdqEutyfYo0quQ", "_n7ZcgN7REdmjRZts2c4ZjQ", "{1E20603F-A5B8-42D5-BDBC-69DCE9C0FCDB}"]}];
contentPage.preload(imgPath, backPath, nodeInfo, '', false, false, false);
Artifact: Analysis Class
This work product specifies elements of an early conceptual model for 'things in the system which have responsibilities and behavior'.
Work Product Kinds: Model Element
Purpose
Analysis classes are used to capture the major "clumps of responsibility" in the system.
Relationships
Container Artifact
Analysis Model
RolesResponsible:
Designer
Modified By:
Designer
Software Architect
TasksInput To:
Class Design
Identify Design Elements
Identify Design Mechanisms
Database Design
Use-Case Analysis
Output From:
Architectural Analysis
Use-Case Analysis
Process Usage
Analysis & Design
>
Define a Candidate Architecture
>
Analysis Class
Analysis & Design
>
Define a Candidate Architecture
>
Analysis Class
Analysis & Design
>
Perform Architectural Synthesis
>
Analysis Class
Analysis & Design
>
Perform Architectural Synthesis
>
Analysis Class
Analysis & Design
>
Refine the Architecture
>
Analysis Class
Analysis & Design
>
Refine the Architecture
>
Analysis Class
Analysis & Design
>
Design the Database
>
Analysis Class
Analysis & Design
>
Design the Database
>
Analysis Class
Analysis & Design
>
Analyze Behavior
>
Analysis Class
Analysis & Design
>
Analyze Behavior
>
Analysis Class
Analysis & Design
>
Design Components
>
Analysis Class
Analysis & Design
>
Design Components
>
Analysis Class
Description
Main DescriptionAnalysis Classes specify elements of an early conceptual model for 'things in the system which have responsibilities and
behavior'. They represent the prototypical classes of the system, and are a 'first-pass' at the major abstractions that the
system must handle. Analysis classes may be maintained in their own right, if a "high-level", conceptual overview of the
system is desired. Analysis classes also give rise to the major abstractions of the system design: the design classes and
subsystems of the system.
Tailoring
Representation Options
UML Representation: Class, stereotyped as <<boundary>>, <<entity>> or
<<control>>.
An analysis class may have the following properties:
name: the name of the class
description: brief description of the role of the class in the system
responsibilities: a listing of the responsibilities of the class
attributes: the attributes of the class
The analysis classes, taken together, represent an early conceptual model of the system. This conceptual model evolves
quickly and remains fluid for some time as different representations and their implications are explored. Formal
documentation can impede this process, so be careful how much energy you expend on maintaining this 'model' in a formal
sense; you can waste a lot of time polishing a model which is largely expendable. Analysis classes rarely survive into
the design unchanged. Many of them represent whole collaborations of objects, often encapsulated by subsystems.
Usually, simple note-cards, such as the example below, are sufficient (this is based on the well-known CRC Card technique - see [WIR90] for details of this technique). On the front side of the card, capture the
name and description of the class. An example for a Course in a course registration system is listed below:
Class Name
Course
Description
The Course is responsible for maintaining information about a set of course sections having a common
subject, requirements and syllabus.
Responsibilities
To maintain information about the course.
Attributes
Name
Description
Type
Course Title
The name of the course
string
Description
A short description of the course
string
On the back of the card, draw a diagram of the class:
Class diagram for Course
There is one analysis class card for each class discovered during the use-case-analysis workshop.
More Information
Checklists
Analysis Class
Guidelines
Analysis Class
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.
contentPage.onload();
Wyszukiwarka
Podobne podstrony:
rup analysis class[5A476Fanalysis class~97273Erup analysis?sign discipline)760231więcej podobnych podstron