1 / 29

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. Software Architecture.

base
Télécharger la présentation

Y2 eProjects

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Y2 eProjects Session 2 – Static Models (or Software Structure) “Don’t learn the tricks of the trade. Learn the trade” Unknown

  2. Objectives • Software Architecture • External vs. Internal design • Static Model • Class Modeling • Class Diagram • CRC ACCP i7.1\Sem3_4\eProject\T2

  3. 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 ACCP i7.1\Sem3_4\eProject\T2

  4. N-tiers Architecture SEM 3 Architecture SEM 4 HTML\ASPX Presentation HTML\JSP\JSF C# Business EJB\JMS\ MDB\JavaMail MS SQL Server Data MS SQL Server ACCP i7.1\Sem3_4\eProject\T2

  5. Package Diagram Image: Larman(2004) Package Diagram shows the structure of a complex system in term of packages (or modules) ACCP i7.1\Sem3_4\eProject\T2

  6. 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 ACCP i7.1\Sem3_4\eProject\T2

  7. Class and Object Object Class 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

  8. Class Names Class Attributes Class Methods Constraints Comment Class Diagram (cont’d)

  9. Representation of Relationship Multiplicity-Multiplicity defines how many objects participate in a relationship

  10. Multiplicity Student Schedule 1 0..* Navigation Multiplicity & Navigation

  11. An aggregation is a stronger form of relationship where the relationship is between a whole and its parts Whole Part Student Schedule Aggregation Aggregation

  12. Part Whole Student Schedule Aggregation Aggregation-Composition • Composition is a form of aggregation with strong ownership and coincident lifetimes of the part with the aggregate

  13. A dependency relationship is a weaker form of relationship Aggregation-Dependency

  14. 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

  15. Professor Professor University University Association Name Works for Role Names Class Employee Employer Association • Association is a connection between classes

  16. 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.

  17. Association Classes

  18. 1 99 Theatre Seat Theatre Seat Row {1,2,…9} Column {1,2,..11} 1 1 Qualified Association

  19. Recursive Association

  20. Inheritance and Generalization-1

  21. Inheritance and Generalization-2 • The mechanism for sharing attributes and operations using the principle of generalization is referred to as inheritance

  22. Same Association or Aggregation

  23. Interface

  24. 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

  25. How to Identify Classes? • Nouns in problem statement • Knowledge of the problem domain • Use Cases • Physical entities • Devices • Events • Roles played • Operational procedures • Sites • Organisational units • Tangible things • Events • Roles played • Interactions • Location • Organizational Units • The Requirements statement • Use Cases • Application experts • Studying the system • Similar systems • Previous systems

  26. Finding Candidate Classes

  27. CRC – A non-UML OOAD approach Class Collaborator Image: Beck & Cunningham CRC cards are paper index cards on which one writes the responsibilities and collaborators of classes ACCP i7.1\Sem3_4\eProject\T2

  28. 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

  29. 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

More Related