y2 eprojects

Y2 eProjects

Session 2 – Static Models (or Software Structure)

“Don’t learn the tricks of the trade. Learn the trade”Unknown

Objectives

Software Architecture External vs. Internal design Static Model Class Modeling Class Diagram CRC

ACCP i7.1\Sem3_4\eProject\T2 2

ACCP i7.1\Sem3_4\eProject\T2

Software Architecture

Software Architecture: The structure of a software system which comprise software components, the externally visible properties of those components, and the relationships between them

Architecture represents the ‘big picture’ of a software system

Common Architecture: Client\Server Distributed Computing N-tier Architecture Service-Oriented Architecture

N-tiers Architecture

ACCP i7.1\Sem3_4\eProject\T2

Presentation

Business

Data

HTML\JSP\JSF

SEM 4

EJB\JMS\MDB\JavaMail

MS SQL Server

HTML\ASPX

SEM 3

C#

MS SQL Server

Architecture

ACCP i7.1\Sem3_4\eProject\T2

Package Diagram

Package Diagram shows the structure of a complex system in term of packages (or modules)

Image: Larman(2004)

ACCP i7.1\Sem3_4\eProject\T2

Class Diagram

Class diagram describes the types of objects in the system and the various kinds of static relationships amongst them

Class Diagram can be used for various perspectives: Conceptual (or domain model) Specification Implementation

Class and Object

Class - A class is a description of a group of objects with common properties (attributes), behavior (Operations), relationships, and semantic

Object - An object represents an entity, either physical, conceptual, or software

ClassObject

Class Diagram (cont’d)

Class Names Class Attributes Class Methods Constraints Comment

Representation of Relationship

Multiplicity-Multiplicity defines how many objects participate in a relationship

Multiplicity & Navigation

Student Schedule

Navigation

Multiplicity

0..*1

Aggregation

An aggregation is a stronger form of relationship where the relationship is between a whole and its parts

Student Schedule

Aggregation

WholePart

Aggregation-Composition

Composition is a form of aggregation with strong ownership and coincident lifetimes of the part with the aggregate

Student Schedule

Aggregation

Whole Part

Aggregation-Dependency

A dependency relationship is a weaker form of relationship

Aggregation-Generalization

A specialization/generalization relationship is one, in which objects of the specialized element (the child) are substitutable for objects of the generalized element (the parent)

Superclass Subclass

Association

Association is a connection between classes

Professor University

Professor UniversityWorks for

Class

Association Name

Role Names

EmployerEmployee

Constraints of Association

An association may have a name that is placed on, or adjacent to the association path

The name of the association should reflect the purpose of the relationship and be a verb phrase; the name of an association can be omitted, particularly if roles names are used.

Each end of an association is a role specifying the face that a class plays in the association (not a constraint). Each role must have a name, and the role names must be unique. The role name should be a noun indicating the associated object’s role in relation to the associating object.

The use of association names and role names are mutually exclusive: one should not use both an association name and role name. For each association, it needs to decide as to which conveys more information.

Association Classes

Qualified Association

Theatre Seat1 99

Theatre Seat1Row {1,2,…9}

Column {1,2,..11}

1

Recursive Association

Inheritance and Generalization-1

Inheritance and Generalization-2

The mechanism for sharing attributes and operations using the principle of generalization is referred to as inheritance

Same Association or Aggregation

Interface

Object Model

Language independent

Notation allowing the specification of classes, their data or attributes (private) and methods (public), inheritance

This diagram depicts the structural relationship and functional behavior of the classes

Nouns in problem statement Knowledge of the problem

domain Use Cases Physical entities Devices Events Roles played Operational procedures Sites Organisational units

How to Identify Classes?

Tangible things Events Roles played Interactions Location Organizational Units

The Requirements statement Use Cases Application experts Studying the system

Similar systems Previous systems

Finding Candidate Classes

Candidate ClassesUse Cases

Requirement Statement

Previous System

Similar Systems

Application Experts

ACCP i7.1\Sem3_4\eProject\T2

CRC – A non-UML OOAD approach CRC cards are paper index cards on which

one writes the responsibilities and collaborators of classes

Image: Beck & Cunningham

ClassCollaborator

Best Practices

Don’t try to model every thing, “design enough”

For analysis, draw conceptual models When working with software, draw

specification models For illustrating a particular implementation

technique, use implementation models For testing a model, write some code

ACCP i7.1\Sem3_4\eProject\T2

References and Readings

Beck K. & Cunningham W., A Laboratory For Teaching Object-Oriented Thinking, (http://c2.com/doc/oopsla89/paper.html )

Fowler M. & Scott K. (1999) UML Distilled, Addison Wesley

Larman, C. (2004), Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, 3rd Edition, Addison Wesley

Aptech India, OOAD Course, ACCP 2003 Curriculum

ACCP i7.1\Sem3_4\eProject\T2