OOAD Midterm PDF

# CH2 Modeling with UML ## Dealing with Complexity - **Abstraction** - Ignore some aspects. - To better understand other aspects. - Problemin belli bir tarafını daha iyi kavramak için. - Gerekli ve gereksin - Gereksiz kısımları soyutluyoruz. Problemin - Yerleri probleme göre...

# CH2 Modeling with UML ## Dealing with Complexity - **Abstraction** - Ignore some aspects. - To better understand other aspects. - Problemin belli bir tarafını daha iyi kavramak için. - Gerekli ve gereksin - Gereksiz kısımları soyutluyoruz. Problemin - Yerleri probleme göre değişir. - What is relevant or irrelevant depends on the purpose of the model. - **Decomposition** - A technique used to master complexity (Divide and Conquer) - 2 major types of decomposition: - **Functional Decomposition** - The system is decomposed into modules. - Each module is a major function in the application domain. - Modules can be decomposed into smaller modules. - **Object-oriented Decomposition** - The system is decomposed into classes (objects) - Each class is a major entity in the application domain. - Classes can be decomposed into smaller classes. - Both views are important. - **Hierarchy** - Another way to deal with complexity is to provide relationships between this chunks. - Objeler nasıl iletişim kurarlar. - 2 special hierarchy: - **Part-of hierarchy** - Sembolü ile gösterilir. - *For example, a computer has 110 devices, 110 devices are part of computer, computer has CPU, CPU is part of computer, CPU has ALU, ALU is part of CPU.* - **Is-kind-of hierarchy (Taxonomy)** - İle gösterilir. - *For example, Bird is kind of animal.* ## Application vs Solution Domain - **Application Domain (Analysis)** - The environment in which the system is operating. - **Solution Domain (Design, Implementation)** - The technologies used to build the system. - Both domains contain abstractions that we can use for the construction of the system model. # UML First Pass ## Rectangles - Names are not underlined - Denote classes or instances ## Ovals - Names are underlined - Denote functions ## Use Case Diagrams: (Functional Model) - Describe the functional behavior of the system as seen by the user. ## Class Diagrams: (Object Model) - Class diagrams represent the structure of the system. - 2 class arası ilişkiye association denir. Farklı türleri de var. ## Sequence Diagrams: (Dynamic Model) - Sequence diagrams represent the behavior of a system as messages (interactions) between different objects. # Statechart Diagrams (Dynamic Model) - Represent behavior of a single object with interesting dynamic behavior. - Sequence diagram dan farklı, tek 1 obje için çizilir. - Trransition - Initial state. - Event. - Final state # Activity Diagrams - Describe the dynamic behavior of a system, in particular the workflow # UML Use Case Diagrams - Used during requirements elicitation and analysis to represent external behavior. - Sistemin fonksiyonlarını verir yani kullanıcı hangi işlemleri gerçekleştirebilir. - **Actor:** Represent a role that is a type of user of the system. - **Use Case:** Represents a class of functionality provided by the system. - **Use Case Model:** The set of all use cases that completely describe the functionality of the system. # Actors - An actor is a model for an external entity which interacts with the system. - User, external system, physical environment - An actor has a unique name and an optional description. # Use Case - A use case represents a class of functionality provided by the system. - Uses cases can be described textually, with a focus on the event flow between actor and system. - The textual use case description consists of 6 parts: - Unique name, participating actors, Entry conditions, Exit conditions, Flow of events, Special requirements. # Uses cases can be related. - **Extends Relationship** - To represent seldom invoked use cases of exceptional functionality. (nadir durumlar, her zaman gelenekselmeyecek) - **Includes Relationship** - To represent functional behavior common to more than one use case. # Class Diagrams - Used during requirements analysis to model application domain concepts. - Used during system design to model subsystems. - Used during object design to specify the detailed behavior and attributes of classes. ## Classes - A class represents a concept. - A class encapsulates state (attributes) and behavior (operations) - Each attribute has a type - Each operation has a signature ## Instances - An instance represents a phenomenon - The attributes are represented with their values - The name of an instance is underlined # Associations - Associations denote relationships between classes. - The multiplicity of an association denotes how many objects the instance of a class can legitimately reference. - 1 to 1 association, 1 to many association, Many-to many associations. - Ex. A bank has many customer, a person may be a customer of several banks. Each customer is uniquely identified by a customerId. - **Qualifiers:** - Qualifiers can be used to reduce the multiplicity of an association. - 1'e çok ilişkidem 1 to 1 geçmek için kullanılır. - **Aggregation (Parça-bütün ilişkisi)** - An aggregation is a special case of association denoting a "consists-of" hierarchy. - The aggregate is the parent class, the components are children classes. - **Composition:** - A solid diamond denotes **Composition:** A strong form of aggregation where the lifetime of the component instances is controlled by the aggregate. - **Inheritance:** - Inheritance is another special case of an association denoting a "kind-of" hierarchy. Inheritance simplifies the analysis model by introducing a taxonomy. - **Ex. UML to Java** # Packages - Packages help you to organize UML models to increase their readability. - We can use the UML package mechanism to organize classes into subsystems. - Any complex system can be decomposed into subsystems, where each subsystem is modeled as a package. # Sequence Diagrams: - **Iteration & Condition / Creation & Destruction** - Iteration is denoted by a preceding the message name. - Condition is denoted by boolean expression in [] before the message name. - Creation is denoted by a message arrow pointing to the object. - Destruction is denoted by an x mark at the end of the destruction activation. # CH 4 Requirements Elicitation - 2 questions need to be answered: 1. How can we identify the purpose of a system? 2. What are the requirements, what are the constraints? 3. What is inside, what is outside the system? - **Requirements Elicitation** - Definition of the system in terms understood by the customer and/or user. (Requirements specification) - **Analysis** - Definition of the system in terms understood by the developer. (Technical specification, "Analysis Model") - **Techniques to elicit requirements:** - Questionnaires, Task Analysis, Scenario, Use cases - Anketler, 6sigma analiz, Senaryeler, Kullanım durumu. - **Scenario:** Sistemin nasıl kullanılacağının bir senaryosu. Son kullanıcının bilgisinden ele alınır. - After the scenarios are formulated: - Find all the use cases in the scenario. - Describe each of these use cases in more detail. - The set of all we cases is the basis for the Functional Model. - Client and end users have application domain knowledge. - Developers have solution domain knowledge. - **Requirements Specification vs Analysis Model:** - Both are models focusing on the requirements from the user's view of the system. - The requirements specification uses natural language. - The analysis model uses a formal or semi-formal notation - **Types of Requirements:** - **Functional Requirements:** Sistemin ve çevresi etrafındaki fonksiyonları belirtir. - **Nonfunctional Requirements:** Fonksiyonların kalitesi ile ilgili. - **Constraints:** Müşteri veya geure tarafından dayatılan şeyler. - **Pseudocode:** Disede geçiyor. - **Functional Requirements:** - Describe user tasks which the system needs to support. - Phrased as actions. - **Non-Functional Requirements:** - Describe properties of the system or the domain. - Phrased as constraints, negative assertions. - **FURPS+** - **Functional:** - **Usability:** Kullanım kolaylığı ile ilgili: Arayüz, kullanımın kolay öğrenilebilmesi. - **Reliability:** Güvenilirlik, Güvenlik: Availabilty - **Performance:** Response Time, ölçeklenebilirliği (Scalability) 7/24 online - **Supportability:** Desteklenebilirlik, Yeni yöntemlerin uyarlanabilmesi. - **Constraints:** - **Pseudo Requirements (Constraints):** - **Implementation Requirements** - **Interface Requirements** - **Operations Requirements** - **Packaging Requirements** - **Legal Requirements** - **Requirements Validation:** - Genellikle gereksinimlerin ortaya çıkarılmasından sonra veya analizden sonra gerçekleştirilen bir kalite güvence adım. - **Correctness** -> Doğru olması - **Completeness** -> Müşterinin beklediği her şey şahısda mı?(fank) - **Consistency** -> Çelişki olmaması gerekiyor. (Requirements) - **Clarity** -> Yoruma açık olmaması gerekiyor. - **Realism** -> Belirlenen süre ve zamanda implement olması gerekir. - **Traceability** -> İzlenebilirlik; bileşenlerin karşılığı olmalı. - **Verifiability** -> Doğrulanabilir; ölçeklenebilir olmalı. - **Different Types of RF:** - **Greenfield Engineering:** Sıfırdan sistem yerme - **Re-Engineering:** Mevcuttaki sistem üzerine - **Interface Engineering:** Varolan sistemi, başka bir sistemde çalıştırma - **Functional Modelling** - **Use Case Model:** The set of all use cases, specifying the complete functionality of the system. - **Use Case Associations** - Dependencies between use cases are represented with use case associations. - Associations are used to reduce complexity. - Refine abstract use case associations. (Includes, Extends, Generalization) - **Types of use case associations:** - **Include:** - It has 2 purposes - **Functional Decomposition:** - Bir use case'in içerisindeki iş yükünü azaltmak için kullanılır. - Büyük alt use case'lere bölünür, caınclude>> ile bağlanır. - **Reuse:** - Aynı fonksiyonu, başka use ceselerde kullandığında olur. - **Extend:** - Use case'i genişletmek, ona ek özellikler kazandırır. - **Generalization:** - Bir işlemin herhangi bir alt parçasına denir. - Use case de "A" işareti ile gösterilir. # CH 5: Analysis: Object Modeling - Sistemin statik yapısını verir: Application domain'i, objeleri neler? Attributeler ve operationlar neler? Objeler arası ilişkı yani associationlar neler? Bunları verir. - **Object Modeling + Dynamic Modeling** --> Analysis Model. - Analysis focuses on producing a model of the system which is correct, complete, consistent and verifiable. - **There are Different Types of objects** - **Entity Objects:** Represent the persistent information tracked by the system. - **Boundary Objects:** Represent the interaction between the user and the system. - **Control Objects:** Represent the control tasks performed by the system. - **Object Types allow us to deal with Change** - Having 3 types of objects leads to models that are more resilient to change. - The interface of a system changes more likely then the central. - The way the system is controlled changes more likely then entities in the application domain - Object types originated in Smalltalk - Entity - Model View, Controller (MVC) - Boundary - - Control - Amacımız ileride daha kolay değiştirilebilir bir dizayn oluşturmak - **Generalization and Specialization:** - **Generalization:** Is the modeling activity that identifies abstract concepts from lower-level ones. Reverse-Engineering - **Specialization:** Is the activity that identifies more specific concepts from a high-level one. from scratch (sıfırdan) - **Finding Participating Objects in Use Cases** - Ames Sistemdeki objeleri tespit etmek Bunun için use ceselerdeki event flowları kullanacağız. - **Nouns:** Are candidates for objects/classes - **Verbs:** Are candidates for operations. - This is also called Abbott's Techniques. - After objects/classes are found, identify their types. - Real word entities --> Entity object - Real word procedures --> Control object - Interface artifacts --> Boundary object - Use other knowledge sources. - **Application knowledge:** Son kullanviciler ve uzmenler, uyguma alanının sınırlarını bilir. - **Solution knowledge:** Gözlem elenındakı soyutlemeler. - **General world knowledge:** Genel bilginiz ve sezginiz. - **Who uses Class Diagrams?** - Purpose of class diagrams: The description of the static properties of a system. - **The main users of class diagrams:** - The application domain expert uses class diagrams to model the application domain during requirements elicitation and analysis. - The developer uses class diagrams during the development of a system during analysis, system design, object design and implementation. - **Who doesn't use class diagrams?** Client and End-user. - **Developers have different Views on Class Diagram:** - According to the development activity, a developer plays different roles: Analyst, System Designer, object Designer, Implementor. - Each of these roles has a different view about the class diagram. - **Analyst:** The analyst's purpose is to establish the relationship **between the end-user and the developer.** (solution domain bilgisine sahip). Application domain classlarının tespit edilmesine bakar. The analyst isn't interested in detail signolure of operations in solution domain classes - **Designer:** The designer focuses on solution of problem (solution domain). Associations between classes are now references between classes in solution domain. The designer describes interface of subsystems and classes. - **Implementor:** Class Implementor: Class'in metodlarını gerçekleştirecek kişi. - **Class Extender:** Başka birinin implement etmiş olduğu class'ı inheritance ile extend edecek olan kişi. - **Class User:** Başka birinin implement etmiş olduğu class'ı kendi problemi çözerek kullanacak kişi. - **Analysis Model vs Object Design Model:** - **The analysis model** is constructed during the analysis phase. - **Main stake holders:** End users, customers, analysist - **The class diagrams contain only application domain classes.** - **The object design model** is creating during the object design phase. - **Main stake holders:** Class specifiers, Class Implementors, Class users. - **The class diagrams contain application domain as well as solution domain classes.** - The analysis model is the basis for communication between analysts, application domain experts and end user - The object design model is the basis for communication between designer and implementors. - **Dynamic Modeling** - Objelerin mesajlaşma süreci nasıl işliyor? - Yeni objeler keşfedilebilir. - State, Sequence ve Activity diagram kullanılır. - **Finding Participating Objects** - An event always has a sender and a receiver. These are the objects participating in the use case. - **Sequence Diagram:** - **Layout:** - 1st column: Should be the actor of the use case - 2nd column: Should be a boundary object. - 3rd column: Should be the control object. - **Creation of objects:** - The control objects create the boundary objects. - **Access of objects:** - Entity objects can be accessed by control and boundary objects. - Entity objects shouldn't access boundary or control objects. - **UML Interaction Diagrams:** - 2 types of interaction diagrams. - **Communication Diagram:** - Shows the temporal relationship among objects. - Good for identifying the protocol between objects. - Doesn't show time. - Position of objects is identical to the position of the classes in the corresponding UML class diagram. - **Sequence Diagram:** - Describes the dynamic behavior between several objects over time. - Good for real time specifications. - **State Chart Diagram vs Sequence Diagram:** - State chart diagrams help to identify: - Changes to an individual object over time - Sequence diagrams help to identify: - The temporal relationship between objects over time. - Sequence of operations as a response to one or more events. # CH 6 System Design 1: System Decomposition - **Why is Design so Difficult?** - **Analysis:** Focuses on the application domain. - **Design:** Focuses on the solution domain. - Solution domain is changing very rapidly. ## How the Analysis Models Influence System Design? 1. **Design Goals (Tasarım Hedefleri) (Non-functional Req)** - Yeni özellikler eklenebilir (Developerler tarafından). - Birbiriyle çelişen durumları tespit etme. 2. **System Decomposition (Sistemi küçük modüllere bilmek) (Func. Model)** - Çeşitli mimariler kullanarak sistemi modüllere ayırmak. - **Coherence/Coupling:** 3. **Concurrency (Dynamic Model):** - Sistemde eş zamanlı olarak çalışabilecek şeyler. 4. **Hardware / Software Mapping (Object Model):** - Subsystemler belirlendikten sonra, onların hangi sistem üzerinde çalışacağının kararının verilmesi. 5. **Data Management (Object Model):** - Belirlenen objelerin hangisinin kalıcı olarak saklanması gerekiyor. Nasıl bir database'de saklanmalı. 6. **Global Resource Handling (Dynamic Model):** - Objeler erişim yetkisi, hangi actor hangi objeye erişecek? 7. **Software Control (Dynamic Model):** - Yazılımın akış modeli nasıl olacak? 8. **Boundary Conditions (Functional Model):** - Düşünülmeyen boundary conditions örneğin sistemi kim açıp, kapatacak, back-up işlerini kim yapacak. - Stakeholders have different Design Goals. ## Subsystem and Services: - Subsystem: - Collection of classes, associations, operations, events that are closely interrelated with each other. - Birbirleriyle ilişkili class/orieler 1 subsystem altında toplanacak. - The classes in the object model are the "seeds" for subsystem. - Her subsystemin kendine has görevleri olacak..